First of all, I should mention that I read this thread and it was useful in my case, but I need more comments and reviews about this authentication method.USB Token authentication which I want to talk is :

1- User logon to server with username and password

2- server requests for some USB credentials like serial number, expiration date, etc

3- User fills the requested parameters and send them to server

4- Server generates an login token and signs it with its private key

5- User downloads the token and save it in encrypted USB Flash memory.

Now every time that user wants to login to server, server asks for username, password and token. User uploads the token from his USB to the server. Server verifies the signature with its public key and if it is verified, the user can log in.

From security point I know that the USB flash memory is not as secure as PKI smart tokens. Because the token is exportable and it has no TPM standard, however I am wondering what other security issues this mechanism has?

  • 1
    "what other security issues this mechanism has?": what security enhancement do you expect that token to provide?
    – Bruno
    Commented Jun 30, 2014 at 8:55
  • @Bruno I expect simple 2 factor authentication. If this method has no critical security issue then why it has not been widespread?
    – A23149577
    Commented Jun 30, 2014 at 8:59
  • One of the security issues which I concerned about is replay attack. Is this possible for attacker to capture the token authentication message and use it for logon? Even if I implement communication via SSL protocol?
    – A23149577
    Commented Jun 30, 2014 at 9:13
  • 1
    @AJeneral For it to become widespread it needs to be both free and extremely convenient. Which today means it needs to work hands free and cross-platform from phones, tablets, laptops, all of the big browsers, windows, and mac. Commented Jun 30, 2014 at 13:41
  • Basically it needs to be a soft-token app on a smartphone that operates over bluetooth, with a hard-token backup. People generally hate having to take their keys out of their pocket just to use a computer. And for many mobile devices, hardware tokens aren't even an option. Commented Jun 30, 2014 at 13:47

1 Answer 1


It doesn't seem to provide much on top of username and password authentication. Your token effectively becomes a secondary password that's at best hard to remember.

The main benefits of PKI smart tokens and client-certificate authentication are that they prevent eavesdropping and phishing attacks: the private key never leaves you, so eavesdroppers or servers you authenticate to using your private key won't be able to use the credentials you've just used to authenticate anywhere.

Here, you don't get any of these benefits. Even if you protect the connection against eavesdropping (e.g. via SSL/TLS), phishing is still possible.

I can see a few additional downsides:

  • Your server initially acts like a pseudo-CA which issues the token instantaneously the first time. It sounds good, but you'll certainly have to deal with lost tokens, having to re-issue them in practice, so it's likely there's going to be a weakness here. (Similar problems as PKI authentication, it's only as good as the administrative side normally done by the CA.)

  • Your users may lose their USB tokens. Why have it stored on a USB stick in the first place, by the way? If you use client-certificate authentication, via a hardward or software token, you can generally protect the private key with a password or PIN that you'll need to enter every time you use it. That's mainly going to cause big problems to your legitimate users, while it's going to be great for potential attackers (they can just make a copy of the USB stick, no need to steal it).

If you want something similar to hardware USB smart tokens, but they're not an option, you could use software-based client-certificates stores (e.g. PKCS#12/PFX). They're not quite as good as hardware tokens because the file can effectively be copied, but at least PKCS#12 files have password protection mechanisms. (Client-certificate authentication mechanisms generally have poor UI interactions, unfortunately.)

  • By the way, the reason for keeping token in usb-flash memory is that the user can keep it with himself and use it wherever he wants to login to server.
    – A23149577
    Commented Jun 30, 2014 at 10:00
  • I thought about your answer last night and I encountered a question. You said "Even if you protect the connection against eavesdropping (e.g. via SSL/TLS), phishing is still possible.". So, If I use a SSL certificate for my server and make all communications via https, method would be immune to typical phishing right?
    – A23149577
    Commented Jul 1, 2014 at 4:24
  • It depends on what you consider typical phishing. Basically, it would be the same as a username/password (except that you effectively have two passwords): if you're sure the server you're typing it into is what it says it is, if you trust it and if it's implemented properly, you should be OK. The problem is that there's no real additional security compared to a complex password (and having it on a USB stick is about the same as having it written down with you at all times...).
    – Bruno
    Commented Jul 1, 2014 at 10:48

You must log in to answer this question.

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