Many of us use an authenticator app such as Authy or Google Authenticator as our way of doing two-factor authentication when logging in at the USPTO. Many of us recall the USPTO crash of about a year ago (blog article), that forced us to do another setup of our USPTO authenticator app settings. Now comes a strikingly content-free announcement from the USPTO that we must all do yet another setup of our USPTO authenticator app settings. Why is it, exactly, that we must do this? I think I figured it out.
We all recall the USPTO system crash about a year ago (blog article) in which the USPTO misplaced everybody’s Secret Code Numbers for their Time-based One-Time Passwords. There was some database at the USPTO in which everybody’s shared TOTP Secret Code Numbers were stored, and this was a central part of how everybody could use two-factor authentication apps for logging in at the USPTO. And there were two screw-ups at the USPTO. First, it turned out that nobody at the USPTO was backing up that TOTP Secret Code Number database. And second, somebody did an “oops” and deleted the TOTP Secret Code Number database.
And the consequence was, all of the quarter of a million users who were using an authentication app for logging in at the USPTO had to start all over again, setting up a new Secret Code Number.
So anyway, now comes this new announcement from the USPTO. The announcement is breathtaking in the extent to which it is content-free. The only actual content in the announcement seems to be:
- May 1, 2022 is an important date. Something, we are not really saying exactly what, will change on May 1, 2022.
- The Secret Code Number that you have been using since March of 2021 (when you got a new Secret Code Number after the USPTO system crash in March of 2021) will stop working on May 1, 2022. We are not going to tell you exactly why.
- You need to get a new Secret Code Number now between now and May 1, 2022 if you want to have uninterrupted service using your authentication app for logging in at the USPTO after May 1, 2022. We are not going to tell you exactly why.
Having given it a lot of thought, I have arrived a guess as to what is actually going on.
Any time that anybody ever logs in on a system that uses TOTP two-factor authentication, there are some steps that take place. You can read my blog article (linked above) and it has a link to a good Wikipedia article about TOTP two-factor authentication. Basically what happens is, you try to log in for example at the USPTO and you indicate that the particular type of two-factor authentication you wish to use is the TOTP two-factor authentication (in plain language, that you wish to use an authentication app). What happens next is that at the USPTO, some engine looks up your user ID and finds your Secret Code Number in a database of Secret Code Numbers. The engine then looks to see what time it is. The engine then does some math, following an open-source math function that everybody knows (see the Wikipedia article) that has two inputs, namely your Secret Code Number and what time it is right now, and what pops out is an ephemeral six-digit code number. The number expires in sixty seconds, something like that.
The snazzy thing about this is that at exactly the same time, you are consulting the app at your end. Maybe it is Authy on your notebook computer. Maybe it is Google Authenticator on your smart phone. Anyway, the app looks up “MyUSPTO” in a database of Secret Code Numbers in the app and finds the Secret Code Number. This is of course exactly the same number as the number that USPTO’s engine is using as mentioned a couple of sentences above. The app then looks to see what time it is. The app then does exactly the same math, following exactly the same open-source math function that everybody knows. The function uses those same two inputs, namely that exact same Secret Code Number and what time it is right now, and what pops out is of course the exact same ephemeral six-digit code number. And so you provide that six-digit code number to the USPTO and of course they match and now the two-factor authentication has succeeded.
All of this depends on the USPTO’s engine and your app being able to check to see what time it is, and being able to get the same answer. That is pretty easy. And all of this depends on the USPTO’s engine and your app having the same Secret Code Number available to them. Which is also pretty easy.
So far so good. All of this is pretty much common sense so far.
So what is the thing that is going to happen on May 1?
Well, we sort of assume that what is going to happen on May 1, although the USPTO is breathtakingly unclear about it, is that the USPTO is going to migrate from a first TOTP engine to a second TOTP engine. The first one I suppose runs on a physical server somewhere. The second one runs in a cloud somewhere.
Most system administrators do their TOTP server functions using open-source software. That’s how I do it for example on all of the systems that I manage. The plugin that I use to provide TOTP 2FA for my blog, for example, is open-source. If I ever needed to get inside of it, for example to extract the Secret Code Numbers so that I could migrate them to some other TOTP server function, there is a way that I could do it.
But I am going to stick my neck out here and I am going to make a guess that when the USPTO developers for the first time started doing TOTP 2FA, they proceeded unwisely. Oh I know, it is hard to imagine they would have proceeded unwisely but just stick with me on this. Imagine that the USPTO developers did not use some well-known and well-understood free-of-charge open-source solution, but instead, selected some super expensive, completely proprietary, closed-box system for TOTP 2FA provided by some first beltway bandit government contractor. The USPTO developers have probably never seen the source code for it and never will. I’d guess the USPTO developers never gave a moment’s thought to what they would need to do if and when they decided to end the contract with that first beltway bandit government contractor. And they are probably over a barrel now. They are only now for the first time realizing that the Secret Code Numbers are in some proprietary database inside the engine, in a way that only the bandit contractor knows how to make use of. And only just recently the USPTO developers sort of asked the first bandit contractor “how do we get the Secret Code Numbers out of the engine so that we can migrate to a new cloud-based TOTP 2FA engine provided by one of your competitors, namely a second beltway bandit government contractor?”
At which point you can guess where this is going. The first bandit contractor says “Oh if you had put a Secret Code Number data export function into your contract with us, that would be one thing. But you didn’t. So that will be a change order. The price for the change order will be … little finger in corner of mouth … One Million Dollars.”
And so instead, here is what is going to happen instead.
With the old engine, there is exactly one time that the USPTO developers can sort of get their hands on the Secret Code Number before it disappears into the proprietary database in the old engine, never to be seen again in the clear, and that is at the moment that the user is “getting a new Secret Code Number”. It is only that that brief moment that the Secret Code Number is communicated “in the clear” on the human-readable web page if the user elects not to use the QR code as the way of obtaining the Secret Code Number. So what is going to happen between now and May 1, 2022 is that every one of the quarter of a million MyUSPTO users will be forced to “get a new Secret Code Number”. And for that fleeting moment, the USPTO developers can intercept the new Secret Code Number and … this is the important part … the USPTO developers can feed it to the new TOTP 2FA engine, the one that will be placed into service on May 1, 2022.
In this way, the new Secret Code Number will be stored identically in both the old TOTP 2FA engine and the new (not yet in service) TOTP 2FA engine.
And then on May 1, 2022, when the old TOTP 2FA engine gets taken offline, it will no longer matter that its proprietary database has the Secret Code Numbers in it, or that it is impossible for the USPTO people to get their hands on the Secret Code Numbers that are stored in that proprietary database.
And then on May 1, 2022, when the new TOTP 2FA engine (the cloud-based TOTP 2FA engine provided by the second beltway bandit) is placed into service, its database will already contain duplicates of most of the Secret Code Numbers that are in the database of the old engine.
That is what I think is going on here.
Oh and you wanna place bets on whether the USPTO developers will have learned their lesson on this? Wanna place bets on whether their contract with the second beltway bandit includes a data export for the Secret Code Numbers? Yeah, right.
How long will it take you, as a MyUSPTO user, to comply with this requirement imposed upon you by the USPTO? In my case, I operate three separate apps and I store the Secret Code Numbers in four places. I imagine I will have to spend forty-five minutes or more on this USPTO required activity.
I imagine most people have to spend twenty minutes on this. So maybe this will burn up eighty thousand hours of time. Let’s make a guess as to the blended billing rate of all of the MyUSPTO users. I will guess $50 per hour. So this will impose a user cost of maybe four million dollars.
So for the USPTO to save maybe One Million Dollars, what will happen is that the USPTO’s users will collectively incur a cost of maybe Four Million Dollars.
We all collectively paid Four Million Dollars a year ago, because the USPTO people failed to back up that database. Now we get to pay another Four Million Dollars because the USPTO people feel like migrating from one TOTP engine to another one and did not provide for a data export from the the old TOTP engine back when they signed the contract for it. And did not use open-source the way anybody else would have done.
Wow.
Thank you for commenting. Wow indeed.
Any thoughts as to whether “mobile” in “mobile authenticator app” (the phrase repeatedly used in the USPTO notice) is merely a throwaway word or whether it has some qualifying significance that we are missing?
Most people say “authenticator app” not “mobile authenticator app,” and most of us probably log in to USPTO from our desktop not our smartphone; I don’t suppose we can ignore the 1 May 2022 date if our authenticator app is not a _mobile_ authenticator app. (I am 63.75% joking; 63.75% is my confidence level that “mobile” here is just nonstandard terminology meant to clarify but instead actually contributing to confusion…if you can follow my convoluted logic.)
Your comment got me thinking about why the nameless author of that USPTO notice adopted that weird and awkward and inaccurate and misleading phase “mobile authenticator app”. I suspect that in a weird way, I am to blame, as I explain in this blog article.
I usually use the term “app” with respect to something that runs on my smartphone, whereas I tend to use “program” when it comes to things that run on my computer. So to me, “mobile app” or “mobile [whatever] app” is both redundant, and indicative of something limited to use on the handheld computer that we call a smartphone. Am I an outlier/dinosaur in regard to this app/program distinction?
“But I am going to stick my neck out here and I am going to make a guess that when the USPTO developers for the first time started doing TOTP 2FA, they proceeded unwisely.” https://www.youtube.com/watch?v=qIitjokEJwg
Carl, thanks very much for your feedback. So consensus would appear to be that we should ignore presumably misleading word “mobile.”
I logged in to USPTO earlier today and expected to be prompted to change my 2FA seed, but nothing yet. Debating internally whether this is one of those things that might go away by itself (like not doing your homework on the off-chance that the world might end before the morrow) or whether getting it out of the way sooner rather than later is best here. As I often do, I’m inclined to watch and wait and let the dust settle before possibly doing something that might prevent me from being able to log in to the USPTO.
As usual, folks, we probably want to make sure we choose a date when we have nothing critical due but which is comfortably at least a few days before the transition date: maybe around 28 April 2022?
Maybe some brave soul who successfully changes their 2EA seed without incident can report that fact here?
In a former life, I worked for a beltway software contractor (not on USPTO work). I was working on systems where the previous contractor’s budgeted work ended, resulting in a dead stop, with no further contact. I suspect the Dr. Evil $1 Million Dollars! conversation never even happened here. The old contractor was gone, so probably not even a thought to ask them.
Carl’s remarks are not well informed. Any security system should NOT build in a BACKDOOR, as Carl suggests with, “Secret Code Number data export function”. That would be an attack vector. This type of system generates the codes at runtime by synchronizing two clocks, one at the user and one at the USPTO. The codes are not sitting around in a database. I am guessing that \shifting to a cloud provider resulted in a change in the “current time” at the USPTO, which means that the new USPTO clock is no longer synchronized the old USPTO clock, which had been synchronized with its users. I am glad that Carl is not in charge of software security systems.
Thank you for posting. There are many proprietary rolling-password 2FA systems where the server maintains a sort of “replica clock” on a per-user basis that tracks the constantly drifting local clock of the individual user. Typically what such a system is designed to accommodate is the constantly drifting local clock that is physically inside the physical fob that the individual user consults when logging in. I imagine this might be the kind of system that you are thinking of. In such a system there is no single “USPTO clock” but instead there are a multitude of individual “replica clocks”, each that has a goal of being a fairly close match to the constantly drifting clock of an individual fob.
But the “code from authenticator app” approach that is being used by the USPTO for the MyUSPTO logins has no “USPTO clock” that somehow differs from Zulu time and instead syncs with users. The “code from authenticator app” approach that is being used by the USPTO for the MyUSPTO logins is simply IETF standard RFC 6238, commonly referred to with a shorthand “TOTP” for Time-based One-Time Password”. That standard uses no clock other than Zulu time (Coordinated Universal Time, or for us old-timers, Greenwich Mean Time). That clock is equally available to all, including to any would-be bad actor.
In the world of TOTP, to the extent that there might or might not be something to export from the server, it would not be a “USPTO clock” value. It would be the “secret key” (sometimes called the “shared secret” or what I call “Secret Code Number” which is a per-user data item). Of course in the server it is important that the database of secret keys be stored securely.
At the user end of the client-server relationship, some of the client apps do choose to submerge the shared secrets for the user’s various server relationships in places that are not easily exported. Google Authenticator makes it very difficult for the user to extract the shared secrets for the user’s various server relationships. But others of the client apps do actively provide the very “Secret Code Number data export function” that you question. In Winauth, for example, I can right-click on any server entry and I can pick “show secret key” and then if I type in a password I can get the software to show me the secret key.
At the server end, at the USPTO or at any other server location where TOTP (that is, RFC 6238) is being used, the code necessarily draws a particular user’s secret key out of the secure database in real time every time a login happens. The reason of course is that at the server side, the server must necessarily carry out the calculation of the TOTP to see if it matches the particular six-digit number being proffered at that moment by the user who is trying to log in. So the way it works out with TOTP is that the secret keys of users are exposed “in the clear” within the computational environment of the authentication server tens of thousands of times per day. If the particular writer of the server code cannot be trusted to secure a “Secret Code Number data export function” well enough to satisfy you, then the particular writer of the server likewise cannot be trusted to secure the computational environment of the authentication server within which those same Secret Code Numbers are manipulated “in the clear” tens of thousands of times per day.