Re: Hashed password secure?

From: Joris Dobbelsteen (none.of_at_your.business)
Date: 07/01/04 

Date: Thu, 1 Jul 2004 22:03:05 +0200

When not storing the salt and searching for it, doesn't this weaken the
security.

So when you are using MD5 with a 16-bit hash, doesn't this actually reduce
the complexity from O(2^127) to O(2^(127-16))?
As the server will check 2^16 possibilities?

It might prevent a simple dictionary attack (you haven't store more than
2^127 hashes anyway), but a password would be factor 2^16 more likely to be
accepted.
So IHMO this would make it less secure...

- Joris

"Matthijs Hebly" <heeb@iname.com> wrote in message
news:Xs1Ec.33374$3N6.4061@amsnews05.chello.com...
> Jarma wrote:
>
> > Is keeping password hashed by e.g. MD5 or SHA secure? I mean
verification
> > would be comparing hash values of key(password) and this hash value
would be
> > easy to obtain (= known). Hash functions are one direction funtions, but
> > would revealing password's hash value be secure? (I'm thinking of
> > brute-force method among others).
> I had an idea about this. Please comment, 'cause I couldn't find
> anything about this (maybe I didn't look hard enough):
> What if I were to salt the password with N bits and *NOT* store the
> salt? Let's say the average today PC is capable of calculating approx.
> 65,536 ($10000) hashes (i.e. SHA-1(Password+Salt)) in 1 second (let's
> just assume, it doesn't matter how much it actually is for my question).
> Let's assume we would take 16-bit Salts, based on this number ('cause we
> can store 65,536 numbers in 16 bits). Then, when the user types in
> his/her password, the PC would have to check on average 32,768 ($8000)
> hashes before concluding that the password is in fact correct, or 65,536
> to conclude that the password was incorrect. But, to avoid timing
> attacks, the PC would check all 65,536 Salts anyway. Anyway, any
> brute-force attack would take 1 second per (tried, and failed) password
> to check whether the password is correct or not.
>
> Is this b*sh*? I couldn't find anything on the internet on *NOT* storing
> salt-values. Why would one *store* the salt if it would take only 1
> second average to check whether a password is correct?
>
> Matthijs.

Relevant Pages

  • RE: Values to use for a salt?
    ... some misunderstandings of salt, hashes, and HMACs (and maybe also plug ... hashes so that the same password doesn't always produce the same hash, ... prevent the attacker using a dictionary of pre-computed hashes. ...
    (SecProg)
  • Re: Is this secure
    ... What I do in my business layer I get the salt, then I use my custom classes ... to hash the passed in password then send the Hash to a Stored Proc to ... Both the hashed password and salt are stored in the database. ... but then i'd need the salt to create a saltedhash to ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Can Kerberos be cracked??
    ... Subject: Can Kerberos be cracked?? ... A "salt" is a "random" value that is appended to the ... possible for you to dictionary-crack my password unless you know the ... >> In order to get the hash you would need to launch a brute force attack ...
    (Focus-Microsoft)
  • Re: Is this secure
    ... I use SHA1 to hash my passwords. ... Both the hashed password and salt are stored in the database. ... but then i'd need the salt to create a saltedhash to compare ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Is this secure
    ... I use SHA1 to hash my passwords. ... Both the hashed password and salt are stored in the database. ... but then i'd need the salt to create a saltedhash to compare ...
    (microsoft.public.dotnet.framework.aspnet)