If websites generated passwords for their users, it would fix so many problems.
It would…
- Keep users from reusing passwords.
- Keep users from using weak passwords.
- Remove the anxiety of creating passwords.
- Show people they don’t need to remember every password.
- Be less complicated than doing 2FA.
- Be easy to write down.
- Speed up and make the sign-up process better.
- Create fewer support tickets.
- Create herd immunity.
- Work the best for the lazy and people who don’t care.
- Help lower liability.
It Removes Anxiety
When you generate passwords for users, you remove the anxiety of password requirements. No more entering 5 different passwords until you create one the website likes.
The less you require people to think when creating an account, the less anxiety they have and the quicker they start using your service.
Password requirements and complexity suck, but generating passwords for users fixes that.
But People Won’t Remember Them?!
The biggest critique I get is that users won’t remember the generated password.
That’s the problem; people are trying to remember passwords.
The average user has over 100 passwords, and it’s increasing every year.
That is over 100 different passwords following 100 different password requirements. It’s no wonder people hate passwords; trying to remember all that is not possible.
No one expects you to remember phone numbers anymore as we have contact apps, so why are passwords any different? Why are we keeping people in the mindset that they need to remember all their passwords? The problem is not the password but the archaic way we train people to keep passwords.
It’s Not 2004 Anymore!
You can’t use the internet without a web browser, and every web browser offers to save passwords for you. Not only do they save them, but they also autofill them.
For the paranoid or less skilled, you can still write down the password. It’s okay to write passwords down! Writing the unique password down in a book is far better than reusing the same or similar passwords.
The problem of storing passwords has been solved for years. You can store passwords in your browser, password manager, text file, spreadsheet, or even in a physical notebook. Anything is better than reusing passwords.
2FA Is –NOT– An Excuse For Bad Passwords
90% of Google users don’t use any kind of 2FA. Only 2.3% of Twitter users use any kind of 2FA (Source). That is because the average user finds 2FA complicated.
Also, 2FA is not an excuse to reuse passwords. Yet that is how many users are treating it. If you’re using 2FA so you can keep using your bad password, you don’t have 2FA anymore and purposely defeated the whole point of having TWO factors.
Even worse are the companies that are forcing every user to use SMS 2FA. Not only is that the worst kind of 2FA, but it’s also not solving the actual problem.
It’s also easier and more cost-effective for a company to generate the passwords for users than to implement 2FA of any kind.
You also have the privacy issue that comes with SMS 2FA – but that is why many companies do 2FA. They don’t want to better protect your account; they want another data point to give to advertisers. If they cared, they wouldn’t allow password resets via SMS.
Other 2FA: What’s funny is that when you start to understand why 2FA like Google Authenticator is so effective, generating passwords for users is nearly equivalent. Google Authenticator is just a bad password manager that uses easy to guess codes that change every 30 seconds.
We Already Do It With Backup Codes
If you’re not sold on randomly generated passwords, don’t forget that most services that support 2FA also have backup codes.
What is a backup code, if not a randomly generated password?
If you lose or can’t use your 2FA device, you can enter one of these randomly generated codes, aka passwords, and get into your account.
Sure, these codes are often one-time use, but they still are randomly generated codes. If you’ve been using 2FA with backup codes, you’ve been relying on random passwords this whole time.
What is even crazier to me is what these backup codes look like.
Many of them are merely 8 characters long. Yup, an 8 character long random password is all you need to get around your 2FA on your account. Not only that, but many services give you 2 to 10 of these codes; the more codes, the greater the chances of “guessing” one.
The worst offender is Google, using only 8 random numbers.
Ultimately, if your account’s strength comes down to a randomly generated password, why not cut the fluff and use generated passwords from the start?
Generating Passwords Is Simple
People think generating passwords for users would look like “-xtKve%3&N?*sFdhp~DLd,_5/4?” which is not the case.
Simple passwords will be fine; for example, the passwords “1475 3723 4559 1530“, “Clean92cymbal“, or “zvnga-DSVBD-56539” will work.
We don’t need to make complex and scary passwords; we have the tools today that allow services to use slow hashing algorithms and rate-limiting to protect users. We already do such things for user-generated passwords.
The uniqueness of a password is the most important factor for online accounts, then comes length, and when covering both of those factors, complexity is pointless.
Even a hexadecimal password would work too, “4F6-E5B-57B9“. They’re easy to read and type.
Notice how that hexadecimal password is 10 digits long, the same length as a phone number; people have no issue storing phone numbers. You could make it 16 digits long, which is the length of a credit card number, which people also don’t have a problem with storing.
Mullvad VPN does exactly this; they generate a random 16-digit Account Number. The account number acts as your username and password. Just head to their website and press the “Get Started” button to see how easy it can be to generate passwords for users. Here is an example of what the password looks like on Mullvad, “2531 3092 1386 8678“.
IVPN is another example of a website that generates the password for the user, and it works quite well. Here is an example of what the password looks like, “i-8QYC-73NF-H4F8“.
IVPN having all their passwords start with an “i” is brilliant, as you can check the value locally before sending it off to make sure the user entered the correct password. It also stops blanket credential stuffing attacks because if it doesn’t start with the correct letter(s) the form doesn’t submit. So, the server is not getting hit with “password” and “princess123” type passwords, which waste time and resources.
Client Side vs. Server Side Generating Passwords
Where the password gets generated seems to be the strongest sticking point that people against this idea have.
They worry the password would be generated server-side, and there is a chance the server may know the password.
Ideally, you would generate the password client-side, but, honestly, it’s not as big of a deal everyone is making it out to be for several reasons.
- When you log into a website, you already send the naked password to the server, so it can be hashed and checked. You hash the password server-side because if you hash client-side then the hash becomes the password, so you’re no better off.
- Servers already generate random secrets all the time. For example, if you have TOTP 2FA, the server generates and stores the naked secret (password) and shares it with the user. Generating a random secret for TOTP 2FA is fine, but generating a random user password is not??? It makes no sense.
- App passwords are a thing, and we have no issues doing them sever-side. The fact we have app passwords and often use them to get around 2FA just proves the effectiveness of generating passwords for users.
- Once you’re logged in, the server generates a random password that is stored as a cookie to keep you logged in. The fact that you stay logged into a site shows a server generating a password and knowing it plus keeping it secure is possible.
- Servers are always generating random passwords when you’re surfing the web, it’s a natural part of being online. Most of this is handled in the background, so most people never notice it.
Once again, ideally, the password should be generated client-side, but we also have several examples of websites in this post that generate server-side, and it’s not an issue.
I never expected this point to be such a sticking spot for so many as to me it feels empty, especially when you realize servers see your naked password when you log in and servers are generating random codes all the time.
We Already Do It With App Specific Passwords
App passwords or app-specific passwords are randomly generated passwords used to get you in your account when a device doesn’t support 2FA or has unusual login requirements.
The concept of generating passwords for users is not a new idea, as we’ve been doing it with app passwords for years.
App passwords are the prime example that generating passwords for users not only works today, but we’ve been doing it for years with no major issues compared to the alternative.
Speeds Up The Sign-Up Process
Generating the password would also speed up the sign-up process. You won’t need to try 5 different passwords until the site are happy with the one you’ll forget anyway.
When you sign up, the website generates a password for you. The user can write the password down, save or print the page that has their login info, save it in their password manager or web browser, or simply do nothing.
Generating the passwords would also teach people that every website should have its own unique password. Password education happens at the signup pages, and password requirements have taught people to make “strong” passwords when they should have been making unique or disposable ones.
This would also make them more likely to take password storage more seriously too.
Fewer Support Tickets
Tickets for the help desk will go down. Someone forgetting their password is simply that, they forgot because they kept it in their head.
If you’re having your users write down or save the password, the less likely they’ll forget their passwords. You can’t forget something that is not in your head.
The help desk would also avoid the users who don’t seem to get password requirements. No more users telling you they used an uppercase but come to find out they used “uppercase numbers” instead. Yes, I’ve run into people saying they’ve used “uppercase numbers” before.
Herd Immunity
If all users are using unique passwords, you have herd immunity to many attacks.
No point in attacking a service to get the passwords if those passwords are not good anywhere else.
It would also help against credential stuffing attacks on the server as no user is reusing passwords. You also avoid the simple passwords that far too many people use too.
Perfect For The Lazy And The People Who Don’t Care
This method also is the best for the lazy and the people who don’t care. You can’t get any lazier than someone doing something for you, like generating the password.
And if you don’t care, you can do what you always do, nothing. If you choose not to let the browser save it for you, which many do automatically anyway, you can always later go to the password reset link and get back in. You’ll basically have “magic links” at that point which is still better than reusing passwords.
A Bad Generator Is Still Better Than Reusing Passwords
There is the issue of a service using a bad password generator, but even then, that is not a huge issue.
Even if you use a password generator that gave every 1 in 1,000 people the same password, it’s still better than those people using the same password they used on other websites.
If the password generator was predictable, you would also need to predict the order and time users signed up. The order and time people sign up are naturally random, making a predictable generator random again.
Once again, it’s not 2004, and doing proper random generators is not hard. A website would have to go out of its way to screw it up. I mean, we already do App Passwords and random TOTP secrets with no issue. Not saying it’s not possible, but we have so many examples of getting it right that it seems like a weak point to make, especially when we look at the alternative.
The Issue With Liability
Disclaimer: I’m not a lawyer.
You also have the downside of liability. If someone’s account gets hacked, they could sue you because you forced them to use a password they did not create.
The reality is that people can sue you for anything, and people still do sue even when they get to make their own passwords. After Ring’s “hacks,” they have a class-action lawsuit against them, and they allowed users to pick their own passwords.
At least, if you’re making the passwords for the users, you’re lowering your chances of them using a bad password. You’re damned if you do and damned if you don’t. The lesser of the two evils is to generate the passwords for the users to remove the chance they screw themselves over, like with what happened to Ring.
What If I’m Not Near My Password Book?
Another con people tell me is “the what if” they don’t have their password book?
After having a password manager and giving every account a unique password, I’ve noticed how much this is not as big of a problem people think it is.
If it’s a password you use all the time, you eventually remember it or place a note in your wallet, or use a password manager app.
Sure, there might be that one time you’ll need for some reason to log into your bank while at a home loan closing, but I wouldn’t let something that you’ll maybe do once in your life keep you from being more secure.
What could be so important that it can’t wait till you get home or call someone?
The people who make this argument are looking for a 1% problem to keep them from solving 99% of their issues.
What If Users Reuse That Generated Password?
An argument I get against generating passwords for users is that the user will think this password is strong, so they’ll reuse it in other places.
It’s a fair argument but also shortsighted.
If you have a user who loves to use “Fluffy123” for everything and one day, a site generates the password “bleep subatomic untainted swimming” do you believe that the user will give up using “Fluffy123”?
Let’s say the user does give up using “Fluffy123” and starts using “bleep subatomic untainted swimming” they would run into many websites that will reject this password because it’s either too long, lacking a special character, number, or uppercase.
The great thing about this problem is that it naturally fixes itself over time. The more websites that generate passwords for users, the fewer options the user has to reuse passwords. The more sites that generate passwords for users, the more it trains people for the right mindset that passwords are meant to be stored, not remembered.
People reusing generated passwords an issue? Yes, but I wouldn’t cut off my nose to spite my face.
What About WebAuthn Or Other Password Killers?
We’ve been trying to kill passwords for decades.
In 2004 Bill Gates predicted the end of passwords, and yet they’re still here.
We have promises of WebAuthn and many others, but they seem to never go anywhere. The biggest reason why these options don’t go anywhere is because they’re not as simple as passwords.
People get passwords. We have smart people working on great tech like WebAuthn, but these smart people forget about Nana who will never grasp the concept, but she does get passwords.
We would be better off evolving passwords into something better. Generating passwords for users doesn’t require much change in how websites are set up now, unlike those password killers. And people don’t have to learn any new tech or buy an expensive fob.
Sometimes the best solution is the easiest one.
Once you get people used to the evolution of generated passwords, it will help to bridge the gap to things like WebAuthn. Jumping right to WebAuthn will be too much of a leap, as people’s mindsets for such things is not there yet. It’s like trying to teach a caveman how to drive a car – let’s get him used to riding a horse first.
The Number Of Passwords Are Only Going To Get Worse
Passwords are a fact of life for the foreseeable future. They’re not going anywhere, and people will keep gathering more and more accounts that need passwords.
We, as a society, are better off generating passwords for users to get them in the correct habit to better secure everyone as a whole.
Am I Wrong?
If you think I’m wrong I would love to hear about in the comments below. Maybe I’m missing something?