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

All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

techcrunch.com

Post reply on HN
Print view View original

91–100 of 112 posts

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#91

Post by anigbrowl »

harpastum wrote: post #59
anigbrowl wrote: post #6

given the nature of their service, I can't help suspecting the bulk of their clientele use one password for everything. Awesome.

I agree with you, in that you're saying it's silly for RockYou to assume their customer's passwords are unique to their service, but I vehemently disagree with your unstated assumption--that 99.99% of other communities aren't just as likely to have users pick dumb passwords. I don't mean this to come off as ad hominem, because I don't think it was your intention to leave the opposite side of the argument open and I t…

You're entirely right, and said it better than my snarky response did.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#92

Post by qeorge »

tptacek wrote: post #8
ichverstehe wrote: post #5

Earlier quoted context omitted.

Many do. E.g. 37signals.

37signals lost a bunch of plaintext passwords? When did that happen?

They didn't lose them, someone just noticed that they would send you your original password if you requested it and made a blog post about it.

The conclusion was that they must be storing passwords plaintext, although that's not necessarily true. IIRC, your opinion was that this was not a big deal in the grand scheme of things.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#93

Post by makulit »

tptacek wrote: post #80
makulit wrote: post #73

Earlier quoted context omitted.

Jmilikin already stated the config salt is not present, that the password IS 4 ASCII digits and he assumes a database breach. Isn't it up to the attacker to figure out the rest of the details? As an attacker, do you think he has a separate config salt in a file or a separate table or secondary system? That's why you DO spend 10 hours on attacking it if you want the results. His posting seems quite legitimite to me.

He stated the opposite of what you said, so I wasted 0.9 seconds of runtime and 15 seconds of coding time verifying that he was not crazy enough to promise $1000 for trying 10,000 SHA1 iterations, which at the time seemed possible. He owes me 0.4% of my bill rate! If your second graf is valid, then it is equally valid to say that rot13'ing your passwords before you hash them is an effective security measure, because…

Actually I thought I paraphrased it pretty well but to I guess a direct quote is better.

"The config salt isn't present in my post -- I'm assuming a database breach, like that which usually occurs. The digest does include a config salt, of course -- this isn't the '70s."

I do agree this is a learning exercise. I also agree that as an attacker you still have to make a lot of presumptions such as maybe they did use a keyed SHA1 process or use Base64. Again, why is this not a legitimite question? He was not trying to trick you anymore than an attacker would have to guess/try/reason what the dev/secofr implemented.

You're a post count leader here but either I am overly sensitive to reading snarkiness or I simply don't understand. I have no problem admitting I'm not a security expert but again there are some good questions from others here. Help us out here.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#94

Post by paulgb »

tptacek wrote: post #65
paulgb wrote: post #62

Earlier quoted context omitted.

I'm not misconstruing your argument as against salted hashes, but as downplaying the advantages of using a unique salt over an install-specific salt (not sure that's the best term, but I'm referring to the type of salt you might find in a config.py file). Let me put it this way: give me a database of 32 million username/password_hash combinations and the hash(password) function used and I can give you a valid usernam…

"Salts" have been password-specific since Ken Thompson invented them in the '70s. We're not talking about different approaches: the approach you're talking about is unsafe. The attack you're talking about --- searching for a radically reduced set of passwords --- is so fundamental to password security that you don't need any crypto to do it. Just open 50 concurrent connections to the login page and rip through the us…

> "Salts" have been password-specific since Ken Thompson invented them in the '70s.

Thanks, that's where my misunderstanding was. I've seen "salt" used (apparently, improperly) in cases where the hash is the same for all passwords. Even the wikipedia article seems to imply that use case.

The other part of my misunderstanding was that I was thinking of BCrypt as a deterministic function. Looking at an implementation, it looks like multiple calls to BCrypt::Password.create with the same value can result in different values, unlike how sha1($x) = sha1($x) for any $x.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#95

Post by tptacek »

qeorge wrote: post #92
tptacek wrote: post #8

Earlier quoted context omitted.

37signals lost a bunch of plaintext passwords? When did that happen?

They didn't lose them, someone just noticed that they would send you your original password if you requested it and made a blog post about it. The conclusion was that they must be storing passwords plaintext, although that's not necessarily true. IIRC, your opinion was that this was not a big deal in the grand scheme of things.

I said it wasn't a vulnerability, or, if it was, it was a minor one compared to a real vulnerability; sev:low compared to sev:medium for a stored XSS flaw and sev:high for SQL Injection. And I believe that.

