3 ms·

When ProjectLocker was accused of storing passwords in plaintext, they responded by saying: "You can't verify this for ProjectLocker or any other website witho

When ProjectLocker was accused of storing passwords in plaintext, they responded by saying: "You can't verify this for ProjectLocker or any other website without access to their backend systems." http://superuser.com/questions/46810/should-i-be-concerned-if-my-git-hosting-provider-stores-passwords-in-plaintext http://superuser.com/questions/46810/should-i-be-concerned-i... Is that incorrect? If not, then I wonder how the author of this article can be so sure of his findings.

mcknz 16y ago
I believe the article is referring to the plaintext transmission of credentials (your browser --> their server) which can be intercepted, rather than the plaintext storage of credentials (their server --> their database). Both are problematic.
- deleted 16y ago
  [deleted]
samdk 16y ago
Well, that's not what this is about. This is about sending the password (from the client to the sever, to log in) in plain text, and that's easy to verify by just sniffing your network traffic (which is what the author of this originally did). It may be impossible to verify completely whether a site stores passwords in plain text without back-end access, but sites that do often send forgotten password emails in plain text too. If a site's doing that, it's a pretty good bet they're storing it in plain text. (And if they're not, they're using a pretty insecure storage scheme anyway. Websites should store salted cryptographic hashes of passwords, not the passwords themselves.)
adamsmith 16y ago
Sorry for the confusion -- this whole thing is about how passwords are transmitted, not how they are stored. When it comes to password storage, though, the only way to find this out is: (1) if you are able to look at the backend systems, (2) if someone hacks in, as happened with rockyou (google: rockyou passwords), or (3) if they send you your password back in the clear in a password reminder email, rather than forcing you to create a new one. Note that #2 and #3, if they happen, only indicate that passwords are stored in the clear. If they don't happen that doesn't mean they are not stored in the clear.
- zck 16y ago
  >...if they send you your password back in the clear in a password reminder email, rather than forcing you to create a new one. This only indicates they store the password in a recoverable format. It could be encrypted. It shouldn't be stored encrypted -- hashing is the way to go -- but it doesn't mean the server has "hunter2" sitting on disk somewhere.
  - tptacek 16y ago
    It is extremely annoying to make "recoverable" encryption schemes even nominally secure. Most of the time, anything that can mail your password might as well be storing the raw passwords. It's bad mojo to suggest that "reversable encryption" is a good strategy. Every time this comes up, someone suggests some rube goldberg contraption involving multiple hosts and escrowed keys which is hard to refute except that it never exists in the real world and, even if it did, would still only provide security that asymptotically approaches hashing.
dmm 16y ago
I don't know how he can be sure, but you can know a site stores passwords if, for example, they are able to send your password to you if you forget it. This would not be possible if the password were stored as a salted hash.
davidcann 16y ago
Storing passwords in plaintext (or obfuscated) in a database is not what the author is saying. He's simply saying that they're not using encrypted HTTPS connections, so if a user logs into one of the offending sites over a publicly accessible connection (i.e. public wifi), anyone nearby could use a sniffer app to see their password travel over the network. Regarding the Super User post, he's correct that storing passwords as reversible rather than plain text is a LITTLE different, but if their servers are compromised, the hacker could simply run the reverse function on your password to retrieve it. The one situation where it's safer is if the database tables are hacked, but the server's code is still secure. I'd argue that storing reversible passwords is almost the same as plain text, but I'm interested to hear if people think reversible is significantly better than plain text.
- btilly 16y ago
  I'd argue that storing reversible passwords is almost the same as plain text, but I'm interested to hear if people think reversible is significantly better than plain text. Reversible can be secure, but only if it is done right. I once had to set up an affiliate section for a website, and we needed to securely store sensitive information such as tax IDs. My solution was to salt it then encrypt it with a public key. (The salt was not stored. Its only purpose was to make it impossible to do a brute force search through possible answers.) The private key was only available on a machine on a different network. (Because it only needed to be run every few months, I went further still and stored the key on a disk that was on no network at all!) From there it was easy to suck in the information, decrypt it with the private key, and put it into the financial system. Yes, I was storing sensitive information in reversible form. However even if you managed to compromise the webserver, the database, and had the source code, decoding that data was still effectively impossible. If you follow this strategy, the one thing that you cannot do easily is have the ability to have your website extract the sensitive information. (If you really want to you can have a table of requests, and a batch job elsewhere that attempts to fulfill them. Be very, very careful in setting something like that up though, because your attempt to open things up a crack may result in a hole a Mack truck could drive through.) However for certain use cases, it works quite well.
  - 16y ago

