Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How crackers ransack passwords like “qeadzcwrsfxv1331”

arstechnica.com

Post reply on HN
Print view View original

101–110 of 123 posts

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#101

Post by _b8r0 »

chiph wrote: post #86
_b8r0 wrote: post #83

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…

As long as there are unsalted hashes or hashes that use predictable salting mechanisms in use, rainbow tables are far from obselete, functionally or otherwise.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#102

Post by _b8r0 »

chiph wrote: post #98
Coincoin wrote: post #92

Earlier quoted context omitted.

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.

Given that an attacker is going to focus on high-value accounts if they can, slowing down a brute force attack on a per-hashed-value basis is pretty much your only defense. Adding complexity (like you would when defending against a rainbow table attack) adds little value when defending against a GPU-based attack that can crank out a billion hashes a minute. So what you can do is add artificial length to the password…

Nope. The correct way to do this is to use a password based key derivation function like scrypt[1] or pbkdf2[2].

[1] - https://www.tarsnap.com/scrypt.html

[2] - http://en.wikipedia.org/wiki/PBKDF2

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#103

Post by jameshart »

mrgoldenbrown wrote: post #78

I don't understand the statement that salts get less effective after you've broken other passwords: "But the thing about salting is this: it slows down cracking only by a multiple of the number of unique salts in a given list. That means the benefit of salting diminishes with each cracked hash." A proper salt for user Joe's password does not have any relation to any other user's salt. Cracking Bob's password should n…

I think they misphrased that a little, unless as you say there really are people commonly using non-unique salts. The krux of the argument is that each cracked hash removes one hash from the list of hashes you need to check. So, say you've got 16000 uniquely salted MD5 passwords. 8000 of them are, though, salted MD5s of 'password'. If you start off by checking weak passwords, your first pass requires you to calculate 16000 hashes, but if your first candidate password is 'password', then it yields 8000 passwords. Your next pass only has to calculate 8000 hashes for each candidate password. So in that case, cracking Bob's weak password does help you crack Joe's strong one.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#104

Post by PwdRsch »

lambda wrote: post #82
chm wrote: post #8

Earlier quoted context omitted.

But doesn't this render the process useless? If an attacker gets access to the hashes, he also gets access to the salts. If both hashes and salts were isolated, I suppose it would be much more secure, although maybe too slow.

A salt is not for adding extra secrecy. It's for making it take more work to solve a large number of passwords at once. It doesn't need to be stored separately to do this. What you're thinking of is a secret-splitting scheme; where you split a secret among multiple parties, where you need the information from both parties to reconstruct the secret. That's a valid cryptographic technique, but that's not what's meant w…

