|
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:
What does one do a web based email situation, where the user doesnt expect to have to enter the password every time they do an operation?
I have been contemplating this for many months, and I am never sure what to search for for the answer.
The way I see it is the password has to be stored somehow either in the page (for a post), in the url (for a get) or as a cookie.
This unnerves me, as the password is stored on the computer (encrypted as it may be) for anyone to access/decrypt and the sole use of web based email for me is to use it from public access clusters (or annoying friends computers who delight in cracking my passwords).
What is the general way to deal with this?
(I hope that made some sense)
|
Re: Secure passwords
by Beatnik (Parson) on Apr 01, 2001 at 13:52 UTC
|
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] |
Re: Secure passwords
by Anonymous Monk on Apr 01, 2001 at 11:35 UTC
|
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] |
Re: Secure passwords
by athomason (Curate) on Apr 02, 2001 at 01:27 UTC
|
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] |
Re: Secure passwords
by fpi (Monk) on Apr 01, 2001 at 09:55 UTC
|
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] |
|
|
