I know arch tries to keep to upstream but their seems some discrepencies that you may or may not be aware of so thought I'd share.
The crypt man page says glibc may not support blowfish (stronger than nists recommendation) and that seems true when used via the commandline (very short output).
The arch wiki says you can use a library from AUR.
There is also a sha512 arch wiki which says you should edit pamd.d/passwd from md5 to sha512 but the default seems to already be sha512, maybe it tries both as some distros default is now sha512 so no need anymore.
It seems if you simply edit /etc/default/passwd to blowfish and reset your password, sha512 is used e.g. encrypted password beginning with $6 in /etc/shadow not $2 (blowfish) and logins work fine.
I guess the /etc/default/passwd config file may be futurised or the config written before changing to SHA which was easier to implement and the wiki is out of date with the code??
On 01/20/2012 04:32 AM, Kevin Chadwick wrote:
I know arch tries to keep to upstream but their seems some discrepencies that you may or may not be aware of so thought I'd share.
The crypt man page says glibc may not support blowfish (stronger than nists recommendation) and that seems true when used via the commandline (very short output).
The arch wiki says you can use a library from AUR.
There is also a sha512 arch wiki which says you should edit pamd.d/passwd from md5 to sha512 but the default seems to already be sha512, maybe it tries both as some distros default is now sha512 so no need anymore.
It seems if you simply edit /etc/default/passwd to blowfish and reset your password, sha512 is used e.g. encrypted password beginning with $6 in /etc/shadow not $2 (blowfish) and logins work fine.
Wouldn't that be because you did not setup blowfish properly? You cant just change passwd only to get blowfish going, according to the wiki. (Not speaking from experience)
I guess the /etc/default/passwd config file may be futurised or the config written before changing to SHA which was easier to implement and the wiki is out of date with the code??
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 was wondering when you change these settings how do you change the hash of other system users, or is that pointless and not needed? I always wondered about that. Such as user ftp or similar.
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 01/20/2012 03:04 PM, Kevin Chadwick wrote:
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.
Ahhh OK that makes more sense, at least to me. I just went through doing everything in the wiki myself for the same reason I did not want to add another AUR package just to get the feature/ability. I agree though that DES should be changed at this point.
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.
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? 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.
-----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.
On Sat, 21 Jan 2012 17:50:13 +0100 Tobias Frilling wrote:
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.
Confirmed, /etc/default/passwd does not enable sha512. It's probably a good idea and the easiest way to get SHA512 for people to reset their password *AFTER* installing PAM. Might be worth adding to the SHA512 wiki that PAM users can just do that.
Now to see if PAM supports blowfish without adding the library from AUR?, I very much doubt it!
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.
-----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
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?
-----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.
I believe that if not specified, the default number of rounds is 5000.
I edit /etc/default/passwd [0] and /etc/pam.d/password [1], to be sure and hope for the best. I also add these lines [2], taken from the Debian version of the file, to /etc/login.defs.
I've been doing this for about a year or so and I always wondered why the default in Archlinux was to use MD5 in /etc/pam.d/passwd and DES in /etc/default/passwd. I see that using DES in /etc/default/passwd is still the case.
[0] http://ompldr.org/vY2VycA [1] http://ompldr.org/vY2Vyag [2] http://ompldr.org/vY2VyeA
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.
În data de Lu, 23-01-2012 la 18:08 -0600, C Anthony Risinger a scris:
login.defs is provided by the `shadow` package, not `pam`, and details these options:
ENCRYPT_METHOD, SHA_CRYPT_MIN_ROUNDS, SHA_CRYPT_MAX_ROUNDS
These options aren't in the Archlinux version of the login.defs file, like I said in my previous message. No ideea why.
... 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.
I wonder, is there anyone still not using pam?
... i can't find any literature suggesting sha512 decreases your security, and no reason to bother switching. both are good solutions.
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.
Yeah, kinda off-topic, I know.
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.
On Mon, 23 Jan 2012 18:08:56 -0600 C Anthony Risinger wrote:
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.
Certainly not worth the effort to me right now, you might be interested or already know about this though.
"http://www.openbsd.org/papers/bcrypt-paper.pdf"
`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:
Thanks for the info. I find it time-consuming to see what is allowed and prevented with udev, pam and dbus, polkit etc.. With sudo for example, it is easy.
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...
By the way, is it possible to upgrade password hashes without an intermediate password, assuming the new/old passwords are identical?
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.
On Wed, Jul 11, 2012 at 11:16 AM, Kevin Chadwick ma1l1ists@yahoo.co.uk 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.
On Jul 11, 2012 3:06 AM, "Chris Sakalis" chrissakalis@gmail.com wrote:
On Wed, Jul 11, 2012 at 11:16 AM, Kevin Chadwick ma1l1ists@yahoo.co.uk
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.
On Thu, Jul 12, 2012 at 7:21 AM, C Anthony Risinger anthony@xtfx.me wrote:
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.
Are you sure the `auth` part is necessary? As far as I know, pam_unix accepts /all/ hash formats supported by system; the configured hash is only necessary for creating new hashes in `password`.
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.
On Thu, Jul 12, 2012 at 11:43 AM, Kevin Chadwick ma1l1ists@yahoo.co.uk wrote:
Does passwd -d work.
It does. But is is still two steps. This isn't really a problem though, just out of curiosity.
--Chris Sakalis
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.
On Thu, Jul 12, 2012 at 1:35 PM, Kevin Chadwick ma1l1ists@yahoo.co.uk wrote:
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.
Exactly. I assume the reason passwd does not allow you to set the same password, is because sometimes you have to change your password, for example on systems that have an expiration date for passwords. Choosing the same password would beat the purpose. Again, this isn't really a problem, so let's not continue this conversation on the mailing list, spamming everyone's inboxes.
Regards, Chris Sakalis
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".
arch-general@lists.archlinux.org