Best practices for passwords and password reset


#1

I’ve been asked to advise a large organisation about best practices for passwords and password reset.

Calls to customer service cost the client millions so the password issue is a huge concern.

At the moment it’s fairly obvious what the problems are: very strict password creation rules compounded by two factor authentication which are letters of a secret answer. The secret answer is created at account signup and is of ‘hidden password’ type. ie another password. This sounds ‘sub optimal’.

To reset the password, a user has to call the call center for a manual reset. Again, this is sub optimal.

I need a heavy evidence base to support my recommendations:

  • Free password creation with strong/weak indicator. Maybe minimum limit would be an idea but I’m certainly going to kill off special character rules.

  • I want two factor authentication but I’m not sure what’s best practice; text to mobile phone or selected entry from a secret second word

  • For password reset there will be option to send reset via email or mobile but I need another pattern when the user has access to neither. Has anyone got any suggestions for this? At the moment they have ‘answer five questions about your account’ which sounds risky.

I’ll be pushing very hard against internal teams who will not want to change data tables containing password creation rules. If I can’t get past this, I ain’t got much chance of making anything usable, I fear.


#2

Ideally, you can move past passwords altogether. (New NIST standards and recommendations are for password-less authentication and security.)

Password strength doesn’t really matter. You’re better off using 1-time passwords connected with an authenticated authority, like a email account.

Security questions are to be avoided as a password reset option. Answering questions about your account is also going to increase support costs.

2FA will help, but will not reduce support costs initially.

I’d spend time on the threat models and security perimeters, looking at making login/logout states non-binary.

There’s a video you can show the internal teams that I made specifically on this topic:

Insecure & Unintuitive: How We Need to Fix the UX of Security
https://www.uie.com/jared-live/#fix-ux-of-security

Hope that helps.


#3

One other factor that may affect things here: the service is used very rarely as it is an annual return type transaction. This makes the password conundrum even more troublesome, so as you say look for ways to move around passwords completely: “I always have information to hand that I can use to verify myself” seems way forward

I really appreciate your help Jared!

edit: I know what needs to be done and the hardest part is convincing the tin foil hat brigade. Can’t wait…


#4

How about the possibility that biometric identification is likely to take over from passwords and usernames for identification? Would that be something your organisation could work towards rather than spending so much time on a way of authenticating that is being superseded?


#5

There’s a really interesting blog post on password security/memorability by Jeff Attwood (founder of Stack Overflow/Stack Exchange) about how a lot of the norms we currently use for making passwords ‘secure’ aren’t really secure.

He suggests enforcing a longer password, rather than one that includes loads of special characters, numbers, uppercase (etc…) as they are easier to remember and actually generally more secure.

Definitely something to take into consideration as allowing users to have passwords that are easy to remember would reduce the amount of people needing to reset them.

https://blog.codinghorror.com/password-rules-are-bullshit/


#6

I’ve written a blog post on what’s wrong with Plusnet’s login process. It doesn’t directly answer the question, but points out somethings to clearly avoid.