2

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 '15 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. – Shritam Bhowmick Aug 8 '15 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 '15 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? – Shritam Bhowmick Aug 8 '15 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 - IT Nerdbox Aug 8 '15 at 16:11
1

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. – Shritam Bhowmick Aug 9 '15 at 15:09
  • @ShritamBhowmick Google Authenticator could also be used as the 2nd factor. – schroeder Aug 9 '15 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 '15 at 21:11
  • @cornelinux could you recommend a very good alternative? – Shritam Bhowmick Aug 12 '15 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 '15 at 14:34
1

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. – Shritam Bhowmick Aug 8 '15 at 17:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.