91–100 of 123 posts
Earlier quoted context omitted.
And have their password added to a word-list.
There is a site that pretends to do just that, though I can’t find its URL. It asks you to enter your password for strength checking, then takes you to a page saying “estimated strength: 0. Because you have typed the password into an untrusted web page, you must assume it is compromised.”
Earlier quoted context omitted.
Indeed, the best resource I've found for adversely affecting brute-force password cracking comes from the *coin cryptocurrencies. GPUs allow us to generate much much longer chains in rainbow tables than before. This means that there's a re-evaluation of space trade-off based on chain length, so simple salting mechanisms (e.g. 4 char alphanumeric such as Cisco Type 5) become feasible. For now they're not incredibly pr…
Since rainbow tables are now functionally obsolete, perhaps the best use of a salt is not to add randomness, but to enforce a minimum length. So if your salt is 40 chars, even if a user puts in a one-character-long password they're still at a length of 41 and will get some protection. Combine that with a skip + take algorithm (not just appending the salt and password together) where you interleave the salt and passwo…
It does not slow down the brute force itself. A lonely salted one letter password is as weak as an unsalted one.
The other day some devs on reddit were using google to find password strength and posted stuff like my password would take "1 billion years to crack", without realizing these sites have garbage algorithms for measuring strength, the Microsoft one is a joke.
If developers are falling for these strength indicators, I'm certain average users are getting a very false sense of security.
Earlier quoted context omitted.
There is a site that pretends to do just that, though I can’t find its URL. It asks you to enter your password for strength checking, then takes you to a page saying “estimated strength: 0. Because you have typed the password into an untrusted web page, you must assume it is compromised.”
Has anyone found this? It sounds great, but I couldn't get a URL from googling the obvious stuff. Please post if you know it!
The Terms and Conditions are worthwhile, too.
EDIT: Also, see http://www.ismytwitterpasswordsecure.com/ (needs Javascript)
The punchline: > The list contained 16,449 passwords converted into hashes using the MD5 cryptographic hash function. Edit: I'm removing all my snarky nitpicking. This is a good article. Yes, the MD5 case they present is a poor case, but it's really about demonstrating the tactics of attack selection, rather than teaching someone how to make crack-resistant password schemes.
Basically, the strength of passwords can look really good on paper (96^12 possibilities or whatever), but in practice the entropy is much less: individual characters are not as independent as we'd like to think, and your clever word or phrase may be in a dictionary already (or may be a short Levenstein distance from something in a dictionary).
Earlier quoted context omitted.
Has anyone found this? It sounds great, but I couldn't get a URL from googling the obvious stuff. Please post if you know it!
http://www.inutile.ens.fr/estatis/password-security-checker The Terms and Conditions are worthwhile, too. EDIT: Also, see http://www.ismytwitterpasswordsecure.com/ (needs Javascript)
Earlier quoted context omitted.
> "Pepper"s are essentially meaningless and provide no real benefit over a salt. 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.
Yeah, that's why I said "essentially" instead of "totally". Writing your own MAC is not a good idea, pretty much full-stop. tptacek has talked about this[1] before. In the sort of environment that necessitates stupid hashing, if your database is owned your app is owned anyway. If bcrypt isn't an option, you straight-up need a better platform. It's inexcusable to refuse to protect your users--if you're not using bcryp…
The fact that they're big doesn't mean they're right, of course. But I know I've seen a bunch of news stories about DB leaking and I haven't seem a bunch about the source code to the website leaking. (Obviously there is some confirmation bias there.)
Earlier quoted context omitted.
Since rainbow tables are now functionally obsolete, perhaps the best use of a salt is not to add randomness, but to enforce a minimum length. So if your salt is 40 chars, even if a user puts in a one-character-long password they're still at a length of 41 and will get some protection. Combine that with a skip + take algorithm (not just appending the salt and password together) where you interleave the salt and passwo…
Nope, a salt is public. Its only purpose is to force you to brute force one hash at a time. It might also protect you against some attacks particular to your hashing algorithm. It does not slow down the brute force itself. A lonely salted one letter password is as weak as an unsalted one.
Combinator attacks guess "the square of the number of words in the dict" when the password is just the combination of two words, correct? So a 3-word pass would require dict^3? This all seems to come back to length.
Consider a binary string. There are two symbols in binary (1 and 0) and the number of symbols you use is the number of bits in the string. This gives us the familiar password length calculation: the complexity is 2^l.
When you start using words as the basic unit, you gain many more symbols: if you use the full Oxford English Dictionary, you have about 600,000 of them. But when you do this, your symbol is no longer a single byte: it's a word. That word can be represented as a string of bytes, yes, but it's guaranteed that this string will be one of the 600,000 byte strings that represent English words, and you can eliminate all of the others. So you can't measure your password in bytes anymore; you have to measure it in words instead. A one-word password is, therefore, of complexity (600,000^1).
Six hundred thousand possibilities sounds like a lot, but computers can crack that in seconds. Even if you restrict yourself to just printable ASCII, you can do better than that in only three characters. I don't recommend actually doing a three-character printable-ASCII password, because you'd have just under 900,000 possible passwords: still well within crackable range.
But because the complexity increases so fast as you increase the length of the password, that's how you can gain complexity back. If you use four words instead of one, you have (600,000^4) possibilities: some 130 sextillion. You'd need 70 random bits, or 11 printable ASCII characters, to do better.
And that, my friends, is why "k[0" is a better password than "antidisestablishmentarianism". But it's also why "correct horse battery staple" is better than either one (or would be, if xkcd hadn't made it so famous).
Earlier quoted context omitted.
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…
If you're targeting a single hash I was going to mention this. If your user record has a column called "IsSuperuser", then an attacker is going to concentrate on those users, since the reward for cracking them is so much higher. Individual salts or not, with multi-GPU based brute-forcing, they won't stand long.