DEV Community

Cover image for What does it take to create a strong password?
Lisa Sy (she/her)
Lisa Sy (she/her)

Posted on • Updated on

What does it take to create a strong password?

At Forem, you might have seen some recent updates to our sign-in flow.

We're working to make it empower communities to provide whichever authentication methods best serve their need — whether that is social authentication (Twitter, Google, Facebook, etc), and/or email and password. We've typically leaned towards encouraging people to sign up using social authentication because 1) that doesn't require storing passwords on our end and 2) we think that requiring social auth prevents spam and harassers from profligating on our platform. But it's not enough just to provide social oauth as an option: some communities and people want to sign up with a good ole email and password.

How do we build out email/password authentication while ensuring that we mitigate as much spam & harassment as possible?! Ideally, we'd want to create and store their passwords with a password manager. But in the more common case where people don't want to use a password manager, how can we nudge them to create secure passwords? Here's where this idea comes in:

A contextual password helper

📹 Watch the video recording here

contextual password helper

Questions:

  • What are your general feedback around the video you see?
  • Should requiring numbers, lowercase and uppercase characters, and symbols be part of our requirements?

Thank you!

Top comments (26)

Collapse
 
shiraazm profile image
Shiraaz Moollatjie

For me, the worst passwords are those with special characters, uppercase combinations. They are easy to forget and dont provide any value except to delay brute force attacks. Additionally, users tend to use a main password and suffix them with some combination so it's not really secure from a holistic point of view.

What works for me is password generation via something like bitwarden or lastpass. These generate really obscure passwords for each account which is great.

What also works is 4 words thats greater than 11 characters as a password. That's more secure than any fancy scheme. Also easier to remember for the user.

Collapse
 
janmpeterka profile image
Jan Peterka

I agree, recommending using multiple words in succession seems to me like safest, yet (hopefully) unique password creation process.

Collapse
 
vtrpldn profile image
Vitor Paladini • Edited

What are your general feedback around the video you see?

Loved the progress bar and the reminder to store it safely. UX-wise I think it is great.

Should requiring numbers, lowercase and uppercase characters, and symbols be part of our requirements?

As a fan of diceware (see XKCD comic below) I don't particularly like the idea.

But I'm not sure if dropping these requirements to appease the minimal share of diceware enthusiasts (there are dozens of us, dozens!) is worth the potential loss of password entropy and security.

I know that Google and some other big players do not enforce it but I'm not familiar with their whole password ruleset.

XKCD comic about diceware passwords

One thing that would add an extra layer of security though, is checking the typed password with haveibeenpwned.com/Passwords and blocking bad ones.

Collapse
 
cescquintero profile image
Francisco Quintero 🇨🇴

Hi Lisa :)

The design and the interaction in the video looks impressive and the "wizard"-like sloth telling how it's going it's great as well.

Personally, ever since I read this Coding Horror article (and whenever I can) I prefer long passwords that resemble full sentences.

The post criticises a lot password rules but it doesn't say they're totally wrong BUT rule #1 should be password length (12 characters minimum).

Collapse
 
jankapunkt profile image
Jan Küster • Edited

Interestingly do less experienced user go better with sentences or groups of words as they are much easier to revognize in a visual way. This is at least what we observed with our project partners.

Collapse
 
cescquintero profile image
Francisco Quintero 🇨🇴

Right. A fun history about passwords I recall is one from a father of a friend of mine. His password for Facebook was a short sentence about his pet parrot 🤣

Thread Thread
 
jankapunkt profile image
Jan Küster

It's the perfect example. End users think way more associative and wenas developera should embrace that in all our deliveries.

Thread Thread
 
lisasy profile image
Lisa Sy (she/her)

+1+1

Collapse
 
wout profile image
Wout

We've recently gone through a similar process. Initially, we had almost the exact same approach as shown in your video.

While we (nerds) liked it very much, our beta testers, not using a password manager, did not. Even the requirement for anything more than 8 characters could be a deal beaker for some.

In the end we scrapped the whole thing, and decided to require just 8 characters. But we check if the password is pwned and don't allow those that are. We check them again every month at login, and warn the user if the pwned status changes.

Hope that helps. :)

Collapse
 
mellen profile image
Matt Ellen

Doesn't checking if a password is pwnd require knowing a user's plaintext password? Isn't that a greater security risk?

Collapse
 
wout profile image
Wout

Good question. Yes, we need to know the plain text password. That's why we can only check the pwned status at signup and login. We never store or log plain text passwords, nor do we send them over a network. Checking with the Pwned API happens by hashing the password and sending just a part of the hash over to Pwned. So the plain text password only exists in memory for the duration of the signup or login request.

Thread Thread
 
mellen profile image
Matt Ellen

Ah OK. I didn't realise you could check the hash at pwnd. That's pretty neat.

Collapse
 
jpantunes profile image
JP Antunes

Why not go passwordless? Something like magic.link/ could be fun

Collapse
 
desbest profile image
Adisa Nicholson • Edited

Strong passwords do not give greater security. They were designed to protect against dictionary attacks in the times when md5 was used to encrypt passwords. The theory was that if your password was not a word in the dictionary, a dictionary attack wouldn't work. Some dictionary attacks can account for numbers now. Dictionary attacks were solved by brute force protection and when md5 was cracked due to rainbow tables, everyone switched to bcrypt for encryting passwords, which protects against brute force (that dictionary attacks use) due to the slowness that bcrypt has, rainbow tables and password databases.

