And yes, without an expiry date, they should expire on closing the browser.

see the specs

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).

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?

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.




Dave

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.

You shouldn't be passing an encrypted password to subsequent pages. All you should be storing, if anything, is a session identifier. You can store this in the url, a hidden field in a form (.NET for example), a query string or a cookie. You can encrypt it too if you like ;).

All your pertinient info can then be stored/accessible to your web server in some form . It might be an encrypted record in a session file or record in a db (or whatever). Though of course, you then need to plan how these records expire, what happens if someone were to gain access to them (etc).

Using any kind of session variable/identifier has its positives and negatives. Cutting and pasting that identifier, for example, may allow someone else to hijack a session. However, at least that session identifier does not contain any information and it doesn't matter if it is stored on disk (etc). It also means you are free up to store larger amounts of info without worring about the size or number of cookies you set.

As an aside, this is more a question of web security. With this in mind, I really do recommend you read up on this via the Open Web Aapplication Security community site. They have a set of PDF guides PDF for distribution that are worth reading. The download page is here.

Just some thoughts ;).

Update: page 157 in the current draft covers sessions and best practise. Check it out!

Thanks for links.

I will check them out