Remember password strategy

[CaseyR]

Hi,

I have an Web server application for many organizations that will have  a very wide variety of users from occasional use by members of the public to intensive all day use by staff.    For production staff, logging in several times a day will be a major irritant.   I would like to give administrators the option of allowing users to 'remember' user id's and/or passwords at the same machine.  Cookies are the apparent method, but are there any tips for reducing the security exposure of passing and logging the information with each request?

Thanks.

[Stu]

Hi Casey,

Just off the top of my head, you could *possibly* (haven't tried this myself) increase the session timeout based on _who_ was logging in.

Honestly, given it's a global template option, you probably can't do that. But I think the idea is sound .. Some people you don't want having to log in again every x time period.

Whether you use cookies or increase the session timeout .. They're both about the same level of lax security

Actually, you could bind to ips instead. Rather than user. Hmmm.

Apologies, this is all speculation, probably not helpful.

[bshields]

G'day Casey,

An example of how to use cookies for login is in example 7, but you probably already knew that.

The general minimum rule is you should MD5 hash (or better, like salting etc) the password you store in a cookie, otherwise its hackable.

Obviously you can go to town and combine the username and password into some crazy hashed string. Don't forget whatever crazy algorithm you use, has to also be undone by you also.

But the key is don't store the password as-is, screw with it somehow.

Regards
Bill

[Poul]

not sure if you are concerned with security or User experience.
But i did a system in NT4 awhile back,

* using https i figure addresses one type of problem.
* Increasing the session timeout solved another.
* Smart "remembering" via a cookie solved another,

And if you have a persistant table that tracks the users authentication with knowledge of the Cookie.
You can use the cookie and that info for things like 
* if the cookie value is not what you expect(something like last sessionID), force auththentication
* if the user IP is not the same as Last time (or you could use white/black lists), force Authentication
* if the user has not accessed the system within a certain number of hours/days, force authentication
* if the users ip changed from the last login, force authentication.
* if his last session was more than 30 days .. etc

Basically i rewarded the user for using the system on a daily basis as a long as he
does it from the same connection with a certain frequency i give him a free pass.

I would not  have credentials in the cookie but merely a token to decide if i need to ask
(encrypt if you like) i can know who to log him in as, by finding the user record with appropriate LastCookie value)
And its only ok if this value is something i expect (since it changes on every login)
if anything is amiss send him thru the normal login authentication.

If he or someone else access the system from another workstation or home, with the same credentials
they would have to authenticate, which would invalidate the auto login for any other workstation.
Giving a mechanism to help indicate if security was compromised
(you could even give an extra notice telling him he is now accessing from a different location)

You can use the authentication table for counting invalid attempts /locking/ disabling/ forcing passwords changes etc

poul

[CaseyR]

Thanks, Stu, Bill, Poul

Excellent suggestions for reducing the exposure.