But if we're comparing one password storage mechanism to another, I get religious fast. There's a right and a wrong way to do it.

37s did it the wrong way. Now I understand they do it the right way. Good for them!

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#97

Post by qeorge »

tptacek wrote: post #95
qeorge wrote: post #92

Earlier quoted context omitted.

They didn't lose them, someone just noticed that they would send you your original password if you requested it and made a blog post about it. The conclusion was that they must be storing passwords plaintext, although that's not necessarily true. IIRC, your opinion was that this was not a big deal in the grand scheme of things.

I said it wasn't a vulnerability, or, if it was, it was a minor one compared to a real vulnerability; sev:low compared to sev:medium for a stored XSS flaw and sev:high for SQL Injection. And I believe that. But if we're comparing one password storage mechanism to another, I get religious fast. There's a right and a wrong way to do it. 37s did it the wrong way. Now I understand they do it the right way. Good for them!

Yeah, I remember that better now. There were a lot of pitchforks that day.

37s has a great track record of listening to and acting on community feedback, which is all you can really ask for. I second your kudos.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#98

Post by tptacek »

makulit wrote: post #93
tptacek wrote: post #80

Earlier quoted context omitted.

He stated the opposite of what you said, so I wasted 0.9 seconds of runtime and 15 seconds of coding time verifying that he was not crazy enough to promise $1000 for trying 10,000 SHA1 iterations, which at the time seemed possible. He owes me 0.4% of my bill rate! If your second graf is valid, then it is equally valid to say that rot13'ing your passwords before you hash them is an effective security measure, because…

Actually I thought I paraphrased it pretty well but to I guess a direct quote is better. "The config salt isn't present in my post -- I'm assuming a database breach, like that which usually occurs. The digest does include a config salt, of course -- this isn't the '70s." I do agree this is a learning exercise. I also agree that as an attacker you still have to make a lot of presumptions such as maybe they did use a k…

He implied he was using SHA1(nonce, password). He was actually using SHA1(k, nonce, password). You're taking a later clarifying comment he made and adding it to the main comment.

But who cares? This is silly. Secure password schemes don't need to protect a key file to avoid being broken, and they don't need you to know how Merkle-Damgaard works to implement without blowing up. Any password scheme that has a "config salt" is a vanity scheme. Adding a "config salt" is less secure than literally just looping 1000 times around SHA1.

Security schemes designed as exercises in vanity have a poor track record.

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#99

Post by [deleted] »

tptacek wrote: post #51
paulgb wrote: post #45

Earlier quoted context omitted.

I certainly get why a slower hash would curb brute force attacks, but when I'm talking about unique salts, slowing down the hash is not the purpose I have in mind. If you have a table of 32 million hashed passwords with no salt (or they have the same salt and you know what it is), you can try a bunch of combinations, take the resulting hash, and look it up in the hashed password database. If you try the password "foo…

Every time I bring this up, which is often because it is, apparently, all I ever talk about here, people misconstrue what I'm saying as some kind of argument against "salted" hashes. It is true that not even bothing to randomize your hashes is worse than doing so. But when we're talking about degrees of grave badness, I stop being super interested in the conversation. If, for reasons passing my understanding, you are…

[deleted]

Re: All 32mil RockYou accounts hacked. Passwords were stored in plaintext.

#100

Post by frisco »

tptacek wrote: post #51
paulgb wrote: post #45

Earlier quoted context omitted.

I certainly get why a slower hash would curb brute force attacks, but when I'm talking about unique salts, slowing down the hash is not the purpose I have in mind. If you have a table of 32 million hashed passwords with no salt (or they have the same salt and you know what it is), you can try a bunch of combinations, take the resulting hash, and look it up in the hashed password database. If you try the password "foo…

Every time I bring this up, which is often because it is, apparently, all I ever talk about here, people misconstrue what I'm saying as some kind of argument against "salted" hashes. It is true that not even bothing to randomize your hashes is worse than doing so. But when we're talking about degrees of grave badness, I stop being super interested in the conversation. If, for reasons passing my understanding, you are…

My understanding was that hashing a hash was stupid because you've effectively limited your attacker's search space. That is, in the beginning the password or pass phrase can be any length (probably up to 255), but after hashing you've restricted it to a known length composed of known characters. Therefore, you've decimated the overall search space. It seems like iteratively rehashing your hash 1000 times would make things significantly more insecure.
Post reply on HN