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

441–450 of 596 posts

Re: Yahoo discloses hack of 1B accounts

#441

Post by lorenzhs »

pugz wrote: post #408
eric_h wrote: post #303

Earlier quoted context omitted.

> I don't like 2FA either That seems to be a rather dangerous position to hold these days. I personally dislike that googles 2FA is SMS based (unless there's a way to use e.g. Authy with it that I'm unaware of), but still seems that the only way to be reasonably safe is a strong password and 2FA. I'll add that The authy app on the Apple Watch has made 2FA for services that support it rather painless.

I use 1Password as my 2FA app for Google services. I only set it up relatively recently so maybe support for non-SMS is new. Or region-based?

It's been there for years. Since ~1yr ago they also support U2F (hardware token based, un-phishable)

Re: Yahoo discloses hack of 1B accounts

#442

Post by lorenzhs »

witty_username wrote: post #424

Anybody getting "NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED"? Chrome says "The server presented a certificate that was not publicly disclosed using the Certificate Transparency policy. This is a requirement for some certificates, to ensure that they are trustworthy and protect against attackers." Probably my Chrome version is too old I guess? (probably not, it's 53 which is only a little behind the latest).

Your Chrome version is indeed to old. There's an issue with Symantec certificates and Certificate Transparency in Chrome 53. Just update it.

Re: Yahoo discloses hack of 1B accounts

#443

Post by bschwindHN »

kijin wrote: post #418
dlubarov wrote: post #347

Earlier quoted context omitted.

I think it's best to allow longer passwords for those who use long phrases. It's easier to remember the full phrase than a truncated version. You could show a warning that the extra chars beyond 50-55 will be ignored.

Or you could SHA256 the original password and feed the hash to bcrypt. Remember to use the 64-byte hexadecimal hash, not the 32-byte binary because bcrypt chokes on null bytes. Everyone's been saying "just use bcrypt", but bcrypt has too many gotchas to be the default choice. We really need to work on getting scrypt and argon2 into the most popular programming languages and frameworks a.s.a.p.

Is "just use scrypt" an acceptable answer then? I'm not a security expert and I don't know the advantages of one over the other.

Re: Yahoo discloses hack of 1B accounts

#444

Post by WA »

Nobody in here mentioned it: phone numbers were leaked, too. Which I consider even worse.

I wanted to sign up for Flickr, but the Yahoo login requirement was a big turnoff, because it requires a phone number. This nagged me so much that I never did it.

Turns out: right decision. Because my 8 year old phone number isn't target of spam yet.

Re: Yahoo discloses hack of 1B accounts

#445

Post by merb »

danielweber wrote: post #329
Normal_gaussian wrote: post #145

Earlier quoted context omitted.

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…

> Now all token s auto-invalidate after a certain period. You need to make sure that there is some process that will refuse to keep on re-upping the cookie lifetime. Otherwise an attacker could indefinitely keep the stolen cookie alive.

You CBS Combine a session cookie with a jwt Token That get sent over a Header

Re: Yahoo discloses hack of 1B accounts

#446

Post by mypalmike »

jsjohnst wrote: post #346
manarth wrote: post #170

Earlier quoted context omitted.

Rainbow tables are attacks against secure algorithms. MD5 is recognised as an insecure algorithm: given a known hash, there are multiple possible passwords that would resolve to the same hash, therefore appearing to be the correct password. With MD5, it's not necessary to compute an infinite number of possible passwords, and it is possible that, given a particular hash, a collision can be found within a reasonable ti…

Either a) you don't have a clue about the complexity involved in finding a collision for a specific hash or b) your definition of "reasonable time" is longer than the age of the universe and/or using 100 trillion state of the art GPUs is realistic. I'm leaning towards option a, you read a blog post once and think you're an expert on cryptography now.

To be fair, pretty much every MD5 discussion I've ever seen or been involved in (including with "security expert" former coworkers) has had someone making the same claim.

Re: Yahoo discloses hack of 1B accounts

#447

Post by manarth »

jsjohnst wrote: post #346
manarth wrote: post #170

Earlier quoted context omitted.

Rainbow tables are attacks against secure algorithms. MD5 is recognised as an insecure algorithm: given a known hash, there are multiple possible passwords that would resolve to the same hash, therefore appearing to be the correct password. With MD5, it's not necessary to compute an infinite number of possible passwords, and it is possible that, given a particular hash, a collision can be found within a reasonable ti…

Either a) you don't have a clue about the complexity involved in finding a collision for a specific hash or b) your definition of "reasonable time" is longer than the age of the universe and/or using 100 trillion state of the art GPUs is realistic. I'm leaning towards option a, you read a blog post once and think you're an expert on cryptography now.

  > the complexity involved in finding a collision for a specific hash
If it can be shown that a preimage collision can be computed in less time than an exhaustive search, the algorithm is generally regarded as having a weakness, even if the given "less time" is still a very very long time.

The theoretical complexity of MD5 is 2^128, but a preimage attack was discovered in 2009 which showed that a collision can be found in 2^123.4. [1]

Collision attacks against MD5 have become more practical, there are even frameworks for it [2]. The complexity of 2^123.4 still makes a preimage attack against MD5 computionally unfeasible, but given that it's been shown to be weaker than its theorerical 2^128, it's possible that MD5 has other weaknesses which would allow the complexity to be reduced to a level that is computationally feasible.

[1] https://www.iacr.org/archive/eurocrypt2009/54790136/54790136...

[2] https://marc-stevens.nl/p/hashclash/

Re: Yahoo discloses hack of 1B accounts

#448

Post by manarth »

Buge wrote: post #394
manarth wrote: post #170

Earlier quoted context omitted.

Rainbow tables are attacks against secure algorithms. MD5 is recognised as an insecure algorithm: given a known hash, there are multiple possible passwords that would resolve to the same hash, therefore appearing to be the correct password. With MD5, it's not necessary to compute an infinite number of possible passwords, and it is possible that, given a particular hash, a collision can be found within a reasonable ti…

You are describing a first preimage attack. There have not been any computable first (or second) preimage attacks on md5. https://stackoverflow.com/questions/822638/does-any-publishe... There are collision attacks, but that is not relevant for password cracking.

From 2009: a preimage attack reduced the complexity from 2^128 to 2^123.4 [1].

It's still a big number, but it's less than the theoretical complexity.

[1] https://www.iacr.org/archive/eurocrypt2009/54790136/54790136...

Re: Yahoo discloses hack of 1B accounts

#449

Post by cm2187 »

schoen wrote: post #348
cm2187 wrote: post #282

Earlier quoted context omitted.

That being said md5 does generate collisions. I was playing with the IMDB movie database that you can download. They use a combination of the title and the year as a primary key. I tried using an md5 instead to save space (but giving a reproducible ID instead if an identity column), and got many collisions. No collision with SHA256.

Wait, what? No MD5 collisions at all were publicly known until Xiaoyun Wang disclosed one in 2004 using a new cryptographic technique she invented (explained in Wang and Yu's "How to Break MD5 and Other Hash Functions"). MD5 has a 128-bit output so collisions that occur by chance should require about 2⁶⁴ inputs (18 exa-inputs). Surely your database didn't contain over 2⁶⁴ different movie records. Could you take a loo…

You must be right. I can't reproduce it. I must have fucked something up then.

Re: Yahoo discloses hack of 1B accounts

#450

Post by [deleted] »

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

[deleted]
Post reply on HN