We all know that two-factor authentication is a Good Thing. Having said that, we have all known from the moment (thirteen years ago) when USPTO rolled out its awkward Entrust java applet approach for access to PAIR and EFS-Web, that it was a Bad Thing. Yes it provides two-factor authentication. But it provides the two-factor authentication in a very poorly designed way. Every year or so I have blogged (over and over and over again) about the need for USPTO to scrap that Entrust java applet approach in favor of any of a number of much more user-friendly types of two-factor authentication.
Having said all of this, the plain fact is that for thirteen years now, USPTO has stubbornly stuck with this poorly designed Entrust java applet approach for PAIR and EFS-Web that it adopted in 2004. The approach is tied to an all-important “EPF file” which is the second of the two factors (in addition to a password). If you don’t have your EPF file with you at the computer where you are trying to log in, or if you misplace the EPF file, or if it expires (which almost always happens without warning) then it is impossible to log in to PAIR or EFS-Web.
Which prompted a member of the PAIR listserv to ask this question:
Is there any reason I can’t store the EPF file on a USB thumb drive? That way I can put it on a physical keychain, use it at any computer, and if it is renewed (whenever that is), I am always using the most recent certificate?
The answer, as I will discuss, is sort of “yes” but with drawbacks.
Strictly speaking no there is nothing holding a USPTO customer from copying that EPF file to a thumb drive. And nothing holding the USPTO customer back from telling the Entrust java applet to use a path to the thumb drive as the path to the crucial EPF file.
In our office, we do something that is a little bit similar — we put the EPF files of our patent practitioners onto a file server so that everyone in our office can always lay his or her hands on any of the several EPF files when needed.
Keep in mind, however, that USPTO’s implementation of the certificate management is very awkward. When USPTO “decides” to force a certificate version update upon a particular user, USPTO’s way of doing this is to quietly follow whatever path you gave to the applet and then the applet deletes the old EPF file and then saves the new EPF file in its place. The applet that is running on your computer uses the execution privilege that you gave to the applet to run off and replace your EPF file without telling you. (Yes, strictly speaking the applet does tell you, with a pop-up that flashes briefly on your screen.) The path might lead to the hard drive on your notebook computer, or might lead to a file server (in the usual routine at our office) or might lead to a USB drive if that is the path that you choose to give to the Entrust java applet.
I say “decides” in quotation marks because USPTO’s observed behavior in terms of when it forces certificate version updates is extremely unpredictable. Sometimes a given certificate will last a couple of years or more before USPTO quietly deletes it and gives you a new one (without telling you). But users have observed USPTO doing this delete-and-replace in a mere twelve months or even in as few as fifteen days.
This would not be so bad except that USPTO’s implementation forces everybody in your office to share that EPF file. (Persons who are not registered practitioners, namely all of your paralegals and admins, are reduced to having to share that EPF file to get into PAIR and EFS-Web.) This means that when USPTO does one of these no-advance-warning file replacements without telling you, it bollixes things up for all of the other people who need to be able to use the EPF file.
So suppose you were to adopt a daily routine of using a USB drive as the storage location for your EPF file. Then if the date and minute that USPTO picks to do a no-advance-warning on your EPF file is right now when you are using your USB drive, then the place where the USPTO will slip in the new EPF file (without telling you) is your USB drive.
This means that from this moment, your paralegals and admins will be unable to log in at PAIR and EFS-Web.
Or contrariwise suppose the date and minute that USPTO picks to do a no-advance-warning on your EPF file is when one of your paralegals or admins happens to be logging in at PAIR or EFS-Web? Then from that moment the EPF file on your USB drive will be out of date and will not work any more.
This offers a reminder of the panoply of reasons why the Entrust java applet method of two-factor authentication which USPTO adopted in 2004 is so flawed:
- the EPF file updates happen without warning and at unpredictable times
- because USPTO won’t give credentials to all users (but only to registered practitioners) an office is forced to share the EPF file among many users
- when (not if) USPTO does one of the no-advance-warning EPF file version changes, the consequence is that N-1 of the users are suddenly unable to log in
- the system does a very poor job of notifying the user that one of these no-advance-warning EPF file version changes has occurred
- the Entrust java applet won’t run on most browsers
- soon the Entrust java applet won’t run on any browsers
USPTO needs to scrap the Entrust java applet system for two-factor authentication. There are many better and friendlier ways in 2017 to accomplish two-factor authentication (just as there were in 2014 or 2011 or 2008 or 2005).
Thanks for this. The USB drive is analogous to a “bathroom key” protocol. It works with the understanding that there is only one copy, and you need the key to access the bathroom. If the key is gone, someone is using the bathroom; you will have to wait. Just like at Starbucks. When you leave for the day you need to take the key with you if you want to access Private PAIR or EFS. Currently I have the EPF file on a laptop that is the only one used for EFS filing or Private PAIR. I just take the laptop with me; this is the “Port-A-Potty” approach. It is apparent that either bathroom protocol only works in small firms.
Agreed. The “no login for non-practitioners” has been an issue for us, but the bigger issue is a better way of doing two-factor authentication. No one else I am aware of, from Google to my bank, does anything remotely similar to this Java-based Entrust… thing, which, as mentioned, doesn’t have great cross-browser compatibility, and that is only going to get worse. This isn’t rocket science. The wheel doesn’t need to be reinvented. They could just integrate a commercial solution. I understand that that issue is perhaps fraught with the scary idea of touching legacy code, but that’s probably most of PAIR/EFS. Just bite the bullet and join this (or at least the last) decade.