6 ms·
Why you shoud never use your favorite password on News.YCombinator.com
- socksandsandals 18y agoUm, pg? Can we get a fix on this, please?
- fiaz 18y agoI don't understand why this guy is getting down modded...I think it's perfectly reasonable to ask a question without incurring a penalty, regardless of how much you disagree with it.
- almost 18y agoIt's not that people disagree, it's just that the question is stupid. This is the kind of place I would have hoped people would know this sort of thing. It's kind of depressing to see such a stupid article at number 1.
- kwdowicz 18y ago@almost: an article can be stupid or smart, I didn't put it as no.1 - users does. If you think that his question is stupid and article is stupid and everything including super bowl is stupid - that means you don't match... take it easy
- almost 18y agoThat's why it's depressing, the fact that it was number 1 for a bit means that a fair amount of users didn't understand it.
- Hexstream 18y agoI wouldn't want us to set a precedent such that everyone formulate statements as questions to avoid the possibility of being modded down?
- fiaz 18y agoWhat about "listening to your users?"
- cperciva 18y agoOf course the password is in plaintext. Logins are done via HTTP, not via HTTPS. You know, there isn't that little yellow lock thingy in the bottom left corner of the window? Is this really news to anyone?
- hsiung 18y agoThere are still ways to add a little extra security for non-ssl logins. One way is by hashing the password via javascript with a random number provided by the server before posting it via HTTP. (see http://pajhome.org.uk/crypt/md5/auth.html http://pajhome.org.uk/crypt/md5/auth.html)
- tptacek 18y agoThat adds no security at all. Security is not an obstacle course.
- simonw 18y agoWhy doesn't it add security? It means the password isn't being transmitted in cleartext (it's using an irreversible hash). For the record, Yahoo! use that exact technique on their login page (though I'm not sure why as it's served over https). UPDATE: I see from a post further down that you're talking about re-writing the JavaScript in transit. Fair point.
- gojomo 18y agoIt adds a little. It means that a passive eavesdropper has to mount a offline dictionary attack before knowing the plaintext password. That's better than nothing.
- tptacek 18y agoNo. Respectfully, you too have failed to think this through. Attackers with access to raw traffic can (and routinely do) change the traffic. Attackers will simply rewrite your hashing Javascript in transit.
- deleted 18y ago[deleted]
- newt0311 18y agoIndeed. md5 hash on password + random token is industry standard now. It would be good to have that here.
- natrius 18y agoMaybe I'm not thinking this completely through here, but to do that, wouldn't you have to store your users' passwords in plaintext to verify the hashes? That's just replacing one problem with another. If you use the salt that you're using in your database as the token to concatenate instead of a random token, an attacker will only be able to use the data they capture to login on your site as opposed to all the sites the user has used the same password on. That sounds like it could work, but it might have security implications I haven't thought through yet.
- pc 18y agoNo. The server stores salted hashes, and serves the salt and a nonce as part of the login page. The client then submits hash(nonce + hash(salt + pass)). This protects against both replay and rainbow attacks.
- natrius 18y agoThat's better.
- apgwoz 18y agoI'm a bit confused here. If you were to store salted passwords when you create an account: salt = randomstring(4) hashed_pw = salt + ':' + sha1(salt + password) store(hashed_pw, login_name) How do you then verify this? In other words, how do you send the user the salt and the nonce if you don't know who the user is ahead of time?
- Hexstream 18y agoHere's how I understand it: The salt is generated on the server, it's always the same for a given user (and possibly all users). You concatenate this with the password in some way. The utility of this is that if a user's password is mypassword then it will be hashed as, say, mypasswordsalt so someone with a "rainbow table" of all hashes and the corresponding cleartext would normally have quickly known that the hash's cleartext is mypassword but the dictionary will fail to match the hash since there's no entry for mypasswordsalt. This is how rainbow tables are made useless should the attacker get access to the passwords in the database. I never used the nounce technique and can only make guesses so I'll refrain from trying to explain that part.
- arthurk 18y agoYou can do this with most sites. I don't know how much more load SSL would cause but a good solution would be to just use HTTPS for the login and then redirect back to the HTTP, like Twitter does.
- rsheridan6 18y agoI wish I could say I was surprised, but I'm not. If you look at websites that don't involve transferring money, you'll find a lot of passwords transferred in plain text. It should not be so, but it is. I use the same password here that I use on other sites which aren't very critical and which wouldn't really do me any harm if my account were cracked.
- axod 18y ago1. Go read up on HTTP vs HTTPS 2. Never use the same login for 2 websites The fact this has been upvoted to top position is more worrying than any security worries.
- kwdowicz 18y agoLook at the title of post - i'm not showing you HTTP is plaintext based - I said exactly "Never use the same login for 2 websites"
- jsteele 18y ago"Never use the same login for 2 websites" I call BS to that. Fair enough for websites that use your banking or credit card information, but for the rest? I don't think so. For irrelevant sites such as Hacker News, Reddit, whatever other minor web 2 site you can think of, you should ALWAYS use the same password. Why fart around with a ridiculous number of passwords for websites that are nothing more than minor daily distractions?
- deleted 18y ago[deleted]
- daniel-cussen 18y agoSo true. Most websites don't deserve good, distinct logins.
- breck 18y ago100% agree. Using "password" as your password will allow you to sign up for twice as many web 2.0 sites in the same amount of time. As an added bonus, you'll always remember your password at the 10% of sites you return to a second time.
- michaelneale 18y agoAgreed - now I would use my 3rd tier pwd for news.YC.
- tptacek 18y ago
- DaniFong 18y agoDigest access authentication is an immediate and halfway decent fix. At one point I thought this was a big enough problem to write a greasemonkey script hashing passwords clientside for every website. But it just isn't a big interest of mine.
- bct 18y ago> Digest access authentication is an immediate and halfway decent fix. It really is a shame that browsers have such a terrible UI for HTTP auth.
- tptacek 18y agoBefore you consider converting your own web app to HTTP auth instead of login forms, be aware of the fact that several of the top security firms will demerit your app for doing it, and that will hurt you selling to companies. I don't totally agree with this (HTTP digest auth, while silly, is still better than the crazy Javascript hashing schemes), but the logic is, it is difficult to "log out" and manage sessions with HTTP auth.
- cperciva 18y agobe aware of the fact that several of the top security firms will demerit your app for doing it Speaking as FreeBSD Security Officer: Several of the top security firms provide ratings which reflect the quality of their checklists more than the quality of the security in the systems they're assessing. The FreeBSD security team recently dealt with a case of "if you don't fix this, people using FreeBSD will lose marks on PCI audits" -- and our answer was "screw the auditors, this isn't a security issue and we're not going to send out a bogus security advisory just to keep some idiotic auditors happy".
- eru 18y agoCare to elaborate?
- 18y ago
- fourlittlebees 18y agoI use a password manager, and auto-generate a new 12-char pwd for every site I register with. Of course, if anyone would like to hack into my bank info and assume my debt, I will be more than happy to oblige. ;)
- immad 18y agouse clickpass
- huhtenberg 18y agoActually - don't. http://img223.imageshack.us/img223/3784/clickpasskf8.png http://img223.imageshack.us/img223/3784/clickpasskf8.png http://codefromthe70s.org/sslblacklist.asp http://codefromthe70s.org/sslblacklist.asp If they don't care about the security of their web interface, do you really want to entrust them with your passwords ?
- snorkel 18y agoOh no. You haxored my HN account. I'm so devastated. I am ruined. Simply ruined. Come to think of it I really don't care.
- JesseAldridge 18y agoI don't speak much bash. What does the script do exactly? Just demonstrates that the password is transmitted in plain text?
- eru 18y agoWhile you are at it: All that javascript hashing still leaks information. Why not implement some zeroknowledge protocoll with AJAX? (You need to send information back and forth because those protocolls are interactive.)
- ig1 18y agosigh the correct solution for this problem is SRP (see RFC 2945) which provides a secure transfer of password data and can be (and has been) implemented in javascript. However while that solution will prevent packet sniffing, if you want to prevent phishing attacks you still need to use SSL
- tptacek 18y agoYou can't implement SRP securely in Javascript, as I've repeat ad nauseum here --- attackers redirect traffic, they don't just sniff it, and when they do that, they can trivially rewrite the JS that delivers the SRP code. Beyond that though, if you're going to implement a crypto protocol, don't make it SRP. It is much harder to do SRP securely than it is to do simple message digests.
- ig1 18y agoWell if you're going to implement a crypto protocol over just using an off-the-shelf solution you're probably screwed anyway[1]. SRP over SSL is secure as far as I know, and SRP is certainly better than most of the other home-brew solutions proposed here. [1] I've read your blog before and know that I don't need to tell you this, but the generally community might :-)
- antirez 18y agoNot being able to downvote this is what you get on the frontpage...