Hi, I'm wondering how companies (like linode.com!) give member login abilities to their website.

One way I suppose is SSL + basic authentication, but then to get into the password protected spot, it pops up the cheesy username password window. Also it might be hard to distinguish users that way.

I was wondering if people just write their own programs (in say Perl, Python or Scheme) say to accept the passwords and load info based on who's account it is? Would it be secure to send passwords "in the clear" as long as you are in an https region of the site?

Thanks for any tips...obviously, I'm just a beginner.

We prompt for the users, username and password via an SSL form, which we then validate against details in a database.

The forms are a lot more elegant way of doing things, than the usual dull gray popup box.

Using perl for example, you can use a form to validate against usernames and passwords against the OS, or you can put up with the dull gray box and use .htaccess and .htpasswd

Adam

Is an SSL form just a regular HTML form going over an SSL connection? Or is there actually something special called an "SSL form"?



Okay, just to see if I'm getting this, if I have a user submit me a username and password over the SSL connection and I wrote a program:

if passwd = "mysecretpass" then goToMemberSite()

would that be secure? What I'm getting at is that the password, if not for the SSL, would be sent in the clear by the HTML form. But as I see it, assuming I have SSL set up correctly, I don't have to do anything to hide the password data that the user sends to me. Thanks for your help Adam.

Hi,

Yes a form sent via SSL is just a normal page, that is served via the https protocol, you just need to make sure that you have an SSL certificate for that domain.

The page will be encrypted using 128 bit encryption, or the highest level supported via the browser and the server.

The next step is up to you, what you do with the username and password, depending on how secure you want your site to be.

We store the password in the database using an MD5 hash, to ensure that no one can ever get the password. To validate the password, we then encrypt the password submitted by the user, in to an MD5 hash, and then compare them.

Adam

Have a login form POST to a cgi or php script (for example) that checks the user and pass in a DB and sets up the session.

Each page inside the protected area must verify that the session is still active. Without that test on every single page, people could just skip over your login page and get to the good stuff.

That would only protect the cgi or php pages, not images and other files inside the "protected area". The only way around that is to use .htaccess and the dull browser password box..

-Chris

Thanks guys!

Very useful info.

One thing to add about the popup box (basic authentication).

You can provide a user name and password in the URL:

http:://username:password@website.com


I use this in Perl to retrieve pages that have authentication

#!/usr/bin/perl
use LWP::Simple;

my $pagescrape=get("http://myuserid:mypassword\@site.com/restofurl");

Not only should each page check that the session is correct as caker said, but if you are really worried about security each page should also check that SSL is really working. If the user typed in http:// instead of https:// your perl/php/whatever code should pick up on this and redirect them to the https:// site. Otherwise paswords could go across the network insecurely and nobody would know!

If you are running a public/commercial site you'll need to get a certificate signed by a trusted authority. If the site is personal or just for a few friends/family members, set up a Certificate Authority on your box and sign you own certificates. Users will get a pop-up from their browser that the certificate is not signed by a known authority, but they just hit continue and the session continues encrypted.

--James

Again, great info, thanks. I've been wondering about this "requiring https" problem. Is there a better way to do this?...ie, at a lower level, before the php or perl code enters the picture? It seems there should be an Apache directive I can set that requires that everything in a directory be accessed with https instead of http. That way I wouldn't have to worry about checking it on every page.

If you're using mod_ssl there is a directive called SSLRequireSSL. This does just what it sounds like, requires the user to use SSL. I'm not sure what it does with a request that does not use SSL though. If it just throws an error, this may confuse some people and they may not understand they need to change http:// to https:// to see the page. I personally like to be able to control things as much as possible. Google around for more info, it isn't very well documented as far as I can tell.

The way I'd do it is this. You need to have every page check that the session is valid anyway, so why not have the same code check for SSL. I'm using PHP as an example here, but all CGI programming methods should be able to look at the environment variables that apache set. Check if the $HTTP_SERVER_VARS[HTTPS] variable was set by apache and if not, redirect the user to the https site. If it is set, check the validity of the session. If it's valid, continue. Just throw all of this logic into a file (some_file.inc) and do require_once(some_file.inc) at the top of every PHP page. That way, every page is protected and if you want to change how things are done, you just change it in some_file.inc and it changes for all files.

Hope that helps you.

--James