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

How to implement HTTPS in an insufficient manner

troyhunt.com

Post reply on HN
Print view View original

11–20 of 68 posts

Re: How to implement HTTPS in an insufficient manner

#11

Post by claudius »

csmattryder wrote: post #2

This is the same guy who exposed similar flaws with Tesco's (UK supermarket chain) systems [1]. Why on Earth these companies are given free advice, but think they (or their PR folks) know better is beyond me. Take the advice! You've now got a security flaw, documented, waiting for Joe Hacker to take your customer's data and shoot a hole through your business, and its reputation. [1] http://www.troyhunt.com/2012/07/le…

Could someone explain to me why storing un(salted/hashed) passwords is such a big thing? Sure, it doesn’t hurt to salt and hash passwords[0], but since users aren’t supposed to reuse passwords anyways, what's the problem in storing 7UgHxJYjkgWDyCa9gsrH rather than db5670ac4a274055e3f785300bec563c48306bf3ab8cb32223a4cd311984a3b4?

[0] And possibly normalise their length/character set, something that comes for free with hashes.

Re: How to implement HTTPS in an insufficient manner

#12

Post by derefr »

JennyZ wrote: post #5
dragcdxfbv wrote: post #3

Do i have to pay or create accounts on third party services to use HTTPS (in nginx)? I never used https on my sites because there are some giant warnings ("dangerous") in browser when you go to a website that is self-signed. No warnings on plain http.

You can get a free SSL certificate at https://www.startssl.com/ , so that should not be a reason to keep you from using it. I do agree that the extreme mistrust of browsers towards self-signed certificates is an odd thing.

> I do agree that the extreme mistrust of browsers towards self-signed certificates is an odd thing.

No, not at all; it's the whole point of SSL. The guy MITMing an SSLed website can create a cert for that site himself, but he can't get it signed by a CA. So he has to sign it himself. Thus, from the browser's perspective, all self-signed certs are possible instances of "there used to be a CA-signed cert here, but now you're being MITMed."

Now, that's not to say something like self-signed certs wouldn't be nice--given some sort of distributed pin cache, we could have something closer to an SSH/PGP model where everyone's current self-signed cert "fingerprint" is on file, and alarm bells go off if you see a cert different from the one you're supposed to see. But without that, self-signing is literally no more secure than no SSL at all: anyone else can also self-sign to MITM you.

Re: How to implement HTTPS in an insufficient manner

#13

Post by eurleif »

claudius wrote: post #11
csmattryder wrote: post #2

This is the same guy who exposed similar flaws with Tesco's (UK supermarket chain) systems [1]. Why on Earth these companies are given free advice, but think they (or their PR folks) know better is beyond me. Take the advice! You've now got a security flaw, documented, waiting for Joe Hacker to take your customer's data and shoot a hole through your business, and its reputation. [1] http://www.troyhunt.com/2012/07/le…

Could someone explain to me why storing un(salted/hashed) passwords is such a big thing? Sure, it doesn’t hurt to salt and hash passwords[0], but since users aren’t supposed to reuse passwords anyways, what's the problem in storing 7UgHxJYjkgWDyCa9gsrH rather than db5670ac4a274055e3f785300bec563c48306bf3ab8cb32223a4cd311984a3b4? [0] And possibly normalise their length/character set, something that comes for free with…

What users do is not necessarily the same as what they should do.

Re: How to implement HTTPS in an insufficient manner

#14

Post by EvilTerran »

claudius wrote: post #11
csmattryder wrote: post #2

This is the same guy who exposed similar flaws with Tesco's (UK supermarket chain) systems [1]. Why on Earth these companies are given free advice, but think they (or their PR folks) know better is beyond me. Take the advice! You've now got a security flaw, documented, waiting for Joe Hacker to take your customer's data and shoot a hole through your business, and its reputation. [1] http://www.troyhunt.com/2012/07/le…

Could someone explain to me why storing un(salted/hashed) passwords is such a big thing? Sure, it doesn’t hurt to salt and hash passwords[0], but since users aren’t supposed to reuse passwords anyways, what's the problem in storing 7UgHxJYjkgWDyCa9gsrH rather than db5670ac4a274055e3f785300bec563c48306bf3ab8cb32223a4cd311984a3b4? [0] And possibly normalise their length/character set, something that comes for free with…

Users do reuse passwords, even if they shouldn't. Defence in depth.

Re: How to implement HTTPS in an insufficient manner

#15

Post by kijin »

The author lists 5 problems, but all of them have to do with the fact that the website in question is not 100% HTTPS. So it's really just one problem that has many different implications.

When you maintain both an HTTP site and an HTTPS site, it's nearly impossible to toss state back and forth between them without exposing yourself to at least one of these problems. Even if you do everything perfectly, people will complain that they get logged out when they visit HTTP URLs. The only solution is to treat HTTP, from now on, as if the only response it could produce were:

    HTTP/1.1 301 Moved Permanently
    Location: https://www.example.com/remainder/of/url
That's it. If you handle personal information, never send "200 OK" responses over plain HTTP, ever.

