11

I've been pretty paranoid about learning to "do security right" for this site I'm building (first non-trivial site I've made), and I've noticed something that bothers me: SSL.

I've read plenty of security threads here, on StackOverflow, and elsewhere that goes on at length about regenerating session ids after n uses, and how your passwords need to be salted, hashed, and never stored in plain text. I've read plenty about how to detect when a session has been hijacked, by tracking IP addresses, user agents, and by using tracking cookies.

What I don't understand is what any of this matters when the website logs you in via a normal HTTP POST and sends your password over the wire in plain text?

I understand that all the other methods I listed are needed to reduce your overall exposure, and maybe there are some sites that just don't need that much security anyway, but I guess what I'm asking is:

  • When is it ok to not bother with SSL?

Sites like Gmail, your bank, and LinkedIn, I can see having a reason to use SSL, but what makes it ok that sites like Facebook and reddit don't bother (hell, PlentyOfFish even stores your password in plain text and even emails it to you weekly as a reminder!?!)?

How concerned should I be with making sure SSL is setup (especially since I'd be starting with a shared host, and I'm being pretty cheap to start)? My site won't hold any particularly personal information, if that helps. If the site becomes a success, I'd seriously look at paying the extra for the added security.

4 Answers 4

7

It matters as much as you and your users thinks it matters. Sending passwords over http as plain text does leave them vulnerable to packet sniffing. Now whether someone is going to actually bother sniffing those packets is a whole other story. If you want to ensure your users the most secure experience possible, use SSL for their login submissions. If you think your users will be happier and more likely to interact with your website in a positive way (i.e. buy stuff, do stuff, etc) then use SSL for their login submissions. If you have anything worth stealing (i.e. user information) then use SSL.

If you don't have anything worth stealing, don't think SSL will enhance security much or at all, or your users won't see it as a useful feature then you may want to consider not using SSL.

For what it costs to install an SSL cert, unless you are on a shoestring budget, it's never a bad thing to secure a site's login. And don't let what other sites are doing influence you as many larger sites don't necessary follow best practices which is why there's is seemingly a steady stream of news stories about one being compromised in some way.

5
  • 1
    +1 "many larger sites don't necessary follow best practices" - I'm sure there will be some laughable headlines when Nigerian 419'ers figure out a way to monetize stolen dating site profiles :)
    – danlefree
    Sep 20, 2010 at 20:40
  • "unless you are on a shoestring budget" - but I am. I really, really am, to the point that I'm considering going m+m on a cheap shared host rather than paying considerably less per month to pay for a year upfront. This way, I can pull the plug if the site doesn't start paying for itself relatively quickly. I think for now I'm leaning towards no-ssl since just getting the static ip needed alone would nearly double my monthly cost, not to mention the cost of the cert itself. The site is pretty close to being a forum, and most data is public, so there's no need for encryption outside of login. Sep 20, 2010 at 20:52
  • @danlefree, That is easy. Use the personal details on the dating sites to answer the password recovery questions for the users email and banking site. Or just capture the password, since people re-use their passwords, far to much.
    – Zoredache
    Sep 21, 2010 at 17:39
  • @AgentConundrum Startssl offers an SSL certificate for free. If you are on a tight budget but have a static IP, you can go for that. Aug 28, 2014 at 11:57
  • @AgentConundrum you don't need a dedicated IP for SSL any more, as long as your host supports SNI (and if they don't, find a new host because they don't know what they're doing). You can get a certificate for free, so that's not an added cost either...
    – Doktor J
    Aug 28, 2017 at 14:02
3

Taking the opposite approach to John's answer, I think you should seriously consider SSL if you handle any personally-identifiable information - to include: names with physical addresses, e-mail addresses, financial information, and communications which users would reasonably expect to be private.

Unless your site provides a means for users to publish information about themselves, you should consider any personally-identifiable information provided by your users to be held by you and you only under strict confidence unless your site's privacy policy informs your users otherwise.

Prevent unauthorized third parties from seeing your visitors' information and keep your users informed of how you use their information to maintain your visitors' trust.

Even Facebook does this, as far as I can tell.

<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form" onsubmit=";var d=document.documentElement;if (d.onsubmit) { return d.onsubmit(event); }else { return Event.fire(d, &quot;submit&quot;, event); }">

(Facebook.com login HTML source)

4
  • Odd. I don't know how I didn't notice that for Facebook. I was looking at it from HTTPFox and somehow missed the 's' on the initial request. I'll edit to remove that. The fact still remains that a lot of sites do this (reddit, hacker news, TDWTF, etc.), so at worst I'd be no better than them. Budget is a massive concern of mine, so to spend an extra $5/mo for a static IP (on a $8/mo host...) as well as buying a decent cert.. I'd almost consider just not building the damn site. Sep 20, 2010 at 20:47
  • @AgentConundrum - Strictly speaking, it is OK to pass a password run through a one-way hashing algorithm over HTTP if the password is salted, so I wouldn't be too surprised to see an MD5 hash implementation on sites which aren't utilizing SSL: pajhome.org.uk/crypt/md5
    – danlefree
    Sep 20, 2010 at 23:07
  • and how would building a hash on the client side help anything? In that case, basically the hash is the password. I should be able to capture the hash and replay it just as easily as I can capture a password.
    – Zoredache
    Sep 21, 2010 at 17:42
  • 1
    @Zoredache That's why the hash must be salted. Here's how it works: I send you the login page with a pre-populated token which includes a microtime() call from the server. Your transmitted hash is a combination of your password + the microtime() and, once I receive your hash, I invalidate the microtime()+password challenge/response pair (it cannot be used again).
    – danlefree
    Sep 22, 2010 at 1:44
3

As of August 2014 Google has officially indicated that HTTPS will be used as a ranking signal.

This means that even if your website is a completely static website, if you care about SEO you should at least consider setting up an SSL certificate.

Of course HTTPS is just one ranking signal out of hundreds, so there are probably more important things you can do for SEO.

1
  • Google also announced that since setting up an SSL certificate takes resources, you need to do that only if your website demands it. In short, they mentioned that your rankings won't be affected just because you did not set up an SSL certificate on your personal blog. Aug 28, 2014 at 12:02
1

Here's an angle you may not have considered: not using SSL/TLS can expose your users to passive monitoring even if your site has no logins.

A threat actor may simply sit between your user and the rest of the Internet, watching all the URLs your user requests and building patterns of things your user is viewing. Individual bits of information may indeed be insignificant in isolation, but combining lots of little bits of information can create a much bigger picture.

It is for this reason I offer HTTPS on my own site, which only provides static content.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.