1

I know that protecting all pages with SSL will slow down the website and add overhead to the server resources.

I also see many other websites only protecting their login and registration page, which I also want to do on my server running apache.

Why is it considered bad practice to only protect only pages where the user's password is entered instead of the whole site?

Also, instead of using something like https://mysite.com/login.php, should I maybe change to https in this way: https://secure.mysite.com/login.php?

5
  • 8
    "I know that protecting all pages with SSL will slow down the website and add overhead to the server resources." <-- do you really know this? Technically speaking, it's true - TLS adds a minuscule bit of overhead, but today's CPUs perform all of the cryptographic operations in hardware, making resource usage not even worth considering. Honestly, just put your entire site under TLS. It will be much easier to manage - there is really no good reason to not do this.
    – EEAA
    Aug 31, 2013 at 16:05
  • Tne short answer is this: In order for people to still be logged in when they go to pages that aren't protected by SSL, they'll have to send something functionally equivalent to their login credentials in the clear. Aug 31, 2013 at 20:36
  • As I understand it, the reason for using a "secure" domain is to protect certain cookies from being sent over an insecure connection, though there are better ways to do that. Sep 1, 2013 at 6:53
  • The main reason why I dont want to secure the whole site is: I often have around 10k visitors/day, but 90%+ of those never login on the site. They only spend time browsing ads on my index page. Yeah it would be much easier for me to just run all pages under ssl, but consider that so little people actually login I dont want to. Sep 1, 2013 at 19:46
  • You haven't really explained where you got this 'bad practice' idea from. This shouldn't be taken as gospel and I (along with EEAA it seems) don't necessarily agree with that statement. Considering this makes up a big part of your question it makes sense to address it. Sep 2, 2013 at 0:54

3 Answers 3

7

Cookie security is the main thing that I'd point to for your approach.

A user that logs in on your secure login page gets a cookie for their session, right? That cookie's then being transmitted in plain text for someone watching the wire (Firesheep) to intercept and steal the session.

There is additional overhead in terms of negotiation time and CPU load from SSL, but it's rather minimal. If there's anything sensitive going on on your site, just use SSL everywhere.

See also: this question

0
4

I know that protecting all pages with SSL will slow down the website and add overhead to the server resources.

This is true. You shouldn't just throw on SSL on a whim. You should make an informed decision about it. While SSL does introduce security benefits, it does come at the cost of performance. It's important to remember that you can always throw technology solutions at a performance problem so I would make sure you're happy with your security first, then try and deal with any performance issues you may come across.

The main takeaway is, if SSL solves your security concerns go ahead and use it.

Why is it considered bad practice to only protect only pages where the user's password is entered instead of the whole site?

It's not. Well not necessarily. You really need to have a look at what data you're trying to protect, and what at attacks you're trying to prevent.

Common areas to consider:

  • Is there sensitive data on your whole site, or just on a finite set of pages?
  • Is it going to be easy to implement SSL on some pages, rather than all pages?
  • Are you dealing with any credit card data
  • Do you have users that log into your site & member pages with private data
  • Do you capture data through forms, what sort of data is it?

Sometimes you may only want to secure parts of your website, such as a login page and any member pages. The public facing parts of your website may not require SSL and making them HTTP could give you considerable performance benefits.

Some people implement SSL on their whole site because it simplifies things.

Of course implementing SSL can be tricky, and sometimes the effort in trying to have SSL on one page but not the other can mean considerably more work. SSL on your whole site helps future proof it, cuts down on developer complexly, can avoid bugs and error messages to users (or worse still accidentally exposing sensitive data over HTTP).

Also, instead of using something like https://mysite.com/login.php, should I maybe change to https in this way: https://secure.mysite.com/login.php?

There are many ways to implement a login (and security) with PHP but you haven't really gone into enough detail here to safely comment. You should first outline what you're trying to achieve, then give an overview of how you're going to go about it, and then you can start to consider the pros and cons of alternatives.

2
  • Thanks for a very good answer, got a lot explained! Well on my website users can register to upload ads. So I only need to SSL secure the login page + register page. The data that they fill in during a registration is then hidden, I only use that data to confirm their identity. Here is why I dont want to secure the whole site: I can have up to 10k visitors/day, but almost 90%+ of those never login. They only spend time on the index page, browsing ads. So to secure the whole site would not be the best way for me. Off topic: Should I secure 1-2 pages with SSL using mod_rewrite? Sep 1, 2013 at 19:40
  • Per Day metrics don't really make much sense, how many users (max) do you have concurrently? Your stats suggest you may have 7 per second which isn't very much. You have to make the decision as to if you want SSL on your whole site or not, there's not much point in someone else deciding for you. mod_rewrite can be used to redirect users so I imagine you'll use that as part of your solution. Sep 2, 2013 at 0:51
0

SSL incurs quite a bit of extra processing time. For low bandwidth sites, the extra processing required by SSL is not really noticable. But for sites with heavy traffic like Facebook, Twitter and Flickr the load caused by SSL is heavy enough that they would have to use didicated SSL encoding/decoding hardware.

So basically yes, it makes sense to minimize the number of pages using SSL. That is why you often see banking sites only protect the actual account pages via https. The home/landing page is usually plain old http.

On the other hand, unless you really are a site like Twitter or Facebook or Gmail, worrying about this is a bit of a premature optimization. First do it simple if you can. Be aware of this issue and be aware of upgrade strategies when your site finally get heavy traffic.

My boss has a saying: this is a happy problem to have. First solve the sad problem of not having enough users then you'd be happy to have a problem that requires you to refactor your architecture.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .