RE: Values to use for a salt?

• Previous message: Brian Hatch: "Re: Values to use for a salt?"
• Maybe in reply to: Craig Minton: "Values to use for a salt?"
• Next in thread: Brian Hatch: "Re: Values to use for a salt?"
• Reply: Brian Hatch: "Re: Values to use for a salt?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: Michael.Wojcik@microfocus.com, secprog@securityfocus.com
Date: Fri, 19 Dec 2003 11:39:33 -0600

Wow. Lots of replies =) I picked the ones that seemed representative.
Before starting, I have to reiterate, I am *not* a cryptographer so do *not*
use anything I've suggested here without first running it past someone who
has the proper experience.

Multiple people continue to refer to how Unix performs its hashing or uses
salt and then point to various lines that are incorrect. I do not disagree
with those assertions, except that I'm not referring to Unix password
hashing.
>>To make the point more relevant,
consider authentication for a web application.

>From: Brian Hatch <bri@ifokr.org>
....
>The first part listed above, 'increased randomness ... of a password's
>hash' doesn't make much sense to me. If you mean the hash will
>be more random, then you have a bad hash function.

Most systems that I'm aware of use the same key, I presume for speed
reasons. Since the key is added to the password before hashing it seems to
me that it only serves to make the password more random. So "MyPassword"
becomes "1234MyPassword". This has only made the password more random and
generates the same hash code for every password that is "MyPassword".

>From: "Richard M. Conlan" <kaige@embracetherandom.com>
....
>What? The salt value is not supposed to be kept secret, per se. In fact,
>it is typically stored and transmitted as plaintext.

I allowed myself to digress from password salt into HMAC. Also, thanks for
correcting my inaccurate comparison of salt with HMAC. Salt is a MAC, not
an HMAC. But I disagree that salt is not supposed to be kept secret, even
if that is how some (many?) systems do it.

FIPS 113 is one of the standards that covers MAC, and states "It is
therefore crucial that keys be protected so that their secrecy is
preserved...." Whether it's routine or not, transmitting the salt in the
clear clearly doesn't preserve their secrecy.

>From: Michael Wojcik <Michael.Wojcik@microfocus.com>
....
>Not unless the random salt happened to be the same for both. Ensuring
>unique salt does not scale well and becomes unnecessarily complex

Exactly my point. Using the same salt over and over results in the same
hash code for the same 2 passwords (at least, it better!). If I see 15 hash
codes that are all the same, that's the one I'll try to brute force. It's
probably simple (why else would so many people have the same password) and
once cracked I can spread my logins around to avoid notice/wreck more
havok/steal more.

>So you're assuming an attacker who has the password hashes but not the
>salt.

No, I'm ensuring that the same 2 passwords do not produce the same 2 hash
codes.

>Password hashes fall to dictionary attacks because of poorly-chosen
>passwords and too little salt.

Couldn't agree more and one benefit of using salt is that it creates more
random passwords. But if the same salt is used for each password, the
attacker can easily identify each person that used the same password. As I
mentioned above, those repeating passwords are probably the bad ones, too.

>Nope. Just the public key, because they can encrypt their precomputed hash
>dictionary with it and compare the result.

Maybe a better way to phrase it is to use 1 asymmetric key for the
encryption and the other for the decryption. Neither would be public. I
used the term because Public/Private is typically the name asymmetric keys
are given. Still, it raises an excellent point I hadn't considered when I
wrote the message. Crack one weak password and then precompute a hash of
that password and the hash of each user's name to spot identical passwords.
The attacker wouldn't have an easy way to spot which passwords are used by
multiple people before hand, but that's little consolation for the reason
you provide below.

>An attacker who knows the username would know the salt for the
>corresponding
>password. Not good. Random salt is the only safe way to go.

You're right. My attempted short-cut of using the hash code of the username
wouldn't suffice.

Scott

_________________________________________________________________
Grab our best dial-up Internet access offer: 6 months @$9.95/month.
http://join.msn.com/?page=dept/dialup

• Previous message: Brian Hatch: "Re: Values to use for a salt?"
• Maybe in reply to: Craig Minton: "Values to use for a salt?"
• Next in thread: Brian Hatch: "Re: Values to use for a salt?"
• Reply: Brian Hatch: "Re: Values to use for a salt?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]