3

We are setting up an authentication system using Cognito and Amplify. We noticed that Amplify suggests Secure Remote Password as the default.

I can understand the benefits of SRP for protecting against man-in-the-middle and such attacks. But it seems there is a downside too: for example, the server is unable to perform strength checks or to call Have I Been Pwned to check if the password has been compromised. By choosing SRP, it seems like we are opening ourselves to more of our users choosing "Password123!" as their password. Edit: To clarify, we would still perform client-side password strength validation, but there are limitations compared to what can be achieved on the server-side.

I haven't been able to find much discussion on whether SRP is really a good choice or not. Does anyone know of standards or best practices I can refer to?

cbp
  • 131
  • 3

3 Answers3

2

Not really a direct answer, but it is way too long to be comment.

In the end, your question will boil down to: who is responsable for the security of a user password? And you fall in a quasi religious war... Many system admins think (know?) that most user do not care at all about the security of their password and they do their best to invent rules to improve that security (minimal length, forced or forbidden patters, maximum lifetime, minimal differences between consecutive passwords, etc.) And some other security actors think of that like a bandage on a wooden leg. Because it leads to users forgetting their passwords and secure password recovery is hard. And because in the end users just write down the password on a paper (post-it) sticked on the screen. So for those other people the only way to obtain security is to educate users so that they are aware of the risk involved by poor security practices, including poor passwords. Additionaly, they say that most of the rules actually (slightly) lower entropy which is bad, and tend to let the system process the plain text password longer which is also bad, specially is it leads to keeping plain text copies of previous passwords.

So if you tend to believe that the admin is the one that knows about security and that trusting users is stupid, then you should avoid any solution that let the end users choose their password without control. If you think that the users should be responsable for their own security and all that you can do is informing them of best and poor practices, then SPR is for you.

Apart from religion, I must aknowledge that some objective things can matter, mainly who the users are (corporate users, users interested in IT or security, or just anybody), and what is the sensitiveness of the application and its data...

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
2

You might want to consider testing password strength on the client side, using a package such as zxcvbn from Dropbox.

mti2935
  • 19,868
  • 2
  • 45
  • 64
  • Hi, thanks for the link. To clarify, yes we will test on the client-side, so the server-side validation would only be necessary if the client-side validation was somehow circumvented, or to access additional services such as HaveIBeenPwned. Indeed we should be using such a package rather than DIY. – cbp Feb 18 '21 at 14:52
  • @cbp That makes sense. I'm afraid that users who are determined to use weak passwords will always find a way to do so. But, the challenge of avoiding sending the password to the server, and ssearching for the password in password dictionaries (e.g rockyou.txt) client-side is interesting. Obviously, you can't download a 130MB password dict file to the client. But, perhaps you can send just the first two characters of the password to the server, then the server downloads just the passwords in the dictionary that begin with these characters (which would be <1MB) for the client to search. – mti2935 Feb 18 '21 at 15:16
  • Interesting idea! – cbp Feb 18 '21 at 22:02
0

Answering my own question here, as it is relevant.

We didn't realise that Cognito doesn't use SRP when passwords are created (e.g. through 'change password' or 'new user creation' operations). It only uses SRP for sign-ins.

This makes sense, because you can then do server-side strength validation and compromised credential checks when the password is created.

cbp
  • 131
  • 3