Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why you shoud never use your favorite password on News.YCombinator.com

rafb.net

Post reply on HN
Print view View original

21–30 of 136 posts

Re: Why you shoud never use your favorite password on News.YCombinator.com

#21

Post by adamsmith »

cperciva wrote: post #9
breck wrote: post #8

Earlier quoted context omitted.

Agreed--not news. However, this is a common security problem that doesn't get enough attention. I would guess the easiest way to crack anyone's bank account is to create some flimsy website that requires users to register. Chances are good they will use the same user/password combo that they would use for their bank. Or you could crack one of the thousands of existing login websites to get passwords, which would be a…

I don't want to be liable if one of my servers is hacked and someone's bank account gets accessed because of it. Don't store user passwords in plaintext.

and hash the passwords on the browser.

Re: Why you shoud never use your favorite password on News.YCombinator.com

#24

Post by apgwoz »

pc wrote: post #17
natrius wrote: post #14

Earlier quoted context omitted.

Maybe 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…

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

I'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?

Re: Why you shoud never use your favorite password on News.YCombinator.com

#25

Post by fiaz »

socksandsandals wrote: post #2

Um, pg? Can we get a fix on this, please?

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

Re: Why you shoud never use your favorite password on News.YCombinator.com

#26

Post by anewaccountname »

adamsmith wrote: post #21
cperciva wrote: post #9

Earlier quoted context omitted.

I don't want to be liable if one of my servers is hacked and someone's bank account gets accessed because of it. Don't store user passwords in plaintext.

and hash the passwords on the browser.

I agree that that will be safe, provided you use the same browser-side hash function that the bank uses

Re: Why you shoud never use your favorite password on News.YCombinator.com

#27

Post by Hexstream »

apgwoz wrote: post #24
pc wrote: post #17

Earlier quoted context omitted.

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

I'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?

Here'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.

Re: Why you shoud never use your favorite password on News.YCombinator.com

#28

Post by almost »

fiaz wrote: post #25
socksandsandals wrote: post #2

Um, pg? Can we get a fix on this, please?

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

It'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.

Re: Why you shoud never use your favorite password on News.YCombinator.com

#29

Post by Hexstream »

fiaz wrote: post #25
socksandsandals wrote: post #2

Um, pg? Can we get a fix on this, please?

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

I wouldn't want us to set a precedent such that everyone formulate statements as questions to avoid the possibility of being modded down?

Re: Why you shoud never use your favorite password on News.YCombinator.com

#30

Post by bct »

DaniFong wrote: post #22

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

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

Post reply on HN