RE: Values to use for a salt?

> From: Ton Geurts [mailto:geurts@xxxxxxxxxx] 
> Sent: Wednesday, December 17, 2003 6:01 AM

> I always store my UID, password in a database with a timestamp. 
> My password hash is md5(timestamp & md5(password)). That way 
> every hash has a unique salt that changes with every password
> change. It makes precomputed dictionaries virtually useless.
> Unless you have direct database access.

Timestamps are often predictable within a range.  If I suspect that Alice
has changed her password today, and I know the timestamp has second
resolution, then I only need to check 86,400 timestamp values - and I can
probably narrow it down further.  That's in the 16-17 bit range, which is
better than the classic Unix salt (which was, what, 1024 unique values or 10
bits?), but not great considering the kinds of storage and processing power
commonly available today.

If I can perform traffic analysis on a remote password-changing system and
guess when a user has changed his password within a few seconds, a timestamp
salt is only a few bits and has very little strength.  (If I can do enough
traffic analysis to have a decent chance of predicting when a user will
change his password in the future, I can precompute a dictionary for the
likely salt values.)

I don't understand this resistance to random salts, which are easy to
provide and have none of these weaknesses.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus