3 ms·

To build on what user "munk-a" said below... Back up a little bit. Start from the premise that you should never ever know the user's password. Period. Consider

To build on what user "munk-a" said below... Back up a little bit. Start from the premise that you should never ever know the user's password. Period. Consider that a liability. This is the beginning of a mindset. With this in mind, erase the statement "we need a program to send a username and a password". That is the wrong mentality. (IMHO) Now, you want your user, who you have authenticated, to be able to access other services that you don't own, am I correct? E.g., like IFTTT or Gmail? If that is the case, you need to use an authentication mechanism (e.g. Oauth2) that allows the user to approve authentication to a service. Then you store the token returned by that service and use that to obtain access. If it is not a big-name platform, then you need to work that platform service to implement OAuth (or Auth0, or Cognito, or some other token-based authentication system). If you are trying to access a service that does not support a token authentication system and only supports passwords, you should not allow the user to connect. This may damage your functionality value proposition, but IMHO it is more secure because you minimize exposure of the user's password. I wouldn't use a service that stored my plaintext password and logged in as me. To me, that's a no-go. Again, all my opinion. In fact, I'm eagerly reading this thread because I was in this situation years ago, and went with Auth0 (actually Stormpath before they were bought by Auhto0), but I had to argue for budget to pay for the service because I faced exactly the same pushback: "Just save the password!" I'd like to know if I missed something obvious.

naasking 7y ago
> Back up a little bit. Start from the premise that you should never ever know the user's password. Period. Consider that a liability. This sounds reasonable until you realize that requiring only the user to handle passwords creates an even bigger liability: users are terrible at creating, handling and remembering passwords. Giving them this sole responsibility means they create simple, short passwords and reuse them across multiple services, thus increasing their vulnerability. Browsers that started handling passwords and helping users create good passwords was one of the greatest security UX improvements of the past 20 years IMO.
- 0xff00ffee 7y ago
  Everything you said is true, but completely unrelated. :) Here's why: we are talking about the huge legal difference between liability of the user and liability of the service. If user's pick poor passwords, that's their problem, and a problem with passwords in general. But if you store the password, suddenly you are opening yourself up to bigger risks, risks that could sink your product. Big difference.

naasking 7y ago

> Back up a little bit. Start from the premise that you should never ever know the user's password. Period. Consider that a liability. This sounds reasonable until you realize that requiring only the user to handle passwords creates an even bigger liability: users are terrible at creating, handling and remembering passwords. Giving them this sole responsibility means they create simple, short passwords and reuse them across multiple services, thus increasing their vulnerability. Browsers that started handling passwords and helping users create good passwords was one of the greatest security UX improvements of the past 20 years IMO.

0xff00ffee 7y ago
Everything you said is true, but completely unrelated. :) Here's why: we are talking about the huge legal difference between liability of the user and liability of the service. If user's pick poor passwords, that's their problem, and a problem with passwords in general. But if you store the password, suddenly you are opening yourself up to bigger risks, risks that could sink your product. Big difference.