# Password hash security



## kpa (Jun 9, 2012)

http://lists.freebsd.org/pipermail/freebsd-current/2012-June/034515.html.

FreeBSD still defaults to MD5 password hashes that are known to be insecure now, consider changing the default to SHA512 as suggested in the mailing list thread I linked.

 You need to update the /etc/login.conf.db with cap_mkdb(8) after editing /etc/login.conf.


`# $EDITOR /etc/login.conf`


```
...
default:\
        :passwd_format=sha512:\
...
```

`# cap_mkdb /etc/login.conf`

Existing password hashes are changed to SHA512 the next time the password is changed with passwd(1). New users created after this change will have SHA512 password hashes automatically.


----------



## Uniballer (Jun 9, 2012)

I know there is a way to create MD5 hash collisions (see the gloss at http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities).  It is unclear to me if this has been shown to be a problem for password hashing, because the common wisdom  is that a sufficiently long salt will prevent hash reversal.

So my question is, if switching the default password hash algorithm from MD5 to SHA-512 would improve password security to a measurable extent why has it not already become the default for new installations?  Or is the consensus that as long as people pick weak passwords it makes no difference because a dictionary attack is too easy?


----------



## UNIXgod (Jun 9, 2012)

I read about this on /.

http://tech.slashdot.org/story/12/0...ssword-scrambler-is-no-longer-considered-safe

IIRC this is the issue that linkdin and others suffered with "hacked" accounts.


----------



## Lowell (Jun 12, 2012)

LinkedIn didn't use salts at all.


----------



## SirDice (Jun 13, 2012)

They didn't use MD5 either, the LinkedIn hashes are SHA256.


----------



## kpa (Jun 13, 2012)

It does not matter what the hash algorithm is if you don't use salts, same passwords will always map to same hashes.


----------



## SirDice (Jun 13, 2012)

kpa said:
			
		

> It does not matter what the hash algorithm is if you don't use salts, same passwords will always map to same hashes.



Absolutely true. But at least they don't have to worry about MD5 collisions


----------



## Nukama (Jun 14, 2012)

Usage of fast hashing algorithms for storing passwords is problematic. And salts are only adding a pinch of entropy. 

blf-hashed passwords in /etc/master.passwd and /etc/spwd.db might be better suited for password storage. Not sure if FreeBSD uses plain Blowfish or a similar approach like bcrypt [1] used in OpenBSD crypt [2] and derived crypt_blowfish [3]. Further readings on password security at [4].

Hashing collisions- Why not use several *different* hashing functions to ensure integrity? (Like in the good old time when ports used md5 and sha256 to check integrity of distfiles)

[1] http://codahale.com/how-to-safely-store-a-password/
[2] https://en.wikipedia.org/wiki/Crypt_%28Unix%29#Blowfish-based_scheme
[3] http://www.openwall.com/crypt/
[4] http://www.openwall.com/presentations/PHDays2012-Password-Security/mgp00001.html


----------



## tsnow20 (Jun 14, 2012)

Correct me if I'm wrong, but you won't be able to use SHA256 / SHA512 as your default hash in anything prior to FreeBSD 9.

If I am wrong, I'd love to know how to do it (I'm on 8.2-RELEASE).


----------



## kpa (Jun 14, 2012)

If SHA hashes are not supported you can use blowfish.


```
default:\
        :passwd_format=blf:\
```


----------



## kpa (Jun 15, 2012)

Nukama said:
			
		

> Hashing collisions- Why not use several *different* hashing functions to ensure integrity? (Like in the good old time when ports used md5 and sha256 to check integrity of distfiles)



The change to use only sha256 for checking distfiles was well founded one decision, md5 was already known to have weaknesses and use of sha256 alone was sufficient to guarantee the integrity of distfiles. If you have anything to prove that sha256 has similar weaknesses that can be exploited in practice I'd like to hear about them.


----------

