111–120 of 144 posts
Earlier quoted context omitted.
I think I answered my own question, but I'll ask anyway - why does memory intensiveness matter?
GPUs (and similar hardware) have a very limited amount of memory per core. If computing a hash requires 100MB of memory, then even a 1GB graphics card can only execute 10 cracks in parallel, not hundreds or thousands.
One thing I didn't find solution for is keyloggers and other similar attacks. If you look at the whole securing your service as a whole, you have to acknowledge the risk of keyloggers also. Now with Flame, Stuxnet and all the other nice things still in the shadows keyloggers can suddenly become also a risk in a large scale.
it is open source, and supported by all platforms i use (windows,osx,android,ios) and the interface is pretty well designed. Once local database is open, simply doing ctrl+c on any of the sites copies the password to clipboard for a very limited time.
this is still a major pain, especially since you need to protect the safe with a long password and this is particularly painful to type on mobile devices.
Earlier quoted context omitted.
> try to imagine a scenario where there could be an operator== timing attack on a password hash Sure, that's simple. You're leaking information about the password hash to the attacker, which they can use to speed up an attack where they have large offline resources but are limited in their online guessing capacity. Let's e.g. assume we have an unsalted hash, but the system limits us to one guess per second. The passw…
How does this matter given a proper avalanche effect?
Earlier quoted context omitted.
> If you have no other choice but to iterate SHA1 many thousands of times, that's still better than what most apps do, and in the grand scheme of things almost "ok". While I won't recommend people simply iterating a hash many times, I also won't slap people down for it anymore. In the grand scheme of things, there are a billion more likely routes of attack than someone breaking your 20000-rounds-of-SHA1 hashes.
Out of curiosity, what do you recommend people use?
Earlier quoted context omitted.
Why, yes, it's eminently doable. Even a single byte will let you discard 255 out of 256 attempts, and as you kindly point out, 4 bytes would be enough to uniquely identify almost any word in the standard dictionary. Feel free to peruse some SHA-256 hashes with slightly above six bytes of fixed prefix - several orders of magnitude more difficult to find than a mere 32 bits partial collision: http://blockexplorer.com/…
The "timing leak" here does not uniquely identify any word in the dictionary; the attacker is on the opposite side of the problem. This attack is implausible.
Here I model the server as a simple function that takes a password, hashes it, and compares it to a known digest with an '==' substitute. The function returns true or false, but also leaks information about how long the match was, through a simulated timing leak.
This lets me identify the dictionary word that was used as a password using just 23 login attempts, instead of the expected 19300 from a brute force attack.
In effect, you're giving the attacker the ability to perform an almost offline attack, as if they possessed the password hash, by supplying however much of the hash they need.
I don't see how this would not be a security problem, if you acknowledge that testing a HMAC with == is.
Again, this is trivially preventable by using a timing independent comparison.
Earlier quoted context omitted.
Ya, that's silly. A common and simple password setup is hash(username+password) or hash(private_account_attribute+password). Also, use bcrypt/scrypt/similar.
I have heard of doing both, though I have not seen it yet in production. It gives the benefit of having to get the code and the database while also requiring dictionaries to be build per password.
Earlier quoted context omitted.
Furthermore, it's important that the salt be unique per password . If you had a single common salt in your code, then two users with the same password would produce the same hash.
This is only a problem in the sense that once one hash has been cracked the so is the other, however most authentication is done using some user/email attribute also. Usually we fetch user/email, hash password, compare to hash in database - authenticate if match or deny if not.
The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…
The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…
Hi Phil -
Yes. Salts are to defeat things like this: http://en.wikipedia.org/wiki/Rainbow_table