Transmitting login credentials securely

[pactalon]

Is there a secure way of transmitting a username and password to every page through a query string? It seems to me that "default.asp?username=kill&password=death" would be too obvious and easy to hack during trasnmission -- likewise for a cookie.

I was thinking about setting up a database that, upon logging in, would contain the user's IP address, username & password, and a "session ID" that would kill itself within half an hour. The session ID would be in the query string, and only be accessible by the IP address corresponding to the record.

Any thoughts on this method, or a better way of doing things?

Use session variables, that way nothing has to be "passed" to each page.

Set rsInfo = Server.CreateObject("ADODB.RecordSet")

rsInfo.Open "Select userid, password, ipaddress from userinformation" & _
"where userid = " & request("userid") & " and password = " & request("password"), & _
strConn, adOpenKeyset, adLockReadOnl


If not rsInfo.EOF Then
 Session("userid") = rsInfo("userid")
 Session("password") = rsInfo("password")
Else
 Response.Write("Invalid UserID or Password")
End IF

The session variables are available to all pages throughout the user's session.

If you abolutely have to pass information through the query string then I say encrypt it!!

Place this simple little function in a file all on its own:

<%

Function Crypt(Text, Key)
    
    If Key < 0 Or Key > 255 Then
        Err.Raise 1, , "Invalid Key"
    End If
    
    Dim n, tmpString
    For n = 1 To Len(Text)
    tmpString = tmpString + Chr(Key Xor Asc(Mid(Text, n, 1)))
    Next
    Crypt = tmpString

End Function

%>

Then every time you need it on a page then just include it

<!-- #include file="crypt.asp" -->

The function is simple to use - to encrypt some info pass the function the info and key (a number between 1 and 255) and the returned info is encrypted.

Do exactly the same thing again to decrypt it...pass the function the encrypted data, the key you encrypted it with and the returned info will be unencrypted.

You could change the key that is used regularly if you wanted to - perhaps base it on the user's ip address or on the date...

Have a fiddle around with the function and you will see that some keys give "better" looking results than others.

[Edited by matthewralston on 01-15-2001 at 11:25 AM]

[pactalon]

Excellent. Which is faster, encrypting the querystring or using session variables?

Probibly using session variables is faster, althought I doubt there is much in it.

I would only use the encrypting method I mentioned if I had to use it in say... a hyperlink or something...

http://login.asp?usr=ckent&pass=‰Œ™Ž‘’

Is more secure than:

http://login.asp?usr=ckent&pass=superman

I would also use the encryption method if I had a form that I wanted to automatically fill in the password on...eg say someone had filled in their logon credentials and I had found the user name to be wrong, I might send the user back to the login form with all correct info already filled in. If I just provided a "Back" link then the password would be wiped.

BTW... what was the joke?

using the session variable is faster, since your code will run throught the encryption function to begin, then through the decryption function each time a new page is loaded.

BUT, if you use session variables, your users must have cookies enabled, and if your web site is on a web farm, be sure all of your redirects use just logical paths, and don't include the full path.

You can also use hidden field variables, and you can pass the information to the new page by referencing the hidden fields:

'Create the hidden field:
<input TYPE="Hidden" NAME="useridField" VALUE="<%=rsInfo("userid")%>">

'Now after the redirection, you can access the userid with the request.form property:
Response.Write Request.Form("useridField") & " is logged in."

Using these hidden fields do not require cookies, and the data can be passed in a web farm.

But doing this leaves confidential information open for the user to see if they do a "view source". So you should encrypt it

<input TYPE="Hidden" NAME="useridField" VALUE="<%=crypt(rsInfo("userid"),196)%>">

<input TYPE="Hidden" NAME="useridField" VALUE="‰Œ™Ž‘’">

Well I gotta have the last word haven't I?

I do agree tho that if you don't need to use my encrypt way then don't bother...it will be slower.

I can't let you have the last word this time

Probably the best way to handle user information though, is just assign a user number in the database.

That way they only have to log in the one time, and their user number is passed to each page, and their privileges, options, etc, are all determined by the userid number (which will also increase speed, as we all know, ints are faster than strings).

Also, if you use a password box rather than a regular text box, the password is automatically encrypted:

<td><input TYPE="PASSWORD" NAME="PASSWORD" SIZE="10" MAXLENGTH="16" VALUE></td>

[Edited by bubba on 01-15-2001 at 11:09 AM]

In a password box it shows up with lil stars but that's about as far as it goes...the password is still visible in the source code (if it was sent with the rest of the page) and it is sent back to the server as plain text (unless SSL is used).

True, and actually it is just generally an unsafe practice to pass the password through the pages....hence the practice of most sites assigning a userID number to the userid that the user enters on the site.....

To ensure that somebody has actually logged in, and not by-passed the login page (by typing the directory and .asp page directly) you just have a check at the beginning of each page:

If session("userid") = "" then
 response.redirect "http:\\mysite.com"
End if

'OR

If request.form("userid") = "" then
 response.redirect "http:\\mysite.com"
End if

I'm probably coming off as saying that the encryption is bad, I'm not at all.....It is quite good and I have used it in applications before....I'm just offering alternatives.

To ensure that somebody has actually logged in, and not by-passed the login page (by typing the directory and .asp page directly)

Clutching at (shrimp) straws, Bubba?
Aren't we getting a little side tracked from the original question here?

From the original post:

Any thoughts on this method, or a better way of doing things?

Using a numeric userid is a better way of doing things, adding security checks on each page is pretty much a standard practice on sites that require a login and password.

It is logical to assume that the reason pactalon wanted to pass the userid and password to each page was for security, or to allow/disallow permissions on each page...so he would want to add these checks on each page.

Wassamatter matthewralston, am I being too helpful?

All right, all right...I'll let you off. I actually do the same - I tend to store userid, forename, surname etc in session vars and have a standard security page which checks them from an ssi include.

But this isn't over...ok?!