Ask HN: what sites should use ssl? | Hacker News Reader

Ask HN: what sites should use ssl?

6 pointspedalpete9 comments

I'm working on a site which deals with some user sensitive information, but not dealing with credit cards and stuff like that.

I'm was thinking that I would need to get an SSL certificate, but I've just noticed that Facebook doesn't encrypt data over https, so I'm wondering if I need to bother.

I'm transfering info like e-mail address for the users login, and all that is encrypted in my db, so should I also be encrypting it over the wire?

-------additional-------------

So the first to responses were basically 'yes, do it', but 1) why wouldn't a major company like facebook do it, and the start.yourdomain.com from google doesn't do it either, and that has all your email and stuff in it?

2)if I do decide to do it, is there a specific source I should get my certificate from? is there another way to encrypt? as I'm bootstrapping along, should I really be paying a few hundred dollars for this?

View on HN

Ideally, you should be using SSL any time you ask for information you don't want others to ever be able to see. Think about it this way:

You log on to your site via an open wireless network at your local coffee shop. Anything that you aren't SSL encrypting is being sniffed and read by the shady looking dude with the laptop and latte over in the corner. What don't you want him to see? SSL encrypt that.

For my sites, this generally means any page where a password is entered. You might want to take it a step further and protect private profile pages or anything like that, but at a minimum, authentication should be encrypted over the wire.

You might say "Well yeah, but I run a site where people post pictures of their morning poo, who cares if they get hacked?" - that's fine, but people have a horrible tendancy to use the same email and password all over the place. When Joe logs in to PostMyPoo with joe@gmail.com/hunter2, chances are Shady Latte Guy is going to pop over to gmail, punch in those credentials, and the vast majority of the time, he's in to Joe's account. He can now go through Joe's email to see what else Joe is signed up for, try his existing credentials, or issue password reset requests to get into anything else he wants. Suddenly, Joe has a data/identity security nightmare on his hands, and you bear some measure of responsibility for that.

We try and make sure all our clients use SSL for authentication and transfer of secure data. Just because Facebook and Google aren't as conscientious as they should be doesn't let you off the hook.

You don't need to pay a few hundred dollars for an SSL certificate, unless you need a wildcard. Go with a cheap reputable Certificate Authority and start this out right.

Any recommendations on a certificate authority?

we mostly use GoDaddy because it is so cheap, but its a horrible user experience. We use DynDns.com for our DNS hosting and I think they offer certs now, so we may switch to them.

Correct me if I'm wrong - looking at the source code, Facebook submits the form over https, though the page is http.

By itself, a leak of information may appear trivial, but piece together a few bits of info and mix in some social engineering, and you could have enough to do naughty things! Yes, users should use different passwords, but you should be the one who does the right thing and takes the responsibility for them, to prevent that exponential spread of consequences. It's more than just "This cert cost me x", it's "If I spend x, I save y people from losing z of time and money." where x<y<z.

StartSSL offer well priced certificates - from free, up to ~USD150, and they are well reviewed here: http://www.sslshopper.com/startcom-certificate-authority-rev...

Google does do it after being being embarrassed into it by some security folk. The 'sign in' link on the main google.com page is ssl, as is Gmail, and http://google.com/a/domainname (at least for me) is redirecting to https.

Facebook does support ssl (https://facebook.com) but the problem is that they don't forwards regular http login to it.

Unless you need a wildcard domain, which you shouldn't, until you have to scale, it shouldn't cost you more than like $20 US for the cert.

It is good practice to at least encrypt the authentication process, so that someone can't grab plaintext passwords as they are transmitted.

My understanding of why some major players don't do it is because there is considerable overhead in running encryption when you are dealing with millions of connections.

I like ssl for logins and signups and if it is something important or sensitive (like say email) for the whole interaction.

Reply on news.ycombinator.com