PAM, delays and hashes

I was reading Planet FreeBSD the other day and I noticed an intersting
post
about PAM. It talks about a couple of old vulnerabilities in OpenSSH that allows to gather information about a system depending on the timing used for authentication.

As it turns out, the issues have been fixed a long time ago in OpenSSH portable so Gentoo is far from being affected by those, but the interesting part is that the issue is caused by the delay that Linux-PAM implements by default on failed login attempts.

As it turns out, I wonder now if there is a reason at all we enable that. I wonder because even if OpenSSH is fixed, similar problems may apply to other remote services that use PAM for remote authentication. One option I see is to enable the delay only on local logins, but that would require a bit of duplication in pambase, as it is. Or maybe it could be implemented through a pam_delay module.

The nice thing about pambase is that it takes very little time to actually get this updated, as I need just to update pambase package rather than the whole Linux-PAM, which is a mess to update.

And just to show one good thing about pambase, in the past days I added an sha512 USE flag to the package, with that enabled, the latest Linux-PAM version is brought in and SHA512 password hashing is enabled. This means that rather than using MD5 for encrypting the passwords in the shadow file, once you’ll change them they’ll be saved using SHA512. The advantage is that SHA512 should be more secure than MD5 (which I think is, nowadays, considered not secure anymore).

Before version 1.0.1 of Linux-PAM to achieve similar goals you had a few different options. You could have used pam_unix2 (which I think was used or developed by SUSE) or you could have used pam_sha512, otherwise you could have been using tcb to use blowfish encryption.

Now that the same result can be achieved with a single USE flag (and a single change to the PAM configuration), the sys-auth/pam_sha512 package is masked for removal, one less package to maintain in tree.

So at the end, pambase is coming along nicely, as I was hoping it would. This should be a very good way to handle future options and other increased securities without having to update the code behind at the same time.

Exit mobile version