mcknz 16y ago

I believe the article is referring to the plaintext transmission of credentials (your browser --> their server) which can be intercepted, rather than the plaintext storage of credentials (their server --> their database). Both are problematic.

deleted 16y ago
[deleted]

samdk 16y ago

Well, that's not what this is about. This is about sending the password (from the client to the sever, to log in) in plain text, and that's easy to verify by just sniffing your network traffic (which is what the author of this originally did). It may be impossible to verify completely whether a site stores passwords in plain text without back-end access, but sites that do often send forgotten password emails in plain text too. If a site's doing that, it's a pretty good bet they're storing it in plain text. (And if they're not, they're using a pretty insecure storage scheme anyway. Websites should store salted cryptographic hashes of passwords, not the passwords themselves.)

adamsmith 16y ago

Sorry for the confusion -- this whole thing is about how passwords are transmitted, not how they are stored. When it comes to password storage, though, the only way to find this out is: (1) if you are able to look at the backend systems, (2) if someone hacks in, as happened with rockyou (google: rockyou passwords), or (3) if they send you your password back in the clear in a password reminder email, rather than forcing you to create a new one. Note that #2 and #3, if they happen, only indicate that passwords are stored in the clear. If they don't happen that doesn't mean they are not stored in the clear.

zck 16y ago
>...if they send you your password back in the clear in a password reminder email, rather than forcing you to create a new one. This only indicates they store the password in a recoverable format. It could be encrypted. It shouldn't be stored encrypted -- hashing is the way to go -- but it doesn't mean the server has "hunter2" sitting on disk somewhere.
- tptacek 16y ago
  It is extremely annoying to make "recoverable" encryption schemes even nominally secure. Most of the time, anything that can mail your password might as well be storing the raw passwords. It's bad mojo to suggest that "reversable encryption" is a good strategy. Every time this comes up, someone suggests some rube goldberg contraption involving multiple hosts and escrowed keys which is hard to refute except that it never exists in the real world and, even if it did, would still only provide security that asymptotically approaches hashing.

dmm 16y ago

I don't know how he can be sure, but you can know a site stores passwords if, for example, they are able to send your password to you if you forget it. This would not be possible if the password were stored as a salted hash.

davidcann 16y ago

Storing passwords in plaintext (or obfuscated) in a database is not what the author is saying. He's simply saying that they're not using encrypted HTTPS connections, so if a user logs into one of the offending sites over a publicly accessible connection (i.e. public wifi), anyone nearby could use a sniffer app to see their password travel over the network. Regarding the Super User post, he's correct that storing passwords as reversible rather than plain text is a LITTLE different, but if their servers are compromised, the hacker could simply run the reverse function on your password to retrieve it. The one situation where it's safer is if the database tables are hacked, but the server's code is still secure. I'd argue that storing reversible passwords is almost the same as plain text, but I'm interested to hear if people think reversible is significantly better than plain text.

btilly 16y ago
I'd argue that storing reversible passwords is almost the same as plain text, but I'm interested to hear if people think reversible is significantly better than plain text. Reversible can be secure, but only if it is done right. I once had to set up an affiliate section for a website, and we needed to securely store sensitive information such as tax IDs. My solution was to salt it then encrypt it with a public key. (The salt was not stored. Its only purpose was to make it impossible to do a brute force search through possible answers.) The private key was only available on a machine on a different network. (Because it only needed to be run every few months, I went further still and stored the key on a disk that was on no network at all!) From there it was easy to suck in the information, decrypt it with the private key, and put it into the financial system. Yes, I was storing sensitive information in reversible form. However even if you managed to compromise the webserver, the database, and had the source code, decoding that data was still effectively impossible. If you follow this strategy, the one thing that you cannot do easily is have the ability to have your website extract the sensitive information. (If you really want to you can have a table of requests, and a batch job elsewhere that attempts to fulfill them. Be very, very careful in setting something like that up though, because your attempt to open things up a crack may result in a hole a Mack truck could drive through.) However for certain use cases, it works quite well.
- 16y ago