Need SSL advice!
September 21, 2010 9:27 PM   Subscribe

I need to password protect a section of the website I built (Mac OS X, Dreamweaver CS4) for my daughter's very small nursery school. Our web host is suggesting we buy a SSL certificate. The information I'm interested in protecting is the names, addresses, phone numbers and email addresses of about 60 people - do I go with 128-bit or 256-bit encryption? 256-bit is more than twice the cost of 128.
posted by missuswayne to Computers & Internet (19 answers total) 4 users marked this as a favorite
 
An ssl certificate will protect the data in transit, but it won't actually secure the data at rest on the webserver. You do not need a 256bit ssl cert to protect this data in transit, a 128bit is sufficient.
posted by iamabot at 9:31 PM on September 21, 2010


Best answer: Yeah, SSL protects you against people listening into your transaction by intercepting the traffic going over the wires; it says nothing about password-protecting part of your site (which can be trivially done for free in most cases with an ".htaccess" file) and honestly, your provider knows that.
posted by mhoye at 9:47 PM on September 21, 2010


nth using .htaccess to secure the data, it's silly simple to use.
posted by Brent Parker at 9:50 PM on September 21, 2010


128b is sufficient, but as iamabot alludes to, the real problem with most modern systems isn't securing the data in transit. That's good, but it would be fairly hard for an attacker to intercept the data there in the first place.

The real risk is the data sitting on the server itself; that's what an attacker would want (if they care about your data at all). Grabbing transactions gets you just one person's information each time, but if they can hack your database and grab the whole thing, then they have potentially lots of people's stuff.

So feel free to go with the 128b cert, but even if the person pushing that requirement is ignorant enough to believe that SSL=secure, don't you believe it, too. Make sure you're following best practices with regards to hardening the server, sanitizing all of your inputs, don't store data you don't need, etc., and aren't just slapping a patina of security onto a lazily engineered app. That's how people's information gets stolen.
posted by Kadin2048 at 9:51 PM on September 21, 2010


In case it's not clear from what other people have written, I'm not really sure it's necessary to get an SSL certificate to do what you want -- which is limit access to this section of your website.

Do you want to have user accounts for people, or is it fine just to have everyone share one password? If it's the latter, then you should probably change it regularly because people are pretty lazy about passwords. All it takes is one person leaving the wrong (or right) info on a sticky note on their monitor.
posted by polexa at 9:56 PM on September 21, 2010


Response by poster: I'm really glad I asked here. Thanks, MeFi'ers! Yup, I totally get that the SSL cert may very well be unnecessary. Which would be great, because the school is a non-profit and it would stink to pay for something that we really didn't need.

I think we're going to probably go with user accounts for each person.
posted by missuswayne at 10:00 PM on September 21, 2010


Without using SSL, passwords are passed over the network unencrypted, and would be trivial for someone like me (who knows IT security) to intercept or manipulate. Please keep this in mind if you ever decide to include anything that could be more sensitive, such as pickup/dropoff times, health information, etc.
posted by TheNewWazoo at 10:05 PM on September 21, 2010


If you're working for a non-profit organization, look into SSL certificate vendors who provide special pricing to non-profits.
posted by Blazecock Pileon at 10:14 PM on September 21, 2010


Without using SSL, passwords are passed over the network unencrypted

That's not necessarily true. If you simply have the password as a regular form field, then sure. But you can do better than that by using a JS sha() implementation client-side to hash the password before sending it. That alone wouldn't be enough to prevent a replay attack so you also need to have the server pass a random string in a hidden field of the form, and you hash twice: $submitvalue = hash(random + hash(pw)). Since hash(pw) is stored on the server, you can compute the same value server-side and compare that the two are the same, which results in the password never actually being sent over the wire in a form. Here's an example. Actually, you should be storing a salted hash on the server side, so in reality you'd need to include that in a hidden form field as well, so it would actually be $submitvalue = hash(random + hash(salt + pw)), but it's the same idea.

Yahoo famously used this method for a number of years on their email login form so that users' passwords were safe even when they didn't submit the form over SSL. I don't know if they're still doing that.
posted by Rhomboid at 10:43 PM on September 21, 2010 [1 favorite]


Really, if it is for friends/family/people-you-know, a self-signed certificate is free, and just has an annoying popup to get past.
posted by lundman at 11:33 PM on September 21, 2010 [1 favorite]


