

7 Major Sites that Send Passwords Unprotected, & China's Deep Packet Inspection - adamsmith
http://blog.adamsmith.cc/2010/01/seven-major-websites-that-send-passwords-unprotected-and-state-sponsored-deep-packet-inspection.html

======
adamsmith
For the curious, below is the list of sites that DON'T send passwords in the
clear.

The curious case was Zynga. They don't have a login form. (!)

Facebook, YouTube, Yahoo, Windows Live, Blogger, Baidu, MSN, QQ.com, Google,
Twitter, MySpace, Amazon, Wordpress.com, Ebay, Rapidshare, yandex.ru, mail.ru,
imeem, Flickr, IMDB, Craigslist, LinkedIn, AOL, Blogspot, deviantArt, PayPal,
Alibaba, Ning, Hulu

~~~
vlad
As ridiculous as it sounds now, eBay used to give an option: use a non-secure
form (by default), or click a link to proceed to a secure login form using SSL
over https.

~~~
bigiain
I once had a website that did that - in '96 or '95 I think...

------
onedognight
Vanilla browser based https encryption cannot stop states like the US or China
which have access to all the major pipes. All it takes to do a man in the
middle on basic https is the key for any _one_ certificate that your browser
trusts. Any organization that has one (including many employers which install
certs) can easily watch your traffic.

HTTPS is fundamentally insecure against MITM attacks by governments.

~~~
tptacek
I think the spirit of your comment is pure tinfoil-hat, but the letter of it
is actually valid.

It is vanishingly unlikely --- on the level of "major diplomatic incident" ---
that China (or any other government, including ours) has the key associated
with Verisign's root CA certificate.

It is somewhat more likely (but still, I think, pretty unlikely) that one of
the following could have happened:

* Your computer is controlled by an employer that installed a deliberately insecure certificate.

* Your computer is infected with malware that poisons the CA store in your browser.

The first scenario is just very unlikely. We work extensively on-site for
Fortune 500 enterprises, in some of the highest-security environments in the
world (and in some of the most idiosyncratic and crazy), and none of them
require us to install bespoke certificates to access the Internet or their
websites. Now, you have to find the one employer (or zero ISPs) that not only
installed a custom root, but also _gave the keys to China_.

The second point is irrelevant. If your computer is infected with malware,
there are worse things to be done to you than injecting bogus certificates.

It is almost the case that it's worth pruning out certs from your browser from
untrustworthy CAs; unfortunately, the market for certificates has devolved to
"who will give us a cert the cheapest". I wouldn't know which ones to kill. A
year or so ago, pruning out untrustworthy CAs would have protected you from
the MD5 problem.

~~~
onedognight
> It is vanishingly unlikely [...] China [...] has the key associated with
> Verisign's root CA certificate.

Sure. I'll give you this.

> It is almost the case that it's worth pruning out certs from your browser
> from untrustworthy CAs;

This was my point. So you trust VeriSign, but do you trust the others (there
are 125 in my list)?

Here's one:

    
    
         Issuer: C=TW, O=Government Root Certification Authority
    

That looks like the Taiwanese government to me. If they have one you don't
think that US has one?

~~~
tptacek
If you suggest "now is the time to get paranoid about your certificate store",
I agree.

If you imply that there's a problem with the SSL/TLS/HTTPS model, I'm pushing
back hard. There is a weird SSL stigma among web developers, and it's time to
start beating it back. The alternatives are worse.

~~~
__david__
It's more a problem of certificate chain trust models. You have to trust the
security of every podunk CA in your browser's root store since they all have
the ability to sign anyone in the world's cert. Should the government CA of
Taiwan have the ability to sign bofa.com? I would say no. Let them have * .tw.

The funny thing is that x509 has the ability to limit signing to various CNs,
so it's possible to limit signing powers, but no one seems to do it.

> The alternatives are worse.

Hardly. _Some_ alternatives might be worse (plaintext everywhere, for
instance). What I would like to see is a * .example.com signing cert being
given to all domain owners when they buy a domain, signed by a single * .com
authority (or .net or whatever the domain is). This would prove to the https
client that the domain they are connecting to is really the domain owner. This
is a basic level of trust that would be an option for everyone who owns a
domain (without any stupid yearly charge for the certs).

