RE: Summary: identifiying unique users
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
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
Summary: identifiying unique users
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
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.
Re: Summary: identifiying unique users
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