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

101–110 of 136 posts

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

#101

Post by tptacek »

ig1 wrote: post #86

sigh 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

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

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

#102

Post by hsiung »

mfenniak wrote: post #92
hsiung wrote: post #6

Earlier quoted context omitted.

There 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 )

The downside to this is that it requires the server to store the password unencrypted and unhashed. The server must have access to the original password to hash with the random number for comparison. In my opinion, this wouldn't be an improvement in the overall security of the system. Avoid sending a plaintext password by using HTTPS. It's the easiest way.

You store the password hashed with a salt in the database (just keep track of the salt you used). The server can send the salt to the client, in addition to the random number. So the client is performing two hashes: md5(md5(password+salt)+random_token).

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

#103

Post by thorax »

tptacek wrote: post #98
thorax wrote: post #89

Earlier quoted context omitted.

Security is nothing but an obstacle course. The only time security is not merely an obstacle course is when you completely destroy the thing you're trying to protect. This is fundamentally something everyone needs to understand about computer security-- it's all about creating bigger and harder obstacles (including literal, physical obstacles). You can never absolutely secure something while it exists.

That's a fine argument for rejecting all of engineering. An asteroid could always strike the bridge we're building! Why bother making it structurally sound?

I'm not sure why you're treating my comment as an argument to reject security (or to reject anything other than your specific wording choice). I'm just saying that security, fundamentally, is about making obstacles.

There's nothing implied there regarding the importance/unimportance/quality of those obstacles. I don't think understanding its fundamental nature takes anything away from Security.

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

#104

Post by [deleted] »

tptacek wrote: post #100
huhtenberg wrote: post #70

Earlier quoted context omitted.

Actually - don't. http://img223.imageshack.us/img223/3784/clickpasskf8.png 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 ?

Ouch. Presumably you reported this.

[deleted]

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

#105

Post by tptacek »

thorax wrote: post #103
tptacek wrote: post #98

Earlier quoted context omitted.

That's a fine argument for rejecting all of engineering. An asteroid could always strike the bridge we're building! Why bother making it structurally sound?

I'm not sure why you're treating my comment as an argument to reject security (or to reject anything other than your specific wording choice). I'm just saying that security, fundamentally, is about making obstacles. There's nothing implied there regarding the importance/unimportance/quality of those obstacles. I don't think understanding its fundamental nature takes anything away from Security.

That's really not true. I think you're conflating cryptography with security. In crypto, I suppose you could consider algorithms that increase attacker cost as "obstacles", though I think the word loses meaning when the "obstacle" involves summoning more CPU cores than there are atoms in the solar system.

In practical security, closing a buffer overflow, sanitizing inputs, and proving code paths are not "obstacles". There are a finite number of vulnerabilities in any piece of code.

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

#106

Post by DougBTX »

tptacek wrote: post #105
thorax wrote: post #103

Earlier quoted context omitted.

I'm not sure why you're treating my comment as an argument to reject security (or to reject anything other than your specific wording choice). I'm just saying that security, fundamentally, is about making obstacles. There's nothing implied there regarding the importance/unimportance/quality of those obstacles. I don't think understanding its fundamental nature takes anything away from Security.

That's really not true. I think you're conflating cryptography with security. In crypto, I suppose you could consider algorithms that increase attacker cost as "obstacles", though I think the word loses meaning when the "obstacle" involves summoning more CPU cores than there are atoms in the solar system. In practical security, closing a buffer overflow, sanitizing inputs, and proving code paths are not "obstacles".…

In practical security, closing a buffer overflow, sanitizing inputs, and proving code paths are not "obstacles".

I think you're being a bit picky over wording, an "obstacle" is just something which makes it harder for some to break your system, examples of which are closing buffer overflows and sanitizing inputs.

You could, possibly, use it as an argument against engineering, but I think you'd be wrong. The same as someone arguing "we're all going to die anyway so lets get it over with now" is wrong: it means that you have to make the most of what you do have.

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

#107

Post by kwdowicz »

almost wrote: post #28
fiaz wrote: post #25

Earlier quoted context omitted.

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.

@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

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

#108

Post by tptacek »

gojomo wrote: post #72
tptacek wrote: post #61

Earlier quoted context omitted.

There are no passive-only attackers. Attackers who can observe raw traffic can hijack it (if it's the '90s) or redirect it (if it's 5 years ago, and in Brazil, and money is involved --- just to make it specific). Look, we're locked in an Internet message board death struggle and neither of us are going to concede anything, so let me just finish with this tangent: If you tried to sell an app to a Fortune 1000 company…

As should have been clear, I wasn't talking about apps with Fortune 1000 company customer data. I certainly did not suggest the mild javascript-hashing technique would be appropriate for such situations. (So, your 90+ word tangent hypothesizing that I might try to sell such a thing is... obdurate? A strawman? Unfair?) And, you seriously think there are "no" passive-only attackers? No people happy to merely scan or lo…

It's not 1997 anymore. People don't hijack TCP sessions. Have you ever done that before? It's incredibly noisy.

If you can observe insecure traffic, you can redirect it. The victim's traffic is never going to hit ycombinator.com.

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

#109

Post by tptacek »

DougBTX wrote: post #106
tptacek wrote: post #105

Earlier quoted context omitted.

That's really not true. I think you're conflating cryptography with security. In crypto, I suppose you could consider algorithms that increase attacker cost as "obstacles", though I think the word loses meaning when the "obstacle" involves summoning more CPU cores than there are atoms in the solar system. In practical security, closing a buffer overflow, sanitizing inputs, and proving code paths are not "obstacles".…

In practical security, closing a buffer overflow, sanitizing inputs, and proving code paths are not "obstacles". I think you're being a bit picky over wording, an "obstacle" is just something which makes it harder for some to break your system, examples of which are closing buffer overflows and sanitizing inputs. You could, possibly, use it as an argument against engineering, but I think you'd be wrong. The same as s…

This isn't just pickiness. This is two totally conflicting mindsets about security. I'll be ungenerous and say that mine, which rejects the concept of obstacle courses, is the practitioner's mindset.

We don't let things ship when we know they have exploitable vulnerabilities. We recognize that there are known unknowns and unknown unknowns, and we try to mitigate the former. But the known knowns? Come on. Just turn SSL on. The Javascript rewriting hack is not hard.

Post reply on HN