Ask PG: Make the login form available over HTTPS only? | Hacker News Reader

Ask PG: Make the login form available over HTTPS only?

108 pointskevinburke35 comments

Hi PG, I noticed news.ycombinator.com supports both SSL and vanilla HTTP. While savvy users probably have been doing this for years, the login form as well as the comment submission pages are available over vanilla HTTP. This means that if I try to log in on a wireless connection and forget to use the SSL link, anyone can sniff my HN username and password by reading the packets sent between my computer and the wireless router. Passing login credentials over HTTPS is a standard industry best practice (passing auth cookies over HTTPS as well is best, as Firesheep demonstrated).

Could you please make the login page available only over SSL? Then I wouldn't have to remember to use the secure link when logging in. Of course all non-logged in visits could continue to use HTTP.

Best, Kevin

View on HN

I strongly disagree. I currently live in Iran, and sometimes (just for fun, I guess - see here for an example: http://news.ycombinator.com/item?id=3575029), they disallow all encrypted connections (to/from outside the country) and every single website/service that uses SSL and is located outside of the country stops working. If HN login were HTTPS-only, I couldn't login at those times.

Sure, now they can easily sniff my HN password (which I don't use anywhere else) and could abuse it, but I don't give the slightest damn about it. I'd create a new account (though it's not ideal as I'd lose my karma and can't downvote objectionable/trollish comments). My HN profile is probably the least valuable online account I have; I don't care if it gets removed or hacked. It's more annoying for me if I couldn't login at all.

Of course, your use case most certainly differs from mine; which is why I think it's a good idea to show HTTPS login form by default. But please always allow a less-secure but probably more reliable option for logging in when you're creating a login form for non-commercial sites like HN.

The solution, obviously, is to have the Login form default to HTTPS, but then have an unencrypted version as well (linked from the FAQ page where it can be found by those in need).

Shouldn't your concern be not that they'd mess with your account but that they know your username and can now, just for fun, decide what you've posted is punishable?

Yes, considering my username is my real name, and I've submitted quite a few objectionable posts (like http://news.ycombinator.com/item?id=3432816 and http://news.ycombinator.com/item?id=3599396), I should be worried. But it's hard to keep quiet sometimes.

pg@ycombinator.com is usually better for stuff like this. Or http://news.ycombinator.com/item?id=363, which doesn't yet have an SSL-related request.

This brings up an interesting point about the cost-benefit of some simple security practices.

If pg spent 2 hours downloading the libraries for and hooking into the API of, say, bcrypt or pbkdf2, that on top of the rest of his authentication code would result in a benefit once the password database has been stolen. There is a man-in-the-middle possibility because HTTP is still a valid login method, though you could argue he can spend less time securing his code against a database breach.

If pg spent 1 hour making SSL the only option for logins, the resulting benefit is that all communication of the password is secure, though you could argue he now has to spend much more time securing his code against a database breach.

Of course, if he spent 3 hours doing both, everything is more secure. But we don't always have time to spend.

This thread has gotten me thinking about how PG might approach security. The existence of https on the site is a starting point.

It allows anyone who is serious about a secure channel to create one while not advertising the fact that some people might find security necessary on a "news" site. Yes, it's security by obscurity, which of course shouldn't be used as the primary method but it probably reduces the attractive nuisance.

But if PG was going to code something up, he wouldn't advertise the fact, nor his approach. It would instead be along the lines of "Lisp as a secret weapon."

And it certainly wouldn't be something based on "industry best practices."

I actually wanted to bring this up a while back too, but it could cause some big issues (forcing SSL in general that is). I wouldn't force all of HN over SSL, but I would make it a lot clearer to users when logging in, if they are logging in over SSL or not (maybe a large text saying click here to log in over SSL? Even though it might look a bit crappy). Or creating filters for IP's that force SSL for certain countries.

Iran for instance blocked all SSL sites a while back, not sure if this is still the case however..

See http://news.ycombinator.com/item?id=3575029

What are the "big issues" that would be caused by forcing SSL? It sounds like visitors from Iran (and other countries that block SSL sites) might be unable to access HN. What else?

(To clarify, I'm interested in the general topic of whether it's a good idea to have all-SSL websites.)

Well, when I said big issues, the only actual issue that came to mind for me was Iran. I'm not aware of any other issues it could cause - would be interested in knowing more about this too, what else could theoretically go wrong?

Web server performance?

For the scenerio you mentioned, just having the login/comment submissions work over SSL results in zero added security. In short, this is because of tools such as SSL strip.

A better suggestion would be to have the entire site available of SSL only. Good to see HN'ers taking security seriously though :)

On Google Chrome you can manually add news.ycombinator.com to the HSTS set via chrome://net-internals/#hsts. This will prevent you from accidentally going to the non-SSL version of the site.

Not quite zero. SSLstrip requires an active MITM, versus other "listen-only" attacks to snoop credentials off the wire.

Agreed, Firesheep demonstrated the problems with sending cookies over HTTP... it's at least a start though.

As a stopgap measure, use something like https://www.eff.org/https-everywhere/ to force SSL for HN. There's even a rule by default iirc in this one for HN.

The HN rule wasn't there by default when I installed it, which was a while ago, admittedly.

One way around this is to use HTTPS-Everywhere with another extension called HTTPS Finder[1] (Firefox only, AFAIK) that tries to load secure versions of any HTTP sites you go to, and writes HTTPS-Everywhere rules for you if it finds one. It asks if you want to add the rule or whitelist the unsecure version.

Fair warning: you'll probably end up being annoyed with it fairly often, and have to whitelist more sites than you expect which have expired or improperly configured SSL versions.

It's more than fine for HN's core audience, but it's not exactly ready for primetime for the average user.

[1] https://addons.mozilla.org/en-US/firefox/addon/https-finder/

I've just installed it and it redirected me to https for hacker news automatically.

To me, this issue looks a lot like security for security's sake. HN isn't a bank. The commercial value of a person's HN login is approximately zero. HN's editorial mechanisms make the Lulz value of a login approximately zero as well.

The real-time commercial value of a person's actual posts to HN is even less, i.e. any man in the middle who is manipulating HN comments is doing so at the expense of forgoing more profitable opportunities.

The root of the security issue is using open wireless networks, and these are vulnerable to man in the middle exploit even when SSL is used.

Passwords are inherently valuable, imo. The more knowledge you have about a person's password habits, the easier it is to crack other services as well. Witness LinkedIn: https://community.qualys.com/blogs/securitylabs/2012/06/08/l...

I'd be willing to bet very few people use truly unique passwords across all their accounts. While personal responsibility is paramount, human nature is what it is, and (again, imo) all sites that require authentication should do it well (over SSL).

SSL is an "industry best practice."

Therefore, I doubt that PG would rely on it as a primary means of preventing mischief on HN.

May I have your password please? I'd like an account with more karma.

What would you do with it?

Post intelligent comments under my name?

Cost me a few karma points by trolling?

Other than the ability to downvote and change the topline color, it's no different from yours. It's not the karma points which make an HN'ers posts better, it's the relevance of their participation.

While we'd all like to see intelligent comments posted under your name, the issue here extends beyond this site. Where else have you used that password? What is the commonality with your password on different sites? If you're so confident that you're safe, why don't you just change your password right now and post the old one?

If I was using a common password across multiple sites, that's the security issue, assuming of course that I engaged in the additional poor practice of using a common password for both sensitive and trivial uses.

But regardless of how one slices and dices it, my HN account does not contain sensitive information and the consequences of a security breech of my account are trivial. HN is not Wells Fargo.

After reading the grandparent comment about wanting my karma I changed my password for the first time since joining. But rest assured, the old password demonstrated how low value access to my HN login is.

It's foolish to introduce security where none is required, and even more foolish to introduce the overhead of a security apparatus which doesn't meaningfully increase security.

Spam your email address? Assuming it's not the same as you have in the description (mine isn't).

