hey,
AFAIK there are 2 kinds of cookies, being the expiring cookies and the session cookies. Session cookies are stored in memory and expire when the browser session ends (which seems a bit handier in this case). Check RFC 2109 for a more detailed explaination.
To be really secure, you can always use SSL
Greetz
Beatnik
... Quidquid perl dictum sit, altum viditur. | [reply] |
Instead of storing the password on the user's machine you can store a session id and have the server timeout the session id after a suitable period of time. | [reply] |
You're right to be wary of transmitting the password with every request. Fortunately there's a fairly straightforward answer: implement sessions, and have your cookies contain a session ID instead of a password. In a nutshell, do this every time someone tries to access a secured resource:
- If a cookie was sent with the request, check for a session ID in the cookie.
- If the session is invalid or expired, or no cookie was sent, send the user to a login page. Otherwise, serve the resource.
- On the login page, ask for the password. You may want this transmission to be secure.
- Once the user is validated, generate an unguessable session ID (see this node for tips on that).
- Set the cookie's expire time to a reasonable amount (or blank if you want it to expire when the browser closes). I've found five to fifteen minutes to be good numbers depending on the application. Longer is riskier, but shorter annoys your users.
- On the server, save the session ID and the login time. The sophistication should depend on the application and anticipated hit rate. A flat file may work if you have very few users, or you may need a full blown database if you have hundreds of logins per minutes. More database-like solutions are more attractive if there's additional info you want to store with the session (e.g. a shopping cart).
- Send the cookie with the login result page. You could help your user out by redirecting to whatever page they originally wanted to go to.
Some finer points:
- When checking for valid sessions, don't trust the browser to expire when you told it to; always use your local knowledge of login time to determine expiry.
- Include an option to log out explicitly. When this is chosen, mark or delete the session locally and send a cookie with an invalid (e.g. empty) session ID and a negative expiry. This will delete the cookie from the browser.
- Update the expiry every time the user requests a page; otherwise they'll be logged out after a constant time following login.
- Every once in a while (minutes to days depending on usage), clear expired sessions from the server.
| [reply] |
I'm not sure at all what you are asking, and what it has to do with Perl, but ...
...is it not also true that some browsers store passwords, not as a cookie, but within their own "password manager" or equivalent?
If so, just turn that password manager feature off, or just don't accept cookies, or switch email services. That's what I would do...
update: I just read your question again, and realized that you are asking how to do it....or are you asking what to do about it like I originally thought? | [reply] |
Most common way is to use basic auth - this is how browsers 'store' passwords. The server asks for authentication, the browser sends it, and keeps sending it in subsequent requests. Usually, this doesn't get saved anywhere unless you ask for it. Of course, the pages may be subject to cacheing though.
The encryption / non encryption thing is mostly about preventing people sniffing your traffic - not highly likely, unless you have reason to suspect otherwise - but the main worry is probably leaving stuff behind in cache. Basic auth is probably fine for most uses, esp. over SSL, but I suppose it depends how paranoid you are...
| [reply] |