Re: Hiding cookies from users

[derby]

What you're describing is the difference between a permanent cookie (has expiration date in the future) and a session cookie (expires when the browser closes ... sometimes). Most browsers (ok - firefox) allow for the inspection of permanent cookies as well as session cookies. Even if they didn't, you should never assume anything sent to a client *cannot* be seen by the client (someone can write their own client).

You're just touching the surface by encrypting the password (even encrypted, how can you prevent man-in-the-middle session hijacking). Check out the W3 FAQ section on Cookie Security ... (but be cautious about using IP address in your scheme since it can change during a session if a user is behind a big proxy server).

[Anonymous Monk]

Thanks for the response

I have to validate the password against the one stored in a flat file. (No database involved)

I am not sure of a better way to pass the encrypted password from one page to another other than cookies.

I tend to think that cookies are better than hidden fields or writing to temp file and retrieving the value each time.

Any suggestions?

[davido]

I have to validate the password against the one stored in a flat file. (No database involved)

DBI and DBD::SQLite are pretty easy to install, and SQLite is a self-contained database that uses a flat file for its data storage. If you feel yourself growing beyond the point where flat files start to become cumbersome, migrate to a database. If you haven't got the ability to install a real database, install SQLite. It's a pretty simple solution, self-contained in a Perl module.

Next point: Don't pass the encrypted password from session to session. Pass a hashed session ID. Validate password once, then maintain an MD5 hashed session ID.

Look at CGI::Session's documentation. It helps to wrap up these loose ends; it facilitates the use of a database (including SQLite), and via CGI::Session::ID::MD5 provides a means of handling hashed session identifiers.

[exussum0]

Whoa, /never/ pass the password, encrypted or otherwise, via the cookie. Create an extremely valid, hard to guess and brute force token, and pass that around. Tie it back to the user. Passing the user's credentials around is begging for a security issue if it's a public interface.