Arch Linux

If we were to switch, I think we should take note from OpenBSD and use blowfish. (OpenBSD uses blowfish by default for system passwords.)

Any decision on this?

This is just a question of default, right? So existing passwords in other forms would stay around.

I'm not sure I see much downside to switching to something more secure than md5.

Has anyone compared blowfish to sha512, on the merits, for this particular application?

Doesn't blowfish add libxcrypt as a dependency (according to archwiki, at least)? For a workstation user, it is unlikely that blowfish is more beneficial compared to sha512, while implementing the latter is simpler...

For password storing (where collision attacks are irrelevant, only preimage attacks matter), it is unnecessary to have such large digests.
In fact, MD5 has only shown weaknesses in regards to collisions: there are no known feasible preimage attacks on it (i.e. your passwords are still safe).
For better security, I would recommend switching to SHA1 or one of the finalists of the SHA3 competition, when they are announced, in August.
http://csrc.nist.gov/groups/ST/hash/sha-3/

although I like blowfish better for this purpose I don't think it's worth the added dependency since sha512 is included with glibc. I would go with a finalist of sha3 also if they were included with glibc.

This is getting more urgent. MD5 collisions can be produced in under an hour on a modern machine. I have changed over to sha512 and would recommend this as the default.

Again, collision attacks are irrelevant here since you don't have a preimage to begin with: in fact, the security of shadow relies on an attacker not being able to find a preimage. For this, MD5 is still (for now) standing: http://en.wikipedia.org/wiki/Md5#Preimage_vulnerability
Naturally, we will have to switch to SHA256 (possibly even SHA512) at some point to ensure security in the long term.

What is, however, subject to collision attacks, are the md5sums arrays of PKGBUILDs and %MD5SUM% entries in repository databases. The former can be replaced by sha*sums by the maintainer, but the latter is hardcoded in repo-add and libalpm.

what does pkgbuild have to do with passwords? which is what this bug is about, really all this bug is about is a default setting.

Vote yes, is complicated it change?

Shouldn't this request be directed at upstream?

As far as I can tell we are not altering the default from upstream, which is the way it should be (IMHO).

@tomegun 7 of may 2011 continue using md5 in fresh install /etc/pam.d/passwd. in fresh install using net install
So.. some body change this some day?, is a good option use sha512, fedora, ubuntu etc use sha512 by default

@synflag: I missunderstood the issue earlier. This bug should not be against pam (we don't select any algorithms in the pam package), but against shadow. I agree that it might make sense to change to sha512 by default. However, it probably is not very urgent as mentioned before.

@tomegun

i agree with you regarding is not urgent, but if, from at least 3 years ago some simplier distros (fedora ubuntu debian mint etc) are using it, why not us?

Good idea. Debian have this by default (you should change passwords after upgrade).

This is very important for me, because i want to use the login password for disk encryption too...
(but i'd like to use home encryption password for loging in completely without shadow in the future)

Here are some tips for "early" adopters: https://wiki.archlinux.org/index.php/SHA_password_hashes

I can also suggest to set some smart default number of rounds to make passwords even more secure...

On my 1.8Ghz Sempron laptop i am using (it takes just the right time to login to not bother me):
password required pam_unix.so sha512 shadow nullok rounds=99999
On quadcore 2.40GHz Xeon server i am using (it takes around second to login):
password required pam_unix.so sha512 shadow nullok rounds=999999
On 900MHz Pentium III personal NAS (with slow i386 debian) i am using (it takes around second to login):
password required pam_unix.so sha512 shadow nullok rounds=65536

Which means that rounds=16384 (which is 2^14 BTW) should be fast enough even on quite slow machines...

Well, I would say that 2^16=65536 rounds is OK as a default. On a P4 3.2 GHz it takes ~0.3 sec to login. The number of rounds should be entered both in /etc/pam.d/passwd and /etc/login.defs, like "SHA_CRYPT_MIN_ROUNDS 65536", correct?

Key derivation is a terrible idea: would you like to wait several seconds on a low-resource (think atom or older) processor to login?
It only annoys attackers as much as it annoys users: this is a bad approach to addressing the issue of people choosing poor passwords.

What's the problem with MD5? Why would we ever want to break compatibility with other systems? People are free to switch hash functions in their configurations, and as Gaetan says, the best security is still to choose good passwords and forbid remote password authentication if really needed. If anybody has access to your shadow file, then you are probably in big trouble already.

lisaev: ~0.3sec on P4 3.2 GHz = ~1sec on 1GHz (even slower systems are not so uncommon) which can be too much...
remy: well i am using this just because i am using pam_encfs and try_first_pass. btw if you are compatible with debian you are compatible with everything :)

BTW there is little issue with SHA512 on 64b archlinux:

on i686 i can use john to crack it (using crypt())
on x86_64 i can't :(says it's generic crypt() but unsupported)
sometimes i'd like to check if all users are using relatively strong passwords and this makes it unusable...

No, high CPU freq. does not mean more performance. My amd sempron 1.8ghz is even faster on login (below my reaction threshhold). Besides, most users login to a DE, which would take much longer to load. And, you don't authenticate 69 times a day, do you?

