5 ms·
All 32mil RockYou accounts hacked. Passwords were stored in plaintext.
- tptacek 17y agoNote that if you store your passwords in a fast hash format like salted SHA1, an attacker with 32MM database rows can publish a very credible sample of usernames and passwords, and leave you scrambling to explain how the breach isn't really as bad as it looks. Not a great position to be in. The right answers to this problem are BCrypt, SCrypt, PBKDF, or (at a minimum) salted "stretched" SHA1, iterated many thousands of times.
- paulgb 17y agoDoes using a unique salt for each user help here? Is there a non-obvious reason why that approach is bad?
- mgrouchy 17y agoI'd be interested in knowing the answer to this too.
- tptacek 17y agoThe "salt" --- which, so far as I can tell, is a term used almost never in academic crypto research --- defeats one very effective exotic attack: the "rainbow table", where an attacker builds a database of perfect hash :: string correspondances. But too many people forget that before the popular Windows cracking tools were released, passwords were cracked exclusively by tools like JtR, which simply contain highly optimized loops for brute forcing passwords. "Salts" do nothing to slow this attack down, because they add insignificant time (really, none) to a single hash iteration. Hashes like MD5, SHA1, and even SHA256 are designed to be fast. To succeed, they need to be able to handle multi-gigabit per-packet hash rates. They are designed explicitly both to be fast on general-purpose hardware and to be straightforward to optimize in purpose-built hardware. This is a bad, bad property for a password hash. BCrypt is "optimized" to be slow - tuneably slow. SCrypt improves on BCrypt by being both slow on general purpose hardware and resistant to simple hardware speedups. PBKDF and "stretched" SHA1 are very simple contructions that are weaker than BCrypt and SCrypt but more buzzword compliant. All of them make it difficult to recover hundreds of thousands of passwords from a database dump. See: http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...
- ephermata 17y agoWhat do you think about halting password puzzles? http://crypto.stanford.edu/~xb/security07/index.html http://crypto.stanford.edu/~xb/security07/index.html
- tptacek 17y agoI think anything ending in "KDF" gives me warm fuzzies, and that whatever you code in already has a library for BCrypt.
- mgrouchy 17y agoThanks for that!
- jmillikin 17y ago"salting" also prevents brute-forcing. Assuming a bare-basics implementation (20-char salt in config file, 20-char salt per user, prepended to the password), the only way an attacker can brute-force passwords in a reasonable timeframe is to compromise the server itself. At that point, it would be just as easy to make the login form mail him passwords. Merely choosing a slower digest doessn't help, because the digest would have to be extremely slow (minutes or hours per password) to prevent somebody from running it against "password", "12345", etc for every row in the table. And that's the only kind of attack worth preventing -- if somebody can brute-force a 20-character alpha-num-symbol password in realtime, your choice of digest algorithm is irrelevant.
- tptacek 17y agoIf you can't understand the significance of these two results (and this is with the default cost factor for BCrypt), you're just arguing to hear yourself talk. t1 = Time.now.to_i 100.times { BCrypt::Password.create("ugh8&eat") } puts Time.now.to_i - t1 => 12 t1 = Time.now.to_i 100.times { Digest::SHA1.hexdigest("ugh8&eat") } puts Time.now.to_i - t1 => 0 I could raise the number of iterations to bring SHA1 above the measurement floor, but I don't want to lock my computer up with pointless BCrypt cycles.
- madair 17y agoThe salt is used for the original encryption, after which the plaintext is thrown away, then when you need to compare what the user enters next time, you use the same salt with the password entered every time. http://en.wikipedia.org/wiki/Salt_%28cryptography%29 http://en.wikipedia.org/wiki/Salt_%28cryptography%29 Edit: On second thought, I might have misread the question, perhaps you're intending to store the unique salt for each user, although that seems impractical to me since it would have to be just as obtainable as the password database.
- timhill 17y agoI Am Not A Cryptographer, so take this with a grain of salt. Using a unique salt for each user "helps", but is still insecure. The problem is that hash functions such as SHA or MD5 are designed to be very fast. This means that even with unique salts it is still fairly trivial to try a large number of passwords on a large number of users and crack many or them. The parent poster has the right idea. For passwords, use bcrypt, scrypt, PBKDF, or a stretched hash.
- jmillikin 17y agoWhat's wrong with using a salted hash? Assuming a competent implementation, it should be computationally infeasible to brute-force any digests in less than a few billion years using current models of computation. I'm particularly curious about how using (for example) BCrypt will prevent brute-forcing "12345", "password", or any of the other simple strings many people use.
- deleted 17y ago[deleted]
- tptacek 17y agoThat first paragraph is a funny statement, since every Unix security book ever written explains how to use Crack, a tool written before I even got into high school, to rip through Unix salted passwords. I don't think it even bears arguing. The second point is valid but not particularly meaningful. You could also try "12345" and "password" over the network using the login page as an oracle, given a list of usernames. But with SHA1, you can feasibly do large combinations of phonemes with numbers and punctuation across millions of accounts. People with passwords like "ugh8&eat" will lose their accounts. You can tune BCrypt so that just "12345", by itself, is too painful to run across 32MM rows to be worth a PR stunt.
- jmillikin 17y agoI said "competent"; the UNIX crypt() and Windows LanMan schemes do not count. If you have any information about defeating a properly implemented salt+hash system, I (and every other developer in the world) would be eager to hear it. For example, I just generated a salt/digest combination for a simple example password. It is digested using SHA-1, and the password is four ASCII digits. Here is the database row -- '|' is a delimiter between the fields. algo | user_salt | digest ---------------------------------------------------------------------- sha1 | lyhsus1eizh815xz69pv | d418a6088847d6f2e5b0e3d2ecf2e300454a0885 If you (or, anybody) can determine the original password from this database row, I will mail you a check for a thousand dollars.
- deleted 17y ago
- ROFISH 17y agoWhat do you think about the Whirlpool hashing algorithm?
- tptacek 17y agoI think it is designed to be fast and is therefore not a good password hash.
- sabat 17y agoIt's funny -- I remember a self-appointed security guru here saying that the fact that 37 Signals doesn't encrypt passwords was perfectly fine, a minor detail. You can't half-ass basic security measures. It's like leaving your car unlocked in east Oakland.
- billclerico 17y agoif true, this is so irresponsible it is almost unbelievable
- tptacek 17y agoDidn't Reddit do something very similar?
- ichverstehe 17y agoMany do. E.g. 37signals.
- tptacek 17y ago37signals lost a bunch of plaintext passwords? When did that happen?
- qeorge 17y agoThey 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.
- tptacek 17y agoI 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!
- qeorge 17y agoYeah, 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.
- anigbrowl 17y agogiven the nature of their service, I can't help suspecting the bulk of their clientele use one password for everything. Awesome.
- harpastum 17y agoI 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 think you personally understand the issue. I just think that we shouldn't have a mentality of "aww, we need to take special care of these unsavvy users." Not having basic levels of security in place for any user-base is simply unacceptable.
- anigbrowl 17y agoYou're entirely right, and said it better than my snarky response did.
- jasonlbaptiste 17y agoThis is just some amateur hour shit. They're a well established and well funded company. How do venture funds not do better technical due diligence(or any at all)? I wouldn't release an app for 32 of my friends to test, let alone 32 million people to use with plain text passwords. Enough of my bitching, because it's inaction. Now for words of action/openings for suggestion: How do we make sure companies don't do dumb things like this?
- tptacek 17y agoMy answer to this question is effective but very self-serving.
- bootload 17y ago"... How do venture funds not do better technical due diligence(or any at all)? ... How do we make sure companies don't do dumb things like this? ..." Because it's not seen by "management" or "VC's" as a priority. Extra programming is seen as a time and monetary cost, not a necessity. One company I worked for used plain-text for customer passwords and mandated Microsoft technology in the same breath. When I talked to the lead tech, I got a shrug. Not because of lack of technical smarts but politically tied hands from management. When I contacted the MBA minted CEO I got a blunt - "it's not a problem, don't worry about it". A physical loss is perceived more tangible than something ephemeral. Things did happen when people walking off the street stole "stuff" from the office. Swipe cards were quickly introduced. I'd broached such arrangements before the incident but that wasn't seen as a problem either.
- gfunk911 17y agoWhat's the plumber equivalent of storing passwords in plaintext, the things where if you heard that a plumber did X, you would be in complete shock at their negligence?
- deleted 17y ago[deleted]
- ars 17y agoHow about: Install a drain without a vent. Why do you want to know? Edit: I picked this example carefully. Someone who knowns nothing about plumbing will not be shocked at this, having no idea what it is (until it's explained to them). Just like someone who is not a programmer will have no idea what the problem with plain text password is (until it's explained to them). PS. A drain without a vent (or at least an anti-siphoning device) can be life threatening.
- chaosmachine 17y agoLead pipes?
- deleted 17y ago[deleted]
- mattmaroon 17y agoI'm not shocked. As I just wrote on my Posterous, RockYou has consistently shown themselves to be just amazingly stupid. I've had the misfortune of dealing with these morons for over a year now. This is far less bad (since I use Roboform) than the time they CC'ed me in with thousands of people on a Merry Christmas email.
- mattmaroon 17y agoWait a sec, something is wrong here. I suspect the title is misleading. RockYou has maybe a couple thousand developers tops using their services. They might have 32 million Facebook customers, but those don't have passwords. They're Facebook app users. Facebook does not permit developers to store private info without special permissions, which I've never seen apps of their ilk ask for. So while this hacker could maybe see what digital birthday card was sent to whom, that's probably about the extent of the damage.
- far33d 17y agoRockYou was a widget company - they probably still have usernames and passwords for myspace users.