Banks and other important sites could go above and beyond and buy certs that
verify that their business is what they say it is, which is another trust
level entirely (this already exists and can be seen when you go to paypal.com
in firefox and get the green location bar thing).

I think that would be a _much_ better alternative than our current system.

~~~
tptacek
I agree with you completely. By alternatives, I meant wholesale replacements
to SSL/TLS.

------
run4yourlives
I'd prefer we focus on sites that still _store_ passwords in the clear.

Yes reddit, I'm looking at you. Of course any other site that can actually
mail you a forgotten password is in fact doing this too.

~~~
adamsmith
Yup, the future is clearly client side hashing. I wonder if we could get the
latest and greatest from that field built into the next jquery etc so people
become more likely to use the routines. ...

That said states like Iran might be more likely to garner the most passwords
through sniffing, which is a passive activity, than hacking the sites that
store passwords insecurely.

~~~
tptacek
The future of secure password handling is feeding browsers _javascript_ so
they can _attempt_ to encrypt passwords?

I thought we got the future something like 10 years ago. It was called "TLS".

~~~
adamsmith
Hm, I guess I always assumed we would end up with SCrypt or something similar
running on the client side with a nonce etc so the server never even sees the
plaintext password.

Even if that means a new protocol that uses SSL to send the javascript, etc.,
and we're 15 years away.

Do you think designing a system where the server never sees (or has the
opportunity to store) the plaintext password is the way of the future?

(Edit: more emphasis on future, not short term, ambitions.)

~~~
Tichy
What scheme would allow for that, though? Except for public key cryptography?

Seems to me storing hashes and nonces does not work, because without the
original password the server can not create new hashes and nonces. So the
client would still always send the same thing, which would be equivalent to a
password.

~~~
adamsmith
yeah, I know what you mean. I do think it's solvable though.

one time during undergrad I was talking with Hal Abelson because there was
this big stink about the new research building (Stata center) requiring rfid's
to get around. Richard Stallman et al were making a huge ruckus about the
privacy implications of not having physical keys.

I mentioned some desired attributes of a protocol to let people in without
logging it, and started worrying about the implementation details /
feasibility. he said "oh don't worry about implementation. this building has
people in it who can implement anything." he had this smirk about him.

so give it some experts and time and they'll figure it out.

~~~
Tichy
Can they prove P = NP or P != NP? Some things just aren't solvable.

------
imgabe
Add to that, Stumbleupon.

They also email your password to you in plain text after you register for an
account. They do this after enforcing a password strength requirement when you
create the password.

It's not like they're storing critical data or anything, but lots of people
use the same password for a bunch of different things. It wouldn't take much
to glean a password from one insecure site and try it out on other, more
critical, services.

------
ax0n
Never mind the fact that if any of the authenticated traffic goes over the
wire in the clear (post-login), The Great Firewall could snarf sessionIDs and
replay them. This is the concept used in Errata Security's Hamster/Ferret
tools. You don't need a username or a password to read their gmail, update
their facebook status, or anything. And if any part of the session happens
without https, the whole session is at risk.

~~~
tptacek
This is the whole reason for the HTTP Cookie "Secure" flag: so that session
IDs set over HTTPS aren't inadvertently handed out over HTTP.

If you log in at <https://mail.google.com>, your entire session is encrypted.
If you log in via <http://mail.google.com>, your password is safe, but your
session ID isn't.

~~~
ax0n
Good point. Also, Moxie Marlinspike's tool, SSLStrip, can break some of this
stuff as well. I haven't tested it against the relatively few sites that go
out of their way to set the Secure flag.

------
pronoiac
I've been wondering this about Twitter _apps_ lately.

~~~
briansmith
Not only do many Twitter apps send your password in the clear, many of them
automatically give your Twitter username & password to any Twitter-specific
photo/video hosting service you use with them.

~~~
tptacek
I haven't used any Twitter app that didn't use OAuth. I don't use a lot of
Twitter apps, but what's the popular one that still wants your password?

I don't love OAuth, but it is at least a decent answer to the concern you're
raising.

