A long time ago the way to log in was with a user ID and password. Then people started using two-factor authentication (2FA or “something you have, and something you know”). USPTO’s particularly poor choice for 2FA was the Entrust Java Applet. After a while some organizations started using a text message on a cell phone as the second factor. This turns out to be a really poor choice as well because it is very easy to hack.
The smart way to do this nowadays is TOTP (time-based one-time password). For most people the way you do this is to install an authenticator app onto your smart phone, and you scan a QR code. The app displays a six-digit code that changes every thirty or sixty seconds. The code is the second factor.
The point of this article is to invite you to consider smarter ways to do TOTP.
Before I can tell you the ways that I suggest to be smarter about TOTP, I need to provide a bit of background about how TOTP works.
With TOTP, the way that the user proves his or her identity to the server is by means of a six-digit number that changes every 30 or 60 seconds. The six-digit number is the output of a math function. The math function has two inputs — the time of day right now and a Secret Key. When the time comes for a user to log in to the server, the user opens up the authenticator app. The app looks to see what time it is, and the app uses the time of day and the Secret Key to calculate the six-digit number that is the number for Right Now. At the same time, the server looks to see what time it is, and the server uses the time of day and the Secret Key to calculate the six-digit number that is the number for Right Now. Assuming that the two six-digit numbers match, then the server is able to conclude that the user must be in possession of the Secret Key. The user is probably actually the true user.
What makes this work of course is that the time of day is the same for the app as it is for the server. (For TOTP, it is agreed that everybody uses Zulu time.) There’s also a window of time to allow for the chance that the clock at one end is running a little slower or faster than the clock at the other end. And the other thing that makes this work is that for each user, there is a Secret Key that is agreed upon between that user and the server.
So now we turn to my first suggestion on how to be smart about using TOTP.
Think about what is going on when you scan that QR code. When you scan that QR code, what you are doing is loading the Secret Key from the server into your authenticator app.
This means you have one copy of the Secret Key. It is in your phone.
What if your phone gets lost? What if it gets run over by a truck? What if it gets stolen? Then you don’t have your Secret Key any more.
I suggest storing your Secret Key in more than one place.
What you might do is to store your Secret Key in three places. A first place where you might store it is in Winauth which is an app that you may have installed on your notebook computer. A second place where you might store it is in Google Authenticator which you may have installed on your smart phone. And then the third place would be some safe place like written down on a piece of paper in a locked desk.
None of this gets done by scanning QR codes. It’s a matter of copying and pasting a sixteen-character string such as “PDDMDYDSKMHS22T7”.
This process gets repeated for each Secret Key that you use. I have one for Stripe (the company that our firm uses to process credit card payments) and one for ePCT and one for MyUSPTO and one for this blog (WordPress) and many, many more. I store all of the Secret Keys in three places.
This is more work than just scanning a QR code. But it gives you more flexibility about how to log in at MyUSPTO. You could log in using Google Authenticator or you could log in using Winauth. And then if somehow your computer were to crash or your phone were to get run over by a truck, the information in that third place could be used to reconstruct things.
I don’t actually use Google Authenticator on my smart phone. I don’t actually store my TOTP Secret Keys on my smart phone. I use a really spiffy dongle called a Yubico Neo. This neat little dongle is usually in my pocket. I can tap it to the back of my smart phone. When I tap it, it exchanges some data packets with my phone using NFC (near-field communication) and then the phone displays my six-digit TOTP numbers which change every 60 seconds. But the Secret Keys do not get stored permanently in my phone. They get stored in the dongle.
Please post comments below.
I can’t find the sixteen character “Secret Key.” Where is it stored (after I have already set up accounts on Google Authenticator and/or Oracle Authenticator)? And how do I save it to the authenticator app?
Yes that’s a thing about some of the apps including the Google Authenticator app. It’s a “black hole” in the sense that once it learns the Secret Key (from the QR code, usually) then that’s it you can’t get your hands on it again for loading into another app such as Winauth. So then the thing to do is go back to the server and generate a new Secret Key and then have the self-control not to use the QR code at all. Instead capture the sixteen characters and copy and paste them into three places or so.
Carl,
I don’t believe I have heard this advice before, and I’ve got 11 accounts configured in my TOTP app. With respect to the USPTO 2FA system: if I lose my phone, can’t I simply select email as the second factor and then reconfigure the TOTP with my new phone (or Winauth, etc.)?
My apologies if I’m missing something obvious. Thank you!
You can get TOTP applications that allow you to have a backup (e.g. to store your non-logged in credentials, so you can retrieve it in case your phone is lost or the app breaks). For example Authy allows you to have a backup.
The USPTO also allows you to change your second factor to email, so that should also solve the problem. You can then go in and set up a new TOTP application, if necessary.