I wrote about wondering how to make “login” to a dynamic website in Perl. The best solution advised by http://perldesignpatterns.com/?WebAuthentication was to make a temporary token: “cookie with an authorization token. Store the token in the database along with an expiration time separate of the cookie. The token should be random generated and completely seperate from the password but handed out when the password is validated. This is the best case;”, but it was overshot for now, so I settled up for this scheme:
Whan user registers, his password is stored as md5 digest in database. Salt is generated – string of eight random letters, numbers etc.I use Crypt::PasswdMD5 qw(unix_md5_crypt);
When user logs in, password is checked- crypted using crypted pass from database as salt:
if ( $cryptedpassword eq unix_md5_crypt($password, $cryptedpassword)) {
and if it is ok, cookie is stored with user ID and crypted password.
The cookie is then checked on every page, whether it contains the crypted password from database.
Well, this is my idea of doing it for now, already implemented, I feel a bit unease about that – what is the point of crypting password and storing it crypted, as it really matters whether the pass from cookie is equal to pass in database – it could be not crypted and it would work the same way.
The only advantage is that the password is not stored in cookie – but it is not needed, as just the digest is needed to pretend to be logged in.
What do you think?
See also:
- Website login with Perl
- Utf8 in web perl application (LAMP) – dbi, mysql
- Perl WTFs – last in function
- Utf8 horror at LAMP – accept charset
- Utf8 in web perl application (LAMP) – binmode, charset
Tags: 
4 responses to “Website authorization – my solution”
Leave a comment
Terrible idea. As soon as someone steals the cookie they can impersonate the user and access the system. The only way to invalidate the cookie is to change the password.
Or am I misunderstanding how your scheme works ?
Simon.
The main reason is to not store the password as plain text in the database. Perl Monks did this and when they got hacked lots of accounts were exposed. People who used Perl Monks had to run around and make sure they weren’t using the same login credentials on any other site. And you store them hashed with a salt so that if you get hacked, no one can use a Rainbow Table to crack the hashes.
“Crypted password from database” isn’t a temporary token. E.g it can be used after user do logout.
@Simon: yes, this is true – is someone steals cookie (and do not let it expire
) he can log in. This is why this solution made me unease – “The only advantage is that the password is not stored in cookie – but it is not needed, as just the digest is needed to pretend to be logged in.”
@mj41: yes, this isn’t a temporary token, as I did not implement what the design pattern said. Now I am wondering whther I should do this, or is the solution good enough.