~~~
wooster
Let me present issue 395, the most starred issue on the Twitter API bug
tracker:

<http://code.google.com/p/twitter-api/issues/detail?id=395>

Also fun: if I have an iPhone client app interacting with Twitter and also
with a web service that in turn interacts with Twitter, how does OAuth fit
into that scheme? Do I make the user do the OAuth dance for the iPhone app? My
web site? Both?

~~~
tptacek
I'm a lot less concerned about the threat model where one side is your
iPhone's persistant store and the other is Twitter. So, no, I think OAuth is
probably unnecessary for actual iPhone apps.

------
nlativy
Wikipedia has a secure server that is linked from their login page
(<http://en.wikipedia.org/wiki/Special:UserLogin>) so users don't have to send
passwords in the clear.

~~~
pgbovine
anything that's not the default will have a tiny chance of actually being
noticed or used :(

------
cmelbye
Not really fair to include Wikipedia on this list. The Wikimedia Foundation
actually has a completely separate secure server that actually forces you to
use https for authentication and article viewing. As far as I know, it works
for every single Wikimedia project and language. Wikipedia also has a bolded
section called "Secure your account" below the login form with six security
tips.

------
jbert
Of the sites which don't send passwords in the clear, any idea how many are
just obfuscating? (Xor, base64, etc).

~~~
tptacek
Anything that uses Javascript to encrypt passwords is almost certainly just
obfuscating passwords, in effect. Meebo was an example, awhile ago.

~~~
jbert
I guess you could send out a unique session key with the page, have the JS run
AES or similar.

Wait, stop, crypotime.

I'm appear to be trying to design a protocol for secret exchange. I should
just go and do some reading instead.

Do you know if there's any value in http digest auth these days? It's deployed
in http clients (but only with md5 algo?) and I think it requires the server
to store single-hash-of (salt,realm,pw) which you've eloquently pointed out in
the past is a bad idea (single-hash of pw is vulnerable to bruteforce since
hashes are fast).

My current thinking is that http basic auth over ssl would be preferred to
http digest (as an auth method widely, natively supported by http clients),
since it avoids pw in plaintext and allows server to store stronger hash (e.g.
stretched sha-256, bcrypt) for pw.

~~~
tptacek
The problem isn't crypto. The problem is that Javascript _in the DOM model_
runs crypto code in an environment where you can't be sure what any symbol
means, because any of a dizzying variety of page components or updates sourced
on-site and off, under SSL and (most likely) not, could have modified them.

------
cracell
We really should reinvent web traffic in encryption/secure setup is the
default way.

~~~
tptacek
With current technology, default encryption massively slows down the web. This
is Dan Bernstein's key research topic (I believe he's currently working on
"High Speed Cryptography", his book, but that's in support of both his DARPA
grant and his mission statement, which is "default encryption for
everything"). That's a _cryptographer_ , inventing and defending entire new
algorithms, because that's what he believes is necessary to achieve default
encryption.

In the meantime, what we really need to do is get rid of the stigma about SSL,
which credibly solves the problems we're talking about on this thread.

------
est
Taobao.com provides an ActiveX control for secure login. It can prevent
keyloggers.

~~~
adamsmith
So that's what that was.....I couldn't read the Chinese, ran into that form,
and then managed to switch over to a 'normal' login box through random
clicking. The normal one was unsecure, but I'm impressed by the ActiveX
control.

~~~
est
Well, an ActiveX login for online trading sites is like _de facto_ standard in
China now. The problem is every site has their own ActiveX, I myself must have
over 7 ActiveX installed.

And they are IE & Win32 only. That's why _every_ Mac & Linux user has to
install a VirtualBox/VMWare for online trading.

I was hoping Google Gears could provide some sort of similar mechanism,
together with CAPICOM exposure to Javascript across platform and browsers :)

------
Rauchg
I wrote about this a few months back: [http://devthought.com/blog/server-
side/2009/09/on-the-subjec...](http://devthought.com/blog/server-
side/2009/09/on-the-subject-of-login-forms-security/)

------
jganetsk
Add to the list plentyoffish.com (aka pof.com)