I would switch providers over this. Please take note that you came to them with a reasonable request, and they suggest a course of action which not only is expensive, it also does not solve your problem. Had you followed their advice you would have spent money to be worse than you were (because before you knew the information wasn't protected, and afterwards you would wrongly think it was protected).

There are many fields in which I am ignorant and rely on advice. People that get my money for that advice can't sabotage my efforts. It's just not acceptable.
posted by CautionToTheWind at 2:10 AM on September 22, 2010 [6 favorites]


Assuming you came to your web hosting company with the request as presented here - needing to password protect a directory - then I have to second CautionToTheWind's advice. I work for a small web hosting company, and your request is fairly commonplace. Trying to sell you an SSL Certificate to solve this particular problem is just unacceptable.
posted by ralan at 4:11 AM on September 22, 2010 [1 favorite]


Is it really necessary to put this information on a web site in the first place? Perhaps there are other means of delivering this information.
posted by MikeWarot at 8:01 AM on September 22, 2010


Agree with MikeWarot. Do you really need to put the info on the website? If you have it there then it's accessible - and then you'll need some way of knowing when someone gets the info that shouldn't have it - and notifying the parents that someone might have their telephone number or address.
posted by Man with Lantern at 9:23 AM on September 22, 2010


Response by poster: Hmmm. You've all given me much to think about, thank you! I do think we'll want to move forward with a password-protected section, as there will also be other information within the pages that we'll want to keep secure -- not as sensitive as personal information, but I think the school director and the board would feel more comfortable having it behind a password.

I should add that (if it's not already evident) I'm not well-versed in the technical aspects of making this happen -- I'm a designer who is learning all the technical stuff as I go. I'll be looking for the easiest way to effectively protect this portion of the site.

As for the hosting company, I do think they are giving me the hard sell on the SSL certificate. I originally called them because I was trying to set up the password protection on my own and couldn't figure it out -- turns out it was because the site is hosted on a Windows platform and because I'm using a Mac I need to switch the site to Linux. That's when they mentioned the SSL cert, suggesting that I go with the 256-bit encryption (without even asking me what I wanted to protect). I'm not going to switch hosting providers over this (not yet, anyway) as they've been easy to work with up until now, and I have no other complaints.
posted by missuswayne at 10:43 AM on September 22, 2010


But you can do better than that by using a JS sha() implementation client-side to hash the password before sending it.

I would not do this unless you really have to. There are good JS libraries implementing things like SRP that are—unless you are a fairly serious cryptographer—probably better than anything you'll write on your own, and handle things like salts and nonces so that you don't have to.

But if you're not a JS programmer at all, I'd probably just ask your host if you can use HTTP Digest Auth. It is not the most secure thing in the world from a theoretical perspective (it uses MD5, which has been found to have some weaknesses, although none that I believe translate into real-world script-kiddie-exploitable breaks) but it is a huge step up from using plaintext passwords, and IMO it is probably better than a poorly-written or amateur attempt at doing auth using JS+HTTP forms. If you do not want to use SSL, it is probably the best thing that will work across almost all browsers and doesn't require any coding on your part.

Assuming your host uses Apache2 (reasonable assumption if the underlying server is Linux), they would need to have mod_auth_digest enabled (this is what you need to ask them about). Then you'll need to create an .htaccess file and a password-digest file. The digest you can generate locally on a Linux machine and then upload. There are lots of tutorials available, but talk to your hosting provider to see what their procedure is.

Your host isn't necessarily trying to sell you a bill of goods by pushing you towards SSL. Forcing plaintext-over-SSL would probably be best practice; if you look at auth_digest threads on Server Fault or other technical forums, a lot of people just avoid it in favor of using SSL. However I think there's still a legitimate place for it, if you know what you're doing and are sure that you just need authentication and not transport security.
posted by Kadin2048 at 11:21 AM on September 22, 2010


It's really difficult to protect a file on your website from being harvested by spam bots, and more nefarious people as well. .htaccess is what you want to use, but I have some serious reservations about using it in this situation. Particularly since - no offense - you're not very technically savvy.

The problem here is the failure case. You're talking about the contact information for children and their families. YouY don't want to have their contact info stolen by a violent ex-husband, or an ex-wife with a restraining order due to a prior kidnapping attempt. Both of these are, sadly, very commonplace.

The first step towards becoming a good and responsible admin is to learn how to respect and protect your users' data. As a general rule, if you wouldn't tape it to the front window of the school, it shouldn't be on your website, no matter how well you think you've hidden it.

You're definitely being fed a line when you contact your hosting company. Be sure that you're talking to tech support, and not calling the sales department. (It happens - a lot of people don't realize that the first person they talk to when they sign up for an account is actually in sales.)

I mean, aside from the SSL issue, unless things have changed since I left the game about 5 years ago, it isn't true that you HAVE to migrate your website to a Linux server just because you're using a Mac. If someone at your hosting company told you that, then as far as I know, they are very very wrong.
posted by ErikaB at 12:01 PM on September 22, 2010


Response by poster: No offense taken, ErikaB - I appreciate your comments. I'm actually thinking that we should leave all the personal info off the website, just to be safe.
posted by missuswayne at 1:27 PM on September 22, 2010


Response by poster: The reason they say I need to switch to Linux is because per their protocol to I would need to download Microsoft IIS 7.0 Manager in order to go into the admin panel and set up the password protection, and there isn't a Mac version.

Does this make any sense?
posted by missuswayne at 2:51 PM on September 23, 2010


« Older Ethics of Web Design   |   Please help!!!! Newer »
This thread is closed to new comments.