Timeline for How can I convince my boss that storing third party passwords in plaintext is a bad idea?
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 6, 2018 at 10:15 | comment | added | Bergi | @LucaCiti Yes, that's the session token I was talking about. However, from a usability perspective you cannot ask a user to open the devtools and look up a cookie value. | |
| Mar 6, 2018 at 0:14 | comment | added | Luca Citi | Some websites use cookies to prevent asking the user to enter their password too often. I wonder if obtaining a login cookie from the client after login may actually give the OP''s company access to the website without having to know the client's password. | |
| Feb 27, 2018 at 16:58 | comment | added | Ian D. Scott | @emory The yubikey can do several things; including gpg. Encrypt passwords with gpg ('pass' does this), and have the decryption key on a yubikey. | |
| Feb 27, 2018 at 12:14 | comment | added | emory | @IanD.Scott the yubikey is cool, but I don't see how it would help the OP's problem. Actually it would break the OP's business. eg, I am a user. I foolishly gave OP my user name/password credentials so OP could fill out some forms for me. Later I sign up for yubikey. Now when OP tries to log into my account to fill out forms, it challenges OP for the yubikey. | |
| Feb 27, 2018 at 11:57 | comment | added | emory | @Accumulation who controls the usb stick key (assume me) and who needs the passwords (assume you)? what if you need to work over the weekends but I don't want to. will I end up just leaving the key plugged into the server (no real benefit to putting it on a removable stick)? or I will create a decrypted copy for you (no real benefit to encryption)? or will I give you a USB stick key (multiple keys mean it is easier for one to get lost)? If a single credential costs 64Kb then a 64Gb stick should hold 8,000,000 users ... why not just put them all on the stick and not on the server? | |
| Feb 27, 2018 at 7:04 | comment | added | Ian D. Scott | "but ultimately the key to it has to reside somewhere on your server"—I don't think this is entirely true. Some kind of hardware security token (like a yubikey, but something else might be better) could have the decryption key, and provide much better security, depending on the constraints. | |
| Feb 26, 2018 at 23:34 | comment | added | Acccumulation | The master password doesn't have to be stored; it can be re-entered whenever anyone wants to access the passwords. At the very least, it can be stored in a separate form. So, for instance, the passwords could be stored on a server while the master password is stored in a USB stick. Not foolproof, but at least one more point of failure. | |
| Feb 25, 2018 at 10:11 | comment | added | hytromo | @Bergi you are right I misread the question and I thought OP was speaking about clients of their website | |
| Feb 25, 2018 at 7:39 | comment | added | Bergi | @hakermania I understand that the OPs company needs access to their clients' accounts on foreign systems. Assuming those foreign systems don't support access by third parties, the user credentials need to be used in the normal login. (Of course when there is an API for third party access, that should be used). I don't understand what you mean by "custom url + trusted email + master password". | |
| Feb 24, 2018 at 22:10 | comment | added | hytromo | @Scott yes I agree with you. I don't say that there should be a master password for all the accounts! I just say that it can be used in combination with my other 2 points so as to have a secure implementation | |
| Feb 24, 2018 at 20:05 | comment | added | Scott - Слава Україні | @hakermania: Can you elaborate on your reference to a ‘‘master password’’? ISTM that storing a master password is just as bad as storing a bunch of individual passwords, and modifying a system to accept a master password makes the system less secure. | |
| Feb 24, 2018 at 18:34 | comment | added | hytromo | How isn't there a way around that? There can be a system that circumvents the login process entirely by using multiple security measures like: (i) a custom url for login, (ii) confirmation email sent to trusted email account(s), (iii) need for a master password. This way you can have support members getting into the clients' accounts for assistance. | |
| Feb 24, 2018 at 17:16 | comment | added | Bergi | @JonBentley I meant like "encrypt so that you cannot decrypt it yourself". If you keep encrypted data and the decryption key close together, it doesn't help a lot. See also the footnote. How can I phrase this better? | |
| Feb 24, 2018 at 17:10 | comment | added | Jon Bentley | I agree that you cannot hash them, but I see no reason why you can't encrypt them. | |
| Feb 23, 2018 at 22:07 | history | edited | Bergi | CC BY-SA 3.0 |
added 246 characters in body
|
| Feb 23, 2018 at 21:59 | history | edited | Bergi | CC BY-SA 3.0 |
added 246 characters in body
|
| Feb 23, 2018 at 21:54 | history | answered | Bergi | CC BY-SA 3.0 |