Yahoo discloses hack of 1B accounts • Hacker News Board

Re: Yahoo discloses hack of 1B accounts

#331

Post by haser_au » Thu, Dec 15, 2016, 2:02 AM UTC

pbhjpbhj wrote: post #302

haser_au wrote: post #98

Earlier quoted context omitted.

There are likely to be a lot of identity systems using the password in the database, all of which have been coded to look for an MD5 hash, not a salted hash. This means code in a number of applications have to be updated at the same time. The typical way around this is to create your new destination column (e.g. sha256 with salt), and progressively have applications reference this column rather than the MD5 unsalted…

>It's a huge amount of work // Really? Moving from doing md5(password) to bcrypt(password,salt)? I see organisations make things hard and legacy code-base, yadda, yadda but surely if Yahoo couldn't do this then they couldn't manage scratching their own butt; it really seems like quite a small change in the scheme of things. Like one senior engineer, one afternoon of work (then testing, etc., OK, sure) ... ?

"It Takes 6 Days to Change 1 Line of Code" https://news.ycombinator.com/item?id=13119138

I'm going to go out on a limb and guess you've never worked as a software engineer in a large organisation.

Given MD5 hashes are currently stored, how do you propose user's password get converted to SHA256/512? Should Yahoo brute force the passwords, and then store them in the new algorithm? Or should they wait for the user to log on, verify their password, and store it in the new hash algorithm (given some users rarely log on, this could take over 12 months to complete 80% of users).

Re: Yahoo discloses hack of 1B accounts

#332

Post by edibleEnergy » Thu, Dec 15, 2016, 2:03 AM UTC

camus2 wrote: post #36

xanadohnt wrote: post #29

Earlier quoted context omitted.

Web tokens, for example, don't necessarily include just a session ID. Some include the full session details within its payload. This can be quite useful, actually, because it offloads session-lookup onto the client.

How do you invalidate a JWT server-side without the user interacting with the server ?

This is possible if you support the 'jti' claim[1]. There's a discussion of an implementation of it here[2].

[1]: http://self-issued.info/docs/draft-ietf-oauth-json-web-token... [2]: https://auth0.com/blog/blacklist-json-web-token-api-keys/

Re: Yahoo discloses hack of 1B accounts

#333

Post by EGreg » Thu, Dec 15, 2016, 2:09 AM UTC

I didn't know Yahoo had 1B accounts. Most must not be active, otherwise how could they be so small financially compared to Facebook and Google?

Re: Yahoo discloses hack of 1B accounts

#334

Post by jsjohnst » Thu, Dec 15, 2016, 2:11 AM UTC

cookiecaper wrote: post #328

drodgers wrote: post #315

Earlier quoted context omitted.

If the password is stored properly, (i.e. bcrypt) then there does need to be some length limit or it becomes too easy to DoS a service by sending it hundreds of megabytes of password to bcrypt. There's no reason for that length limit to be less than 100 characters though.

Yep, people who've run marginally popular sites have dealt with this before. Give someone a text box and watch them try to stuff 4GB of content in it. There has to be a cutoff somewhere, but as you note, it should be well outside of the realm of reasonable password lengths (hundreds of characters).

GitHub is the only website I can think of off the top of my head that doesn't limit to an arbitrarily small number (aka <100). Do you name any other "major" websites that allow 100 character passwords?

Re: Yahoo discloses hack of 1B accounts

#335

Post by danielweber » Thu, Dec 15, 2016, 2:11 AM UTC

semicolon_storm wrote: post #177

JonDav wrote: post #136

Earlier quoted context omitted.

I thought the whole point of the MD5 vulnerability was that the limit was 2^128 and as such there are more inputs that possible output hashes, meaning more possible input collisions.

All hashing algorithms that I am aware of have more inputs than outputs. By the pigeon hole principle, there will always be collisions. MD5 is weak, but it still isn't trivial to find an input that hashes to the same thing as a high entropy password.

> that hashes to the same thing as a high entropy password.

To be clear, it's not the entropy of the original password that matters, except for the fact that all common low-entropy passwords already have their MD5s stored in public databases. (What hashes to 5f4dcc3b5aa765d61d8327deb882cf99? You can look it up with Google.)

