-1

I have a commercial website where people pay to use the services on it. The services I offer on it is of a word games-nature so it really doesn't need serious banking "Ford Knox" type encryption, and is therefore very basic user authentication security I need. It currently uses a normal username and password authentication. The problem with that is that one person can subscribe and give his username + password to everyone he wishes and all can then get free access. IP Address, device type, location etc, is not a great way to authenticate him since I want him to be able to login at any computer or from any mobile device provided he is present there himself when doing so. Since sending smss's (that should go to only one device) becomes rather expensive, I was hoping that the Google Authenticator app would be a cheaper option since it happens on his device, to ensure it's the same person who logs into the website.

My problem comes in with that QR code (or code he types in) that is created when linking my service to his Google Authenticator app the first time. It seems from what I have read so far that if he copies that QR code to all his friends and family (screenshot and send it or whatever way) and they also simply scan it on their Google Authenticator application and then they will have the same access as he does. Am I right and would this therefore be a bad way to approach software piracy or website content protection?

Thank you

  • Yes you are right, it would be totally ineffective way for the reasons you have already identified. Is that all you wanted to know? – techraf Jul 5 '16 at 1:58
  • 1
    This can be avoided by only allowing a single session for each account, how you accomplish that, is entirely based on your website technology – Ramhound Jul 5 '16 at 4:39
  • Thanks for all the insightful answers. Just wanted to make sure I am not missing something really stupid. I wish there was a working Whatsapp API available for .net that always works and allows you to send a code to a user instead of expensive smsses. Thanks again all, got the answer(s) to my questions. – JayCee Jul 5 '16 at 23:48
  • You are right. TOTP can be copied. You may use HOTP with Google Authenticator to mitigate the problem a bit. netknights.it/en/the-problem-with-the-google-authenticator – cornelinux Jul 9 '16 at 7:35
1

Multi factor authentication cannot protect the accounts if the account owner himself wants to share an account.

When you use Google Authenticator (or any other such app), it receives a "seed" that can calculate the current 2FA PIN number. If someone else has the exact same seed, they can generate it too.

If you were to send an SMS without minding the expenses, it can be an accessibility problem, and you would appear rather greedy too.

For real protection, you will need to check something that is:

  • Cannot be changed by the user to an arbitrary value.
  • Guaranteed to be available.

Apple has a lint on the number of devices iTunes account can be used. They have the hardware ID to determine that. For a web interface, there is nothing much you can do.

Limit number of sessions it can hold. Fr example, keep only the 3 latest sessions. This will make it impractical to share an account by large.

1

Theres 4 options here:

Either, you can use Android Keystore System to generate a key inside Secure Storage, such as the private key is either very hard, or impossible to extract. (it depends on phone model, some models can only have a software-based keystore and that is not as secure as a hardware based key storage)

Theres 2 options here when you use this method. Either, you can requre the IsInsideSecureHardware() boolean to be true, but that would limit your game or app to only devices which have a secure storage.

Or you can just use the Keystore as is, and be compatible with all Android 6.0 devices and up.


The second option, is to provision a physical OTP device. A physical OTP device cannot be copied, and is designed to erase any secrets if any attempts is made to open it. You could also provision a U2F device, but that would limit compatibility to Chrome.


A third option is to provision a standard Yubikey. The OTP code from a yubikey is entered like a keyboard, and the AES key for creating the key, is stored inside secure storage that makes it impossible to extract. If you go for this route, you can even program each Yubikey to have the same AES key for all users, and then store the UserID inside the "private ID". Then no identity needs to be part of the public OTP string, and the user does not need to enter any UserID or similar, instead they just insert the YubiKey in a USB port and touch the button - voila logged in.


A fourth option you have, is to use Event-based HOTP along with Google Authenticator. They can still share the seed, but then you have a trap, such as so if a spent code is entered, or if any code that is not the "current" code (eg a future code) is entered, account is locked, and then its required to both enter 2 codes from the HOTP token, then provision a new seed (new QR code), and then you have a "administration fee" that is like 25% of the original fee.

This means that if any share happens, and they fail to "sync" their tokens along with each member of the "share group", it will cost them 25% of the admission fee. 25% (could even be 10%) isn't too much if you accidentially click the token without using the code or accidentially reenter a spent code, but its too much to get locked out again, again and again if you are sharing the account.

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.