We have a situation here. The client which I work for is currently placed as a finance brokerage firm and their current positioning are:

  1. The firm has different branches in different locations
  2. The firm has a giant customerbase
  3. The firm takes security serious

Now, their requirements specifies these:

  1. Passwords if shared by customers should trigger an OTP to real account
  2. With generation of OTP, the account owner is informed

The question is what can be done to prevent different people using the same shared password or in simple, what are different ways in which the firm can restrict the use of shared password for intended users apart from using OTP?

Note: Earlier they had trading password which alongside with the main password could be shared to the third-party so that's not a reliable option.

  • Is OTP in this context suppose to mean One Time Pad?
    – John
    Aug 8, 2015 at 12:08
  • @John, it's one time password which means on every access attempt - one has to receive random generated code at his/her registered device to the firm. Aug 8, 2015 at 13:07
  • I would think you could associate the OTP to a specific user in the database, so it is just valid for that one person.
    – John
    Aug 8, 2015 at 13:14
  • @John - OTP will itself take care. Could you kindly re-read the question? It says what are other measures that can be taken besides OTP? Aug 8, 2015 at 15:45
  • While I prefer OTP, what about TFA or several secret questions? I do not mean the stuff we all can get on social media websites. Why are you looking for an alternative for OTP?
    – Jeroen
    Aug 8, 2015 at 16:11

2 Answers 2


The problems with a password is, that it can be shared and there is no good way of realizing if it was shared. You do not know easily if person A or person B used the password. As @Rory mentioned there are ways to try to cope with that. Implementing a sophisticated logic to verify if the password is used by the same human. You can track the client's IP and if a user will try to login from south Africa one hour after being logged in from Australia your logic might deem this suspicious.

You should use something that can not be shared easily.

It is easier to identify the person with a second factor. You can use an OTP token that generates a One Time Password and which the user needs to enter and or you could send an OTP to the mobile phone of the user. Both scenarios are supported by privacyIDEA which is an open source solution you might take a look at.

But still the problem with OTP is, that person A could also share the current OTP with person B even via phone or email. Person B: "Hey, person A, I know your static password, but what is your current OTP?"

If you want to be really safe, you might want to use client certificates preferrable on a smartcard. Then the user needs to present his smartcard to login. person A will not be able to "share" his smartcard via phone ;-)

  • Which means hardware security via RSA tokens could be a go, right? I see no standard solution to this via web security implementations. Aug 9, 2015 at 15:09
  • @ShritamBhowmick Google Authenticator could also be used as the 2nd factor.
    – schroeder
    Aug 9, 2015 at 20:04
  • @ShirtamBhowmick You could use RSA. But RSA uses a unknown proprietary algorithm. It uses preseeded tokens, where you are not sure, where copies of the seeds are located... I would not use RSA ;-)
    – cornelinux
    Aug 10, 2015 at 21:11
  • @cornelinux could you recommend a very good alternative? Aug 12, 2015 at 3:35
  • @ShritamBhowmick If you are thinking of OTP tokens do not use RSA SecurID but rather use Yubikeys in conjunction with privacyIDEA. If you want to use client certificates on smartcards, you need to check the users operating systems, since you will need to enroll SC drivers.
    – cornelinux
    Aug 26, 2015 at 14:34

If i understand the question correctly you're looking to stop users sharing passwords on a web based system.

A common approach for this is to limit each account to one simultaneous session, and the if a new session is commenced, to terminate the original one.

This reduces the effectiveness of sharing passwords as they can't actually use the system at the same time.

You could also try to detect abuse by noting whether one account was coming from a number of different systems ( e.g. Checking things like user agent or source ip address) and then taking some kind of actions if abuse is detected.

  • @Rory, thanks for the heads up but the risk is if the original user isn't logged in and after logging out the sessions are destroyed at the server side - In anyway the ones who are not intended users could re-create new session tokens when they login with the master password and trading password. Aug 8, 2015 at 17:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .