Answer the question
In order to leave comments, you need to log in
Authorization without the ability to transfer login / password to another
Please advise how to implement the following.
There is a certain base, access through the web interface. Task: to log in only, roughly speaking, "signed" users, those if one user wants to transfer the password to another, then he will no longer be able to use it. IP binding is unrealistic, because dynam. Sending an SMS confirmation code to the client, both with a unique code and with a certain client identifier (roughly a piece of the session ID), is also not an option, it can also be sent. There is only one option - authorization through etoken. But is it really all that paranoid?
Answer the question
In order to leave comments, you need to log in
Can it be enough to prohibit the simultaneous work of several users under one login? Then the “wise men” who give access may find themselves without access. Often this is enough.
All options can be bypassed. How secure should this system be?
Technically, the simplest is binding to the user's mail. Each time you log in, a unique confirmation link is sent there. Of course, the user can each time forward this link to another, or give a password from his mail.
From social methods - to bind the password to information that the user does not want to share with others (what it can be depends on the category of users).
Apparently, to clarify the method, it is necessary to clarify the conditions under which it is applied, what restrictions are still imposed on users. Because no one prevents one person from entering a password and putting another person at the computer - linking to a token / computer will not help here, and even authentication by a chip in the right hand will not help.
So only biometric authentication by the iris, performed continuously during the entire session of work and allowing access only from a special room, where the security controls the entrance one at a time.
Use certificates. Like on light.webmoney.ru/login.aspx?ReturnUrl=/default.aspx X.509 certificate.
And the token can also be transferred. You can issue certificates marked as non-exportable (win only), but also no one bothers to clone the system at the block level.
The system is a kind of "black list", with the purchase of a key by end users for the duration of its use, with the ability to add list items.
The variant is the simplest: every time the page is refreshed, change the user cookie with a value, leave the same value in the properties of the user object on the server. That is, at one time only one person has a valid cookie and only he can get the next valid one. When logging into the system, you can reset the value so that there are no stuck sessions that cannot be completed.
This solves the problem of simultaneous access by several people (one of them will be constantly thrown out of the system), but does not solve the transmission of the password when one used and went to use the other, then changed again.
The option can be combined with a one-time password for mail or SMS, which will make life difficult for someone else who transfers their login (you will always have to do something).
The second tier is to log simultaneous login from different ip and or browsers, and here it depends on the user agreement what will happen to the person who violated the terms of use (ban, fine, etc.).
Another option: for money and / or for some time to issue a package of one-time passwords, so that it would be easy for a person to break them to transfer them to someone else, especially if the method is implemented when he crashes after another person enters and is forced to use a new one-time password, and them and so back to back.
I’m not sure about the web, but on the corporate network we also have the ability to pull out the
poppy address - it’s not dynamic, after all :) screen colors, screen resolutions, Java version, Flash version, etc. Of course, software versions change, but not all at once, so you can make an error in the direction of increasing versions 1-2 of programs. During the first authorization, a similar snapshot of the system will be made, and during subsequent authorizations, it will simply be compared.
Send a user a sms session token into which his (current) IP is wired. Changed IP - you need to restart.
OpenID limited by Google, Facebook. No person in their right mind would transmit such an acc.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question