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 …
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).
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.
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.
> 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...
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.
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.
* 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...
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.
"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).
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.
http://www.mscs.dal.ca/~selinger/md5collision/
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.
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.
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.
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.
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.
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...
Vic.
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 :)
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.
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.
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.
"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?
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.
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.
...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.
.. 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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