Given the frequency at which I anticipate communications from HN regarding my account, the email in my profile is sent to the catchall, i.e. it's a lower priority than the public one.

To put it another way, if PG emails me directly using the private address, I'll see it eventually. But I will probably see anything sent to the public address more quickly...though again probably not right away.

Just as I don't see security on HN as high importance, for me, emails related to it are not treated as time critical. However, separating them out from my normal inbox makes anything coming from HN stand out.

How much would you be willing to pay for more karma? Perhaps we could start up a karma selling business..

>To me, this issue looks a lot like security for security's sake.

I think this is only a reasonable consideration when the implementation is inconvenient. We're talking about an SSL login on a site that already uses HTTPS. This is not a particularly difficult endeavour.

Convenience doesn't make it any more purposeful. And SSL communications take up more bandwidth.

I'd add that using SSL for the sake of using SSL may give HN'ers a false impression regarding the priority given to securing communications on the news site.

HN does not have a private messaging system (at least at my karma level) and the bottom line is that my communications are being published to the internet at large. It is difficult to see what purpose security serves.

The root of the security issue is using open wireless networks, and these are vulnerable to man in the middle exploit even when SSL is used.

HSTS, as we've seen here recently, cuts down the risk significantly, especially if HN were to submit itself to browser preloaded lists.

As repeatedly noted, a clear-text password is usually much more valuable than as just a credential to a site. And you're very naive if you think this is just an issue for open wireless networks. It's not at all uncommon for ISPs to get compromised, and in many countries is actually the norm (whether due to criminal activity or by government mandate).

>The root of the security issue is using open wireless networks, and these are vulnerable to man in the middle exploit even when SSL is used.

Could someone please explain to me how this could happen ? By my understanding, that is exactly the type of attack that SSL was designed to protect against.

http://crypto.stanford.edu/ssl-mitm/

This is why, to run an open wireless network, you should use WPA2 and provide the password in the SSID.

Reply on news.ycombinator.com