Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Six Months Later: Seven Major Websites that Send Passwords Unprotected

blog.adamsmith.cc

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected

#21

Post by btilly »

davidcann wrote: post #7
toxicflavor wrote: post #2

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-i... Is that incorrect? If not, then I wonder how the author of this article can be so sure of his findings.

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 pass…

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.

Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected

#22

Post by davidcann »

btilly wrote: post #21
davidcann wrote: post #7

Earlier quoted context omitted.

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 pass…

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. (…

I went further still and stored the key on a disk that was on no network at all!

That's a good solution and it sounds like your system was about as secure as one could expect when needing to store sensitive data in a reversible format.

Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected

#24

Post by bl4k »

If you assume that an attacker has access to your traffic (via MITM DNS poisoning, proxy or something else remote) then logging in via SSL while running the logged in application over non-SSL prevents nothing, since the attacker can grab the session token/cookie.

Campaigns like this one are good, but they risk creating a false sense of security since sending a session token over the clear is vulnerable to the same exploits that logging in over the clear is.

This is why Gmail is all SSL by default now (and with the secure bit on the cookie set, so that it is only sent over https)

(with a XSRF exploit in a web app, capturing the session token is as easy as:

  document.write('');
speaking of, the session token on Hacker News is crazy short, which would make the keyspace small enough to be viably brute-forced (especially since expiry is infinity))

Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected

#25

Post by bosch »

It's extremely disappointing that the majority of sites don't have secure logins. Is there a certain performance penalty that is associated with it? (Not for something small, but say Facebooks scale if they were to have https as the default login?)

(After we get sites using https for logins I suggest we go after ones e-mailing passwords to users ala Plenty of Fish)

Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected

#26

Post by whakojacko »

bl4k wrote: post #24

If you assume that an attacker has access to your traffic (via MITM DNS poisoning, proxy or something else remote) then logging in via SSL while running the logged in application over non-SSL prevents nothing, since the attacker can grab the session token/cookie. Campaigns like this one are good, but they risk creating a false sense of security since sending a session token over the clear is vulnerable to the same ex…

Good point, but for most of the websites guilty of these problems I really dont care about stealing my session or any data being transmitted. Most of them have little other information I care about being stolen, besides maybe my email address (and that shouldnt even be a problem if the website is designed properly, although of course if they arent using SSL in the first place you might they probably aren't)

Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected

#27

Post by snoobie_ »

bosch wrote: post #25

It's extremely disappointing that the majority of sites don't have secure logins. Is there a certain performance penalty that is associated with it? (Not for something small, but say Facebooks scale if they were to have https as the default login?) (After we get sites using https for logins I suggest we go after ones e-mailing passwords to users ala Plenty of Fish)

My effort with Reddit, there is a post there with google's effort to do something similar and their performance issues.

http://www.reddit.com/r/ideasfortheadmins/comments/ct13j/add...

Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected

#28

Post by bigiain »

A question, how many people have seen a "password sniffed on the wire" attack in the wild? Apart from unsecured hacker attended conference wifi networks, Ive not encountered one, or heard about one from friends/colleagues. There's cases like the TJMax credit card exploit where the attacker got sniffing code running inside their processing network, but do attacks on Internet traffic while in-the-fuzzy-cloud-on-the-diagram actually happen? I suspect highly targeted attacks might, but not the large scale impact of server intrusions exposing (even hashed) password databases... ( Ive had "low grade" passwords exposed a couple of times in the last few years that way...)

Re: Six Months Later: Seven Major Websites that Send Passwords Unprotected

#29

Post by naz »

bl4k wrote: post #24

If you assume that an attacker has access to your traffic (via MITM DNS poisoning, proxy or something else remote) then logging in via SSL while running the logged in application over non-SSL prevents nothing, since the attacker can grab the session token/cookie. Campaigns like this one are good, but they risk creating a false sense of security since sending a session token over the clear is vulnerable to the same ex…

12 characters isn't _that_ short, there are still something like 52^12 combinations. I suppose it all boils down to how many sessions are active.
Post reply on HN