7 ms·

How to implement HTTPS in an insufficient manner

135 points by tomelders 14y ago

csmattryder 14y ago
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/lessons-in-website-security-anti.html http://www.troyhunt.com/2012/07/lessons-in-website-security-...
- nwh 14y ago
  I emailed my ISP today to ask them why my password was being stored in plain text (and not even escaped) in a MySQL database. Their response was that everything was "working", so I didn't have to worry. Bear in mind, this is a company with my banking details. I have absolutely no expectation that it is going to be fixed either.
  - devcpp 14y ago
    How do you know they do? That said, you should have seen my face when my ISP emailed me my very password for online access, in plain text. It was something like 123456. Unforgivable double offense.
    - nwh 14y ago
      Their tools truncated my changed password to 25 characters silently (first clue), their password reset tool emailed the plaintext password back to me (second clue), and their "api" endpoint errors out when I use special characters in my password (last clue).
- claudius 14y ago
  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.
  - eurleif 14y ago
    What users do is not necessarily the same as what they should do.
  - EvilTerran 14y ago
    Users do reuse passwords, even if they shouldn't. Defence in depth.
    - claudius 14y ago
      > Defence in depth. Thanks.
  - webignition 14y ago
    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.
    - claudius 14y ago
      I give you the first three points, though at least the first one sounds a little academic, given that someone with access to the backend database could probably effect queries ‘simulating’ an active user. However, > 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. sounds odd, since the user transmitted their password in clear text to the server at least once when registering, unless you use browser-side hashing/salting, in which case this hash would then take on the role of a password (i.e. wouldn’t help at all). Furthermore, anyone with database access could overwrite the hash in the database, log in with the password matching the new hash and then put the old hash back in place.
- WatchDog 14y ago
  These companies likely have staff that already are acutely aware of the problems. It is sometimes very difficult to change anything from the inside, sometimes you need some negative PR to actually get the ball rolling.
dragcdxfbv 14y ago
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.
- JennyZ 14y ago
  You can get a free SSL certificate at https://www.startssl.com/ 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.
  - derefr 14y ago
    > 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.
    - claudius 14y ago
      > but he can't get it signed by a CA. I strongly doubt that.
      - derefr 14y ago
        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.
deleted 14y ago
[deleted]
markhemmings 14y ago
I'm the guy who originally contacted Troy Hunt about this, as he mentions in the blog post. What annoys me is I'm a very young developer, and I've only really just become interested in security (12 months ago I didn't even know what hashing was!!!), yet there's developers out there with years and years of experience making huge sites for the likes of Tesco and TopCashBack for vast sums of money and they don't think about incorporating even the simplest foundations of internet security a novice like me would implement without even thinking! How is this possible?! If I'm doing it in tiny little php sites with 1 unique visitor ever, why are these 'experts' not in there huge corporate sites with hundreds of thousands of users a month?!
- kijin 14y ago
  Because huge corporations often prioritize other things over technical expertise, and experts often prefer to work in settings other than huge corporations.
- troyhunt 14y ago
  Years and years of experience? Often not, and that's speaking from years and years of experience! Vast sums of money? Yes, at least the outsourcing vendors who churn this sort of thing out. Unfortunately you're the exception Mark so good on you for that. Well I mean unfortunate for the greater web using population, but very fortunate for you!
  - ZoFreX 14y ago
    To expand further on those points with a personal anecdote... I worked on a "big website" for a very big government department. I was still in university at the time, had about a year's experience with the platform, and was earning close to callcenter wages. The government only contracts to companies on a particular whitelist, which we weren't. They paid a company something in the region of £300,000 for the website. That company then outsourced 100% of the work to the tiny (single digits employee count) company I was at. They paid us £40,000. My share of that works out at about £2,000. The fact something cost half a million dollars in no way implies any kind of quality, or that the people working on the software will know what they're doing. (Really: another horror story involved a website that only needed to work in IE6... and had been built and tested purely in Firefox)
