![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Security, authentication, and breaking changes to older clients
TL;DR: We are making some changes to how we do authentication (how you log in) that will unfortunately break a number of older clients that you might be using to talk to Dreamwidth. This is very unfortunate, but we think that the tradeoffs in improved security are very much worth it. This post talks about where we were, what we're changing, and the path forward for clients/APIs.
Historical Context
Hi all -- the times, they are a changin'.
Dreamwidth is, of course, based on LiveJournal, which was started in 1999. The codebase is old enough to buy a beer in the United States, and has been able to in much of the rest of the world for years. I'm sure there are people reading this post who were born after Brad started slinging lines of bad Perl1 back in the halcyon days2 of his University of Washington dorm room.
Anyway. We start our story back in ancient times.
Things looked very different back then. Server side CPU was constrained, hardware encryption was not a thing yet, browsers were all over the map, TLS was the new kid on the block, there was no Cloudflare/AWS/GCP (cloud computing wasn't a thing), etc.
Back at the beginning, the way you accessed LiveJournal was over a good old fashioned unencrypted HTTP connection and everything that went on between you and your long deceased3 LJ was completely visible to anybody who had the means or desire to sniff your traffic. This was obviously not great.
One of the biggest concerns we had back in those days wasn't that people would read your journal, but that they would be able to get access to log in as you. I'm not actually sure who built the original version, but it was very early on, LiveJournal added client side password hashing using MD5.
Now, the advantages of this system were that basically, your password never left your browser. When you tried to log in, the server would give you some personalized bit of information (a challenge) and then your browser would, using JavaScript, construct a response that was crafted based on cool mathematics (the one-way hash MD5).
This change let us guarantee that your password was never sent in the clear. This approach also allowed us to protect against so-called man-in-the-middle attacks and replay attacks by carefully crafting the challenge. The details of that are outside the scope of this blog post, but it was the right way to do things back in the early 2000s.
Anyway, that was good enough for the web browser, but LiveJournal also had a custom set of API interfaces (what we called "protocols") that enabled people to write non-browser clients. Originally we built something called the flat protocol and later came the XML-RPC protocol.
We used the same authentication plans here as we did in the web browser:
- Plain (cleartext) authentication, where you send us your password.
- Challenge-response authentication, where you do some client-side MD5 hashing.
These two systems have the same pros and cons of the web browser authentication schemes. Sending a password in the clear over an unencrypted HTTP connection is all sorts of bad, so we steered people towards using the challenge-response authentication scheme. At this point, I think most clients do this and don't even provide options for using the plain version.
A Digression, or, Why Not Challenge-Response?
Now I want to take a small digression into the main downside of the challenge-response authentication scheme:
It requires us to store your password.
Since most of us (including me!) aren't cryptographers, let me elaborate4 on this. Challenge-response authentication basically works by doing some fancy math with black boxes. The main thing to understand here is that we will use a "black box" (technical term is: a cryptographic hash function) and this box takes an input number and returns an output number.
So for example, if we gave the box a 7 it might tell us 12. And if we gave it an 8 it might respond with a 4. You could go on forever and the responses it would give you are never predictable and never duplicated. These two properties are very important.
To put this another way, if I told you that the number I got from the black box was 351, it's important that you not be able to guess what the input was that resulted in that 351. While this is obviously easy to guess in my example with small numbers here, but in the real world these black box (hashing functions) will give you a very large random number. In fact for this one particular function (bcrypt, with a digest size of 2184), you'll get a number in the range:
2,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 (2.45e+55)
Okay so that's big. I'm going to use some simplified numbers here to make the example palatable but let's pretend that your password is the number 10. Logging in would look like this:
Server: Hey, your challenge is the number 5.
challenge = 5 (random number created by the server)Client: Ok. Let me put my password (10) in the black box... it says 13. I'm going to now add that to the challenge (13 + 5 = 18) and put that in the black box... my response is now 25.
response = black_box( challenge + black_box( password ) )Server: The challenge was 5, let me put their password in the black box... 5 (challenge) + 13 = 18, now to black box that... 25! Yup, let them in.
test response = black_box( challenge + black_box( password from database ) )see if response from client is the same as test response
The meat of this algorithm is that the client is proving that they know some secret (your password) by doing some math on it and showing us the result. We do the same math on our side and we can check that the results match. The security is added by us giving them some controlled random inputs (the challenge), which forces the client to do "fresh math" (they can't reuse a previous answer).
This is a super simplification of the process but hopefully it describes it well enough. The main point I'm trying to make is that this entire algorithm requires that we know your password. Which sucks. I don't want to know your password. The reasons for this are many -- but one of the big ones is that if someone were to steal our database, I don't want them to suddenly have millions of email addresses and passwords that they can use to log in to your bank or something more important than your journal!
Digression: We do not believe, and have no evidence of, our database ever being leaked or accessed other than by the 3 staff members who maintain Dreamwidth's infrastructure. We are making these changes not because of some extrinsic motivation but because we believe that they're the right thing to do.
Anyway, let's move on from authentication for now. There is also the fact that we were using unencrypted HTTP. This was fine for your journal (well, "fine"), but was less good for things like entering your credit card and things. At some point in the past, LiveJournal did actually build in support for using HTTPS and encrypting your connection, but it was only used for pages like the shop and other areas that were considered sensitive.
LJ did move logins to use SSL at some point too, but of course the unencrypted version was still available if for some reason you couldn't use the encrypted version. This remained the case for many years and the propensity to use unencrypted connections was substantially unchanged for 15+ years, but we'll get into that soon.
Encrypting the Tubes
Let's fast forward to the late teens (the twenty-teens)...
CPUs are much, much faster, and more importantly, services like Cloudflare have built a business on encrypting the world's traffic. Literally everybody wants you to use encryption and they make it very easy (and, important to Dreamwidth, very cheap!) to do so.
Over the past few years, we here at Dreamwidth embarked on a project to make HTTPS the default and, more than that, to require it. It's not even possible anymore to browse Dreamwidth unencrypted -- we detect and redirect anybody who tries. This is the way it should be, security should be the default! Since it is technically and economically feasible, there's zero reason for us not to do this for all of our users, wherever you are and whether or not you pay.
So we did that. That's great, this definitely improves the security of the system and the risk of our users getting their data exposed, but fundamentally we still have the same problem we had above re: knowing your password. Those are still stored in the database and, if the worst were to happen, we don't feel comfortable having that data around when we really don't need to.
(But as above, we have no evidence of any compromise of our database having ever happened. We're making these changes proactively though, to ensure that if it ever does, we can try to ensure that passwords are not easily compromised.)
How Not to Store Passwords
Before we get into what we're doing, let's talk about how you can provide a secure service without storing somebody's password. Again, I'm going to go back to that example I was using above, except this time we're going to leverage those black boxes again but slightly differently.
Assuming that we're using modern, strong connection encryption for everything, we no longer need our authentication layer to protect against man-in-the-middle and replay attacks. This is a pretty great trade since it means we can simplify the approach taken in our authentication system quite substantially... and we get to go back to sending passwords plain5!
But more importantly than how we send the password, the fact that we no longer need to provide protection against those two attacks means that we can store the end result of the black boxes in the database instead of your password. Let me break that down... let's talk about creating an account and setting your password for the first time.
Client: Ok, I'd like to make a new account, my password is
bob.Server: Great! Welcome to Dreamwidth, let me just do some math here...
salt = make a very big random numberdatabase_password = black_box( password + salt )
The server then stores that database password! It never writes down the user's actual password. (Remember that these black boxes are one-way, which means that you can't6 figure out the user's password from the database password.)
Next time, when the user goes to log in, this is what it looks like:
Client: Ok, let me log in, my password is
bob.Server: Great, welcome back! Let me see...
test_password = black_box( client password + salt from database)compare test_password with database_password
Notice that we basically re-did the math we did in the create account step, but we used the salt7 (stored only on the server) and the password (that the client gave us). Then we checked the result of our math with the result we stored in the database.
There's a lot of technical depth to this area, but the TL;DR is that by using an appropriate black box here, we guarantee that even if our database gets stolen, it will be very, very hard for the attackers to figure out anybody's password. It's still doable -- but the attacker has to guess every possible password, for every single user, which is... very hard.
But the astute reader will point out that even this scheme is only as resilient as your password, so pick strong passwords! If your password is actually bob an attacker will be likely to find it pretty quickly.
But, What About Challenge-Response?
Now we get to the hard part.
Since the server no longer knows your password, we can no longer implement challenge-response. We have no way of verifying that the response you're sending us is actually correct, so this improvement in password storage will break existing clients.
This sucks, but there are paths forward.
If you are a client maintainer: you can immediately switch to using plaintext authentication over HTTPS. This is secure and, by sending the password, we can validate you just the same as we validate any browser login. This is the short term path and you should do this.
However, the better path is to start using our new API. This post won't go into too many details, but we've been working on building out an OpenAPIv3 compatible API. Check out the API spec! We don't have all of the methods you will need to build a full client yet, but we're working on it.
What's Next
This week, we are rolling out strong password storage (see pull request #2621) which will have the impact of breaking clients that are using challenge-response authentication. If you have the ability, we recommend you switch over to using plain authentication -- using HTTPS, of course!
Coming soon, we are are also building the ability to optionally use two-factor authentication (2FA) (see pull request #2624) to further increase the ability to protect your account, if you want (it will be opt-in). There are a lot more edge cases here, though, and we need to consider the various authentication flows, so this is still "coming soon."
Finally, we are going to continue to invest in our modern API and work to deprecate and remove all of the older ones ... better security, functionality, and a simpler codebase! Many wins.
We care a lot about your security and privacy, and while some of these changes will definitely have a negative impact on some functionality, we make them with the goal of honoring our pledge to respect your data. And, honestly, this was too long coming.
Thanks for reading, and as always, please let us know if you have any questions/comments.
From vault 37.566329, -122.323479, this is ![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png){kind=small}
mark, signing off.
1 Up to the reader whether this is 'bad as in cool' or 'bad as in not good,' it really depends on your point of view, and the author is not trying to imply anything here.
2 I have no idea on whether or not Brad actually looks back fondly on those days.
3 Because honestly, anything I wrote in my LJ in the early 2000s better well be gone and buried by now and I pray never sees the light of day again.
4 I am suuuuuuuper simplifying here, and obviously eliding over the properties of a one-way hash. I understand that addition is trivially reversible here, but hey now it's an example.
5 Well, it's not actually plaintext. Since we're forcing everybody to be using HTTPS all of the data (including your password) is strongly encrypted and is already safe against all sorts of attacks.
184 That's an exponent, not a superscript. But hey, made you look!
6 I'm using words like can't, but when it comes to cryptography the actual worlds are things like "infeasible." I just wanted to keep it simple, but I understand that there's a big difference here. It's still possible to figure out a user's password it just takes millions of years and millions of today's servers...
7 This post is already way too long, so I chose not to go into details about what a salt is and why it matters. I would have left it out of the examples but then someone would have commented that we sucked at security for not using salts. Yes, we're using salts. Random, one per bcrypted thingy.
no subject
also: *learns things*
no subject
no subject
no subject
i'm curious: are people still using clients? is DW able to detect traffic from them?
no subject
Thanks for keeping our stuff secure and explaining what you're doing!
no subject
Idea to avoid breaking existing clients
I don't know what discussions happened around whether you want to put in effort to avoid breaking existing clients, or how much, so I'll toss this out as a possibility: generate and store an app-specific password, and use that for the challenge-response flow (and/or Digest auth flows).
People would have to update the "password" used by their client, but the value stored in the database would no longer be something of their choosing, and thus exceedingly unlikely to match up with their password elsewhere, so far less useful in the event of a database breach.
Wouldn't solve the issue of a database breach allowing the attacker to impersonate people on Dreamwidth, but at least that's limited and easy to regen the tokens should it ever be necessary.
no subject
I should figure that out soon. Huh.
Thank you for this explanation! I'm going to sit down and read it for understanding soon instead of skimming. I think I should be able to get most of it, even as a non-techie.
no subject
no subject
no subject
no subject
no subject
We definitely do try to keep things working in older clients despite the small number of people who are using them, because we know that people keep their workflows for a reason and that there are a lot of clients no longer under active development, but in this case, the security update is important enough (and overdue enough) that we need to make it, and it's the kind of update where you can't keep the old version working and still get the security benefit of the update. We did make this post so developers of clients that are still under active development are aware of the changes they need to make, so your best bet is to contact the developer and make sure they've seen it.
no subject
no subject
As for HTTPS I don't know either. In the "advanced" options there's an authentication section with a checkbox next to "Challenge/response" and I don't have it checked, but that's all I can tell you.
no subject
no subject
client GNOME-Drivel/3.0.5 1
client GTK2-LogJam/4.6.2 6
client Mozilla-DeepestSender/0.9.9 17
client PHP-JournalPress/1.0 2
client python-Charm/1.9.1 1
client python-Charm/1.9.2 1
client Web/2.0.0 11206
client Web/3.0.0 453
client Win32-MFC-Sema/1.5.9.9U 1
client Win32-MFC-Sema/1.7.4.5 1
client Win32-MFC-Sema/1.7.4.5U 1
client Win32-MFC-Sema/1.7.9.7U 2
client Win32-MFC-Sema/1.7.9.9U 12
client Win32-MFC-Sema/1.8.0.1 4
client Win32-MFC-Sema/1.8.0.1U 60
client Win32-MFC-Sema/1.8.0.2U 1
client Win32NT-.NET/0.9 14
Re: Idea to avoid breaking existing clients
But,
I'll go ahead and take a stab at that before this goes live, and try to make sure that Semagic at least works.
no subject
no subject
no subject
no subject
no subject
no subject
It's a particular challenge-response protocol whose details look like a modified version of Diffie-Hellman key exchange. The key feature is that the information the server needs in order to verify the password is not sufficient to perform the client's side of the exchange.
In other words, it gets both the advantages of challenge-response and clear passwords. On the one hand, the data sent by client to server during a verification isn't enough to base further verifications on, so it defends against MITM and replay attacks. And yet it also has the advantage that stealing a password file entry from the server doesn't confer the ability to conduct the client side of the exchange – so your password file isn't an ultra-high-value target either.
You may have encountered this and decided it's not for you – I certainly wouldn't be surprised if it turned out that it was too slow to be practical in client-side Javascript. But you don't mention it here as an option that was considered, so I thought I'd just check.
just regarding 2FA
I said "YESSSSSSS" aloud!! And not in a whisper either! :D
posting from unix command-line
Is it still possible to write a Unix command-line client to post the contents of a file to one's dreamwidth blog, using an ssl-capable libcurl?
no subject
Re: Idea to avoid breaking existing clients
no subject
no subject
no subject
Yet again, procrastination comes to my rescue. *happily crosses "figure out how to implement challenge-response auth to dw" off to-do list*
no subject
At some point I'll look forward to there being an official client again!
no subject
When I do a new install, I have to hope that the old .deb package still works, because I don't know of a viable Linux alternative.
Let's see what happens. I do at least have the source (C).
I wonder if using MD5 is a reason why attackers were able to get the passwords from Some Other Site. Databases of MD5 hashes of billions of plaintexts exist.
Re: just regarding 2FA
It will probably be a bit of a slog to get it integrated with all of the ways you can authenticate (there's a bunch), but we're working on it!
no subject
I think I'm still going to continue with the bcrypt approach, primarily because to implement SRP it looks like we'd have to force users to use JavaScript or some way to implement client side logic to implement the protocol.
We have a number of use cases that rely on being able to just send a password (such as posting-by-curl, ancient unmaintained clients, etc). While we could implement SRP also, at that point it seems like it doesn't add much benefit if it's just an additional authentication protocol in addition to the others?
no subject
No, probably not, in this case.
In other use cases there are benefits that might still make it worthwhile – in particular, you can arrange that the password verification proves to both sides that the other one knew what the password ought to be, and also, a by-product of the exchange is a shared secret between prover and verifier that they can use as a MITM-proof session key. But I don't think either one applies here, where session key setup and server identification are already done separately.
no subject
2) salt... great, now I'm hungry.
no subject
no subject
no subject
no subject
(Anyone using the same password on multiple sites should probably use a password manager and change it on both, for that matter!)
There's also something to be said for changing your DW password after the new auth changes finish rolling out, since that would protect against any unknown past leaks of DW's plaintext user database.
no subject
no subject
no subject
no subject
Edited to add: Gah! Pre-coffee me assumed this was already live. If that's not true, then just imagine that the below is a warning from an alternate future.
Edited further to add: Earlier pre-coffee me was underconfident, and current pre-coffee me has found the![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
dw_maintenance post. Sigh, me. The “does this increment the failed login count” question is still relevant, but maybe should've been somewhere else…
(Original post:)
Say, was there an actual announcement about this anywhere? I didn't find one. This doesn't impact me directly, but is indirectly concerning after seeing someone report trying to post using Semagic and giving up after getting vague error messages followed by some kind of temporary IP ban for too many failed logins (I wasn't entirely clear on what happened; DM me if you want a little bit more info).
Relatedly:
no subject