more useful options | |
PerlMonks |
CGI Security Advice Soughtby Ovid (Cardinal) |
on Jul 31, 2001 at 22:03 UTC ( [id://101247]=perlquestion: print w/replies, xml ) | Need Help?? |
Ovid has asked for the wisdom of the Perl Monks concerning the following question: Looking for feedback on the security model that I have for a particular site. We've been asked to encrypt only the login process (SSL). This site is for an administration console and will only have a few users. They are required to have cookies enabled. Here's basically how it works: The user enters a username/password combination. This is sent over an ssl connection to the authentication script. The password is hashed using Digest::MD5 and a salt that is read from a non-web accessible file. This is compared to the hashed password in the database. If they don't match, they are redirected to the login screen up to seven times, after which they are locked out until an administrator unlocks them. If successful, a digest is created with the following algorithm:
This digest is returned as a cookie. Subsequent accesses to the admin console will return the digest and compare it to the database. If this takes too long, their session times out (controlled by the script, not the cookie) and they must relogin. If the digest matches, a new digest is created, stored in the database, and sent back in a cookie. Except for the initial SSL connection when the username and password are submitted, they will never again be sent. Here's the main code that controls this:
In the future, I plan to add a 'bogusLogin' table to the database. The intent is to even lockout non-existent user IDs after MAX_LOCKOUT_ATTEMPTS so that crackers can't use the lockout feature to determine if they have a valid user id. Have I overlooked anything? Cheers, Vote for paco! Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.
Back to
Seekers of Perl Wisdom
|
|