lucb1e 14y ago
Https article served over http. Lovely. Edit: Besides that problem #1 is offtopic since it has nothing to do with https and that 3/4 other points are captain obvious, #4 is actually a good one. It's so obscure that many will forget to enable it ("all pages are secured anyway"), but whenever a user visits any http page, an attacker can inject a small frame loading the http version of my website, and even if I redirect, the cookie was already sent and read by the attacker. Only an HSTS header or enabling the secure-cookie option protect against this.
- troyhunt 14y ago
  If there was something worth protecting on a personal blog site, it might be a different story. 1 is very on-topic - there's no way that data should be sent in the clear. HSTS is good, but unfortunately only partially supported. Agree on the secure cookie, but of course you need to drop the dependency on accessing it over HTTP before you do that.
  - lucb1e 14y ago
    > If there was something worth protecting on a personal blog site, it might be a different story. It's not about security here, it's about privacy. https://willnorris.com/2012/12/all-https-all-the-time https://willnorris.com/2012/12/all-https-all-the-time > This blog isn’t terribly controversial. But if only the "controversial" stuff is private, then privacy is itself suspicious. Thus, privacy should be on by default.
    - Tomdarkness 14y ago
      HTTPS is not really that effective for privacy. An attacker can still see what site you visited (Well, the IP, but it would be fairly trivial to get the domain as well) and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested.
      - Hannan 14y ago
        >> ...and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested. Could you elaborate on this? I would have assumed that with the request URI being encrypted that this would be extremely difficult (load times/payload size maybe?) for all but the simplest of sites.
kijin 14y ago
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.
- lucb1e 14y ago
  > 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 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 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.
  - kijin 14y ago
    > Problem number 4 is actually also relevant for HTTPS-only websites. You're right, but I was thinking along the lines of: The reason why they don't set secure cookies is probably because they want to share state between their HTTP site and their HTTPS site. > Also a 301 only works for one page. You can make it work on every page. Even the query string will remain intact. POST requests are more complicated, but they are usually triggered by forms and JS on your own pages, so you have more control over that. RewriteEngine on RewriteCond %{HTTPS} !on Rewrite (.*) https://www.example.com/$1 [L] Of course, this doesn't solve the insecure cookie problem. But again, I'm assuming that not being HTTPS-only is the root of all evils.
ancarda 14y ago
SSL should really be all or nothing. The same way browsers don't like loading insecure content from a secure origin, they should also squirm at the idea of submitting a form to a secure area (from non-secure) -- including if the parent is non-secure. An iframe isn't good enough.

135 points by tomelders 14y ago

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/lessons-in-website-security-anti.html http://www.troyhunt.com/2012/07/lessons-in-website-security-...

nwh 14y ago
I emailed my ISP today to ask them why my password was being stored in plain text (and not even escaped) in a MySQL database. Their response was that everything was "working", so I didn't have to worry. Bear in mind, this is a company with my banking details. I have absolutely no expectation that it is going to be fixed either.
- devcpp 14y ago
  How do you know they do? That said, you should have seen my face when my ISP emailed me my very password for online access, in plain text. It was something like 123456. Unforgivable double offense.
  - nwh 14y ago
    Their tools truncated my changed password to 25 characters silently (first clue), their password reset tool emailed the plaintext password back to me (second clue), and their "api" endpoint errors out when I use special characters in my password (last clue).
claudius 14y ago
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.
- eurleif 14y ago
  What users do is not necessarily the same as what they should do.
- EvilTerran 14y ago
  Users do reuse passwords, even if they shouldn't. Defence in depth.
  - claudius 14y ago
    > Defence in depth. Thanks.
- webignition 14y ago
  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.
  - claudius 14y ago
    I give you the first three points, though at least the first one sounds a little academic, given that someone with access to the backend database could probably effect queries ‘simulating’ an active user. However, > 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. sounds odd, since the user transmitted their password in clear text to the server at least once when registering, unless you use browser-side hashing/salting, in which case this hash would then take on the role of a password (i.e. wouldn’t help at all). Furthermore, anyone with database access could overwrite the hash in the database, log in with the password matching the new hash and then put the old hash back in place.
WatchDog 14y ago
These companies likely have staff that already are acutely aware of the problems. It is sometimes very difficult to change anything from the inside, sometimes you need some negative PR to actually get the ball rolling.

dragcdxfbv 14y ago

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.

JennyZ 14y ago
You can get a free SSL certificate at https://www.startssl.com/ 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.
- derefr 14y ago
  > 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.
  - claudius 14y ago
    > but he can't get it signed by a CA. I strongly doubt that.
    - derefr 14y ago
      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.

deleted 14y ago

