Stas Bekman wrote:
> Perrin Harkins wrote:
> > Zack Brown wrote:
> >
> > > I'd like to implement something that tries to ensure that one user
> > > can't masquerade as multiple users.
> >
> > We talked quite a bit about preventing multiple logins recently.  I
> > think it was last week.  Check the archives.
>
> Perhaps someone would like to summarize these and put a short tutorial on
> perl.apache.org? This question seems to come back pretty often.

I tried to recap the discussion and looked in the archive. Am I wrong
when I summarize it with "it is not possible in a foolproof way?"
Or, with a bit more words:

| How to avoid multiple logins?
|
| The short answer is: you can't. To ensure that a login is only used
| by one person at the same time, you need to have some method to
| identify "persons". You can't do that based on the information you
| can get from a request. And even if you could get information, there
| is no guarantee that the information is correct - it can be faked
|
| IP-address
|    can hardly be mentioned as a contestor with proxy servers,
|    firewalls, anonimyzers and the rest;
|
| MAC-address
|    there are reports that it is able to get this as part of the UUID
|    or in an SSL key, but it can't be trusted as a user could simply
|    change this or make it a non-unique value
|
| SSL session id
|    it seems that SSL_SESSION_ID offers some unique recognition of
|    the client; it stays valid for some time (hours, days) and is
|    there to avoid needless handshaking
|
| Cookie
|    you can do something supplying a unique identifier in a cookie
|    that you provide, but chances are that you lock up your system.
|    The interesting issue is 'when do you expire a cookie/user link?'
|    Do this too early and you will allow logins to hop from one person
|    to the other, do this too late and you will have problems with
|    people that (for instance) suffer from a crashing browser
|
| Where IP and MAC address seem totally unusable, the SSL session and
| your own cookie offer a mechanism that can of use. If you aim at the
| not-so-technical user and are prepared to be "rude" to those users
| that tamper with your system, you can make it work to some extent.

Comments and additions to this summary are welcome through the list.
After polishing this, it can be brought into the proper docs.

--Frank

Reply via email to