Summary: identifiying unique users

[Frank Maas <fr...@cheiron-it.nl>]

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

Re: Summary: identifiying unique users

[Zack Brown <zb...@tumblerings.org>]

On Tue, Sep 16, 2003 at 10:46:28PM +0100, Ged Haywood wrote:
> Hi all,
> 
> On Tue, 16 Sep 2003, Frank Maas wrote:
> 
> > | How to avoid multiple logins?
> > |
> > | The short answer is: you can't.
> 
> Sure you can.  Charge $10 per login.

If they can make more than $10 by faking a login, then it's worth it.

> 
> 73,
> Ged.
> 

-- 
Zack Brown

Re: Summary: identifiying unique users

[Patrick Mulvany <pa...@firedrake.org>]

On Wed, Sep 17, 2003 at 08:39:58AM +0200, Frank Maas wrote:
> Ged wrote: 
> >>> How to avoid multiple logins?
> >>> 
> >>> The short answer is: you can't.
> > 
> > Sure you can.  Charge $10 per login.
> 
> I don't want to clobber the list with non-technical trivia, but
> even when you charge money, you can't avoid it. If only there is
> one user that is willing to pay the amount twice, your scheme 
> is broken. As with technical solutions: the higher the amount
> you charge, the lesser the risk of people doing it. But the
> risk remains...

The only nearly reliable way I have found of doing this is to 
impliment a two stage registration process. Normal online 
registration with a face to face sales meeting where the account 
is activated. This however requires significant investment in an 
offline process and backoffice.

On the down side people can always :-
A. Use another legitimate account (Beg, Borrow, Steal)
B. Have another meeting where an actor obtains the new acount details 
(Fraud).

In respect to client side cookies this does not help as I will often in 
the case of system testing use multiple machines (Unix/Windows) with 
multiple browser versions.

Your best be is to use server side token versioning which will prevent 
multiple browsers simultaniously using the same login but does not prevent
different logins being used. 

Hope it helps

Paddy

RE: Summary: identifiying unique users

[Frank Maas <fr...@cheiron-it.nl>]

Ged wrote: 
>>> How to avoid multiple logins?
>>> 
>>> The short answer is: you can't.
> 
> Sure you can.  Charge $10 per login.

I don't want to clobber the list with non-technical trivia, but
even when you charge money, you can't avoid it. If only there is
one user that is willing to pay the amount twice, your scheme 
is broken. As with technical solutions: the higher the amount
you charge, the lesser the risk of people doing it. But the
risk remains...

--Frank

Re: Summary: identifiying unique users

[Ged Haywood <ge...@www2.jubileegroup.co.uk>]

Hi all,

On Tue, 16 Sep 2003, Frank Maas wrote:

> | How to avoid multiple logins?
> |
> | The short answer is: you can't.

Sure you can.  Charge $10 per login.

73,
Ged.