in reply to Cookie login (pseudocode)

Be sure to include some kind of exception handling so that difficulties updating the user row (updating the session_id to either the session_id value or resetting it back to null) doesn't leave your application in pieces on the floor or wide open.

Constrain what will be accepted as userid/password combinations so that someone cannot add a bit of sql to the end of the login string and read your whole user base.

I'm not a big fan of storing userid/password combinations in the clear, but that's up to you. (I'm also not an expert on encryption or obfuscation, or else I'd offer some technique to avoid that)

Good luck

Replies are listed 'Best First'.
Re^2: Cookie login (pseudocode)
by moritz (Cardinal) on Feb 20, 2008 at 13:18 UTC
    Constrain what will be accepted as userid/password combinations so that someone cannot add a bit of sql to the end of the login string and read your whole user base.

    No! Use place holders in the first place, then you don't even have to sanitize the user input for DB operations.

[reply]
      Moritz, Please elaborate on the use of place holders for this purpose. I have a similar need, and I'm not sure what you are recommending here. Thanks, --Akoya.
[reply]
        Akoya, the DBI module will sanitize the parameters you pass in to placeholders in a prepared statement: 
        my $sth = $dbh->prepare("SELECT * FROM foo WHERE bar = ?");
$sth->execute("my 'scary variable here';");

        [download]
        Whereas if you just did it using $dbh->do(): 
        $dbh->do("SELECT * FROM foo WHERE bar = " . "my scary 'variable here';
+");

        [download]
        You would have a problem, because the ' and ; characters would not have been escaped - and would therefore do Bad Things™ to your database.
        website army
[reply]
[d/l]
[select]
        my $sth = $dbh->prepare("update thetable set that=? where this=?");
$sth->execute($that, $this)
        I believe he means that $this and $that are sql safe below. $this could easily be "1;delete from thetable" the engine would merely look for column data of that string, not append the information. Unlike something like ... 
        my $sth = $dbh->prepare("update thetable set that=$that where this=$this");
[reply]
Re^2: Cookie login (pseudocode)
by Anonymous Monk on Feb 21, 2008 at 00:08 UTC
    Re: storing passwords in cleartext

    In the past, i've used javascript to hash the password client-side, and compare it to the hashed passwords stored in the database.

    The hashed password is still sent in the clear (and someone eavesdropping can still use it to log in), but no cleartext passwords are revealed to the eavesdropper or someone who has gained entry to the db.

    While it doesn't do much for the security of your application, it will prevent an attacker from trying a password on another system (e.g. to access your e-mail or banking information)

[reply]

In Section Seekers of Perl Wisdom