Re: password salting

For attacker, I assume pre-computed hash tables are just not that helpful
anymore and they just assume they need to run-time each one based on the
particular hash implementation (as everyone seems to use there own these
days). So on my single cpu laptop, I can calc:

Simple Sha1 hash: 10 seconds per million guesses.
rfc2898 w/ 1000 iterations: 5.5 hours per million. Each 1000
iterations ~doubles the time.

So it is still very doable. The other problem is it scales better for the
attacker then for the attackee. So the attacker can keep adding cheap
machines to distribute the time. You can only add so many iterations to
your own security system before it becomes impracticable for responsiveness.

--
William Stacey [MVP]

"Dominick Baier" <dbaier@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:4580be63e62a8c891a79ae6a4c0@xxxxxxxxxxxxxxxxxxxxx
| Hi,
|
| i disagree - salting also helps with pre-computed hash tables which makes
| "looking up" password a matter of a select statement. Combine salt with
iterations
| to buy even more time - up to a point where it might me infeasible to
brute
| force the password.
|
| dominick
| www.leastprivilege.com
|
|
|
| > If you have the salt and the hash, the salt does not make attacking
| > your password much harder (only a tinny bit). Different salt per user
| > only forces one to crack *each password separately - even if they are
| > the same clear text password. But it does not slow the algo down much
| > if I have the salt and can infer the algo used (i.e. hash (pw + salt)
| > or hash(salt+pw)). In most cases, the attacker does not need or care
| > about all passwords, only 1. And he can run the algo all week until
| > he finds it (doing millions of iterations per minute using many
| > dictionaries and combinations, etc). So the salt does not really help
| > if it is in the clear and with the user's hash record. Additional
| > protection would be to store the salt encrypted if possible. Then I
| > can't really do a brute force attack. One could try, but good luck
| > with that on a crypto random 16 byte salt or greater.
| >
| > "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
| > wrote
| > in message news:e9Txl9zuGHA.5084@xxxxxxxxxxxxxxxxxxxxxxx
| > | I'm not sure what you mean here, Rob. Can you explain?
| > |
| > | The general recommendation is to salt your hashes, as that makes
| > them very
| > | difficult to crack brute force if they are somehow stolen. If you
| > are
| > going
| > | to salt your hashes, you have to have the salt available when you go
| > to
| > | compare the hashed value. Where would you recommend storing the
| > salt
| > | otherwise? The other standard way is in a second column in the
| > table.
| > |
| > | Joe K.
| > |
| > | --
| > | Joe Kaplan-MS MVP Directory Services Programming
| > | Co-author of "The .NET Developer's Guide to Directory Services
| > Programming"
| > | http://www.directoryprogramming.net
| > | --
| > | "Rob R. Ainscough" <robains@xxxxxxxxxxx> wrote in message
| > | news:OZzM3XzuGHA.4688@xxxxxxxxxxxxxxxxxxxxxxx
| > | > But if the source isn't secure what is the point of doing this?
| > And if
| > | > the source is secure, then there is no pointing is storing the
| > salt this
| > | > way in the first place.
| > | >
| > | > Rob.
| > | >
| > | > "Joe Kaplan (MVP - ADSI)"
| > <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
| > wrote
| > | > in message news:OVEeLjwuGHA.5056@xxxxxxxxxxxxxxxxxxxxxxx
| > | >> It really is that simple, but you would tend to do it in bytes
| > instead
| > of
| > | >> characters. The hash would be the first X bytes and the salt
| > would be
| > | >> the remaining bytes, or vice versa.
| > | >>
| > | >> If you store the value in the database as a string, make sure you
| > convert
| > | >> to Base64. Then, after you read it back out, convert back to
| > byte[]
| > with
| > | >> Base64 again and then just grab the relevant parts of the byte
| > array.
| > | >>
| > | >> Joe K.
| > | >>
| > | >> --
| > | >> Joe Kaplan-MS MVP Directory Services Programming
| > | >> Co-author of "The .NET Developer's Guide to Directory Services
| > | >> Programming"
| > | >> http://www.directoryprogramming.net
| > | >> --
| > | >> "Dan" <Dan@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
| > | >> news:1456564F-FF25-4D1A-B263-5E2A17A10D4C@xxxxxxxxxxxxxxxx
| > | >>> in the patterns and practices guidelines for securing
| > applications it
| > | >>> recommends hashing passwords and using a salt if storing to a
| > database
| > | >>> (i am
| > | >>> ok with this bit). however, it also recommends appending the
| > salt to
| > the
| > | >>> hashed password for simplified storage and then makes the
| > following
| > | >>> statement:-
| > | >>>
| > | >>> This approach means you do not need to store the salt
| > separately. To
| > | >>> verify
| > | >>> a password, you extract the salt from the stored combination of
| > the
| > hash
| > | >>> and
| > | >>> salt value and then recomputed the hash using the salt value and
| > the
| > | >>> plaintext password value obtained from the user.
| > | >>>
| > | >>> my question is, how exactly do you extract the salt from the
| > stored
| > | >>> combination? is it really as simple as knowing in advance that
| > the
| > salt
| > | >>> was x
| > | >>> characters long so you can do an easy substring when extracting?
| > or is
| > | >>> there
| > | >>> another method?
| > | >>
| > | >>
| > | >
| > | >
| > |
| > |
|
|


.

Relevant Pages

  • Re: Importance of salt
    ... That is the problem with using one-way hash ... The salt is used on ... The attacker really couldn't use his ... > even knows the correct iteration count used. ...
    (microsoft.public.dotnet.security)
  • Re: Newbie - Is this Reasonable?
    ... PKCS5v2 to generate your IVs and Keys. ... I use PKCS5v2 to generate the hash of each user's login ... So you use PKCS5v2 to generate a key hash from a salt and ... themselves to off-line analysis, so the attacker can ...
    (sci.crypt)
  • Re: Hashed password secure?
    ... ]> The stupidly written BSD md5 based unix password function simply runs the ... ]> hash 1000 times to try to slow it down. ... ]impossible for some attacker to create a dictionary of hashes ... As machines get faster, the salt will get more bits, so it ...
    (sci.crypt)
  • Re: Hashed password secure?
    ... > Consider the way that a typical password hash attack program works. ... > the salt, and then it hashes the dictionary once for each unique salt value ... So the attacker has to hash the dictionary 2^16 ... want to not store his dictionaries, he'd have to try on average half his ...
    (sci.crypt)
  • Re: Importance of salt
    ... generate a key which is then used for encryption. ... The salt is used on ... The attacker really couldn't use his ... As for the iteration count... ...
    (microsoft.public.dotnet.security)