linux

In the last few years, we’ve been seeing some significant changes in the suggestions that security experts are making for password security. While previous guidance increasingly pushed complexity in terms of password length, the mix of characters used, controls over password reuse, and forced periodic changes, specialists have been questioning whether making passwords complex wasn’t actually working against security concerns rather than promoting them.

Security specialists have also argued that forcing complexity down users’ throats has led to them writing passwords down or forgetting them and having to get them reset. They argued that replacing a password character with a digit or an uppercase character might make a password look complicated, but does not actually make it any less vulnerable to compromise. In fact, when users are forced to include a variety of characters in their passwords, they generally do so in very predictable ways. Instead of “password”, they might use “Passw0rd” or even “P4ssw0rd!”, but the variations don’t make the passwords significantly less guessable. People are just not very good at generating anything that’s truly random.

To read this article in full or to leave a comment, please click here

Deploying password quality checking on your Debian-base Linux servers can help to ensure that your users assign reasonable passwords on their accounts, but the settings themselves can be a bit misleading. For example, setting a minimum password length of 12 characters does not mean that your users’ passwords will all have twelve or more characters. Let’s stroll down Complexity Boulevard and see how the settings work and examine some settings worth considering.

First, if you haven’t done this already, install the password quality checking library with this command:

apt-get -y install libpam-pwquality 

The files that contain most of the settings we’re going to look at will be:

To read this article in full or to leave a comment, please click here

In the last few years, we’ve been seeing some significant changes in the suggestions that security experts are making for password security. While previous guidance increasingly pushed complexity in terms of password length, the mix of characters used, controls over password reuse, and forced periodic changes, specialists have been questioning whether making passwords complex wasn’t actually working against security concerns rather than promoting them.

Security specialists have also argued that forcing complexity down users’ throats has led to them writing passwords down or forgetting them and having to get them reset. They argued that replacing a password character with a digit or an uppercase character might make a password look complicated, but does not actually make it any less vulnerable to compromise. In fact, when users are forced to include a variety of characters in their passwords, they generally do so in very predictable ways. Instead of “password”, they might use “Passw0rd” or even “P4ssw0rd!”, but the variations don’t make the passwords significantly less guessable. People are just not very good at generating anything that’s truly random.

To read this article in full or to leave a comment, please click here

Deploying password quality checking on your Debian-base Linux servers can help to ensure that your users assign reasonable passwords on their accounts, but the settings themselves can be a bit misleading. For example, setting a minimum password length of 12 characters does not mean that your users’ passwords will all have twelve or more characters. Let’s stroll down Complexity Boulevard and see how the settings work and examine some settings worth considering.

First, if you haven’t done this already, install the password quality checking library with this command:

apt-get -y install libpam-pwquality 

The files that contain most of the settings we’re going to look at will be:

To read this article in full or to leave a comment, please click here

Linux system administrators should be on the watch for kernel updates because they fix a local privilege escalation flaw that could lead to a full system compromise.

The vulnerability, tracked as CVE-2017-6074, is over 11 years old and was likely introduced in 2005 when the Linux kernel gained support for the Datagram Congestion Control Protocol (DCCP). The problem was discovered last week and was patched by the kernel developers on Friday.

The flaw can be exploited locally by using heap spraying techniques to execute arbitrary code inside the kernel, the most privileged part of the OS. Andrey Konovalov, the Google researcher who found the vulnerability, plans to publish an exploit for it a few days.

To read this article in full or to leave a comment, please click here