back to article Security! experts! slam! Yahoo! management! for! using! old! crypto!

Fallen web giant Yahoo! has been branded negligent for failing to tackle the prodigious challenge of upgrading its MD5 password hashing before some one billion accounts were stolen. The security-battered organisation revealed today that attackers had stolen more than a billion accounts in August 2013 in history's biggest …

  1. smartermind


    Have a Yahoo! account... but it has no real data on it so the crooks are welcome to it. Hope the scum choke on it, though!

    As for Yahoo!, put the dunces hat on and stand in the corner of the class, facing the wall!

    1. asdf

      Re: Yawn

      Yahoo will be remembered more for getting lucky investing in the right Asian companies than anything they ever did as a company (except supposed poker bad azz Jerry Yang stupidly walking away from a payday at the worst time). Geocities tell no tales (except for library nerds on the Wayback machine).

  2. Dan 55 Silver badge

    Never mind, we can use Yahoo's wonderful secure mobile sign-on app instead of passwords

    Oh. That gives them your phone number which has just been stolen.

    1. Adam 52 Silver badge

      Re: Never mind, we can use Yahoo's wonderful secure mobile sign-on app instead of passwords

      This is the real point. Who cares about the passwords being poorly secured when they've already lost everything the passwords would have given access to anyway.

      From the FT:

      "Among the information taken were unencrypted security questions and answers, potentially arming hackers with personal details such as pets’ names, parents’ maiden names and memorable dates that they could use to access many other online accounts."

      They could have used bcrypt with a billion iterations, it wouldn't matter. Like having a massively secure lock on a gazebo.

  3. Adam 1

    The big benefit with salting is that you can't leverage knowledge about one user's password to determine someone else's. Md5 was considered a bad choice 10 years ago. Why were yahoo still using it is a big mystery. It is literally broken to the point where you can google the hash to reverse it.

    If you aren't using salt, you find someone with the password hint "password is Bernie2016" and now you know what all those F1697D2047065D93EECFEC16D670CD61 hashes mean. At least with salt you have to brute force each user independently.

    And now you have that detail, you can use enumeration attacks on other sites to see what other accounts are valid and then try your luck with the same password.

    Lesson 1

    Use a different password on each website, so your yahoo breach doesn't give away your other more important passwords.

    Lesson 2

    Use long passwords. 4 random English words (like random, not quotes, verses or xkcd comics). This will guarantee that it is easy to memorise and type yet is too much entropy to exist in a rainbow table.

    Use a password manager if you find that easier.

    1. Paul Hargreaves

      > This will guarantee that it is easy to memorise

      I currently have 775 sites, with 869 passwords total. 67 entries are duplicates. I'll fix those soon(tm).

      Even if that was only 100 passwords, it'd still be impossible to remember anything but a few of the most recent ones.

      Especially when some sites, internal systems etc demand frequent password changes, $tup1d p4$$w0rd$ L1K3 it'll make any differenc3. And then there are sites where you have multiple accounts.

      Password management in general is broken. Tools like 1password/Lastpass help, but overall the whole thing is just utterly tosh. I don't have a better alternative, but you can't blame the users for using the same password everywhere...

      1. Pascal Monett Silver badge

        Re: "you can't blame the users for using the same password everywhere"

        Well, not to throw the stone, but when it comes to keys and locks, somehow they understand the importance and manage.

        Of course, this begs to consider whether or not users would use the same key everywhere if they could configure the locks. I'm guessing they likely would.

        There is no good solution right now, but I try to explain the password/lock similitude to get the message across. Of course, I have no control over how long my words may influence their behavior.

        1. Paul Hargreaves

          Re: "you can't blame the users for using the same password everywhere"

          Two 'key' differences (sorry):

          1) How many keys (and doors) do you realistically have? Car, house, err... car, house. Even with 10 keys, it's a problem of scale.

          2) > 'users would use the same key everywhere if they could configure the locks. I'm guessing they likely would.

          Absolutely they would! So do jailers, janitors, etc. But that's again a scale issue, even if a key was stolen and not recovered, how many locks would you need to change?

          On the internet though, changing 100's of passwords isn't going to be practical.

          OpenID tried to have a go at this but my bank won't accept it, neither will El-Reg, so it's dead to me.

      2. Prst. V.Jeltz Silver badge

        "I currently have 775 sites"


        i have about a dozen i think

    2. asdf

      >Use a password manager if you find that easier.

      KeepassX is offline open source and cross platform. Sure there are others but it comes on Tail OS (IIRC) by default so has to be doing something right.

  4. Anonymous Coward
    Anonymous Coward

    1-Billion... Watch a load of politicians & data regulators:

    * Scramble to do absolutely nothing. This is a monumental problem for the Irish DPC for example. I don't think they sell solutions next door at the local Centra / Spar either. Except maybe a bottle of whiskey to drown sorrows and help us forget!

    * Learning points? We're on our own! Everyone is vulnerable on some level too, as long as someone in your circle of friends / family / co-workers has a Yahoo account.

    * Because some of these accounts will have been cracked open and juicy data therein will have been slurped to Hacker-DB... New attack vectors here we go...

  5. Chewie85

    Real info?

    Seriously who puts real info into anything online? I mean banks are the only real exception. Everything else is just a comical farce as far as i am concerned. "what is your favourite colour?" first three lines of book xyz. simples. Oh yeah and never repeat passwords for different services! That is just asking for trouble.

  6. juul

    Salte or unsalted

    If they had used a salt, they would be sure to mention it.

    So expect that they did not use salted MD5.

  7. Destroy All Monsters Silver badge

    "The MD5 hashing algorithm has been considered not just insecure, but broken, for two decades," says Ty Miller, director of Sydney-based security firm Threat Intelligence, noting that MD5 collision vulnerabilities were found in 1996 with practical attacks developed in 2005.

    Which is COMPLETELY irrelevant when talking about salted and hashed passwords.

    Some director of a security outfit (ok, he's just the director, tech knowledge may not be his strong point).

    The only problem with MD5 here is that it can be computed too efficiently (and then you get a made-up Yahoo account)

    How to securely hash passwords?

    However, collisions are not an issue for password hashing. Password hashing requires the hash function to be resistant to preimages, not to collisions. Collisions are about finding pairs of messages which give the same output without restriction, whereas in password hashing the attacker must find a message which yields a given output that the attacker does not get to choose. This is quite different. As far as we known, MD5 is still (almost) as strong as it has ever been with regards to preimages (there is a theoretical attack which is still very far in the ludicrously impossible to run in practice).

    1. Adam 1

      You are right in pointing out that the brokenness of md5 isn't the key issue here. I mean, broken when talking about cryptographic hashes is a technical term which basically means that there is a more efficient algorithm to discovering the input than to brute force it.

      It's big flaw here is that we have much better hardware now and can do most of the computations on GPUs at rates best measured in "billions per second". That makes brute force attacks for passwords under 7 characters practical and dictionary attacks highly likely to spill the beans in a substantial percentage of records.

      Collisions just get you another password that the system would accept. In other contexts they are more worrying. The following link gives 2 example executables that do different things but have the same md5 hash.

      But at the end of the day, it's much less effort to try hundreds of billions of combinations of words, common letter substitutions, common prefix and suffixes and passwords found inside plaintext password dumps. The attackers here won't be worried if they can't unlock all accounts. Even if it's "only" tens of thousands, they can still use it as a steppingstone to attacking other services a user might have, doing a ransomware on flickr photos or whatever or resetting passwords for other non yahoo services they find emails for.

      1. patrickstar

        MD5 + salt and multiple rounds is not necessarily a bad choice even today if constraints demand it - eg. no existing implementation of other crypto for some oddball platform, or (more common) you have an existing user database with plain MD5'd passwords and want to spice it up.

        Like, you make your password hashing do:

        HASH(password) followed by HASH(salt | round | previous output)

        and can convert your existing password hashes by simply running them through the same procedure but skipping the initial hash.

  8. EnviableOne

    Ok so migrating has to reset passwords... thats a joke

    why they did not encrypt the MD5 hash with salted bcrypt

    and flag it for password change?

    its been done elsewhere.

    1. Jack Douglas

      exactly what I was going to ask — though you mean "hash the MD5 hash with salted bcrypt", not "encrypt the MD5 hash with salted bcrypt"

      1. Destroy All Monsters Silver badge
        Thumb Up

        Ah! Good idea. Evident in retrospect...

  9. allthecoolshortnamesweretaken

    I think the price for Yahoo! just went down again. If Verizon can manage to draw out the negotiations just a little bit longer they should be able to pick it up for a song and a dance.

    1. Pascal Monett Silver badge

      If Verizon waits a little bit longer, they just might decide that it's not worth the risk anymore.

    2. C Montgomery Burns

      I think the price for Yahoo! just went down again.

      I think if Verizon had sense they'd simply walk away. I don't think it's a question of it being one or two billion dollars less. It's the potential other pitfalls a legacy of incompetent management is going to bring.

      Lastly, I doubt that there are even 100 million, real, current users of Yahoo.

    3. PeterM42

      Is Yahoo really worth...

      ..... a song AND a dance?

      Account deleted.

  10. Milton

    Not as smart as we think

    Not all of this staggering incompetence was on Meyer's watch, but her tenure will be the How Not To textbook for CEOs for the next century. She had time and money to get it right, and instead we got posturing, alienation of an entire workforce, wild shopping sprees, serial unforced mistakes ... well, as doctors say: Yahoo is "circling the drain".

    To specifics, though, I suspect part of the problem is that developers are not all as clever as they think. That's not a general criticism of skills, more of an observation about culture and assumptions. When you can write good code, it's easy to develop a sense of superiority. A skilled developer will frequently come into contact with people who work in marketing or sales or HR or other Centres of Mediocrity¹ and it takes rare humility and patience not to come away shaking your head like a dog with a horsefly in its ear, thinking "Blimey, I've spent hours talking to gro-bags."

    But even good techies can get over-confident, and I think I have seen it a lot where encryption is concerned. Perhaps it's to be expected: even quite decent mathematicians sometimes don't really understand the depths of crypto very well. Everyone knows the story of amateurs who dream up 'unbreakable'² crypto which really, really isn't. But even quite knowledgeable techies can be prey to the same delusion: it is awfully easy to obfuscate something and tell yourself that no one else will see through it, perhaps convince yourself that no one else would be motivated even to try hard enough.

    If it hasn't already been done, there is a growing case for every serious coding course to include a module on crypto: not just implementation of this or that algorithm, but to get under the skin of the math somewhat, so that new developers actually gain an understanding. After all, as surely every coder learns: if you don't know the math underlying a problem or process, you really can't write good code for it.

    ¹ Not mentioned in management texts as frequently as 'Centres of Excellence', which is odd, since they outnumber the latter by 10 to one ...

    ² As someone (might have been Schneier?) said, speaking of enthusiastic or naive amateurs: "You may be able to create a crypto system *you* can't break. But you almost certainly can't create one that *we* can't break.

    1. Destroy All Monsters Silver badge

      Re: Not as smart as we think

      This is not the problem.

      Crypto comes prepackaged nowadays (i.e. in libraries) so you are not supposed to roll your own or code up an algorihm described in a paper xeroxed from "Proceedings of...". You certainly need to understand the context in which this or that crypto algorithm shall be applied, and you may want to know what happens under the hood, and there is an excellent book on the subject: Applied Cryptography Arguably the book to which Schneier owes his Guru Status,written in 1996. (20th Anniversary Hardcover USD 70.00 WTF!)

      However, the crypto sauce lives and is executed inside a technological/social/economic context. Bad thinking, bad implementations, bad politics, bad policy, bad economic pressures, bad languages, bad code, bad timing, bad luck, bad OSs, bad laws, bad deployment, bad developers and bad bosses will cause the deployed system to be insecure, even if the crypto is top notch.

      Indeed, there is a book on the subject: Secrets and Lies, also by Schneier (written in 2000? so long ago already?), in which he tells people that crypto is not a silver bullet at all, contrary to what he believed when he wrote Applied Cryptography. The introduction is still as important and readable as it was back then.

    2. Vic

      Re: Not as smart as we think

      there is a growing case for every serious coding course to include a module on crypto

      There is a growing case for every serious coding course to include a module on humility: everything else flows from that.

      The reason we get these half-arsed security measures is that someone thinks he's much better than he actually is. Dunning-Kruger strikes again...


  11. Anonymous Coward
    Anonymous Coward

    Teach, train, don't complain only...

    For a long time, I've seen very little reliable information spread around how to hash and salt data properly.

    Sure, there were a lot of explanation about what a "salt" was, but very little about how to properly implement the whole salt+hash workflow. Implementing it correctly it's not easy at all for developers without the proper knowledge. Especially web applications are tricky to secure, especially if they don't use SSL/TLS - while many of their developers are usually among the less skilled ones.

    Just like many other things in security, there are many ways to do things the wrong way, and only a few (if not exactly only one) to make them the right way. Spread the knowledge :)

    1. Brewster's Angle Grinder Silver badge

      Re: Teach, train, don't complain only...

      I'm sure it can be done better or worse. (Didn't /etc/passwd used to use the first two letters of the user's username?) And I'm not sure I know the difference. But any form of salt is a massive improvement over none.

      AIUI a per user random string stored in the DB would be best. (You can store it at the start of the hash.) If that's not possible, add user specific component (the username) and a global, site-specific component, that's the same for all users on the site, in case the user uses the same username and password elsewhere.

    2. Dan 55 Silver badge

      Re: Teach, train, don't complain only...

      Spread the knowledge when the training budget has been blown on jollies in other countries by those who are always somehow first in the queue and the grunts can't even set up internal workshops in the same office because those hours aren't charged to an end client?

      Then people complain about mediocre software.

    3. G.Y.

      1973 Re: Teach, train, don't complain only...

      The documentation for the 1st Unix to get out of Bell labs tells you how they salted password. This was in 1973.

  12. Anonymous South African Coward Bronze badge

    The only secure database and server is the system that is switched off.

    1. Destroy All Monsters Silver badge

      Here is the full quote by Eugene Spafford:

      This quote is about security of computer systems. It appeared in "Computer Recreations: Of Worms, Viruses and Core War" by A. K. Dewdney in Scientific American, March 1989, pp 110. It was later misquoted in the book @Large: The Strange Case of the World's Biggest Internet Invasion by David H. Freedman and Charles C. Mann. (The misquoted version refers to titanium and nerve gas -- I never said anything like that.) The original quote is: " The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts. "

      Of course, the usefulness of such a system is marginal at best.

  13. Doctor Syntax Silver badge

    "to say nothing of Flickr, Yahoo! IM, and the hundreds of millions of webmail users who hadn't logged in for years, and you begin to see the scope of the engineering challenge."

    There seems to be a general acknowledgement that the number of real user accounts is less than the number of stated user accounts. Presumably the latter contributes to the stock market valuation. Isn't this something TPTB (?SEC) should take an interest in?

  14. adam payne

    Just lmao when I saw the screenshot of using Yahoo to find MD5 hashes.

    Now everybody is looking at me like i'm mad, I don't like it.

  15. Will Godfrey Silver badge

    I don't understand

    Yahoo seems to have a continuous stream of failures, stretching back for years - failures that seem to get progressively bigger. How is it possible that it still survives?

    1. Anonymous Coward
      Anonymous Coward

      Re: I don't understand

      It's like a catbus, maybe?

      The ride never ends, it just gets bigger.

  16. Thomas 4
    IT Angle

    Recommended alternatives?

    Been a while since I've haunted these parts but I figured this would be a good place to look for suggestions. Given yet another Yahoo fuck up, I think it's time I jumped ship to a new mail provider. Any recommendations for a secure, reliable service. Would prefer free but could pay for a good alternative.

    1. C Montgomery Burns

      Re: Recommended alternatives?

      I'd recommend Protonmail as long as you just want email.

    2. Mr Dogshit

      Re: Recommended alternatives?

  17. Anonymous Coward
    Anonymous Coward


    Not to be all pedantic, but the article says that bcrypt is "the best". While it's nice and all, Argon2 won the 2015 contest:

  18. Jamie Kitson

    Upgrade Process

    Couldn't they have bcrypted the MD5 until the user next logged in?

    (Obviously before they were hacked and all passwords were leaked.)

  19. DanielR

    Execute the ignorance. But where would the salt be coming from considering it can't be stored as a config on the server and it needs to be recoverable for database lookups ?

    I meant if that salt is stored in a config that would be the first place to look on the server,

    1. Vic

      I meant if that salt is stored in a config that would be the first place to look on the server

      So what?

      The salt doesn't need to be secret to do its job...


  20. The Purple Pineapple

    Please stop using ! ! ! in titles every time there's a Yahoo! story

    Yes, we all know it's annoying that Yahoo! have punctuation in their name. It doesn't mean we should try to be exponentially more annoying every single time they're mentioned.

    1. diodesign (Written by Reg staff) Silver badge

      Re: Please stop using ! ! ! in titles every time there's a Yahoo! story

      Oh ok, since you asked so nice, we'll just drop them. We've been doing them for years as a running joke, but because you, one person, demanded it, we'll stop the gag right now.

      Just! kidding!


    2. Korev Silver badge

      Re: Please stop using ! ! ! in titles every time there's a Yahoo! story

      But it makes the headline less vulnerable to brute forcing

  21. ChrisBedford

    In! Other! News!

    El! Reg! Continues! To! Use! Lots! Of! Italicised! Exclamation! Marks!

    Readers! Irritated! By! Hackneyed! Technique!

  22. Anonymous Coward
    Anonymous Coward

    It is needed a better solution based on public/ private key

    It is time to end this password mess!

    When open standard: SQRL "Secure Quick Reliable Login" becomes available this problem can end once and (hopefully) for ever (at least until quantum computing becomes a problem to Curve25519 technology).

    Specially if the person uses a dedicated device just for that, some kind of hardware security module device (so that malware can't crawl in, on some wholesale fashion) but with a screen, camera and some kind of network connectivity to perform the login (wifi, RJ45, 3G, 4G, 5G...).

    What is this SQRL? Open standard, uses Curve25519 key pair, the web server receives the public key part that is exclusive to that web site/ account and the user just have one private key that can be used in all web sites/ accounts (that support SQRL system). The user receives something, signs it with its own private key, the web site receive it, compare to the database to find the public key, if it finds it the user is log in. If someone stoles the private key their is in the protocol itself ways to recover from that to.

    SQRL doesn't depend on third party's like username & password also don't, unless the web server is outsourcing that to Google or Facebook for example.

  23. Luiz Abdala

    I thought MD5 was only used for checksums...

    ...But Yahoo! uses this for cryptography?

    I believe that's just for waist-high-white-picket-fence security purposes, just like WEP WiFi, no?

    "Oh, but the wifi had cryptography enabled!"

    "But it was using WEP! Which just looking at, with an angry frown, made it wet its trousers!"

    "But it was state-of-the-art back then!"

    "Exactly, back in 1998! My coffee machine has better cryptography than that!"

    Which I imagine as a conversation between the BOFH and the PFY and your average boss/luser.

  24. napalmDaz

    Yeah, because you *have* to get the user to sign in...

    .. or not.

    Really they should be hashing the existing MD5 hashes with Argon 2i with a salt, or brypt and batch upgrading the existing passwords without waiting for users to sign in. Then to validate, perform the same two step hashing process. I guess they are just assuming as the email and MD5 pairs are known, rehashing won't make any difference.

    All they need is a column with a versioning strategy number in the password table and they can start and stop the upgrading process whenever they want.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like