Need more server resources? Maybe. And this is probably why 99% of websites that have the problem the author mentions resist making changes. But the "HTTPS uses more server resources!" complaint is so 20th-century it's not even funny anymore. If you're not going to invest in 10% more server resources (or 5%, or 25%, or whatever) to protect your users' personal information, I seriously doubt that you deserve anyone's business in the first place.

Re: How to implement HTTPS in an insufficient manner

#16

Post by claudius »

derefr wrote: post #12
JennyZ wrote: post #5

Earlier quoted context omitted.

You can get a free SSL certificate at https://www.startssl.com/ , so that should not be a reason to keep you from using it. I do agree that the extreme mistrust of browsers towards self-signed certificates is an odd thing.

> I do agree that the extreme mistrust of browsers towards self-signed certificates is an odd thing. No, not at all; it's the whole point of SSL. The guy MITMing an SSLed website can create a cert for that site himself, but he can't get it signed by a CA. So he has to sign it himself. Thus, from the browser's perspective, all self-signed certs are possible instances of "there used to be a CA-signed cert here, but now…

> but he can't get it signed by a CA.

I strongly doubt that.

Re: How to implement HTTPS in an insufficient manner

#17

Post by webignition »

claudius wrote: post #11
csmattryder wrote: post #2

This is the same guy who exposed similar flaws with Tesco's (UK supermarket chain) systems [1]. Why on Earth these companies are given free advice, but think they (or their PR folks) know better is beyond me. Take the advice! You've now got a security flaw, documented, waiting for Joe Hacker to take your customer's data and shoot a hole through your business, and its reputation. [1] http://www.troyhunt.com/2012/07/le…

Could someone explain to me why storing un(salted/hashed) passwords is such a big thing? Sure, it doesn’t hurt to salt and hash passwords[0], but since users aren’t supposed to reuse passwords anyways, what's the problem in storing 7UgHxJYjkgWDyCa9gsrH rather than db5670ac4a274055e3f785300bec563c48306bf3ab8cb32223a4cd311984a3b4? [0] And possibly normalise their length/character set, something that comes for free with…

Firstly, an attacker with access to your backend database will have full access to user credentials if passwords are not salted and hashed. An attacker can then sign in as any user. The attacker may not be trying to steal all your have and may instead be looking to make life difficult for a single specific user.

Secondly, users will reuse passwords. An attacker with access to the plaintext password and the user's email address can use this to try to gain access to other services.

Thirdly, the attacker in the first example could be a disgruntled employee. You don't want a disgruntled employee causing trouble.

Lastly, I like to protect myself. A user of your services may claim you or your employees are signing in as them. It is convenient to be able to honestly state that this cannot happen.

Re: How to implement HTTPS in an insufficient manner

#18

Post by claudius »

EvilTerran wrote: post #14
claudius wrote: post #11

Earlier quoted context omitted.

Could someone explain to me why storing un(salted/hashed) passwords is such a big thing? Sure, it doesn’t hurt to salt and hash passwords[0], but since users aren’t supposed to reuse passwords anyways, what's the problem in storing 7UgHxJYjkgWDyCa9gsrH rather than db5670ac4a274055e3f785300bec563c48306bf3ab8cb32223a4cd311984a3b4? [0] And possibly normalise their length/character set, something that comes for free with…

Users do reuse passwords, even if they shouldn't. Defence in depth.

> Defence in depth.

Thanks.

Re: How to implement HTTPS in an insufficient manner

#19

Post by lucb1e »

kijin wrote: post #15

The author lists 5 problems, but all of them have to do with the fact that the website in question is not 100% HTTPS. So it's really just one problem that has many different implications. When you maintain both an HTTP site and an HTTPS site, it's nearly impossible to toss state back and forth between them without exposing yourself to at least one of these problems. Even if you do everything perfectly, people will co…

> all of them have to do with the fact that the website in question is not 100% HTTPS

Problem number 4 is actually also relevant for HTTPS-only websites. That is, if the website doesn't use HSTS, and most don't.

Also a 301 only works for one page. Consider this: You go to example.com (typed in address bar), it redirects you to https://example.com via a 301, then you load your favorite news website, I inject an iframe in the news website that loads http://example.com/pwnd, and the browser happily sends the cookie (if it wasn't set to secure-only).

The HSTS header is what you need to do, not only a 301.

Re: How to implement HTTPS in an insufficient manner

#20

Post by derefr »

claudius wrote: post #16
derefr wrote: post #12

Earlier quoted context omitted.

> I do agree that the extreme mistrust of browsers towards self-signed certificates is an odd thing. No, not at all; it's the whole point of SSL. The guy MITMing an SSLed website can create a cert for that site himself, but he can't get it signed by a CA. So he has to sign it himself. Thus, from the browser's perspective, all self-signed certs are possible instances of "there used to be a CA-signed cert here, but now…

> but he can't get it signed by a CA. I strongly doubt that.

Well, like I said--it's the whole point of SSL. If he can (and the CA responsible isn't immediately shut down), it means SSL is fundamentally broken.
Post reply on HN