[deleted]

markhemmings 14y ago

I'm the guy who originally contacted Troy Hunt about this, as he mentions in the blog post. What annoys me is I'm a very young developer, and I've only really just become interested in security (12 months ago I didn't even know what hashing was!!!), yet there's developers out there with years and years of experience making huge sites for the likes of Tesco and TopCashBack for vast sums of money and they don't think about incorporating even the simplest foundations of internet security a novice like me would implement without even thinking! How is this possible?! If I'm doing it in tiny little php sites with 1 unique visitor ever, why are these 'experts' not in there huge corporate sites with hundreds of thousands of users a month?!

kijin 14y ago
Because huge corporations often prioritize other things over technical expertise, and experts often prefer to work in settings other than huge corporations.
troyhunt 14y ago
Years and years of experience? Often not, and that's speaking from years and years of experience! Vast sums of money? Yes, at least the outsourcing vendors who churn this sort of thing out. Unfortunately you're the exception Mark so good on you for that. Well I mean unfortunate for the greater web using population, but very fortunate for you!
- ZoFreX 14y ago
  To expand further on those points with a personal anecdote... I worked on a "big website" for a very big government department. I was still in university at the time, had about a year's experience with the platform, and was earning close to callcenter wages. The government only contracts to companies on a particular whitelist, which we weren't. They paid a company something in the region of £300,000 for the website. That company then outsourced 100% of the work to the tiny (single digits employee count) company I was at. They paid us £40,000. My share of that works out at about £2,000. The fact something cost half a million dollars in no way implies any kind of quality, or that the people working on the software will know what they're doing. (Really: another horror story involved a website that only needed to work in IE6... and had been built and tested purely in Firefox)

lucb1e 14y ago

Https article served over http. Lovely. Edit: Besides that problem #1 is offtopic since it has nothing to do with https and that 3/4 other points are captain obvious, #4 is actually a good one. It's so obscure that many will forget to enable it ("all pages are secured anyway"), but whenever a user visits any http page, an attacker can inject a small frame loading the http version of my website, and even if I redirect, the cookie was already sent and read by the attacker. Only an HSTS header or enabling the secure-cookie option protect against this.

troyhunt 14y ago
If there was something worth protecting on a personal blog site, it might be a different story. 1 is very on-topic - there's no way that data should be sent in the clear. HSTS is good, but unfortunately only partially supported. Agree on the secure cookie, but of course you need to drop the dependency on accessing it over HTTP before you do that.
- lucb1e 14y ago
  > If there was something worth protecting on a personal blog site, it might be a different story. It's not about security here, it's about privacy. https://willnorris.com/2012/12/all-https-all-the-time https://willnorris.com/2012/12/all-https-all-the-time > This blog isn’t terribly controversial. But if only the "controversial" stuff is private, then privacy is itself suspicious. Thus, privacy should be on by default.
  - Tomdarkness 14y ago
    HTTPS is not really that effective for privacy. An attacker can still see what site you visited (Well, the IP, but it would be fairly trivial to get the domain as well) and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested.
    - Hannan 14y ago
      >> ...and with a little bit of analysis could most likely make a fairly accurate educated guess about exactly which page you requested. Could you elaborate on this? I would have assumed that with the request URI being encrypted that this would be extremely difficult (load times/payload size maybe?) for all but the simplest of sites.

kijin 14y ago

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.

lucb1e 14y ago
> 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 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 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.
- kijin 14y ago
  > Problem number 4 is actually also relevant for HTTPS-only websites. You're right, but I was thinking along the lines of: The reason why they don't set secure cookies is probably because they want to share state between their HTTP site and their HTTPS site. > Also a 301 only works for one page. You can make it work on every page. Even the query string will remain intact. POST requests are more complicated, but they are usually triggered by forms and JS on your own pages, so you have more control over that. RewriteEngine on RewriteCond %{HTTPS} !on Rewrite (.*) https://www.example.com/$1 [L] Of course, this doesn't solve the insecure cookie problem. But again, I'm assuming that not being HTTPS-only is the root of all evils.

ancarda 14y ago

SSL should really be all or nothing. The same way browsers don't like loading insecure content from a secure origin, they should also squirm at the idea of submitting a form to a secure area (from non-secure) -- including if the parent is non-secure. An iframe isn't good enough.