Re: Hashed password secure?
From: Bill Unruh (unruh_at_string.physics.ubc.ca)
Date: 06/29/04
- Next message: Guy Macon: "Re: Security for embedded device"
- Previous message: Vernon Schryver: "Re: How secure is SSL emails?"
- In reply to: Matthijs Hebly: "Re: Hashed password secure?"
- Next in thread: Matthijs Hebly: "Re: Hashed password secure?"
- Reply: Matthijs Hebly: "Re: Hashed password secure?"
- Reply: Matthijs Hebly: "Re: Hashed password secure?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 29 Jun 2004 16:49:22 +0000 (UTC)
Matthijs Hebly <heeb@iname.com> writes:
]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).
exhaustive search will depend on the strength of the password itself.
Using the latter "a" for a password is probably not very secure. Using this
email post as a password is probably reasonably secure.
I would not worry about finding some way of reversing the hash. But brute
force is always a problem with passwords.
]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.
The stupidly written BSD md5 based unix password function simply runs the
hash 1000 times to try to slow it down. Your suggestion would run it 65000
times. The problem is whether it would actually deliver a password in a
reasonable time for valid users on the range of machines it is likely to be
used on.
Also in your case if someway was found to reduce the number of salts needed
to be searched, the attacker would suddenly have a much faster way of
attacking the passwords.
Ie, why not just do something like
pi=sha1(password+pi-1+salt)
for i from 1 to 65000.
]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?
Because the salt is for preventing lookup tables, not for slowing down. The
slowing down is done by just rerunning the hash multiple times-- ie making
the slowdown an inherent part of the process rather than based on a secret.
- Next message: Guy Macon: "Re: Security for embedded device"
- Previous message: Vernon Schryver: "Re: How secure is SSL emails?"
- In reply to: Matthijs Hebly: "Re: Hashed password secure?"
- Next in thread: Matthijs Hebly: "Re: Hashed password secure?"
- Reply: Matthijs Hebly: "Re: Hashed password secure?"
- Reply: Matthijs Hebly: "Re: Hashed password secure?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|