[Discuss] salt question

[richard.pieri at gmail.com (Richard Pieri)]

Tom Metro wrote:
> % echo saltmonkey | sha1sum
> a3a686f363fb197b9688f70a392992763ff42b14  -
>
> (Yes, salt can literally be as simple as a concatenated string.)

c.f. APOP authentication authentication: combine a time stamp with 
account credentials, hash with MD5, and send that across the network 
instead of credentials.

>> So if they are not secret what is the advantage if your site is
>> exploited?
>
> To guard against use of rainbow tables.

Password salts aren't about defending accounts against rainbow tables. 
They're about making any given rainbow table useful for as few different 
accounts as possible.

Predictability of salts doesn't weaken the system. An attacker still 
requires a unique table for each unique salt. Predictable salts does 
mean that an attacker potentially has more time in advance to compute 
rainbow tables. Changing passwords on a routine basis goes a long way 
towards neutralizing this threat.


>> Also I see in PHP crypt() you don't have to supply a salt.  How does
>> that work?
>
> Same idea as the first example above. An empty string is concatenated
> (or the concatenation step is sipped).

According to the PHP manual, it depends on what underlying encryption 
algorithm is used. Also according to the PHP manual, failing to provide 
salts can lead to unpredictable results.


> Most hashing algorithms traditionally used for storing passwords were
> designed for speed of execution, like SHA1, which is opposite of what
> you want in a password hashing algorithm.

The shift from DES to MD5 in Linux and UNIX authentication systems was 
to increase the hashed key space from 56 bits to 128 bits with the 
commensurate increase in rainbow table sizes and time to compute. 3DES 
was showing weaknesses. Other candidate algorithms had patent or 
copyright issues interfering with adoption in free software. These made 
MD5 the obvious choice at the time. That it was much faster than 3DES 
was a bonus.


> There are also some people experimenting with the idea of fragmenting
> the password hash and storing it distributed among multiple servers. A
> form of Secret sharing[5]. This way if one server is breached, the
> attackers have not necessarily obtained the full hash.

"[I]f one server is breached." That's the wrong way to think about it. 
"WHEN one server is breached" is how you should be thinking. And if all 
of the shares are running the same code? One breach means the whole 
thing is about to be compromised.

I still say that the best system to date, conceptually, is 
Needham?Schroeder symmetric with time stamp on a single-purpose server 
or cluster residing in a private, hardened DMZ. The only way in is the 
authentication system itself. The only way out is the return from an 
authentication request. In other words: Kerberos. It's not easy to 
deploy, certainly, but I've yet to see anything that beats Kerberos for 
secure authentication.

-- 
Rich P.