7 ms·
And passwords. In particular, probably some people reuse passwords between Stack Overflow and GitHub, and keep other credentials in files in private repos.
by smelendez 7y ago
And passwords. In particular, probably some people reuse passwords between Stack Overflow and GitHub, and keep other credentials in files in private repos.
- 9nGQluzmnq3M 7y agoI would like to hope Stack Overflow of all companies doesn't store passwords in plaintext, but you never know.
- rcfox 7y ago10 years ago, almost to the day, they had a password vulnerability involving unsalted hashes. So not plain text, but who knows if they've learned the right lessons? https://blog.codinghorror.com/i-just-logged-in-as-you-how-it-happened/ https://blog.codinghorror.com/i-just-logged-in-as-you-how-it...
- 0xffff2 7y agoUnless I'm badly misreading something, the unsalted hashes in that post were on some other (unspecified) site unrelated to Stack Overflow.
- rcfox 7y agoIn the first sentence, he links to a previous post where it's made more clear that he's talking about Stack Overflow. > I found what one could call a security hole in Stackoverflow. I'm curious enough to go digging around for holes, but too ethical to actually do anything with them.
- 0xffff2 7y agoI hate to say this, but did you even read the post you actually linked? From the second post (the one you linked), where Jeff quotes the hacker: >>I guess I can tell you, so you don't fall into this trap again. There's a site I help out with that doesn't salt their passwords. They're MD5 encrypted, but if you've got a dictionary password, it's very easy to use a reverse-MD5 site to get the original. I was able to figure out you were a user on the site some time back, and realized I could do this, if only I knew your openid provider... The "password vulnerability involving unsalted hashes" was on another site. The hacker was only able to gain access to Jeff's Stack Overflow account through a combination of their privileged access to the database for that other site and Jeff's own bad op-sec. The only real security error attributable to Stack Overflow in any way was Jeff's own and had nothing to do with Stack Overflow's infrastructure.
- robomc 7y agoThey don't have to store them as plain text for it to be a problem. If they're not salted it's trivial to crack the hashes, and if they are all uniquely salted, while it's time consuming, they can still gradually crack them. Given that you could probably sift through the users to find particularly juicy targets (usernames of maintainers of top open source projects with github repos for example?) that could justify the work of a time consuming attack on the hashes.
- bigiain 7y agoAlso "Some level of production access" could easily include the ability for the attacker to intercept and exfiltrate passwords as users log in.
- adrianN 7y agoI haven't checked in a while, what's the cost of cracking a single salted password that is stored properly, e.g. with pbkdf2 or bcrypt or whatever is currently state of the art?
- lucb1e 7y agoThe cost? That depends on the password. How long does it take to crack 123456? That depends on the parameters. In a good case, it takes 50ms per hash on a modern system, so that's 20 attempts per second (instead of 20 billion per second for a plain md5 or so). I don't really expect a popular site to do much more than that, so that's the best case. From experience, most sites will be more around the 20 billion mark than the 20 mark, but I expect stackoverflow to be on the good end. The current state of the art is Argon2, with scrypt second and bcrypt/pbkdf2 tied for third. The first two have memory hardness, and the first one is the standard chosen in the password hashing algorithm competition. The third is still acceptable because most developers still go for a salted single hash like sha256. Somehow they got the salting method, but I'd rather they break all identical passwords at the same time (they weren't that strong anyway if they're shared between more than one person) than that they crack only a tiny percentage because of the cost. Slowness helps more than salting, yet as a pentester I see more of the latter than the former. So I'd rather recommend something available for their platform as a good third choice than them going "meh, effort" and not implementing the recommendation.
- bredren 7y agoI work on an enterprise infosec tool that just demonstrated 48 trillion MD5s per second using AWS GPUs. Hashed passwords are cracked so easily it is a minor obstacle at this point. It is a question of when not if a hash table is fully cracked.
- dhritzkiv 7y agoMD5 is one thing as a password can be retrieved from a hash table. But pulling out passwords from a hashed + salted value (e.g. via bcrypt) is many orders of magnitude more infeasible, no?
- bredren 7y agoI would be impressed if SO's user password table is in bcrypt.
- dhritzkiv 7y agoWhat makes you say that? bcrypt's been the defacto best practice for user password "storage" for probably 10 years now. MD5's been known to be inadequate for much longer. Even if they had a legacy implementation in MD5, gradually migrating from storing MD5 hashes to storing bcrypt hashes is trivial to do.
- gpvos 7y agoI would be disappointed if such a high-profile and technically savvy site would be using anything less.
- blablabla123 7y ago...unless you use Google login or so. It's almost as if there is nothing to get by hacking SO. That's actually really good engineering.