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

191–200 of 596 posts

Re: Yahoo discloses hack of 1B accounts

#191

Post by cm2187 »

noonespecial wrote: post #184
cm2187 wrote: post #141

Earlier quoted context omitted.

But would it require users to change their password? The way I would have implemented it, but would be keen to know how secure it is, is that you start with the md5 of the password ( md5(password) ). You then bcrypt or scrypt that md5 ( bcrypt(md5(password)) ) and replace the md5 in your database with the bcrypt hash. When a user logs in, all you need to do is to calculate the md5 first then check that md5 against th…

The problem is in collisions. Md5(password) can yield the same result for many different values of password so simply bcrypting that result means that you start with a restricted possibility space. So less secure. Punts the question to how much less secure. Seems to me it would still be worth it to do and then all new passwords going forward are done correctly.

Agree, but a collision even for md5 is a relatively rare event. When brute-forcing the bcrypt hash, this would reduce the attempts you would need to try against a given hash, but only by a very small factor. With a reasonable work factor, I would assume it would still make a brute force attack impractical at scale.

I didn't do the test, but I'd expect that there wouldn't be more than a handful of collisions for the md5 of the 100m most common passwords.

[edit] I actually I just did the test on this 10m password list and no collision

https://xato.net/today-i-am-releasing-ten-million-passwords-...

Re: Yahoo discloses hack of 1B accounts

#192

Post by manarth »

longwave wrote: post #124
inopinatus wrote: post #92

Earlier quoted context omitted.

By now I suspect you can simplify it down to just matching on the RHS for any domain registered to Yahoo.

A number of ISPs have used Yahoo to provide mail services in the past, so it's probably not quite as straightforward as that.

And not just small ISPs, but major ISPs, such as BT (with 32% of the broadband market-share in the UK).

Re: Yahoo discloses hack of 1B accounts

#193

Post by trevyn »

cmurf wrote: post #111

OK so I'd like to invite the pure free market types to explain how this gets fixed without any government, including no lawsuits. Because I keep hearing from free market types that 100% of phishing victims are ignorant and basically deserve what happens to them, if they can't learn that they're being duped they deserve to be duped, they somehow think wholesale loss of trust ends up being focused only on specific comp…

I think "free market types" understand and accept that the world is a messy place, and that human organizations cannot generally be trusted to consistently do what they claim. ("Your information is safe with us", etc.) I believe that this is due to fundamental properties of human nature and group psychology.

I believe that there is no general way to create near-perfect accountability for the statements of people, and that the second-best option is to embrace the uncertainty and develop a finely-honed sense of risk assessment.

It sounds like this is the underlying concern -- if you are unable to appropriately assess risk, and you place your trust in an organization that then betrays your trust, you feel violated and want to work toward preventing that sense of violation in the future.

You could do that by working to hold organizations accountable through regulation or other means.

Or you could improve your ability to assess risk, and consciously and deliberately accept risks as they come. When the inevitable adverse event happens, you understand that you consciously accepted a risk in the past, and appreciate the opportunity to refine your own personal ability to evaluate risk.

So, I don't agree that this is something that needs to "get fixed". I fully expect that my basic personal information is poorly secured, and I consciously accept that in exchange for the benefits of participating in our current society and using the current services offered.

It's easy to say that "we need better information security", but every decision has a tradeoff. Increasing security fundamentally increases costs, slows the flow of information, and creates less nimble organizations. Many of the services you expect to be available -- Uber, cheap IoT devices, whatever -- may simply not exist in a world where a "proper risk assessment" and "tangible cost" of information breaches are applied.

You, of course, are free to spend your time educating the public about information security, or how corporations can't be trusted, or even lobbying for information security regulation. That's what makes Earth fun and interesting -- everyone's following their own passions!

Re: Yahoo discloses hack of 1B accounts

#194

Post by lotyrin »

cm2187 wrote: post #141
Endy wrote: post #123

Earlier quoted context omitted.

From everything I've read, the engineers did. The problem was that the security team had to go head-to-head with the budget team. And unfortunately, the budget team won - since the upper levels didn't feel that the IT security salaries were a necessary expenditure. And beyond that, there was concern that making people actually change their passwords regularly and requiring anything like security in said passwords was…

