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

Security Update

stackoverflow.blog

Post reply on HN
Print view View original

201–207 of 207 posts

Re: Security Update

#201

Post by thaumasiotes »

AstralStorm wrote: post #198
thaumasiotes wrote: post #138

Earlier quoted context omitted.

At 123 bits, you're five bits short of the 128 bits I calculated with. I don't think a medium sized botnet can rise to the level of doing 8 quadrillion years of work within your lifetime. What problem are you trying to solve? As I understand it, we're discussing enumerating the hash space, such that: 1. You are given a hashed value, such as 2b0f4e60b80da7ef1e84573d764f1bf4 . 2. The value is someone's hashed password.…

You do not do this by brute force. You can assume the system uses a certain salt pattern, e.g. 4 byte prefix or 8 byte prefix or suffix. This can reduce work from full crack to some 40 bit crack. (Guess salt then presume stupid concat scheme, use collision attack to get matches.) That one is doable on a modern PC on a GPU. It is a targetted attack. The mass variant are salted rainbow tables. You usually do not even h…

Please try to describe the actual attack you're talking about. What do you have, what do you want, how do you get it.

Re: Security Update

#202

Post by dagenix »

viraptor wrote: post #181
dagenix wrote: post #149

Earlier quoted context omitted.

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

If that were the case, his advice ought to have been something like "use libcrypt with SHA-2" or something like that. Just "use SHA-2" was kinda useless in 2007 and hasn't gotten more useful since then.

Re: Security Update

#203

Post by dagenix »

killjoywashere wrote: post #154
dagenix wrote: post #149

Earlier quoted context omitted.

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

To be fair, Jeff's post was written in 2007 ... this predates Khanna's PS3 clusters. CUDA was released the same year. So I'm not sure it would be obvious in 2007 that SHA-2 would be "worthless for storing passwords".

PBKDF2 seems to have been specified in 2000 as part of RFC 2898 [1] and, IIRC, existed before then. Bcrypt is from 1999 [2]. Both of those algorithms were explicitly designed to be slow. My understanding is that PBKDF2 wasn't explicitly designed for password storage, but that it was recognized as being useful for that early on. Bcrypt was explicitly designed for password storage. The article referenced came out 7 years later. IMO: there was evidence that salted SHA-2 was not secure.

[1] - https://tools.ietf.org/html/rfc2898#section-5.2 [2] - https://en.wikipedia.org/wiki/Bcrypt

Re: Security Update

#204

Post by dagenix »

blowski wrote: post #153
dagenix wrote: post #149

Earlier quoted context omitted.

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

He wrote it in 2007.

He said to use Bcrypt or SHA-2. One of those algorithms was explicitly designed for password storage, the other was not. They aren't really the same class of algorithm. As such, it doesn't really make sense to suggest one as an alternative to the other. Nobody ever suggests uses Bcrypt as the hash in a hashtable - even if it technically could be made to work. GPUs that could crank through trillions of hashes per second might not have existed, but, that doesn't make it good advice. Good advice would have been "use bcrypt or, if you can't, PBKDF2 (or maybe some other library that implements a variant of one of those)"

Re: Security Update

#205

Post by 0xffff2 »

rcfox wrote: post #199
0xffff2 wrote: post #196

Earlier quoted context omitted.

Unless I'm badly misreading something, the unsalted hashes in that post were on some other (unspecified) site unrelated to Stack Overflow.

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

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

Re: Security Update

#206

Post by smitop »

Sea_Wulf wrote: post #60
9nGQluzmnq3M wrote: post #40

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…

If Stack Overflow's enterprise knowledge management systems were breached then that could potentially be a big deal. A release of knowledge on development and production systems from companies could potentially lead to larger hacks in the future. Of course, that is all speculative until the extent of the breach is released. From the press release, they seem to imply that the only affected areas were public facing.

Stack Overflow Enterprise is either self hosted or hosted by SO, but on a individual Azure server instance, so each instance would probably need to be compromised individually. SO will probably release an update for Enterprise customers that scans server logs to check if that Enterprise customer was affected.
Post reply on HN