But I agree with Remy -- defaults do not matter if you know what you want...

> you don't authenticate 69 times a day, do you?

ever heard about sudo or xscreensaver? :)

anyway... archlinux is quite lightweight, so i can imagine someone using it on some quite old (or "quite embeded") machine as router, NAS or whatever...

MD5 is only okay if we use enough rounds(don't know if we do). Ubuntu,Debian,OpenSuse,etcpp. all use other algos.

Andreas: rainbow tabless? i've completely forgoten about them... well... then we should use different number of rounds than other distros (so no one will be able to use rainbow tables generated for other distro using it's number of rounds...)

I really don't know if we even use more than one md5 round. In glibc you can find a standard of 5000 rounds for sha512/etc. but not for md5. (but I took just a quick look into md5-crypt.c and sha512-crypt.c). But if we change rounds, we can also change it to sha512 - old pws will be useable, even if they are md5.
The number of rounds itself is not so important, because the pws are salted(random salt), but it is less difficult to generate a rainbow table if there are only few rounds or even no extra rounds.
The University of Amerstam showed that (GPU powered) the efficiency falls from 3 Billion (md5) to 30 Million(sha512) hashes per second. That means, for example, a password like "P4ssW0r7" is computed in 14 hours (md5 hash) or 58 days (sha512 hash).

BTW crypt() implementation of salting uses 8 chars long salts for SHA512 (for MD5 only 2 chars)
i wonder if its md5(salt.pass) or md5(md5(salt).pass), because the second approach can be even more secure than vast number of rounds...

That remark doesn't make any sens to me.

I guess we could change to a more secure default. Just keep in mind that you can reconfigure your systems the way you want them, a default is something you must use.

If you change it, I would prefer changing it to sha512 without any round paramter (it uses default 5000 rounds then), see here for more: https://wiki.archlinux.org/index.php/SHA_password_hashes
That should be fine and it is only a small change.

@Thomas Bächler, agreed, everyone is free to change the configuration, but a lot of people will let this kind of stuff by default.
When we talk about security, default configurations should provide a good protection by default for the novice user. (Even if that user is not a novice in computer usage).
Nobody can think on everything, and that's why default configurations are there for.

IMHO, I do agree that this must be changed. MD5 can not be called secure, it has been proved many times.

I still don't understand what scenario you are trying to protect/secure against.

In industry the problem is not if it is necessary or not. It must be secure.
People who loose their laptops for e.g. or have their laptops stolen. Even with a good password, MD5 is not secure.

Use case :
Let's admit that the user has an encrypted partition and so on. (working for his company, his company has done the necessary for that).
He likes Archlinux, all installed by the IT team, but the team didn't know that Archlinux only used MD5 (they simply forget to check that information).
Okay he got his computer stolen by X or Y interested in his computer and research.

How can you say that his computer is still safe (it will never be, we know that) when you still have an MD5 based log in process ?
I'm running Archlinux, and I've to run an antivirus. (I don't trust it personally, but that's the way the company where I work are protected. They have to be PCI and so they are) I had to change from MD5 to SHA and lot of other security "tricks&fixes".
It was simply mandatory.

In this case I won't think like I would for a home device. Professionals must have a device that they can trust.
Log in and log out must be secured operations. Even if it take 1sec more to do it.

After all Archlinux is a distribution like another one, if now the distribution will start to have dark spots (even if it's little spots) some people might just stop using / allowing it.

In my case of use I bet I MD5 is enough, I'm quite sure that nothing will happen but I can't guarantee it.
The question is, should Archlinux change this behavior ?
IMHO, yes. And most comments here tend to think the same way.

Best regards.

A partition encrypted with a password which is *stored* on the disk (even in hashed form) does not look secure at all to me. In any case, I support switching to a SHA-based hash by default, and I do not support using a fancy multiple rounds scheme by default.

@Rémy Oudompheng No it doesn't :)
Forgot to mention it, but I also don't support multiple rounds scheme by default.

2Rémy: well. encryption software is able to detect if the entered passphrase is correct or not. some of them are using hashes, some of them are using some header that is checked after being decrypted, etc... it has been proved secure for strong passwords so we need used hash algo to be equally strong to the used encryption.

I strongly hope your encryption software does not use MD5 for its hashes. I still don't see how the hash algorithm used for /etc/shadow can be possibly relevant for encryption purposes. Even if the hash algorithm is weak, there is no possibility that it can be used to recover the exact password unless you chose it in the dictionary.
Encryption software has nothing to do with the present discussion.

2Rémy: No it's not using MD5 and that is why i do not want to store the same password using MD5 in /etc/shadow. It's not so sure if you are using passwords made from ASCII characters (:-) and used password is shorter than MD5 sum string.

I am using same password for encryption and for loging-in and i still believe that it's strong enough to not be cracked when i don't use MD5 in /etc/shadow

This is not a pam issue, but shadow corrected the title.

I've set the default hash to sha512 and left the number of rounds at the default of 5000. The wiki page is awfully misleading -- login.defs never needs to be touched as ENCRYPT_METHOD is only read when login is not linked against PAM (something every distro does).

in file chpasswd: 512 instead of sha512