Most people are privacy conscious and data conscious and most people do not like social login. They prefer a username and password as people like to give out as little information about themselves as possible. When websites require social logins, less people will sign up. Although some people believe that using real names reduces harassment and bullying online, I don't agree. In general people don't like to use their real names online.

Password managers are a nightmare because if you forget the password to a password manager, you have lost all your passwords. So it's not surprising they aren't popular or mainstream.

I use a free service called Stop Forum Spam to protect against spammers. It stops 99% of spam from entering my forum.

Collapse
 
linuxwrangler profile image
linuxwrangler • Edited
  1. Go to the experts, first: pages.nist.gov/800-63-3/sp800-63b.... (section 5.1.1.2 in particular) and especially note that their previous recommendations are updated to reflect years of real-life experience. For instance:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Also (one of my pet peeves when people add goofy scripting to prevent pasting of credentials):

Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.

That's just a bit of the advice. Read the doc.

Many security audit requirements either reference or are derived from NIST guidelines which may prove helpful if you end up in a situation where security audits or compliance are required.

Additionally, if you are using something like an email address as the user name be really, really, absolutely sure that you are consistent in verification across all components and that your verification strictly adheres to the appropriate RFCs. I can't believe how many so-called professionals screw this up and end up accepting, confirming and successfully using a provided email address but then refuse to allow completion of account setup using that address (looking at you Red Cross, AARP, Fastrak, ...). Yes, "+" is a legal and useful character.

Finally, if there are restrictions/requirements, be sure they are all shown up-front. Don't leave me pasting in a strong auto-generated 32-character random password and keep rejecting it without any displayed reason leaving me to guess what non-NIST-conforming "rule" was broken and retry (looking at you, USC recommendation portal).

Collapse
 
webbureaucrat profile image
webbureaucrat

It's disappointing that this thread is full of people sharing their formulae for
making passwords memorable. I don't know why people pretend that any person can generate long, random, unique passwords and memorize them for each service they use. It's dishonest and harmful, and we all know that the people who say that they do that are actually reusing passwords.

Password managers are the only safe way to use passwords.

Collapse
 
cescquintero profile image
Francisco Quintero 🇨🇴 • Edited

People won't. Even I have a "generic" password for places I don't care too much. However, we should encourage and try our best to educate users to create good passwords. It's for their good.

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt

I love password policy shaming... Even the password policy enforcers aren't really get it straight.

twitter.com/PWTooStrong

Collapse
 
jwp profile image
John Peters

Today's big companies require 8 to 9 chars, at least one in caps, one number and one special char. Not too bad once we get into the concept and change our public accounts using same general rules. For example I may leave out special chars for public low impact sites, or adopt a common sub rule of the corporate rules. This makes them easier to remember. Also don't forget about expiring password to enforce change.

Collapse
 
michaelphipps profile image
Phippsy

The original strong password recommendations made by Bill Burr back 2003 need to be tossed into molten lava.

Expiring passwords is a bad design that causes password fatigue in users. Ultimately users create Pa$$w0rd1, Pa$$w0rd2, Pa$$w0rd3. This causes more requests for password resets because they can't remember what they did, and doesn't actually improve security.

Microsoft actually stopped expiring passwords in Windows 10
zdnet.com/article/microsoft-says-w...

Collapse
 
michaelphipps profile image
Phippsy

Beautiful user interface. Horrible user experience. I can already hear my wife screaming at the screen!

The strong password rules being used come from a document written back in 2003 by Bill Burr, who wasn't even a security expert. Over time, those rules have come to be the cause of some really bad password practices.

As a designer, you want to improve the user experience while still getting strong passwords.

If you must use passwords, maybe try displaying a random passphrase of nonsensical words to the user as a password suggestion rather than forcing their password to comply with all the character rules.

Here's an example I just got from a random word generator.

we lump expect inch provide

(I swear these are random words! Sorry it sounds naughty, but the plus side is it actually makes it easier to remember)

The arguments for this being a suitable alternative for passwords that contain special characters / hieroglyphs / gang signs break down after about 4 words. (search "random words versus random characters for passwords" for more insight on this)

Of course, enforcing the 4+ word requirement would also introduce friction, but could make for a better user experience than the character level rules. Split testing would give you some idea.

One last thing to consider. Do your accounts actually have a need for super strong passwords? What bad things could happen if a user's account was compromised? If the consequences of a weak password are low, and removing the password check removes friction, I'd ditch strong password requirements immediately - particularly if you're making a sale on the other side of the user registration.

I personally prefer another approach - the magic link - because it removes the need for a user to come up a suitably strong password all together. However, it does introduce the friction of having to go to your email client to login.

Collapse
 
andrewbaisden profile image
Andrew Baisden

I just use LastPass. If you don't even know your own password then nobody can hack you 😂

Collapse
 
catalinradoi profile image
CatalinRadoi

Does anyone else do lifehacking with passwords? Or is it just me?

@HaveAGla$$OfWater.Now321go

Collapse
 
miggy_pop profile image
miggy_pop

Hi! This video by Computerphile is a pretty solid take on the subject. Cheers!

Collapse
 
mdev88 profile image
Martín Vukovic

I really like this approach: grc.com/haystack.htm

Collapse
 
michaelphipps profile image
Phippsy

That article is a brilliant read! Thank you for sharing!