You can come up with two plaintexts that hash to the same thing in MD5. You can't come up with something that hashes to a new MD5 value given to you, aside from finding it in one of those databases.

Re: Yahoo discloses hack of 1B accounts

#336

Post by knz » Thu, Dec 15, 2016, 2:12 AM UTC

Normal_gaussian wrote: post #145

camus2 wrote: post #36

Earlier quoted context omitted.

How do you invalidate a JWT server-side without the user interacting with the server ?

My preferred method: Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period. Allow some or all tokens to "refresh" by calling a particular endpoint (call with valid token and get a token with expiry from now). Optionally add some form of identifier to the token (user_id works great) so that you can push a message…

> Add an "expires" field to the token, this should contain a date after which the token is no longer valid. Now all token s auto-invalidate after a certain period.

Doesn't JWT already have this - "exp" is a reserved claim for expiration time?

https://tools.ietf.org/html/rfc7519#section-4.1.4

4.1.4. "exp" (Expiration Time) Claim

The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim.

Re: Yahoo discloses hack of 1B accounts

#337

Post by CobrastanJorji » Thu, Dec 15, 2016, 2:12 AM UTC

jsjohnst wrote: post #260

mturmon wrote: post #247

Earlier quoted context omitted.

Yet, somehow they did get out.

Apologies, I've heard the details at this point and I can't disclose them. The limit of what I can do is poke holes in the theories that are wrong.

Aren't the details "three years after we were hacked, law enforcement told us that we had been hacked, and we believe them?"

The press release explicitly says "We have not been able to identify the intrusion associated with this theft." I especially noticed that the "What are we doing to protect our users?" section doesn't mention anything about Yahoo fixing any security issues.

Presumably, then, as a Yahoo engineer, you know what your security practices are but you don't know what you did wrong or whether you've fixed it.

Re: Yahoo discloses hack of 1B accounts

#338

Post by sqldba » Thu, Dec 15, 2016, 2:13 AM UTC

phantom_oracle wrote: post #89

there's a couple of things that these major providers getting pwned teaches you: 1) their security isn't good just because of their scale/size (that begins to seem more and more like a false-assumption nowadays) 2) migrating your email to a new provider is quite difficult (consider that the average person will have just 1 - or 2 - email accounts and they link EVERYTHING to it) 3) the price of ads/convenience is no lo…

What irritates me is that there's really no safe place for email.

Even if you pay for a host they still have access to it all. You have to really trust them.

If you try to set it up at home you need a static IP and need to be prepared for it never working because of spam filters and stuff not trusting dinky self hosted services.

And no matter what you do - barring PGP which nobody uses - it's all sent over plain text anyway.

But that's less worse than anyone having your entire email life with one hack. Sigh.

Re: Yahoo discloses hack of 1B accounts

#339

Post by danielweber » Thu, Dec 15, 2016, 2:15 AM UTC

JonDav wrote: post #130

ubercore wrote: post #79

Earlier quoted context omitted.

What do you mean by a password that can't be reasonably brute forced? EDIT: To clarify, I mean specifically with md5. I'm by no means an expert, just curious because I had considered md5 so broken that this comment caught my attention.

Pretty much even if you choose a high entropy password like say: `]{;& rQQQjoJkxm0ayM+gG,@vf*>#-{X4E>aZG(A1~tf the MD5 algorithm can be broken using various techniques like collisions, unsalted I believe means that their database would accept the hashes the third party has. End result is they should have migrated away from MD5 after it was declared unsafe.

No it can't.

Two principles here:

1. If your password is very very good (a Diceware password would suffice), then any method of storing passwords that is better than storing them in plaintext will stop someone from brute forcing it.

2. If your password is very bad, then even an excellent password hashing algorithm will not save you.

"Just use bcrypt" is meant to save people who are in the middle.

Re: Yahoo discloses hack of 1B accounts

#340

Post by wapz » Thu, Dec 15, 2016, 2:16 AM UTC

I logged into my yahoo email in chrome in an incognito tab and it logged into someone else's account. This was probably in 2014 (it could have been in 2013). I wonder if this was related at all.