LiveJournal data breach impacts 33M users with plaintext passwords(twitter.com)
twitter.com
LiveJournal data breach impacts 33M users with plaintext passwords
https://twitter.com/weleakinfo/status/1149904387374026752
14 comments
Plaintext passwords huh, that's about as bad as it gets when it comes to breaches. The only upside is that this data is from 5 years ago so _hopefully_ a percentage of this breach is outdated.
Turn of millennium was era before of SSL/TLS. Livejournal did not want to send clear text password during login to the site. SRP was patent encumbered (and anyway implementing proper PAKE in JavaScript of that era was unfeasible).
So at Livejournal implemented their own challenge-handshake auth: https://www.livejournal.com/doc/server/ljp.csp.auth.challres.... Unfortunately it require storing plain-text equivalent of password on the server.
Seems to be worked fine through the years, but they used it well past "best before" date.
(SRP - http://srp.stanford.edu/, PAKE - https://en.wikipedia.org/wiki/Password-authenticated_key_agr...)
So at Livejournal implemented their own challenge-handshake auth: https://www.livejournal.com/doc/server/ljp.csp.auth.challres.... Unfortunately it require storing plain-text equivalent of password on the server.
Seems to be worked fine through the years, but they used it well past "best before" date.
(SRP - http://srp.stanford.edu/, PAKE - https://en.wikipedia.org/wiki/Password-authenticated_key_agr...)
And that API still works (just tested the example), which means that LiveJournal still stores MD5(password) in their database.
So even 5 years ago they weren't using basic hashing to store the passwords...
Good to know
Good to know
I doubt they were storing plaintext passwords. If I remember rightly the way LiveJournal login worked back in the day is that the server stored the MD5 of the password. Then when someone went to log in the server sent a random challenge to the client, which computed the MD5 of the password locally, concatenated that with the challenge, and sent the MD5 of that to the server. This does have the unfortunate consequence that knowing the server-stored MD5 is equivalent to having the plaintext password when logging into LiveJournal, but it doesn't give the server an actual plaintext password that can be used elsewhere. Someone's probably been busy doing some password cracking.
Ah true, though today the plaintext passwords of most MD5 hashes can be obtained quickly
Even if everybody on LiveJournal has since changed their passwords (there and everywhere they repeated it, which we know they won’t have), this now adds to the dictionary of passwords which _other_ humans may have chosen elsewhere and will certainly increase the hit rate of password spraying attacks etc.
While everyone recommends turning on 2FA everywhere, I’m increasingly convinced we’d all be safer if the password was the second, optional factor.
While everyone recommends turning on 2FA everywhere, I’m increasingly convinced we’d all be safer if the password was the second, optional factor.
> I’m increasingly convinced we’d all be safer if the password was the second, optional factor.
Yes! Why can I not always login via an emailed token, secured by a TOTP? It would set a cookie, so no different in UX once you’re in, and that’s the normal “forgot password” flow, so no different in terms of security. But it would remove the need for me to constantly be opening up various password generation toolkits and resetting passwords and etc.
Yes! Why can I not always login via an emailed token, secured by a TOTP? It would set a cookie, so no different in UX once you’re in, and that’s the normal “forgot password” flow, so no different in terms of security. But it would remove the need for me to constantly be opening up various password generation toolkits and resetting passwords and etc.
>will certainly increase the hit rate of password spraying attacks etc
I do not see how this works in the context of other humans.
I do not see how this works in the context of other humans.
Because people don’t choose random passwords on the whole. So for every person who is revealed to have used zxcvbnm1234567890 as a password, there is a chance others have too. Obviously not for every password, but every large leak of actual passwords adds some that will match elsewhere.
I don’t see how this leads to an increased hit rate, now you’ll just be making more incorrect attempts.
Only way I see this kind of working is if you’re cracking the passwords offline.
Only way I see this kind of working is if you’re cracking the passwords offline.
Yes, that’s one use case. Let’s say you have a database of actually properly hashed passwords. What passwords are you going to prioritise to try first? Every plaintext leak adds to the list of passwords you’d be sensible to try before brute forcing. Plus even for online attacks like password spraying, you’ve got to get an idea of common passwords from _somewhere_ and this leak inevitably adds to that. The only point I’m making is that humans are similar and therefore there’s always a chance they pick similar passwords. Therefore even if all LJ users have since changed their passwords, there are still many risks.
I’m afraid it won’t be the case for most of it.
For people aware of the breaches problem, like most of us here, it won’t because it’s been a long time since we use twice the same password.
But for everyone else...
For people aware of the breaches problem, like most of us here, it won’t because it’s been a long time since we use twice the same password.
But for everyone else...
Expect a knock on the door from the Information Commissioners Office.