RE: Values to use for a salt?

From: Michael Wojcik (Michael.Wojcik_at_microfocus.com)
Date: 12/17/03

  • Next message: Chris Alfeld: "Re: Values to use for a salt?" 
    To: "'secprog@securityfocus.com'" <secprog@securityfocus.com>
Date: Wed, 17 Dec 2003 09:58:15 -0800

    > From: Ton Geurts [mailto:geurts@vanveen.nl]
    > 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
  • Next message: Chris Alfeld: "Re: Values to use for a salt?"