8 ms·

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 up

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.

cm2187 10y ago
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...
- Endy 10y ago
  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 going to discourage users from using Yahoo and send them over to GMail. Unfortunately... that argument wasn't wrong.
  - cm2187 10y ago
    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 the bcrypt hash you have stored. I am not a crypto expert but intuitively it doesn't look like I would have weakened the security that way. You can't really attack bcrypt(md5(password)) much more than bcrypt(password). Can you?
    - noonespecial 10y ago
      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.
      - cm2187 10y ago
        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-b6278bbe7495#.ekbaa699p https://xato.net/today-i-am-releasing-ten-million-passwords-...
        noonespecial 10y ago
        Very nice. Thanks for that. So yes, this is likely the thing to do in this situation.
        jsjohnst 10y ago
        I've done it before on a 1 billion word / password list and didn't get any collisions.
        cm2187 10y ago
        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.
  - tempestn 10y ago
    Especially about it being a bad idea to make people regularly change their passwords!
  - pbhjpbhj 10y ago
    > The problem was that the security team had to go head-to-head with the budget team. // Wouldn't engineers at such a big corp whistle-blow such incompetent decision making? Apparently [1] they had a $1.37B net income in 2013. Given using bcrypt with a Blowfish hash and salting was pretty much a de facto standard by that point (I think that's what Wordpress were doing, hardly revolutionary security work) it seems the relative cost for Yahoo was approximately zero. All I can imagine is that those in control were asked to leave the system open for government snooping? Why else would engineers working there not [anonymously] bring this to press attention - "hey, Yahoo security amounts to a piece of sticky tape holding a bank-vault shut". - - - [1] http://www.marketwatch.com/investing/stock/yhoo/financials# http://www.marketwatch.com/investing/stock/yhoo/financials#
    - danielweber 10y ago
      It's not that hard to implement something at the start. It's more work to retrofit it on top of an existing system in a way that doesn't reduce the total security.
lotyrin 10y ago
https://en.wikipedia.org/wiki/Salt_(cryptography)#1970s-1980s https://en.wikipedia.org/wiki/Salt_(cryptography)#1970s-1980...
throwaway34916 10y ago
I'd like to believe that. However, I was recently asked to test a new website for an organization I volunteer for, and discovered their "forgot password" flow emailed me my plaintext password. I wrote an explanation of why this was bad, and how it could be fixed, to a non-technical friend of mine who works there; he passed my email to the (Bay Area based!) consulting shop that did their website. The shop sent this response: "We do not store passwords as a plain text in database. We have functionality which encrypts and decrypts passwords. We have only ecnrypted passwords in the database. Almost all other servers use one-way encryption. In this case, passwords cannot be decrypted from hashing." Again, this is a Bay Area based shop. For code written in 2016. I was shocked to receive this, but it (among other things) leads me to suspect that there are lot of people out there, in positions of power, who aren't just ignorant, but who actively cling to password-storage anti-patterns. I'm at a loss for how to fix this.
- crazypyro 10y ago
  Just for clarity, the "forgot password" flow emailed you the current password of the account (not a temporarily one)? That's insane...
  - throwaway34916 10y ago
    Yes, the current password.
- wtfishackernews 10y ago
  submit the website to http://plaintextoffenders.com/ http://plaintextoffenders.com/
  - syncsynchalt 10y ago
    Ironically, hosted on a Y! site.

cm2187 10y ago

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

Endy 10y ago
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 going to discourage users from using Yahoo and send them over to GMail. Unfortunately... that argument wasn't wrong.
- cm2187 10y ago
  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 the bcrypt hash you have stored. I am not a crypto expert but intuitively it doesn't look like I would have weakened the security that way. You can't really attack bcrypt(md5(password)) much more than bcrypt(password). Can you?
  - noonespecial 10y ago
    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.
    - cm2187 10y ago
      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-b6278bbe7495#.ekbaa699p https://xato.net/today-i-am-releasing-ten-million-passwords-...
      - noonespecial 10y ago
        Very nice. Thanks for that. So yes, this is likely the thing to do in this situation.
      - jsjohnst 10y ago
        I've done it before on a 1 billion word / password list and didn't get any collisions.
        cm2187 10y ago
        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.
- tempestn 10y ago
  Especially about it being a bad idea to make people regularly change their passwords!
- pbhjpbhj 10y ago
  > The problem was that the security team had to go head-to-head with the budget team. // Wouldn't engineers at such a big corp whistle-blow such incompetent decision making? Apparently [1] they had a $1.37B net income in 2013. Given using bcrypt with a Blowfish hash and salting was pretty much a de facto standard by that point (I think that's what Wordpress were doing, hardly revolutionary security work) it seems the relative cost for Yahoo was approximately zero. All I can imagine is that those in control were asked to leave the system open for government snooping? Why else would engineers working there not [anonymously] bring this to press attention - "hey, Yahoo security amounts to a piece of sticky tape holding a bank-vault shut". - - - [1] http://www.marketwatch.com/investing/stock/yhoo/financials# http://www.marketwatch.com/investing/stock/yhoo/financials#
  - danielweber 10y ago
    It's not that hard to implement something at the start. It's more work to retrofit it on top of an existing system in a way that doesn't reduce the total security.

lotyrin 10y ago

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

throwaway34916 10y ago

I'd like to believe that. However, I was recently asked to test a new website for an organization I volunteer for, and discovered their "forgot password" flow emailed me my plaintext password. I wrote an explanation of why this was bad, and how it could be fixed, to a non-technical friend of mine who works there; he passed my email to the (Bay Area based!) consulting shop that did their website. The shop sent this response: "We do not store passwords as a plain text in database. We have functionality which encrypts and decrypts passwords. We have only ecnrypted passwords in the database. Almost all other servers use one-way encryption. In this case, passwords cannot be decrypted from hashing." Again, this is a Bay Area based shop. For code written in 2016. I was shocked to receive this, but it (among other things) leads me to suspect that there are lot of people out there, in positions of power, who aren't just ignorant, but who actively cling to password-storage anti-patterns. I'm at a loss for how to fix this.

crazypyro 10y ago
Just for clarity, the "forgot password" flow emailed you the current password of the account (not a temporarily one)? That's insane...
- throwaway34916 10y ago
  Yes, the current password.
wtfishackernews 10y ago
submit the website to http://plaintextoffenders.com/ http://plaintextoffenders.com/
- syncsynchalt 10y ago
  Ironically, hosted on a Y! site.