On Mon, Jan 23, 2012 at 6:30 AM, Kevin Chadwick <ma1l1ists@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