On Fri, 20 Jan 2012 14:17:22 -0800 Don Juan wrote:

Not sure if I am getting what you mean here but to me sounds like you did not complete what is in the wiki in regards to running blowfish, since you need AUR package and what not and it says there is more to do than change a single file to make blowfish the algo.

I know I didn't. Blowfish is stronger but I'm settled with sha512 rather than building a library and fixing any possible fallout in the future. Maybe I missed giving a piece of info. The default password is DES which is really crap and starts with $1 so simply enabling blowfish in /etc/default/passwd has enabled SHA512, you'd expect to uncomment SHA512 not blowfish. It seems for sha512 you don't have to do as much as the wiki suggests anymore.

On Fri, Jan 20, 2012 at 11:04:12PM +0000, Kevin Chadwick wrote:

Maybe I missed giving a piece of info. The default password is DES which is really crap and starts with $1 so simply enabling blowfish

DES is indeed crap, but it hasn't been the default for a long time. The $1$ hashes are salted MD5, as crypt(3) can confirm. -- Mantas M.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/21/2012 05:06 PM, Don Juan wrote:

Then if the default is that then why are default system users, such as http mail postfix and similar not displaying the $1$ on the shadow file? Also according to the wiki it says des is the default and to upgrade the hashes out of the default. Am I not understanding it correctly in the wiki, and the users that I am talking about the hashes do not matter? Sorry feel confused at the moment.

A ! or x as the hash in /etc/shadow indicates that login for these user is not permitted. (Also you may login using ssh-keys). The CRYPT setting from /etc/default/passwd is only used if pam is not enabled. If it is enabled, the used configs are in /etc/pam.d (e.g. passwd, login etc.) which default nowadays to sha512. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPGuy+AAoJEEDINPnaM7l+QGYH+we8QwHXO8OsAOEibRRAHz2j hwWnXpitJVDLuxJ406F4DtbxXLMD2addtC1tQtSvKhcLAj1Q3bGoCEETqpUaSBTh ZhZOeqBKKyP0BR980Qy3DRSHFWDkWY8ZpwgmutNj7QmmJt3NOwfdSZhzXVbqlx/u vu3BsKAwuAeIE60HbJS4Ugn8VdUlY3HSp1EW0eR2sxb2x81y/T7YW7koBk6aVCv5 6pFqO8S+tgBQnh+5bvagBWvJq1zGGTA1A9sjCEYadynqEVjIY0i5ydsLQ2J+dhUG hiWaGQu4JKBK7meAv5OBtfoewFEVQb4qYqYn1R1D4/Y1IuwTS60SW6nSO/UJrsw= =Dcl9 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/23/2012 12:59 PM, Kevin Chadwick wrote:

OpenBSDs bcrypt with configurable rounds is awesome by the way and far more secure, yet wouldn't pass PCI compliance, how dumb some of these certifications are.

I know next to nothing about bcrypt, but you can configure rounds in pam too: password required pam_unix.so sha512 shadow nullok rounds=999999 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPHU39AAoJEEDINPnaM7l+/UYH/11e5JPq2CE5yWTsNfcDFa67 R6YOJppkE+de4kYedkx0WOg6zTZ1GwQohbrFYJU7XPhNqQCGM0z5Q5bRbBJQbQee bdUJcVjtpwEFFk6+F86/ArW0N3+MLRB+v5eebzzE86JFCtES1op44sJadtsDlqgE QZFCPnKn7Pz3FxLgxW2k0jJAxA7VyLX3MgMUCgTmpqcYfq7OibFTQ+4nMQhVwmVK eUbb5Tw6DCwKG0qJrBInsEfP/nScrYd2Wew2kYmei1tVpy1LfddfJYWYuKc1sXz3 WQHKfbQ31Dp8ZhgehXdH7x3+Yuw+nmUsNpnrlBMD0RekZGvZt6wYKpkqF1xsE3M= =bXbX -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/23/2012 01:30 PM, Kevin Chadwick wrote:

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?

The rounds options is documented in pam_unix(8). If you want something along "The Sysadmins Guide to PAM" search for pam at http://www.linuxtopia.org, they have some manual from SLES, Red Hat etc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPHVZ4AAoJEEDINPnaM7l+mZIIAI1fbGJiGhnxvr1+N+I9BNPT RuGifa5BqLKDhFP9L+vSghTxRdpVXV9M/HCFpMISX77pm4g0eP7+dtfV2ZF12pa0 gOEIZcg7AFQa0KFCt2JQAJzpjgAM6ntg42RqIQNFdUWKYfHsjCMpUEdoJpDfd/Gk baGW3u8hCzYY3rbo2BYTPAnnISqLpZ6RHqiFAihB6n1lzA8587kkZRql6TxK2gr4 O+3ggwkUX57lL353kvPK2cZUfUf3cIJpsGjxHIQlltZrvhWcZN8bSzk8hwOlW9YZ jYKaqf3I49kc08ivC93OxzCVoASRm6IsURENMi9XN/9gbt2LLZPYS4hUzoXxhg0= =uJAF -----END PGP SIGNATURE-----

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

