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
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)
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.
I agree, recommending using multiple words in succession seems to me like safest, yet (hopefully) unique password creation process.
Loved the progress bar and the reminder to store it safely. UX-wise I think it is great.
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.
One thing that would add an extra layer of security though, is checking the typed password with haveibeenpwned.com/Passwords and blocking bad ones.
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).
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.
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 š¤£
It's the perfect example. End users think way more associative and wenas developera should embrace that in all our deliveries.
+1+1
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. :)
Doesn't checking if a password is pwnd require knowing a user's plaintext password? Isn't that a greater security risk?
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.
Ah OK. I didn't realise you could check the hash at pwnd. That's pretty neat.
Why not go passwordless? Something like magic.link/ could be fun
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.
Also (one of my pet peeves when people add goofy scripting to prevent pasting of credentials):
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).
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.
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.
I love password policy shaming... Even the password policy enforcers aren't really get it straight.
twitter.com/PWTooStrong
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.
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...