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

521–530 of 596 posts

Re: Yahoo discloses hack of 1B accounts

#521

Post by slig »

barking wrote: post #487
Tepix wrote: post #485

Earlier quoted context omitted.

I've changed my paypal email twice in the past already when I started getting too much spam. Regarding 2FA at Yahoo!, I've also had issues... SMS stopped arriving altogether and I had to disable it.

Paypal says I can't change it because it's my primary email address. I prefer using authenticator anyway rather than sms 2fa and yahoo don't offer that it seems

Maybe you have to add a new email to your paypal account, then change it to be the primary and then delete the old one.

Re: Yahoo discloses hack of 1B accounts

#523

Post by rietta »

aaronbasssett wrote: post #475
amenghra wrote: post #457

Earlier quoted context omitted.

Yes, scrypt is a perfectly fine password hash. If you are currently using something else (say salted md5 or even just plain md5), you can migrate your passwords to scrpyt(current_hash()) without having to change everyone's password and/or wait for everyone to log in. See also this comment thread: https://news.ycombinator.com/item?id=12549110

Don't do that. You've essentially just turned the old hashes into plain-text passwords, and how sure are you that those hashes don't exist in backups anywhere?

No, not exactly. An adversary who has the old hash, but not the plaintext that it represents cannot login because scrypt(H(H(value))) != scrypt(H(value)). This is not considering the offline crackability of a compromised hash. But there are legitimate situations where upgrading the password backing to a modern slow hash is preferable to continuing to use the old hash or worse storing the old hash as a field for a long time so that when a breach happens both the new and old hashes are available.

There are user experience battles when talking about forcing a million users to change their passwords in a real system. Hashing the hash may be vastly preferable to management nixing the security upgrade. A password updating schema that changes the hash as users login and eventually locking the accounts of users who have not logged in for an extended period of time can accomplish rolling the hashes without having to tell users to change their passwords.

Re: Yahoo discloses hack of 1B accounts

#524

Post by metafunctor »

bartl wrote: post #518
metafunctor wrote: post #198

Earlier quoted context omitted.

All hash functions have collisions. The point is that a good cryptographic hash function makes it very hard to find collisions. The “preimage attack” on a cryptographic hash function tries to find a message that has a specific hash value. That is, you lock down a hash value (the MD5 hash for a password) and try to find a message that hashes to that value (the original password, or any other input that happens to have…

What about Rainbow Tables? ( https://en.wikipedia.org/wiki/Rainbow_table#Precomputed_hash... ) Instead of computing the MD5 of a huge number of passwords looking for a match, you simply store the precomputed password and hash pairs in a database table.

A rainbow table is just a precomputed table of hashes for a lot of passwords. Some tricks are used to make the table smaller, but you can think of it as just a lookup table. Only the passwords that were precomputed and put into the table will be found.

Rainbow tables are usually computed for short passwords (1-10 characters) and limited character set (say, alphanumerics). They are good for finding the bad passwords if you get your hands on a set of MD5 hashed passwords. But they are of no help if you need to reverse a good, long, random password.

Re: Yahoo discloses hack of 1B accounts

#525

Post by jupp0r »

jsjohnst wrote: post #31
niftich wrote: post #14

> August 2013 > hashed passwords (using MD5) I don't even know what to say. > investigating the creation of forged cookies that could allow an intruder to access users' accounts without a password. Based on the ongoing investigation, we believe an unauthorized third party accessed our proprietary code to learn how to forge cookies How is this possible? Aren't most auth cookies just a session ID that can be used to lo…

1) As Yahoo "upgraded" all password storage in UDB (where all login / registration details are stored) to be bcrypt before 2013, I'm curious how this was possible. 2) Yahoo doesn't use a centralized session storage. If you know a few values (not disclosing the exact ones) from the UDB, it's theoretically (guess not so theoretical now) possible to create forged cookies if you steal the signing keys. To my knowledge, t…

> 1) As Yahoo "upgraded" all password storage in UDB (where all login / registration details are stored) to be bcrypt before 2013, I'm curious how this was possible.

You check the plaintext password sent to the backend against the md5, on success you rehash it as bcrypt, insert it in the table.

Re: Yahoo discloses hack of 1B accounts

#527

Post by hobarrera »

mkj wrote: post #480
2sk21 wrote: post #473

Earlier quoted context omitted.

This is a terrible policy. Do other email providers have a similar policy?

Probably not that terrible if they only do it for accounts that were created and never used. Like all the good GitHub usernames that seem to be abandoned.

GitHub usernames and emails are very different things. You don't get password reminders sent to your github profile, but you can get those via email.

BTW, no, most email providers never allow the reuse of close account names.

Re: Yahoo discloses hack of 1B accounts

#528

Post by 0xfeba »

XorNot wrote: post #403
cookiecaper wrote: post #328

Earlier quoted context omitted.

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

Hash the password locally (you are serving JavaScript over SSL right?) and only send the SHA256.

How would you know that the hash is of a password of sufficient entropy?

Re: Yahoo discloses hack of 1B accounts

#529

Post by ausjke »

ticoombs wrote: post #455
ausjke wrote: post #371

Earlier quoted context omitted.

good to know that, not sure if aws is better as far as IP-range-blocking is concerned.

Hey just to let you know I host ~300 domains on 1 aws instance. We only have issues when a clients password gets phished, but we also have a limit on the amount of emails per day they can send. So it's never a real issue. ~20,000 emails a day Going on 4 years. AWS "blocks" are perfectly fine. If you are going to host your own just get your self an Elastic IP and let your account manager know that you intend to send m…

for [1] do you mean http://www.iredmail.org/ ? never heard about redmail.com though.

Re: Yahoo discloses hack of 1B accounts

#530

Post by keehun »

djhworld wrote: post #519

Yahoo is so frustrating I got the email this morning regarding the hack, I've not used Yahoo for a long, long, long time, so figured I would go and delete my account. So I log in, password in 1password is incorrect, no big deal I go to reset it. They send me an email, I reset the password then go through the account deletion process. It tells me my account is "deactivated" and will be deleted in 90 days ...Once that…

If your account name is related to identifiable to you in any way and could potentially be used to spoof your identity, you shouldn't delete it because Yahoo will let a new user take your account's address.
Post reply on HN