On Tue, 24 Jan 2012 03:01:09 +0200 Sorin-Mihai Vârgolici wrote:

It might be because of the FUD that OpenBSD is the only secure OS, which isn't the case; I think they still don't provide full disk encryption, of any kind.

That has next to nothing to do with security, lets not open that can of worms, we'd be here all day. -- Kc

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.

This is interesting WRT memory usage. Whether it's a reason to bother switching or coding in the first place is still debatable of course. http://www.h-online.com/security/news/item/John-the-Ripper-now-able-to-crack... -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

By the way, is it possible to upgrade password hashes without an intermediate password, assuming the new/old passwords are identical?

You can have no password at all to start with but the system doesn't know the password, only what you entered matches. You could attack the md5 but that would be a waste of energy and likely time. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On Jul 11, 2012 3:06 AM, "Chris Sakalis" wrote:

On Wed, Jul 11, 2012 at 11:16 AM, Kevin Chadwick wrote:

...

...

By the way, is it possible to upgrade password hashes without an intermediate password, assuming the new/old passwords are identical?

You can have no password at all to start with but the system doesn't know the password, only what you entered matches. You could attack the md5 but that would be a waste of energy and likely time.

I do not think that this is what Nemo is asking. If you try to set your password to the same one you already have, passwd fails with "Password unchanged" and asks you again for a new password. So, if you just want to update your hashes, you have to choose an intermediate temporary password first and then change it again to the old one.

From root shell:

# usermod -p '' myuser - repeat all users - update algo # passwd myuser - repeat all users ... hashing algorithms are, by design, one-way only. If you're desire is to update the algo in place -- without knowing the user passwords -- you're out of luck :-( However PAM, also by design, works in stacks, and thus offers a reasonable solution -- update the `auth` and `password` PAM keys to the new algo (so new passwords are read/written properly) then duplicate the `auth` key, restore the original algo, and change `required` -> `sufficient`). This would accept the old (higher in stack, sufficient) hash until that line was removed. Additionally, you'll want/need to sprinkle some `use/try_first_pass` in there to make it fluid (see man pages). Lastly, expire the users pass, thereby forcing an update/rewrite at next login. tl;dr ... passwords in shadow are prefixed with all the info needed to select the proper algo at runtime ... the above may not be needed at all, ie. there may be a more succinct method or not needed at all, but I'm unsure offhand. Sorry if terse/example-less/wrong-terminology/etc ... mobiles suck at times. -- C Anthony [mobile]

I do not think that this is what Nemo is asking. If you try to set your password to the same one you already have, passwd fails with "Password unchanged" and asks you again for a new password. So, if you just want to update your hashes, you have to choose an intermediate temporary password first and then change it again to the old one.

Does passwd -d work. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

It does. But is is still two steps. This isn't really a problem though, just out of curiosity.

Fair enough. I don't understand the reason to want to do this, am I missing something aside from why should the system stop you when it could just warn you (similar to requirements for root). When upgrading to a stronger hash I have never tested if it stops you from using the same password when the hashes are different because it matches both but I expect, that would be how it works. Is that the issue? In that usually you would expect a password change at upgrade time but on a new install that may not be a consideration. -- ________________________________________________________ Why not do something good every day and install BOINC. ________________________________________________________

On Sat, Jan 21, 2012 at 08:06:04AM -0800, Don Juan wrote:

On 01/21/2012 07:34 AM, Mantas M. wrote:

...

On Fri, Jan 20, 2012 at 11:04:12PM +0000, Kevin Chadwick wrote:

...

Maybe I missed giving a piece of info. The default password is DES which is really crap and starts with $1 so simply enabling blowfish DES is indeed crap, but it hasn't been the default for a long time. The $1$ hashes are salted MD5, as crypt(3) can confirm.

Then if the default is that then why are default system users, such as http mail postfix and similar not displaying the $1$ on the shadow file?

Because they *do not have* passwords. "x", "!" or "*" are invalid hash values, and they basically mean "password-based logins are not permitted". -- Mantas M.