Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#13591 - [shadow] Use sha512 hash for passwords for improve local security

Attached to Project: Arch Linux
Opened by Bruno Tsubouchi Yporti (yportilog) - Saturday, 28 February 2009, 07:52 GMT
Last edited by Dave Reisner (falconindy) - Monday, 28 November 2011, 13:51 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Dave Reisner (falconindy)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 42
Private No

Details

Description: SHA512 is better for protection of local passwords. Please, change the default configuration of pam/shadow for use sha512 intead of md5.

I change manually the config in /etc/pam.d/passwd to sha512 and works fine for me.



Thanks.
This task depends upon

Closed by  Dave Reisner (falconindy)
Monday, 28 November 2011, 13:51 GMT
Reason for closing:  Fixed
Comment by Thomas Dziedzic (tomd123) - Wednesday, 19 August 2009, 14:00 GMT
If we were to switch, I think we should take note from OpenBSD and use blowfish. (OpenBSD uses blowfish by default for system passwords.)
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 01 November 2009, 20:59 GMT Comment by Paul Mattal (paul) - Saturday, 06 March 2010, 20:38 GMT
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?
Comment by Leonid Isaev (lisaev) - Friday, 16 April 2010, 16:41 GMT
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...
Comment by Gaetan Bisson (vesath) - Monday, 19 April 2010, 13:36 GMT
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/
Comment by Caleb Cushing (xenoterracide) - Sunday, 16 May 2010, 14:11 GMT
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.
Comment by John H. (darkenergy) - Wednesday, 22 September 2010, 11:27 GMT
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.
Comment by Gaetan Bisson (vesath) - Wednesday, 22 September 2010, 13:47 GMT
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.
Comment by Caleb Cushing (xenoterracide) - Monday, 04 October 2010, 16:48 GMT
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.
Comment by synflag (synflag) - Thursday, 07 April 2011, 05:34 GMT
Vote yes, is complicated it change?
Comment by Tom Gundersen (tomegun) - Thursday, 07 April 2011, 06:40 GMT
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).
Comment by synflag (synflag) - Saturday, 07 May 2011, 09:57 GMT
@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
Comment by Tom Gundersen (tomegun) - Saturday, 07 May 2011, 10:19 GMT
@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.
Comment by synflag (synflag) - Sunday, 08 May 2011, 02:38 GMT
@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?
Comment by Tomas Mudrunka (harvie) - Thursday, 09 June 2011, 22:08 GMT
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...
Comment by Leonid Isaev (lisaev) - Thursday, 09 June 2011, 22:31 GMT
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?
Comment by Gaetan Bisson (vesath) - Thursday, 09 June 2011, 22:42 GMT
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.
Comment by Rémy Oudompheng (remyoudompheng) - Thursday, 09 June 2011, 22:57 GMT
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.
Comment by Tomas Mudrunka (harvie) - Friday, 10 June 2011, 00:04 GMT
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 :)
Comment by Tomas Mudrunka (harvie) - Friday, 10 June 2011, 00:32 GMT
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...
Comment by Leonid Isaev (lisaev) - Friday, 10 June 2011, 00:41 GMT
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...
Comment by Tomas Mudrunka (harvie) - Friday, 10 June 2011, 01:19 GMT
> 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...
Comment by Andreas (Evilandi666) - Wednesday, 15 June 2011, 15:37 GMT
MD5 is only okay if we use enough rounds(don't know if we do). Ubuntu,Debian,OpenSuse,etcpp. all use other algos.
Comment by Tomas Mudrunka (harvie) - Wednesday, 15 June 2011, 16:49 GMT
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...)
Comment by Andreas (Evilandi666) - Wednesday, 15 June 2011, 18:23 GMT
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).
Comment by Tomas Mudrunka (harvie) - Wednesday, 15 June 2011, 20:53 GMT
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...
Comment by Rémy Oudompheng (remyoudompheng) - Wednesday, 15 June 2011, 21:29 GMT
That remark doesn't make any sens to me.
Comment by Thomas Bächler (brain0) - Wednesday, 15 June 2011, 21:35 GMT
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.
Comment by Andreas (Evilandi666) - Thursday, 16 June 2011, 15:13 GMT
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.
Comment by yvan da silva (dlzerocool) - Sunday, 31 July 2011, 07:09 GMT
@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.
Comment by Rémy Oudompheng (remyoudompheng) - Sunday, 31 July 2011, 07:19 GMT
I still don't understand what scenario you are trying to protect/secure against.
Comment by yvan da silva (dlzerocool) - Sunday, 31 July 2011, 07:44 GMT
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.
Comment by Rémy Oudompheng (remyoudompheng) - Sunday, 31 July 2011, 08:04 GMT
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.
Comment by yvan da silva (dlzerocool) - Sunday, 31 July 2011, 08:06 GMT
@Rémy Oudompheng No it doesn't :)
Forgot to mention it, but I also don't support multiple rounds scheme by default.
Comment by Tomas Mudrunka (harvie) - Sunday, 31 July 2011, 21:53 GMT
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.
Comment by Rémy Oudompheng (remyoudompheng) - Monday, 01 August 2011, 06:11 GMT
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.
Comment by Tomas Mudrunka (harvie) - Monday, 01 August 2011, 11:08 GMT
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
Comment by Tobias Powalowski (tpowa) - Sunday, 07 August 2011, 09:53 GMT
This is not a pam issue, but shadow corrected the title.
Comment by Dave Reisner (falconindy) - Saturday, 26 November 2011, 05:51 GMT
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).
Comment by Matthias Dienstbier (fs4000) - Monday, 28 November 2011, 11:38 GMT
in file chpasswd: 512 instead of sha512

Loading...