51–60 of 123 posts
Bet that would be harder to crack and still easier to remember for a multi-lingual person.
In fact if non-latin alphabet is widely supported for entering password, it would make them a bit more secure I feel.
I've been using 2-factor authentication (Google Auth) lately and I'm fairly impressed with it. I only have to whip out my cell phone a couple of times a day/month so It's fairly convenient, and it seems very secure. Then again, I thought my password was fairly secure, but after reading this story and the HN comments, I can say that I'm just like everyone else when it comes to passwords. Ignorant. :/
Earlier quoted context omitted.
Right there in the same field as the password: :: The pepper on the other hand shouldn't be in the db. Hardcode that into a config file.
"Pepper"s are essentially meaningless and provide no real benefit over a salt. And you should be using bcrypt anyway.
Citation needed. There appears to be a case where it could prove to be an advantage: http://security.stackexchange.com/questions/3272/password-ha...
> And you should be using bcrypt anyway.
Yeah, except bcrypt isn't always an option. Eg: on Google App Engine.
Enjoyable read, but I question the bit near the end claiming that salts wouldn't help much against this kind of attack. From my understanding, per-user salting does substantially slow down this kind of attack because it forces you to calculate a different hash for each user/plaintext combination rather than hashing a suspected plaintext once and comparing the hash against the whole list. What it doesn't slow down is…
What you're describing is partially correct. When you crack passwords (either with rainbow tables or by brute force) you generate an iterator or use a dictionary and work through this generating hashes (with rainbow tables this works via a series (or chain) of what are called hash reduction functions instead of a plain iterator).
You then compare the hash you've generated against all the hashes being subjected to the crack. Where there's a match, you win!
If you're targeting a single hash and it's unsalted, rainbow tables will work as they're precomputed. It's inefficient, but it'll work.
If you're using a salt, rainbow tables need to be pre-computed for the salt - I actually did this years back with a team for oracle 10g SYS and other default user passwords as the username was used as the salt.
If you're targeting a single hash and it's salted then the iterative or dictionary approach will still work in roughly the same time as the salt is known. Separating the salt means you have to brute force it which is a PITA but generally because the way hashes tend to be stored (remember we're talking about a mechanism that shouldn't really be used anyway) the salt needs to be accessible by that system so you can dump the salt out regardless.
Depending on where my current research goes it looks like some salting mechanisms may be feasibly pre-computable now beyond those that use predictable salts. GPUs allow you to create and traverse enormous chains in rainbow tables and while having to precompute per salt will be a PITA it looks like it is possible with sufficient storage and GPU power.
Cue a test-how-strong-your-password-is service where security conscious individuals can test how their particular password stands up against these new attacks.
Earlier quoted context omitted.
Where/how do you store the salts?
Salting would definitely make a difference. The point of salting is to increase the complexity and overhead of generating rainbow tables. The first mistake here is the use of MD5. MD5 is flat out broken. Do Not use md5. Do use bcrypt. In your db, you can store the salt right there....next to the hash... How a salt increases the complexity is quite simple. If a attack has a giant rainbow table, the salt causes him to…
Earlier quoted context omitted.
Maybe we read different articles, but the one I read seemed intent on strongly downplaying the amount of extra security that salting provides. It actually uses the phrase "minimal amount of protection" to describe a salt's effect on cracking attempts. That seems like a strange choice of words when salting would've completely changed the outcome of the cracking attempts described in the article. Edit: To be clear, I'm…
Salting wouldn't have changed the outcome of the cracking attempts in the article. The primary focus was on how pre-computed hashes (rainbow tables, etc.) are no longer a tool used by most people attacking password lists because GPU-based hashers are efficient enough, the dicts long enough, and the methods of permuting the dicts (combinations, leet substitutions, markov chains, etc.) are rich enough that storing all…
Global hash:
while(s = guess()) {
if (md5(s,salt) in list) {
print s;
delete(md5(s,salt),list);
}
}
while(s = guess()) {
foreach(h in list) {
if (md5(s,salt)==h) {
print s;
delete(h,list);
}
}
}
Cue a test-how-strong-your-password-is service where security conscious individuals can test how their particular password stands up against these new attacks.
And have their password added to a word-list.
Enjoyable read, but I question the bit near the end claiming that salts wouldn't help much against this kind of attack. From my understanding, per-user salting does substantially slow down this kind of attack because it forces you to calculate a different hash for each user/plaintext combination rather than hashing a suspected plaintext once and comparing the hash against the whole list. What it doesn't slow down is…
I'm in the middle of researching re-evaluating rainbow table attacks in light of Moore's law, GPUs and Crack (lookup) tables, I've also looked into countermeasures. What you're describing is partially correct. When you crack passwords (either with rainbow tables or by brute force) you generate an iterator or use a dictionary and work through this generating hashes (with rainbow tables this works via a series (or chai…