My company is developing a web application, and I was asked to research how to do hardware-based token authentication to login into our web application. Let me repeat: basically there will be a web app, and there will be a usb of sort to be connected to the computer, may be user will need to enter user name & password somewhere and provided that user name & password is correct, user should be authenticated to use our web application. Of course we don't want user to download/install anything on there machine because the machine might not be theirs or they just don't want to do anything extra. My company suggested having a browser plugin, but since the plugin has whatever the system rights the browser has or less, and a browser should not be able to access the underlying hardware (except for camera & microphone since they are essentials)

One way I see how to do it is probably to have a modified version of a web browser which at the same has the ability to check if the security token (the usb) presents, then start the web app from there. If users don't want to run anything or the target computer doesn't allow running this sort of thing, I think doing this is impossible. Just want to check with you guys if I'm missing something.

5 Answers 5


I would then suggest Yubikey ( http://www.yubico.com ). Yubikey is a OTP hardware token that does pretend to be a keyboard (Thus requiring NO extra software installation), and then sends a 128 bit encrypted secret to the server. The tokens are fully programmable by the administrator, and its possible to use the token in a variety of ways. You could either use the tokens password-less, eg use the tokens as a one-factor "What you have" authentication.

But you can aswell have the user type a password prior to pressing the button on the token.

Its also possible to configure the token to either use a public identity and then a unique AES key per user, OR you could use a secret identity and then iterate through all AES keys and decrypt (eg, if you have 10 users then you iterate through the 10 different AES keys stored on server) but the process can be CPU consuming, OR you could have the same AES key for all users.

If you select any on the first alternatives, you could use any of the Yubico tokens. If you go for the last alternative, I would suggest Yubikey NEO, which does have a tamper-resistant cryptographic Smart card Chip, which makes it impossible for a rogue user, to tamper with the yubikey to extract the AES key (that would make it possible for this rogue user to identify itself as a Another user).

The advantage of using a secret identity is that if someone finds the yubikey, they wont be able to find out who it belongs to. Another advantage of the NEO is that is has NFC support, and can generate the signals that a "NFC URL sticker" does, but appending a OTP to the end, like "http://www.example.com/login.php?otp=ifhgieififhgieififhgieififhgieif" so the user can use his Yubikey to login via a NFC-compatible mobile phone.

  • Thank you for your answer. I find Yubikey seems like an appropriate solution to my company's requirement. I'm just curious about this extra point: if all this thing does is to send (by physically typing) an OTP to the server, then would an 2FA app on users' phones do the same job? Yes, it's more convenient to touch a key to enter the OTP value but for simplicity (?) I would imaging having the OTP displayed as a QR code image - user would display that to the webcam and the web server decode that? (I'm thinking about possibilities here)
    – wakandan
    Oct 19, 2014 at 1:40
  • 3
    I would say that a bad idea. USB ports are far more common than webcams. Using a 2FA app on a phone is not secure since a phone can be cloned or rooted easly. This means its enough to leave a phone out of Control for just 5 minutes to regard it as "compromised". You dont know. Yubikey however is pretty tamper-resistant, and the NEO is VERY tamper-resistant, meaning they have to physically steal the whole device and keep it for gaining access. You dont notice if someone copied your phone. You do notice if your yubikey is missing. Oct 19, 2014 at 5:47
  • If you go for a mobile app, then instead, do that you show a QR on the login page. You photo this, then the 2FA app on phone does send the OTP via mobile/wireless to the server. The QR then identifies the login session so if multiple users attempt to login at the same time, the authentication backend knows which session that should be logged in. But as I said, using a mobile app isnt secure. Software based tokens does not have the "singularity" property. Using a hard token - then its far more resistant to attacks. You could even run without password and have "what you have" only. Oct 19, 2014 at 5:51

The CryptoStick uses the Web Cryptography API to expose a keys to the browser. Its likely that the proposed USB security token product product would use a similar technique. CryptoStick is open source, so it is easy for 3rd parties to verify it's security.

The 2-factor authentication that I use regularly is Google Authenticator, which makes it very easy for web applications to support two-factor auth. It seems like more and more services are supporting Google Authenticator, LastPass and Amazon AWS are good examples.

  • Thank you for your answer. It was great to open my eye to such new standard which I never aware of before. However I see that the Web Cryptography API you mentioned is in drafting state (Oct 2014)? If that's the case it's possible that there will be some browsers do not support this standard right...?
    – wakandan
    Oct 19, 2014 at 1:32
  • By the way I just registered this account and doesn't have enough reputation to vote up you guys answers. That's too bad :(.
    – wakandan
    Oct 19, 2014 at 1:33
  • You can come back later when your rep has increased and upvote. The people who took time to answer will likely appreciate it.
    – Bob Brown
    Oct 19, 2014 at 9:27
  • oh wow now I have enough reputation. Thank you all guys :)
    – wakandan
    Oct 19, 2014 at 14:07

In addition to sebastians answer you might also consider not using yubicos backend server but to run your own system, so that the authentication request is not forwarded to yubico but handled on your own system or within your own (your customers) subnet. Alas, you need to install/run such a backend system. Yubico themself provide an authentication server but you can also take a look at the open source auth backend privacyidea, that you can use to manage yubikeys but also soft-OTP-tokens like the Google Authenticator.

You could also set up one such system and run it for several customers of yours.

  • I assumed the OP will code the backend itself. Which in fact the best way to do, since then the OP can use the full capabilities of the yubikey, including authentication without a public identity, using the secret 8hz counter to authenticate subsuquent requests, and the authentication step can be more integrated in the authentication flow. Oct 20, 2014 at 5:53
  • You may be right about integration although privacyidea provides a full API to make integration easily. It also enrolls the yubikey in every available mode: AES with and without Identifier, OATH, Challenge Response and static password.
    – cornelinux
    Oct 20, 2014 at 9:49

An RSA token might be another option. This requires the user to enter an OTP which is displayed on the RSA token. Works well but is not inexpensive.


Though this comes late as the year of 2020, the now Solo Keys is an open-sourced hardware token. And the standard for it is FIDO2. FIDO2 consists of a CTAP2 that is for the client to hardware protocol, and WebAuth that is the client browser to the web protocol.

You must log in to answer this question.

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