Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

passwords! and encryption! and scripts! OH MY!

Status
Not open for further replies.

arcnon

Programmer
Aug 12, 2003
242
0
0
US
a liitle wizard of Oz twist hehe.

I have been contemplating security issues on my inherited server.
Issues:
1. At this point all the server passwords are contained in modules that scripts call to access the databases and tables. The modules permissions are set to httpd rwx, webmgnt rwx, and rx. The user and passwords are static in the modules. To me I think that this is a very insecure mothodology.

2. We have SSL set up but I dont think that is hasn't been done right because the scripts can be accessed through http & https which I know isn't right... I think.

3. Cookies are used to maintain state/sessions they are not encrypted either and it seems that the login script fills the login data once you type in the user name.

On the positive side to do anything on any of the servers you have to use ssh.

In your opinion is this enough. If not do you have any suggestions?
 
1) I would centralize my username/passowrds to a single file for ease of maintenance. I would not encrypt them etc. If someone gets on your server you have MUCH bigger issues, the encryption status of your web passwords is a minor issue at that stage.

2) You can use mod_rewrite to force an ssl connection. Only worry about this if the data is super sensitive.

3) The login script can't really fill anything out, thats usually a browser side 'feature' where it remembers passwords. Probably has nothing to do with the cookie. As long as the cookie only contains the session ID your set. If your sticking usernames/passwords in it thats bad.

Overall you have a pretty standard setup here, I would not worry to much unless you have abnormal security requirements(eg: Your a bank or something).
 
The login script can't really fill anything out, thats usually a browser side 'feature' where it remembers passwords. Probably has nothing to do with the cookie....

it is a javascript that reads the cookie
if the user matches the cookie user it fills in the password.
 
Ok, I assumed by script you meant 'CGI Script' since this is the CGI forum :)

I think your pretty standard on this as well. I would not prefill the password though since a 'view source' will get the password info out of the HTML, exposing a users data to anyone who can get on their PC.

What I usually do is take the username and the password, sign it into a SHA1 hash, stick the SHA1 hash and the username in a cookie.

Then, when that browser connects I take the username, retrieve the password, SHA1 them together and compare to the SHA1 in the cookie. If they match I auto-log them in.

That way your never sticking a password in a page or otherwise exposing sensitive user information.
 
To fix the problem where the login script fills in information for you (I'm assuming this is the password field that is being filled in), you can add the following parameter to your <input type="password"> tag to surpress browsers from doing this.

autocomplete="off"

Sometimes, the smallest things are the best.

- Rieekan
 
Oho I can use that on another project, thanks Rieekan!

I think he has javascript prefilling the field though,will javascript override the autocomplete setting?
 
Had this issue with a credit card field once upon a time

<textarea> is the answer, it's bigger, it's better, and most of all it has no memory...

Code:
                  <td class="p">Card Number</td>
                  <td>
                    <textarea cols="20" rows="1" name="cardnumber" class="p"></textarea>
                  </td>
The scrollbar is a bit unsightly, but that can probably be fixed with a style directive

The problem with the type=password is that it changes charcters to asterisks, and the user can't verify if that was the case

hth
--Paul
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top