Here's how I deal with it:
- password is stored crypted on server
- user sends password which is crypted and checked
- if ok, append REMOTE_ADDR environment variable, crypt this and send back as a cookie
- for future requests, read crypted password from file, append REMOTE_ADDR, crypt this and compare with cookie sent
This means that:
- unencrypted password is entered only once
- cookie only works from that IP address
- if cookie is sniffed, it's not very useful
Of course, if security is essential, you'd be using SSL with 128bit encryption, wouldn't you, making most of this conversation moot :)
cLive ;-) | [reply] |
two thoughts right off the top of my head: DHCP and mobile users. Basically, IP is not a reliable method of identification in any scheme. What you suggest means floating into keeping a state - which is covered very well by merlyn here, in a thread that's somewhat relevant to this too.
"A man's maturity -- consists in having found again the
seriousness one had as a child, at play." --Nietzsche
| [reply]
[d/l] |
The cookie should be set to be good only for that session of the browser.
The result is that, even using DHCP, it will work just fine,
since when the person disconnects and re-connects from elsewhere,
they will have to re-login to the central server.
Also, what about the idea of having the central server,
which (once it checks the passwd), creates a cookie,
does an MD5 hash of the cyphertext cookie, then RSA encrypts the hash
with a public key. (then base64 encodes it all as one string and sets the cookie).
After that, subsequent calls tear off the signature field, unencrypt it, then compare the
result to their own MD5 hash of the rest of the cookie. Since IP and username, etc.
are in the cookie, those items can also be tested, giving the same protection as the other methods.
This method is only really usefull of course in a place with multiple servers, one
central passwd server, etc. But it works. We use it.
What does this little button do . .<Click>;
"USER HAS SIGNED OFF FOR THE DAY"
| [reply]
[d/l] |
Valid points, but for my task:
DCHP - IP stays the same for that session doesn't it? That's all I need.
Mobile users - the application I use it for is not designed to use mobile phones.
AFAIK, AOL is our only problem (users' requests get sent through multiple proxy servers?!?! I'm not even sure about that issue even existing - I read it somewhere, but our clients don't use AOL, so again, not an issue), It's only used to check that this session is being run from the same IP that logged in.
"IP is not a reliable method of identification in any scheme"
I agree. What I mean is that the IP is not being used to identify the user, the password does that. I only use the IP to ensure that all future requests are made using a cookie that is useless if stolen and used by another user.
But then, like I said, this is what I use. Different circumstances require different approaches. This was the best I could think of for my particular task :)
later
cLive ;-)
| [reply] |
