3 ms·

Tokens were introduced to avoid saving passwords anywhere and they have the benefit of expiration. Don't save plaintext passwords. Ever. It's really that simpl

Tokens were introduced to avoid saving passwords anywhere and they have the benefit of expiration. Don't save plaintext passwords. Ever. It's really that simple. Why is this still an issue in 2019/2020?

deleted 7y ago
[deleted]
gowld 7y ago
> Tokens were introduced before 1990 https://en.wikipedia.org/wiki/Kerberos_(protocol) https://en.wikipedia.org/wiki/Kerberos_(protocol)
- 0xff00ffee 7y ago
  Precisely.
mcny 7y ago
> Don't save plaintext passwords. Ever. Sorry if I am saying something obvious but just so I understand... we need Team viewer to expose some way for a program to send a username and a password and team viewer then sends back a token saying store this instead. Now, every time the client makes a request, it should use this token? and if the client tries to use a user password, refuse? Thank you
- munk-a 7y ago
  When the user initially attempts to authenticate into Team Viewer send the user a randomly generated (not-derived off of user information at least) token in the response and register it with a data-store on the server. From that point on the user can re-authenticate with Team Viewer by sending the token until, for some reason, you decide to invalidate the token on the server - then the user is forced to re-authenticate with their password. At any point before their token is forcefully invalidated the user can optionally re-authenticate with their password to get a new token. That's the general gist, but if you're thinking of writing some software for it I'd suggest searching out some third party tool to manage these tokens for you or, if you're unable to find anything, then doing a bit of research into the pitfalls you can run into with this approach. The less you write in-house the better.
- 0xff00ffee 7y ago
  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.

deleted 7y ago

[deleted]

gowld 7y ago

> Tokens were introduced before 1990 https://en.wikipedia.org/wiki/Kerberos_(protocol) https://en.wikipedia.org/wiki/Kerberos_(protocol)

0xff00ffee 7y ago
Precisely.

mcny 7y ago

> Don't save plaintext passwords. Ever. Sorry if I am saying something obvious but just so I understand... we need Team viewer to expose some way for a program to send a username and a password and team viewer then sends back a token saying store this instead. Now, every time the client makes a request, it should use this token? and if the client tries to use a user password, refuse? Thank you

munk-a 7y ago
When the user initially attempts to authenticate into Team Viewer send the user a randomly generated (not-derived off of user information at least) token in the response and register it with a data-store on the server. From that point on the user can re-authenticate with Team Viewer by sending the token until, for some reason, you decide to invalidate the token on the server - then the user is forced to re-authenticate with their password. At any point before their token is forcefully invalidated the user can optionally re-authenticate with their password to get a new token. That's the general gist, but if you're thinking of writing some software for it I'd suggest searching out some third party tool to manage these tokens for you or, if you're unable to find anything, then doing a bit of research into the pitfalls you can run into with this approach. The less you write in-house the better.
0xff00ffee 7y ago
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.