Ask HN: Do I need to secure (SSL) my login page?
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.
16 comments
[ 3.1 ms ] story [ 50.3 ms ] threadAbout 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.
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.
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.
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.
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.
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.
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).