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

Yahoo discloses hack of 1B accounts

yahoo.tumblr.com

Post reply on HN
Print view View original

101–110 of 596 posts

Re: Yahoo discloses hack of 1B accounts

#101

Post by cimi_ »

ausjke wrote: post #24

I'm speechless. More and more are migrating to cloud these days, I expect more and more epidemic leakage will come. I host everything myself except for email, which is always a headache but contains more private info than all others I manage combined. Maybe it is time to run a small email server again but it is easily said than done, gosh please give me something like a working PGP or whatever for safe emails(PGP is…

> PGP is dying from what I read... Can you please provide some references for this? What are the alternatives?

Re: Yahoo discloses hack of 1B accounts

#102

Post by fencepost »

hbosch wrote: post #18

So, the scuttlebutt last time was that they disclosed the hack due to a potential Verizon buyout forcing their hand. Seems as though this could be the same thing, generally speaking. Can anyone enlighten me as to how Verizon compels Yahoo to disclose this information? Or rather, how does Verizon know about these intrusions, if they do?

I believe in this case Yahoo wasn't previously aware of the hack - they were notified by law enforcement, which presumably found a file of the information somewhere during an investigation. There was enough info to let them ID a time period, but nothing that lets them know the who/how of the breach.

Re: Yahoo discloses hack of 1B accounts

#103

Post by xanadohnt »

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 ?

The client can hold onto the token indefinitely, the server doesn't care. But next time a request comes in with that token it will be expired. The server validates the timestamp which is part of the encrypted payload that only the server can decrypt; instant validation and no DB lookup.

Re: Yahoo discloses hack of 1B accounts

#105

Post by ashark »

x0 wrote: post #75
dopamean wrote: post #56

Earlier quoted context omitted.

I'm genuinely curious how the decision to use MD5 gets made. Who says, "hey, maybe we should use MD5." And then who responds, "that sounds like a great idea Bob." Seriously. I've known for years that MD5 is insufficient for hashing passwords and I'm just some random guy. This kind of thing really baffles me.

And nobody ever seemed to say "hey, maybe we should be using something more secure". Yahoo's been around for how many decades, and the fact they were still using MD5 in 2013 is just shameful. Yeah if it was some legacy code from 1993 you can probably excuse it, but I just can't believe after 20 years nobody thought it was a problem. I'm not really a software developer but I really can't imagine it being a huge change…

Well, you can only rehash if you have the plaintext password. So you have to wait until they login again, or force a password reset for everyone. In the former case you're stuck with a bunch of md5 passwords hanging around for any account that's not very active, and for the latter you'll lose some percentage of active accounts whose reset process is for some reason no longer functional. You could mix-and-match the two methods (start with the former, force the latter on any stragglers after, say, a few weeks) to minimize the damage, but that's more work and a number that someone somewhere in the organization finds very important is still probably gonna go down.

(I've never had to do this myself, so these are just the most obvious options I came up with. Possibly there are others.)

Re: Yahoo discloses hack of 1B accounts

#106

Post by mikestew »

Klathmon wrote: post #53
mikestew wrote: post #44

Earlier quoted context omitted.

No, I pull up the answer out of 1Password and read it off to them.

Sorry, I meant to imply that the support person will hear the explanation and let you reset the password without the actual answer.

Fair enough, as I believe I've had that happen. Random string for one of my financial institutions, needed to reset something. Pull up 1PWD, with random string at the ready and...they asked me questions that could have been pulled from a copy of my credit report. I didn't ask, so I'm not entirely sure, but I wonder if they didn't look at the answer, said to themselves "fuck that" and went with Option #2.

Re: Yahoo discloses hack of 1B accounts

#107

Post by cm2187 »

stanleydrew wrote: post #61
dopamean wrote: post #56

Earlier quoted context omitted.

I'm genuinely curious how the decision to use MD5 gets made. Who says, "hey, maybe we should use MD5." And then who responds, "that sounds like a great idea Bob." Seriously. I've known for years that MD5 is insufficient for hashing passwords and I'm just some random guy. This kind of thing really baffles me.

Yahoo has been a company for a long time. I imagine your conversation happened round about 1999 when using MD5 wasn't insane. And then they were just slow to upgrade. It's still bad, I'm just saying the conversation about what hash algo to use didn't happen yesterday.

But it's not like if we didn't have a pretty much continuous stream of major data leaks for the past 5 years. Surely yahoo engineers occasionally open a newspaper...

Re: Yahoo discloses hack of 1B accounts

#108

Post by lotyrin »

stanleydrew wrote: post #61
dopamean wrote: post #56

Earlier quoted context omitted.

I'm genuinely curious how the decision to use MD5 gets made. Who says, "hey, maybe we should use MD5." And then who responds, "that sounds like a great idea Bob." Seriously. I've known for years that MD5 is insufficient for hashing passwords and I'm just some random guy. This kind of thing really baffles me.

Yahoo has been a company for a long time. I imagine your conversation happened round about 1999 when using MD5 wasn't insane. And then they were just slow to upgrade. It's still bad, I'm just saying the conversation about what hash algo to use didn't happen yesterday.

https://en.wikipedia.org/wiki/Salt_(cryptography)#1970s-1980...

Re: Yahoo discloses hack of 1B accounts

#109

Post by aidos »

_asummers wrote: post #87
x0 wrote: post #75

Earlier quoted context omitted.

And nobody ever seemed to say "hey, maybe we should be using something more secure". Yahoo's been around for how many decades, and the fact they were still using MD5 in 2013 is just shameful. Yeah if it was some legacy code from 1993 you can probably excuse it, but I just can't believe after 20 years nobody thought it was a problem. I'm not really a software developer but I really can't imagine it being a huge change…

Hashing the hash isn't a good idea, you're reducing the domain of your secure_hash function to the range of md5. The way to do it is to have a "password hash algo version" column and when the user puts in their password, you verify against the hash[algo](password) and rehash with the later version, changing the algo column for that user.

You could do both though. Give much more security in the short term and upgrade anyone else who logged in later.

I did ask about the hash of hash thing some time ago and ptacek claimed that's a reasonable thing to do.

Post reply on HN