|
in reply to Re: Securing Passwords
in thread Securing Passwords
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
|
Re: (jptxs) Re: Securing Passwords
by tame1 (Pilgrim) on Apr 02, 2001 at 17:13 UTC
|
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] |
|
|
Maybe, maybe not. as tilly notes above, some DHCP servers refresh the address very frequently and it could be the case that the IP would change during one session even. If all they need is the cookie, then you may be fine as in the time that the whole process takes place the cookie is made and they have it and all is well. If the IP is validated in any way, it could change, and therefore invalidate the session. If it is not validated, you could argue that it's prone to spoofing if the cookie is intercepted in transit. The other problem is the case where the DHCP server changes the IP in the middle of the initial validation, then you're really screwed.
I worked with security products at a previous company, and, in every case, when they depended in any way on IPs, even the slightest, there were always problems with DHCP. it's a PITA for sure =)
"A man's maturity -- consists in having found again the
seriousness one had as a child, at play." --Nietzsche
| [reply]
[d/l] |
Re: (jptxs) Re: Securing Passwords
by cLive ;-) (Prior) on Apr 02, 2001 at 10:05 UTC
|
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] |
|
|
| [reply] |
|
|
DHCP - IP stays the same for that session doesn't it?
Maybe, maybe not. My DSL times out an IP address after about 5 minutes, forcing a renegotiation. It's often the case that I'll start something in a browser window, then get distracted for a few minutes (phone call, daughter wants to play, etc.) then suffer the slight delay as my broadband router haggles for a new IP address.
| [reply] |
|
|
Thanks for insight (I'm on fixed IP).
Clients are in UK are on dial-up at mo (broadband is v expensive now - c. $150pm for DSL)
Something to take into account though, as this may become an issue later... :)
cLive ;-)
| [reply] |
|
|
