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

21–30 of 68 posts

Re: How to implement HTTPS in an insufficient manner

#21

Post by kijin »

markhemmings wrote: post #8

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 a…

Because huge corporations often prioritize other things over technical expertise, and experts often prefer to work in settings other than huge corporations.

Re: How to implement HTTPS in an insufficient manner

#22

Post by claudius »

webignition wrote: post #17
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…

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 ema…

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.

Re: How to implement HTTPS in an insufficient manner

#23

Post by [deleted] »

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…

[deleted]

Re: How to implement HTTPS in an insufficient manner

#24

Post by troyhunt »

markhemmings wrote: post #8

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 a…

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!

Re: How to implement HTTPS in an insufficient manner

#25

Post by [deleted] »

[deleted] wrote: post #23
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…

[deleted]

[deleted]

Re: How to implement HTTPS in an insufficient manner

#26

Post by troyhunt »

lucb1e wrote: post #10

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…

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.

Re: How to implement HTTPS in an insufficient manner

#27

Post by kijin »

lucb1e wrote: post #19
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 ifram…

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

Re: How to implement HTTPS in an insufficient manner

#28

Post by shawabawa3 »

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…

Another point:

If someone has read-only access to the database (e.g. a junior developer) they can do absolutely nothing with a hashed password

Re: How to implement HTTPS in an insufficient manner

#29

Post by RyanMcGreal »

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…

> since users aren’t supposed to reuse passwords anyways

Never design for what people are supposed to do. Design for what people actually do.

Re: How to implement HTTPS in an insufficient manner

#30

Post by csmattryder »

claudius wrote: post #22
webignition wrote: post #17

Earlier quoted context omitted.

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 ema…

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 t…

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

With a salt, it removes all doubt. If an employee has a grudge against one customer, they could take the unsalted pass, and authenticate as that customer, no database transactions; essentially no paper trail.

If that scenario happened on a hashed and salted database, you'd have transactions that X employee changed the salt & hash, then 20 minutes later changed it back. As soon as (CEO/CTO/Mr. Manager) finds that out, X employee is held accountable for their actions.

Post reply on HN