[arch-general] Upgrading password hashes

[C Anthony Risinger]

On Mon, Jan 23, 2012 at 6:30 AM, Kevin Chadwick <ma1l1ists at yahoo.co.uk> wrote:
> On Mon, 23 Jan 2012 13:09:33 +0100
> Tobias Frilling wrote:
>
>> I know next to nothing about bcrypt, but you can configure rounds in pam
>
> I could say similar about pam. In OpenBSD rounds are in plain sight in
> /etc/login.conf
>
> The PAM documentation I've found seems incomplete and a bit ambiguous
> especially if you edit /etc/pam.d/other and make it explicit. I've been
> wondering if that has anything to do with the Support companies that are
> so involved with Linux, with it paying to be less straight forward. Do
> you know of a good reference for PAM?

login.defs is provided by the `shadow` package, not `pam`, and details
these options:

ENCRYPT_METHOD, SHA_CRYPT_MIN_ROUNDS, SHA_CRYPT_MAX_ROUNDS

... but it's not clear that the `shadow` option to pam_unix.so honors
these values, only that pam_unix.so will "Try to maintain a shadow
based system", which sounds more like a compatibility statement.

it's important to note that bcrypt != blowfish (modified blowfish used
internally), and also understand hashing != encryption.  sha512 is a
parameter-less hash function, blowfish is a parameterized [keyed]
block cipher, and bcrypt is a blowfish-based effectively-hash-like
encryption of *known* plaintext. both hashes computationally FUBAR
your password's to infeasible realms -- blowfish the cipher cannot be
compared directly.

further:

http://stackoverflow.com/a/1561245/404019
http://en.wikipedia.org/wiki/Bcrypt

... i can't find any literature suggesting sha512 decreases your
security, and no reason to bother switching.  both are good solutions.

`man pam_unix` will give you a good overview of PAM, simply because
it's the primary module responsible for traditional, file-based login.
 in a nutshell, PAM looks at the requester's name (the binary), loads
a config with the same name from /etc/pam.d/{name}, and finally pipes
your activities through each defined modules in four groups:

account: whoa buddy, i'll need to verify {user} can even access
service {name}, first.
authentication: ooook, but are you who you claim to be?
password: uhm, if you want to update {user} creds, you'll have to go
thru me first, pal.
session: welcome masta' {user}! let me get the door when entering and leaving!

... that's about all there is to it.  normally each module must
succeed, but they can also be flagged optional, and there is a massive
number of available modules to inject at any point, from time-of-day
denial to obsure password storage devices like OTP/smart cards,
whatever, and anything else you can dream up.

-- 

C Anthony