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

131–136 of 136 posts

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

#131

Post by cperciva »

tptacek wrote: post #130
cperciva wrote: post #129

Earlier quoted context omitted.

You want evidence for the fact that SSL libraries have bugs? http://security.freebsd.org/advisories/FreeBSD-SA-07:08.open... http://security.freebsd.org/advisories/FreeBSD-SA-06:23.open... http://security.freebsd.org/advisories/FreeBSD-SA-06:19.open... http://security.freebsd.org/advisories/FreeBSD-SA-05:21.open... http://security.freebsd.org/advisories/FreeBSD-SA-04:05.open... http://security.freebsd.org/advisories/…

Of the 12 postings you provided, 6 have nothing to do with server security, 2 are dupes, and only two of the remainder date to after 2004. Thanks for making me do that research. I guess I deserve it. The comparison to Sendmail? Pretty laughable. Why don't you work from the real list of Sendmail vulns, not the ones in your personal database? Now, I'll respond: under what circumstances would you advise a prospective YC…

Of the 12 postings you provided ... 2 are dupes

I only posted 10 links, which is probably why you think there were 2 duplicates. :-)

The comparison to Sendmail? Pretty laughable. Why don't you work from the real list of Sendmail vulns, not the ones in your personal database?

FreeBSD security advisories were an easily available list of vulnerabilities which were assessed on the same basis. If I were going to "the real list of Sendmail vuln[erabilities]" (whatever you consider that to be) then I'd also have to use a real list of OpenSSL vulnerabilities -- including those which didn't affect FreeBSD because we didn't ship those versions, and the "oops, last months' security patch was broken" vulnerabilities which didn't affect FreeBSD thanks to the fact that the FreeBSD security team proofreads vendor patches.

under what circumstances would you advise a prospective YC app developer to avoid SSL because of the risk of server vulnerabilities?

If they didn't care about the confidentiality or authenticity of data being transmitted, then I would advise them to not use SSL.

More importantly, if they were using SSL, I'd advise them of the increased risk and suggest additional layers of defence -- for instance, terminating HTTPS within a jail at a proxy which forwards requests in plaintext over a localhost connection.

Of course, individual circumstances always vary, so it's hard to give any sort of blanket advice.

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

#132

Post by tptacek »

cperciva wrote: post #131
tptacek wrote: post #130

Earlier quoted context omitted.

Of the 12 postings you provided, 6 have nothing to do with server security, 2 are dupes, and only two of the remainder date to after 2004. Thanks for making me do that research. I guess I deserve it. The comparison to Sendmail? Pretty laughable. Why don't you work from the real list of Sendmail vulns, not the ones in your personal database? Now, I'll respond: under what circumstances would you advise a prospective YC…

Of the 12 postings you provided ... 2 are dupes I only posted 10 links, which is probably why you think there were 2 duplicates. :-) The comparison to Sendmail? Pretty laughable. Why don't you work from the real list of Sendmail vulns, not the ones in your personal database? FreeBSD security advisories were an easily available list of vulnerabilities which were assessed on the same basis. If I were going to "the real…

You have two advisories for the same 0.9.7l get-ciphers vulnerability. I have, as you've noticed, lost the ability to count. Yes, less than 40% of the evidence you provided survives a minute's scrunity.

If you really think OpenSSL has a worse track record than Sendmail, assert it directly. I don't think you will.

I think you've just provided some spectacularly bad advice to web devs here, Colin.

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

#133

Post by cperciva »

tptacek wrote: post #132
cperciva wrote: post #131

Earlier quoted context omitted.

Of the 12 postings you provided ... 2 are dupes I only posted 10 links, which is probably why you think there were 2 duplicates. :-) The comparison to Sendmail? Pretty laughable. Why don't you work from the real list of Sendmail vulns, not the ones in your personal database? FreeBSD security advisories were an easily available list of vulnerabilities which were assessed on the same basis. If I were going to "the real…

You have two advisories for the same 0.9.7l get-ciphers vulnerability. I have, as you've noticed, lost the ability to count. Yes, less than 40% of the evidence you provided survives a minute's scrunity. If you really think OpenSSL has a worse track record than Sendmail, assert it directly. I don't think you will. I think you've just provided some spectacularly bad advice to web devs here, Colin.

You have two advisories for the same 0.9.7l get-ciphers vulnerability.

No, there's one advisory for the original vulnerability, and a second advisory for a new vulnerability which was added when OpenSSL shipped a broken patch (this one we didn't notice in time -- mea culpa).

If you really think OpenSSL has a worse track record than Sendmail, assert it directly. I don't think you will.

Overall? No -- Sendmail had a horrible track record in the past. Recently? Yes, I would say that OpenSSL has a worse track record than Sendmail over the past 4 years.

I think you've just provided some spectacularly bad advice to web devs here, Colin.

You're entitled to your opinion, of course, but I'd like to hear more details -- which bit in specific do you consider was bad advice?

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

#134

Post by xirium »

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…

> bank transactions in Brazil

Banks in Brazil routinely issue each customer with a duress PIN to mitigate the situation of a customer being frogmarched to an ATM at gunpoint. This is in addition to ATMs being unavailable in early hours due to the majority transactions being theft at gunpoint.

Initial implementations of the duress PIN displayed an identical withdrawal limit and led to customers being shot. Subsequent implementations provide a reduced limit.

I discovered this after lending a trifling amount to a Brazilian ex-colleague in the UK. He retained his Brazilian bank account and, to repay me, he had calculate the timezone differences for ATM use.

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

#135

Post by immad »

huhtenberg wrote: post #70
immad wrote: post #35

use clickpass

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 ?

Thanks for pointing that out. We will fix this very soon...

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

#136

Post by ig1 »

tptacek wrote: post #101
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.

Well 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 :-)

Post reply on HN