Live data from Hacker News

Security Update

stackoverflow.blog

181–190 of 207 posts

Re: Security Update

#181
post #130

Earlier quoted context omitted.

Of all the sites and people, I expect Jeff Atwood and Joel Spolsky to have followed best practices in storing user passwords. Jeff wrote this in 2007: > Do not invent your own "clever" password storage scheme > Never store passwords as plaintext. > Add a long, unique random salt to each password you store. > Use a cryptographically secure hash. I think Thomas hates MD5 so very much it makes him seem a little crazier…

> SHA-2 or Bcrypt would be a better choice. As the sibling comment points out, SHA-2 is worthless for storing passwords. A GPU can crank through an obscene number of SHA-2 hashes per second. Bcrypt is is intentionally much slower and harder to use a GPU to brute force. The two algorithms are almost totally unrelated and it's concerning they were mentioned together.

> SHA-2 is worthless for storing passwords

It really depends on what the person means. Yes, single sha-2 hash is pretty useless. But that's often not what's really happening. For example libcrypt is used in many cases with the default $6$ format which uses thousands of rounds of sha512. That's still "password hashed with sha-2".

Re: Security Update

#182
post #7

I wonder why they are disclosing this so early, with so little information.

Would you prefer that they didn't?

I think I would prefer to wait until they have something more specific to disclose. The current update gives me absolutely nothing to go with.

It's as if a prison disclosed that the front gate was left unlocked for several minutes and they're still counting the prisoners. I would much prefer to hear about it after they have learned whether anyone escaped.

Re: Security Update

#183
post #160

Earlier quoted context omitted.

Sure. But that advice was written 12 years ago . I'd be surprised if they didn't update their password storage since then.

How do you update password storage if you don't store the passwords only hashes? You could upgrade it for new users, but for old ones? (e.g. I don't change passwords often)

If they aren't salted, just generate your own rainbow table!

Re: Security Update

#184
post #141

Earlier quoted context omitted.

They have job listings, information about listings I have applied to, and a copy of my resume with contact information.

Job listings are public information, your resume may also be considered public info if you have sent it out to recruiters or public job posting sites. Listings you've applied to could be potentially private. But if you use an alias (and only reveal your real name after the company agrees to interview you), then it's not a problem either!

> your resume may also be considered public info if you have sent it out to recruiters or public job posting sites.

No, absolutely not.

Re: Security Update

#185

Serious question: what sensitive user data is there on Stack Overflow anyway? Questions, answers and comments are all public, the content is Creative Commons licensed and even available in handy downloadable & queryable form: https://data.stackexchange.com/ As far as I can see, the primary sensitive user data they have is e-mail addresses, but (unlike, say, Reddit) most StackExchange forums don't deal with personally…

And passwords. In particular, probably some people reuse passwords between Stack Overflow and GitHub, and keep other credentials in files in private repos.

...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.

Re: Security Update

#186

What tends to be the first indication of breaches? It's one thing to do a forensic analysis after learning of a breach, and it's another to detect it in the first place.

I’ve done a few small IR jobs in my time, and also have a hobby of reading every breach report that comes out.

It seems the vast majority of breach discovery amongst typical companies is an engineer going “hrmm that’s odd”: a router at 100% CPU because it’s currently part of a DDoS attack. A DBA noticing a huge query they don’t recall running. Unusual login times for administrative accounts. Having email systems sinkholed for sending spam. And of course “all my files are encrypted?”

Re: Security Update

#187
post #130

Earlier quoted context omitted.

Of all the sites and people, I expect Jeff Atwood and Joel Spolsky to have followed best practices in storing user passwords. Jeff wrote this in 2007: > Do not invent your own "clever" password storage scheme > Never store passwords as plaintext. > Add a long, unique random salt to each password you store. > Use a cryptographically secure hash. I think Thomas hates MD5 so very much it makes him seem a little crazier…

> MD5 is vulnerable. Why pick anything remotely vulnerable, when you don't have to? SHA-2 For the purpose of hashing passwords, there's no significant difference between MD5 and SHA-2. Both are awful choices. Edit: Actually, SHA-2 may be worse because CPUs have hardware acceleration and thus the attacker may be able to crack it somewhat faster than MD5.

It’s definitely not worse—MD5 is faster with GPUs—but plain SHA-2 isn’t much better, either.

Re: Security Update

#188
post #28

Earlier quoted context omitted.

@dataflow I sync my phone using Syncthing, so that's one way.

Oh I see. (Why not just reply to my comment? :-) ) But then you lose the entry-level syncing capability?

I tried but on the thread page itself the reply button was missing under your comment. I guess I'll open the message direct link next time to reply when it's missing.

Re: Security Update

#189
post #160

Earlier quoted context omitted.

How do you update password storage if you don't store the passwords only hashes? You could upgrade it for new users, but for old ones? (e.g. I don't change passwords often)

You ask people to change their passwords, and when they do so, you store them with the new scheme. You can do that by e.g. requiring everyone to change their password on their next login/visit.

You don't even need to ask people to change their passwords; when they login, you have a copy of the original password, so you can just store the new hash over the old.
Post reply on HN