Ask HN: Do I need to secure (SSL) my login page? | Hacker News Reader

Ask HN: Do I need to secure (SSL) my login page?

12 pointsxatax15 comments

I'm creating a real site for the first time, and I'm considering forgoing getting an SSL cert for financial reasons.

Money is tight, and I'm even considering paying monthly for a shared host rather than paying less per month on a longer contract so I can pull the site early if it fails hard. With the hosting itself being only about $10/mo, I'm having a hard time justifying to myself that I should pay 50% more to get a dedicated IP, in addition to the cost of the cert.

This isn't e-commerce, so the only thing being secured are the user login. The data will initially be entirely public, though I do have plans for private-unless-you-want-it-public features.

HN doesn't secure its logins, nor does reddit, TheDailyWTF, or any number of other forums, so how guilty should I feel about not providing secured logins? The site is aimed at developers, in case the users are an important part of this equation.

View on HN

I'd say it depends on the level of security your users would expect from your site. If it's merely information you're offering than I wouldn't use an SSL certification. If there's financial data involved (mind you: payments through paypal or some other payment broker are SSL certified) it's a whole different story. Also: an upgrade to your site is easier to sell your users ('now even more secure') than a downgrade.

I'd say it depends on the level of security your users would expect from your site.

About the same level of security as posting on reddit or HN, which is why I used them as examples. Submit this, vote for the best that, etc. A closer example might be StackOverflow, but I honestly have no idea what goes into logging in over there, since it's all done behind the scenes with OpenID (though there was nothing https-y shown in HTTPFox when I tried it).

If there's financial data involved

Nope. Monetization, initially, will be provided via affiliate links. If you buy something you saw on my site, you wouldn't be buying it from me.

Also: an upgrade to your site is easier to sell your users ('now even more secure') than a downgrade.

This is my thinking. If the site ever gets to the point where it's nicely paying for itself and I can justify the cost of the static IP and the cert, I will.

You could also delegate the login to Facebook, Twitter, Google, OpenID, etc which are all supposed to be secure. It also reduces the friction of the signup/login process. However, I do hate it when sites don't let you signup directly and force you to use OpenID.

You could also delegate the login to Facebook...

I refuse to use FacebookConnect (or whatever it's called), since it's my real identity being used. I imagine a lot of people are the same.

...Twitter...

I also don't have a twitter account, since I don't really see the point of it.

...Google...

Can you elaborate here? I'm not quite sure what you're referring to, though I feel like I should.

...OpenID

This is definitely a consideration, and has been brought up elsewhere in this thread. I'm definitely going to check it out, and see what's actually involved in it, since it seems a bit involved for something I'm not even sure will work.

However, I do hate it when sites don't let you signup directly and force you to use OpenID.

Same here. When StackOverflow launched, I didn't understand what they asking me to do to log in. I understand it now, but I've never had a reason to use my OpenID outside of the StackExchange network, so to me it's pretty much the same as having a single account for that purpose.

Google accounts act like an openid/oauth account. Lots of sites have a "log in with your google account" option.

Short answer: No.

Slightly longer answer: If you use SSL on the login page, how do you maintain state between requests over non-SSL sessions? If you just SSL encrypt the logon you're given a cookie. If you send that cookie over HTTP, the end user is susceptible to more or less the same issues as before, only instead of the account being compromised, it's the session (until it expires).

The user can mitigate this by logging out, in which case compromise is limited to the session, assuming that the adversary doesn't have the ability to intercept and block the logout request (which they most likely would in an intercept situation).

You don't need to, just make sure your users are aware. I don't think users would disregard your service - as long as it doesn't deal with some heavily private stuff - just because you don't have an SSL cert.

as long as it doesn't deal with some heavily private stuff

Nothing private. The only things that wouldn't get made public by default are intended to be things that I'd like you to opt into making public anyway, and none of these features would be in the 1.0.

just make sure your users are aware

Any suggestions for this? A popup saying "hey, this is pretty insecure.. are you sure you want to bother?" seems like a good way to get people to leave your site alone.

Nah, leave the users alone. If they are developers they should check that it does not say https anyway. I mean, hacker news does not scare people by saying, hey man this data is not secured. But then hacker news asks for a username which you make up on the spot and a password for which you do the same.

You may also try using Janrain Engage (formerly RPX) http://www.janrain.com/janrain-products-overview

What about using something like OpenID, Google Accounts or Facebook accounts and not doing the login yourself?

Honestly? Because it looks like entirely too much work. I'll admit that I haven't looked into it as thoroughly as I should have, but just a quick check of StackOverflows login screen shows 12 different providers they accept with a field to allow any other you want. That sort of scared me off.

Now, thinking about this logically, the fact that they provide a field for "just throw your OpenID here" probably means that there's a singular path to follow, and that the other 12 are just shortcuts so that you don't have to remember the full URL for your credentials.

I'll look into it a bit further now, but if you have any suggestions on documentation or tutorials you've found helpful, I'd appreciate it if you could pass them along (I'll be using PHP).

Thanks.

I have not needed to use any yet, but next time I need a login, I'll be investigating the three I mentioned. As for stackoverflow, I've never used the butons they provide, I've always just typed my openid url into the box. Probably they went a bit crazy witht he whole thing, I doubt you really need to go to the same extent that they did.

Sorry I don't have anything more helpful to add. If you do look into this more, would you mind reporting back on any findings? I'd love to hear about your experiences.

I can make a note to let you know how this works out, since I sincerely doubt you'd notice a reply here.

If you'd prefer, I'm also blogging about my experience of writing a site from scratch for the first time. You can check it out at http://www.appscanadian.ca in case I don't remember to contact you when I start working on the login functionality.

Bookmarked, thanks.

Reply on news.ycombinator.com