There actually has been research on how to split passwords across multiple servers (one example http://www.passwordresearch.com/papers/paper270.html), and RSA is currently marketing a commercial product that does this. While I agree that most people probably aren't concerned enough about password exposure to do this, there are effective solutions to accommodate those that are.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#105

Post by aidenn0 »

Corrado wrote: post #53

My big takeaway from this article is that passwords, in almost any form, are a bad way to secure your information. The only acceptable way to use a password nowadays is to use a password manager to build huge passwords that a human could never remember or type in reliably. Even then, as machines get faster and crackers get smarter, these behemoth passwords will fall. I've been using 2-factor authentication (Google Au…

Even then, as machines get faster and crackers get smarter, these behemoth passwords will fall.

This is fairly trivial to show is false. A 256-bit password that can be checked at one clock-cycle per iteration with 1 million cores running at 30GHz will take 1.2e53 years to crack[1]. If you generate it by base-64 encoding a random 256-bit string you will end up with only a 12 character password (hardly a "behemoth").

[edit] It's 1.2e53 years to exhaust the search space; you can expect to crack X% of the passwords in X% of the time (or have an X% chance of cracking a single password in X% of the time)

[1] https://www.google.com/search?q=2%5E256%2F(1e6*30e6%2Fs)#scl...

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#106

Post by PwdRsch »

jokoon wrote: post #85

Maybe we should tell users to use passphrases instead. The 8 char limit is very low now. The limite should be raised to 30 characters.

Telling people to use passphrases is a great recommendation, but you still have to spend some time teaching them how to use passphrases effectively. In the article they list several passphrases that were cracked, such as "sleepingwithsirens", "gonewiththewind1", and "momof3g8kids". So if a user chooses "ijustbluemyself" thinking that it's a great choice they are likely to be disappointed if a skilled cracker gets access to their password hash.

My basic suggestions are to choose 4+ words that are not a common phrase, song name, quote, etc. And make sure you still use both lowercase and uppercase letters, plus throw in some symbols in non obvious places (e.g., don't convert your a's into @ signs). It doesn't need to be as random as a shorter password, but it still shouldn't look like a normal sentence.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#107

Post by PwdRsch »

deathanatos wrote: post #52

Anyone know where the article's author got the "MD5.txt" file (the list of hashes he ended up cracking)? I'd like to take a crack at this (pun intended) myself.

Here's what it says in the "How I became a password cracker" article (http://arstechnica.com/security/2013/03/how-i-became-a-passw...) on Ars from March:

"Dan suggested that, in the interest of helping me get up to speed with password cracking, I start with one particular easy-to-use forum and that I begin with "unsalted" MD5-hashed passwords, which are straightforward to crack. And then he left me to my own devices. I picked a 15,000-password file called MD5.txt, downloaded it, and moved on to picking a password cracker."

My guess is that the forum he mentions was the insidepro.com web site, since it is a popular password hash sharing site. A quick search there found several attached files named MD5.txt, but none seemed to be the right size or have the right hashes. However, a search for hashes mentioned in the article found this file (http://forum.insidepro.com/download.php?id=12783&sid=160...), which contains 16,880 (instead of the 16,449 hashes listed in the Ars article) and at least 3 of the MD5 hashes specifically mentioned in the article.

There's a good chance this is the same file or close to it, but you'd have to try matching it with more of the hashes from the article to know for sure.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#108

Post by jokoon »

PwdRsch wrote: post #106
jokoon wrote: post #85

Maybe we should tell users to use passphrases instead. The 8 char limit is very low now. The limite should be raised to 30 characters.

Telling people to use passphrases is a great recommendation, but you still have to spend some time teaching them how to use passphrases effectively. In the article they list several passphrases that were cracked, such as "sleepingwithsirens", "gonewiththewind1", and "momof3g8kids". So if a user chooses "ijustbluemyself" thinking that it's a great choice they are likely to be disappointed if a skilled cracker gets acc…

well it's either that or security cannot really be guaranteed.

Maybe one day password will just be 1MB files kept on people's computer instead of remembering a short string.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#109

Post by jpalomaki »

In addition to per user salt, it would be good to also add "per application" salt. A random, long string, that is stored somewhere in the application code and not in the database.

Obviously this does not help if the whole site is compromised, but it may help against SQL injection attacks where the attacker gains access to just data from database.

Re: How crackers ransack passwords like “qeadzcwrsfxv1331”

#110

Post by eropple »

danielweber wrote: post #97
eropple wrote: post #89

Earlier quoted context omitted.

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…

I know at least one major security company (that deals with Fortune 500 companies) is recommending having an extra key inside the app server, distinct from the database, since there are situations where someone can get the a copy of the DB and not your server. 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…

For sure, and I've done similar myself in the past, but let's be real here--they actually have app/DB separation in those cases. They're definitely not running on Google App Engine, where it's much more likely that they're getting data through an exploit in your app than by getting ahold of the database.

For the 99% case, 'pepper's are illusory security.

And you should still be using bcrypt. (Or PKBDF2, or scrypt, whatever. Just not something where a "pepper" actually ends up mattering.)

Post reply on HN