

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

I'm creating a real site for the first time, and I'm considering forgoing getting an SSL cert for financial reasons.<p>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.<p>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.<p>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.
======
dirktheman
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.

~~~
AgentConundrum
_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.

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

~~~
AgentConundrum
_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.

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

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

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

~~~
AgentConundrum
_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.

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

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

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

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

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

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

~~~
dkersten
Bookmarked, thanks.

