My university doesn't support the POST cgi method (I know, it's crazy), and I was hoping to be able to have a system where a user can have a username and password and log in securely. Is this even possible?
If it's not, how would you do it with POST? Just out of curiosity.
Cheers!
You could use HTTP Authentication, if supported.
You'd have to add SSL, as all methods, POST, GET and HTTP Auth (well, except Digest HHTP authentication) send plaintext.
GET is basically just like POST, it just has a limit on the amount of data you can send which is usually a lot smaller than POST and a semantic difference which makes GET not a good candidate from that point of view, even if technically they both can do it.
As for examples, what are you using? There are many choices in Python, like the cgi module or some framework like Django, CherryPy, and so on
You can actually do it all with GET methods. However, you'll want to use a full challenge response protocol for the logins. (You can hash on the client side using javascript. You just need to send out a unique challenge each time.) You'll also want to use SSL to ensure that no one can see the strings as they go across.
In some senses there's no real security difference between GET and POST requests as they both go across in plaintext, in other senses and in practice... GET is are a hell of a lot easier to intercept and is all over most people's logs and your web browser's history. :)
(Or as suggested by the other posters, use a different method entirely like HTTP auth, digest auth or some higher level authentication scheme like AD, LDAP, kerberos or shib. However I kinda assumed that if you didn't have POST you wouldn't have these either.)
With a bit of JavaScript, you could have the client hash the entered password and a server-generated nonce, and use that in an HTTP GET.
Logging in securely is very subjective. Full 'security' is not easy to achieve (if at all possible...debatable). However, you can come close.
If POST is not an option, maybe you can use a directory security method such as .htaccess or windows authentication depending on what system you're on.
Both of the above will get you the pop-up window that allows for a username and password to be entered.
To use POST as the method to send the login credentials, you'd just use an HTML form with method="post" and retrieve the information from, say, a PHP or ASP page, using the $_POST['varname'] method in PHP or the request.form("varname") method in ASP. From the PHP or ASP page, as an example, you can do a lookup in a database of users, to see if that username/password combination exists, and if so, redirect them to the appropriate page.
As reference, use http://www.w3schools.com/ASP/showasp.asp?filename=demo_simpleform for the HTML/ASP portion
A good choice: HTTP Digest authentication
Harder to pull off well, but an option: Client-side hashing with Javascript
Javascript is the best option in this case.
Along with the request for the username and password, it sends a unique random string. You can then use a javascript md5 library to generate a hashed password, by combining the random string and the password [pwhash = md5(randomstring+password)]. The javascript then instantiates the call to http://SERVER/login.cgi?username=TheUsername&random=RANDOMSTRING&pwhash=0123456789abcdef0123456789abcdef
The server must then do two things: Check if the random string has EVER been used before, and it if has, deny the request. (very important for security)
Lookup the plaintext password for username, and do md5(randomstring+password). If that matches what the user supplied in the URL as a pwhash, then you know it's the user.
The reason you check if the random string has ever been used before is to stop a repeat attack. If somebody is able to see the network traffic or the browser history or logs, then they could simply log in again using the same URL, and it doesn't matter whether they know the original password or not.
I also recommend putting "Pragma: no-cache" and "Cache-Control: no-cache" at the top of the headers returned by the CGI script, just so that the authenticated session is not stored in the browser's or your ISPs web cache.
An even more secure solution would be using proper encryption and Challenge-Response. You tell the server your username, the server sends back a Challenge (some random string encrypted with your password), and you tell the server what the random string was. If you're able to tell the server, then obviously you have the password and are who you say you are! Kerberos does it this way, but quite a lot more carefully to prevent all sorts of attacks.