Generated Passwords, UX and Security Absolutism
Last month, Disney launched their new streaming service Disney+; “The best stories in the world, all in one place”, apparently. The service was obviously rather popular because within days the tech (and mainstream) headlines were proclaiming that thousands of hacked Disney+ accounts were already for sale on hacking forums. This is becoming an alarmingly regular pattern with online services, the cause of which was soon confirmed by Disney:
Disney says that there is “no indication” of a security breach on Disney+, and that the source of the problem might be a so-called “credential stuffing” attack, in which hackers obtain passwords and usernames from Dark Web databases, and then use a brute force method to see if those passwords and usernames will work on new sites as well.
So the root cause is credential reuse. We’ve all done it at some time or other and the vast, vast majority of online users still do it today. But what if we could stop this attack dead in its tracks? What if one simple design decision in the auth process could completely rule out any chance of ever suffering a credential stuffing attack?
Genius! Absolute genius! So why doesn’t every site take away the ability for people to choose their own passwords? Why not just generate the password for them thus completely eradicating password reuse? Because it’s an absolutely terrible idea, which brings me to the catalyst for this blog post:
We don’t allow users to pick passwords so that we don’t store any of your sensitive information.
Instead, passwords are randomly generated by the system and they need to be stores in plaintext so that we can send you the reminder in case you forgot it.
We hope this makes sense. https://t.co/Eio5N68WMG
— Practical Pentest Labs (@ppentestlabs) December 6, 2019
I woke up earlier this week to a flood of tweets pointing me at this one with people aghast at the premise of firstly, storing passwords in plain text and secondly, emailing them out to people:
LITERALLY NOBODY SHOULD STORE PASSWORDS IN PLAIN TEXT.
It doesn’t matter who generated the password. Do ? not ? store ? passwords ? in ? plain ? text.
— ☃️ Johannes-shaped snowman ☃️ (@jkbckr) December 9, 2019
This is largely a practice of a bygone era and it’s increasingly rare to see in modern times (and if you do see it, name and shame over at Plain Text Offenders). But how relevant is this criticism when the passwords are system-generated? Whilst the storage and delivery of the password in plain text certainly smells bad, when it’s a (pseudo) random string, the risk is very different to when the user chooses their own secret:
After reading the original linked post and follow-ups, if they get compromised, the only usable information stolen is the email and nickname.
This compromise would expose all their accounts to be exploited /for their services only/.
They then would mass-reset pwds and go on.
— Martin Boissonneault (@ve2mrx) December 9, 2019
For me, the issue isn’t really about the storage and delivery of the password, it’s about the practice of generating a password for someone that just doesn’t add up. There’s a fundamental flaw in the logic which I summarised as follows:
If the site generates a password, how do you store it? Password manager? Then you have a strong password generator already. No password manager? So now the site is a UX nightmare. When does this pattern actually make any sense whatsoever? There’s a reason for “pitchfork raising”! https://t.co/Rw2upmgbwF
— Troy Hunt (@troyhunt) December 9, 2019
The tweet I quoted linked to a blog post titled Pentesting Training Website Challenges Authentication Best Practices and referenced the infosec community doing much “pitchfork raising”. Somehow, despite my joining the conversation late, my single-word tweet featured at the beginning of that post which concluded that:
Practical Pentest Labs makes a great case for innovation and not following the pack in the IT security landscape.
So let’s go through the registration process and look at why “the pack” doesn’t implement things this way. Registration involves entering a username and email address which then delivers the following to your inbox:
Now, put yourself in the shoes of someone who’s just registered – how do you login? Copy and paste the password of course, that’s the easy bit. But how do you login next time? Clearly, you’re not going to remember the password so you need to record it somewhere, but where? Password manager? Great, which means you also have the ability to do something like this on account creation:
This is 1Password’s password generator and I use it for every new account I create so clearly there’s no “uniqueness” value to assigning the user a password when you can generate your own strong password anyway. And if you have no password manager? You’re not going to write it down because that would be absolutely painful, as would re-typing it on return to the website. In all likelihood you’re simply not going to record the password at all which means then doing a password reset. Except it’s not a reset, it’s a recovery which is why they store it in plain text in the first place:
I love their argument that it’s so they can email it when you need a new one. ???
— .PHONY: rappers (@tehsuck) December 9, 2019
The generation of passwords isn’t even the problem. It’s the fact that they send you the password in an email instead of just sending a “reset” email.
— Joe Philwaukee (@phillijw) December 9, 2019
Now of course there are very well-established patterns for implementing a password reset so this remains a really odd design decision, but it’s one that’s tangential to the discussion around generating the password. Using the “forgot password” feature as a primary means of authentication was enthusiastically supported by a number of people who joined in on the conversation:
from a UX perspective, here’s why this is genius: I don’t need a password manager, I don’t need to select/remember the password, breach of them won’t affect other accounts. Each time I need to login, I do forgot password, new sys gen pass – almost becomes a genius OTP system.
— Manan ??♂️ (@manan) December 9, 2019
Let’s be clear about the first bit: using this feature as a means of recovering access to an account isn’t “genius” due to their decision to generate passwords because you can use exactly the same approach with any site that allows you to choose your own password. This is simply using the password reset feature for auth, pure and simple. And it has a heap of issues.
Firstly, it always involves more steps and more time than entering a username and password either from memory or password manager. It’s no longer a matter of entering a username and password, it’s enter the email address, wait for the email, go to the mail client, click the link, now you’re in.
Secondly, “wait for the email” can be a protracted process. We’ve all had plenty of occasions where mail delivery is delayed and, in this case, that’s a blocking process; you simply cannot log back in until the mail comes.
Thirdly, there’s junk. Just this morning I discovered all my Disqus notifications were going direct to the spam box:
I don’t know if that’s Disqus’ fault or Office 365’s fault, but what I do know is that a whole bunch of legitimate emails were no longer being delivered to my inbox (it wasn’t just Disqus either). Now imagine you’re dependent on that email simply to access a system you’re already registered on – it’s painful. Of course, you still need successful email delivery for registration verification and the times you genuinely need to perform an account recovery, but making that a dependency on every single authentication attempt is just nonsensical.
Much of the discussion had on this topic centred around the pain imposed on users choosing passwords:
I think we underestimate what a UX nightmare choosing a password is for the average user. For many, it’s a really stressful exercise.
— Chris McGrath (@cpmcgrath) December 9, 2019
You can argue this two different ways: On the one hand, manually creating a password that meets what is often arbitrary complexity criteria can be painful, and that’s before you even begin listening to that nagging voice in the back of your head saying “also make it unique”. On the other hand, passwords are one of the simplest security constructs we have and every single person using the web today understands how to use them. Indeed, this is what keeps human-chosen passwords alive today; just last year I wrote how Here’s Why [Insert Thing Here] Is Not a Password Killer where I explained that despite the technical merits of alternate approaches, the simple reason we still use passwords the way we do today is because everyone understand them! It’s exactly the same reason why I ended up standing in front of US congress testifying about the impact of data breaches on knowledge based authentication; relaying your date of birth as a means of verifying your identity is terrible in terms of security, but it prevails because every single person knows how to do it! You cannot escape these basic security truths and time and time again, usability trumps security.
Which brings me to the “security absolutism” term in the title of this post. Security absolutism – the view that all else is secondary to this one strongly held principle – was rampant throughout the discussion:
We are willing to trade UX anytime if it means more security for our users. https://t.co/MZHZadRNc7
— Practical Pentest Labs (@ppentestlabs) December 9, 2019
This feels like a very sage, grandfatherly thing for me to say, but this is simply not how the world works. If it was, they’d force 2FA on every single user and demand they purchase a U2F key for auth. As it stands, there’s not even a self-service means of changing your password:
By unchangeable we meant that we do not have the option within the dashboard. But if the user emails us we will be able to assist on that.
For paid accounts we verify the requester using the Paypal transaction, from our Paypal account.
— Practical Pentest Labs (@ppentestlabs) December 6, 2019
If security was such an important focus, they wouldn’t still be supporting TLS 1.0 and 1.1 (SSL Labs will cap their grade to “B” in a few weeks from now for that faux pas), they’d use DNS CAA and they wouldn’t be scoring a failing “F” grade on Security Headers due to no HSTS and no CSP. To be clear, none of these are particularly sensational findings, but the assertion that security is somehow sacrosanct and that everything else must be sacrificed in its pursuit is clearly not what’s going on here.
I first used the term security absolutism a few years ago now when writing about responses to folks using Cloudflare to implement HTTPS on their sites. As with this post, I proposed that a myopic focus on security was unhealthy and causes people to miss the many fine nuances involved in protecting online assets whilst still delivering a usable service. For example, this tweet in response to the terrible UX of generating passwords for people:
Still beats the UX of dealing with a hacked account.
— Karl Shucks (@KarlShucks) December 9, 2019
Clearly this is untrue for Disney and for every other service I can think of that’s recently been the victim of credential stuffing (geez that list is getting big). Not a single one I can name has, after being on the receiving end of an attack, turned around and said “You know what? No longer allowing users to choose their own password and instead just assigning one to them sure beats the UX of dealing with a hacked account!”. Not. One.
This is also a case where this particular site is by no means a valid reference point for the general online populous. Practical Pentest Labs is targeted at people who want to “take their hacking skills to the next level”, which one would assume means the audience is somewhat more security-conscious than your average punter. This audience is better equipped to store secrets such as a generated password but again, they’re also more likely to have a password manager in the first place thus negating the uniqueness value proposition of a generated secret.
To be clear, I don’t have any personal gripes with Practical Pentest Labs and if this method of auth is working for them then good on ’em, that’s their call. But regardless of how much you might like their approach, it’s an inescapable reality that their implementation is highly abnormal and that’s not by accident – this model is simply a UX nightmare. This approach would completely solve Disney’s credential stuffing problem by entirely eradicating password reuse, that part I agree on:
I hate to say it, but PPL is right.
Password reuse is the biggest problem and they solved it. If their servers are breached the passwords are useless anywhere else and the attacker is already knee-deep in the system. All sites should generate the user’s passwords.
— Karl Shucks (@KarlShucks) December 9, 2019
But as for “all sites should generate the user’s password”, no, you’re never going to see it happen at Disney because they actually want customers! This, again, is security absolutism because it places security above and beyond all else and damn the consequences.
By all means, people should robustly debate the merits of alternate auth systems, but you cannot escape the reality that no matter how endorsed you might be in this approach, websites simply don’t implement it. There are very good reasons why not and if you’re inclined to chime in on the comments section in support of generated passwords, perhaps start with thinking about why this approach is so rarely seen.