But would it require users to change their password? The way I would have implemented it, but would be keen to know how secure it is, is that you start with the md5 of the password ( md5(password) ). You then bcrypt or scrypt that md5 ( bcrypt(md5(password)) ) and replace the md5 in your database with the bcrypt hash. When a user logs in, all you need to do is to calculate the md5 first then check that md5 against th…

The method I've used is to add the column for the new stronghash then you update the old column to stronghash(), where is dumbhash(password) check against that on login stronghash(dumbhash(password)) and generate just stronghash() while you have the plaintext password in memory and update the row to add the new hash (simple and interoperable, not dependent on dumbhash) and drop the stronghash(). After a limit (to optimize both maintenance overhead of the additional column / behavior and limit exposure to only minority users that haven't logged in for ), you drop the stronghash() from everyone and do a "we sent you a reset email" for anyone that's trying to log in but has no password hash.

Re: Yahoo discloses hack of 1B accounts

#195

Post by eric_h »

Endy wrote: post #153
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…

If Yahoo goes down, I won't have email; or at best I'll maybe keep a Zoho. I hate Google's mail interface, I hate the way they make 'conversations' out of discrete emails, and I especially hate their lack of folders. I use GMail begrudgingly at work, and only when necessary, and every time, I look at it and go, "what dipshit ever thought this was a functional way to deal with email?" As a dedicated Windows user, I'm…

> I hate Google's mail interface

Their IMAP interface is both standards compliant and fully functional. I'm not terribly fond of the Gmail web/native apps either, so I just don't use them (though I do occasionally hop on the web app when my client isn't searching the email as effectively as google does).

With 2FA it can be a bit more work adding devices, but it's not a deal breaker for me.

Re: Yahoo discloses hack of 1B accounts

#196

Post by mschuster91 »

ozten wrote: post #151
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…

For an IdP at the scale of Yahoo, the can adopt something as complicated as supporting versioned passwords and migrating credentials to the latest secure algorithm upon successful login. You have the clear text password at that point. You can store metadata such as the version (or algorithms) used to hash the credential.

Complex?!

It's easy as hell. Even PHP, so often flamed for "bad security" these days supports EASY functions for this (and polyfills are available, if you're running PHP - password_hash, which creates a salted hash (the returned value consists of a type/strength spec, the hash, and the salt)

- password_verify, which verifies a password with a hash in a timing-safe manner

- password_needs_rehash, which tells you if you should update the hash in the database

password_hash and password_needs_rehash take a parameter for the hash function (currently only bcrypt is supported, quite likely to keep people from using md5/sha1), and for the cost (the amount of hash function calls).

I believe any reasonable programming language these days has such functions.

What I am NOT so sure about is how the various LDAP server implementations, which many people use for SSO and "normal" account management (because it's easier to connect a new software to LDAP than to migrate existing user db's into LDAP), handle password storage. I mean, having an LDAP server for the credentials prevents any form of password leakage, but in case someone breaches both servers/the LDAP daemon is running on the same host as the webserver?

Re: Yahoo discloses hack of 1B accounts

#197

Post by dsl »

alyandon wrote: post #11

"Separately, we previously disclosed that our outside forensic experts were 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." So that exactly explains how my Yahoo account was used to send spam despite having a pa…

The forged cookie attack was used on a limited number of accounts, by a state sponsored actor. Going to this amount of effort and then sending spam would be on par with breaking into a bank just to steal the printer paper from the office.

Most likely either: 1) you were phished and didn't realize it 2) logged in to your Yahoo account from a device that had malware on it

Re: Yahoo discloses hack of 1B accounts

#198

Post by metafunctor »

JonDav wrote: post #136
metafunctor wrote: post #94

Earlier quoted context omitted.

A preimage attack for MD5 has complexity of about 2^123. So, even if you get the MD5 hash for a password, it will be exceedingly hard to find a password that has the same hash (assuming the original password is long and random).

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 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 the same hash).

The best known preimage attack against MD5 has complexity 2^123. It's better than brute forcing, but still unpractical. Thus, if I come up with a good password that is long and random, you will have a very hard time coming up with a string that has the same MD5 hash value.

The practical attacks against MD5 are collision attacks. A collision attack tries to find two messages with the same hash value. With MD5 in particular, there's a chosen prefix collision attack, where you choose two messages and append to them so that the hashes will match. This was particularly devastating with X.509 signatures and certificates, where the attacker could have the MD5 hash signed by a certificate authority, and then use the same signature with their other message that has the same MD5 hash.

Post reply on HN