7 ms·
7 Major Sites that Send Passwords Unprotected, & China's Deep Packet Inspection
- adamsmith 17y agoFor 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 17y agoAs 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.
- deleted 17y ago[deleted]
- run4yourlives 17y agoI'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 17y agoYup, 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.
- run4yourlives 17y agoI think more people should be worried about the janitor with night time server access and a big Vegas debt to pay than the government of Iran, to be honest. That being said, point taken. While both are important variables to address, one is just plain bad practice.
- tptacek 17y agoThe 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".
- jacoblyles 17y agoCould you elaborate on this for us security newbs? Maybe expand the acronym? I know enough to encrypt my password storage, but I never thought to encrypt passwords client-side. I'm interested in knowing what are best practices.
- swolchok 17y agoTLS = SSL. HTTPS = HTTP over SSL.
- adamsmith 17y agoHm, 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.)
- pronoiac 17y agoI've been wondering this about Twitter apps lately.
- briansmith 17y agoNot 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.
- pronoiac 17y agoIs there an open catalog of these issues somewhere?
- tptacek 17y agoI 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.
- pronoiac 17y agoI haven't seen OAuth in use on the iPhone, though I've only tried a couple of Twitter clients.
- wooster 17y agoLet 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 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 17y agoI'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.
- onedognight 17y agoVanilla 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.
- deleted 17y ago[deleted]
- ronnier 17y agoWhile I was in China, I remoted back to my home computer through a remote desktop session to check email. I also tunneled my RDP session through an SSH proxy. Hopefully that was secure enough. I also changed my passwords once I returned home.
- deleted 17y ago[deleted]
- onedognight 17y agoOnce you have the host key for the site you are connecting to on your laptop SSH is not vulnerable to a MITM attack in the same way that browsers are with their huge CA list. Of course, pay attention to the warnings about changed host keys.
- swolchok 17y agoPatently false. If users submit to the login URL through a link that was sent in the clear, a MITM can just run sslstrip (http://www.thoughtcrime.org/software/sslstrip/ http://www.thoughtcrime.org/software/sslstrip/) and presto, you're visiting the HTTP version of the page instead of HTTPS. The login URL needs to be unavailable over HTTP, as does the login form.
- wooster 17y ago
- nlativy 17y agoWikipedia has a secure server that is linked from their login page (http://en.wikipedia.org/wiki/Special:UserLogin http://en.wikipedia.org/wiki/Special:UserLogin) so users don't have to send passwords in the clear.
- pgbovine 17y agoanything that's not the default will have a tiny chance of actually being noticed or used :(
- imgabe 17y agoAdd 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.
- cracell 17y agoWe really should reinvent web traffic in encryption/secure setup is the default way.
- sounddust 17y agoThat's one of the things that Google has proposed as part of their SPDY protocol.
- tptacek 17y agoWith 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.
- cmelbye 17y agoNot 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 17y agoOf the sites which don't send passwords in the clear, any idea how many are just obfuscating? (Xor, base64, etc).
- tptacek 17y agoAnything that uses Javascript to encrypt passwords is almost certainly just obfuscating passwords, in effect. Meebo was an example, awhile ago.
- jbert 17y agoI 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 17y agoThe 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.
- jganetsk 17y agoAdd to the list plentyoffish.com (aka pof.com)
- Rauchg 17y agoI wrote about this a few months back: http://devthought.com/blog/server-side/2009/09/on-the-subject-of-login-forms-security/ http://devthought.com/blog/server-side/2009/09/on-the-subjec...
- est 17y agoTaobao.com provides an ActiveX control for secure login. It can prevent keyloggers.
- adamsmith 17y agoSo 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 17y agoWell, 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 :)
- est 17y agoAlso it DOES provide a SSL login page https://login.taobao.com/member/login.jhtml https://login.taobao.com/member/login.jhtml plaintext version http://login.taobao.com/member/login.jhtml http://login.taobao.com/member/login.jhtml IIRC most of these popular sites provide a switch option between HTTPS and HTTP.
- ax0n 17y agoNever 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 17y agoThis 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 https://mail.google.com, your entire session is encrypted. If you log in via http://mail.google.com http://mail.google.com, your password is safe, but your session ID isn't.
- ax0n 17y agoGood 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.