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

51–60 of 136 posts

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

#51

Post by tptacek »

rw wrote: post #47
orib wrote: post #38

Earlier quoted context omitted.

You are. One of the defining properties of a cryptographic hash is that you cannot easily deduce the input given the output, nor can you easily construct an input to produce a given output. (see the overview at http://en.wikipedia.org/wiki/Cryptographic_hash ) However, it's still possible to do a dictionary attack on the database of hashes ("is the hash of "password" the same as the user's password hash? yes? Bingo!"…

Provided, of course, that P != NP.

Message digest functions are not, generally, number-theoretic.

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

#52

Post by tptacek »

jsteele wrote: post #20
kwdowicz wrote: post #16

Earlier quoted context omitted.

Look 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"

"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 d…

Start here: you forgot gmail. With your gmail I account, I can get most of what you do with money online.

You're also ignoring reputation. Breaking your Facebook account may not be a huge win by itself, but if I can use it to get your 50 Facebook friends to load a Javascript worm, I might have probably 40-50% of their bank passwords. Look what happened with Orkut a few months back.

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

#53

Post by cperciva »

tptacek wrote: post #42
newt0311 wrote: post #31

Earlier quoted context omitted.

Here is how it generally works. This method provides a salt along with a nonce. In general, only the actual user knows the password. Start: User registers for a service and submits a username + password. The password is salted and hashed in the browser and then sent to the server over a secure connection along with other info. like username etc... Then when somebody wants to so log in: Server sends a random nonce and…

You're not thinking this through. Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security. If attackers don't have access to raw traffic, sending over the plaintext password is just fine, because attackers don't have access to raw traffic. I'm sorry, but sec…

Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security.

No. It's entirely possible for an attacker to have access to your data (say, because they compromise a system which has been dumping packets for offline analysis) without being able to rewrite packets in transit.

I'm not saying that the suggested mechanism is a good idea, but let's be honest in our security analyses, ok?

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

#54

Post by tptacek »

Hexstream wrote: post #27
apgwoz wrote: post #24

Earlier quoted context omitted.

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…

This is going to make me sound like even more of an asshole, but I'm going to say it anyways because it is true: if you have to explain to yourself what a "salt" is, or you can't spell "nonce", you shouldn't be designing security systems. That doesn't mean your app needs to be insecure; it just means you should be using someone else's authentication system to do it.

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

#56

Post by tptacek »

cperciva wrote: post #53
tptacek wrote: post #42

Earlier quoted context omitted.

You're not thinking this through. Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security. If attackers don't have access to raw traffic, sending over the plaintext password is just fine, because attackers don't have access to raw traffic. I'm sorry, but sec…

Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security. No. It's entirely possible for an attacker to have access to your data (say, because they compromise a system which has been dumping packets for offline analysis) without being able to rewrite packets…

Colin, attackers aren't sniffing SprintNet with sunsniff to get access to traffic anymore. They're knocking over one of the 15-odd points where they can substitute their IP for COMCAST.NET.

Personally, I think you do a grave disservice to developers by dignifying the notion that "passive-only attacks" are a reasonable threat model.

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

#57

Post by gojomo »

tptacek wrote: post #50
gojomo wrote: post #46

Earlier quoted context omitted.

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

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

That's an active attack. My statement was clear and correct. The number of people who can passively eavesdrop on traffic (eg, on open wifi) is much larger than those who can dynamically change traffic in transit.

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

#58

Post by cperciva »

tptacek wrote: post #56
cperciva wrote: post #53

Earlier quoted context omitted.

Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security. No. It's entirely possible for an attacker to have access to your data (say, because they compromise a system which has been dumping packets for offline analysis) without being able to rewrite packets…

Colin, attackers aren't sniffing SprintNet with sunsniff to get access to traffic anymore. They're knocking over one of the 15-odd points where they can substitute their IP for COMCAST.NET. Personally, I think you do a grave disservice to developers by dignifying the notion that "passive-only attacks" are a reasonable threat model.

I didn't say that "passive-only attacks" were a reasonable threat model. In fact, I explicitly stated that I was not saying that the suggested mechanism was a good idea.

But even if only 0.0001% of attackers are limited to passive-only attacks (and I suspect the actual value is higher -- more like 0.1%) then the suggested mechanism is 0.0001% more secure than transmitting the password in plaintext -- which invalidates your assertion that it "provides no additional security".

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

#59

Post by tptacek »

cperciva wrote: post #58
tptacek wrote: post #56

Earlier quoted context omitted.

Colin, attackers aren't sniffing SprintNet with sunsniff to get access to traffic anymore. They're knocking over one of the 15-odd points where they can substitute their IP for COMCAST.NET. Personally, I think you do a grave disservice to developers by dignifying the notion that "passive-only attacks" are a reasonable threat model.

I didn't say that "passive-only attacks" were a reasonable threat model. In fact, I explicitly stated that I was not saying that the suggested mechanism was a good idea. But even if only 0.0001% of attackers are limited to passive-only attacks (and I suspect the actual value is higher -- more like 0.1%) then the suggested mechanism is 0.0001% more secure than transmitting the password in plaintext -- which invalidate…

No, because you're ignoring the fact that one of the 15-odd places that an attacker can bust up to redirect traffic to their own servers is the "observe all packets" vantage point, which allows them to predict DNS XIDs and source ports.

I know you're smarter than this, Colin. I think you're being pedantic. Would you advise anyone on this message board any differently than me? I think you already said "no".

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

#60

Post by cperciva »

tptacek wrote: post #51
rw wrote: post #47

Earlier quoted context omitted.

Provided, of course, that P != NP.

Message digest functions are not, generally, number-theoretic.

How is this relevant? The question of P ?= NP isn't limited to number-theoretic functions -- if P = NP then it is possible to find a preimage to any (polynomial time) hash function in polynomial time.
Post reply on HN