Yesterday the USPTO posted a very odd notice telling all of its customers who use Time-base One-Time Password apps for two-factor authentication that between now and May 1, 2022, they need to discard their existing Secret Code Number and get a new Secret Code Number. As I blogged yesterday (blog article) the notice is strikingly close to being content-free, explaining almost nothing about what it is trying to say. Alert reader Gerry Peters posted a comment to my blog article that made me realize that not only was the USPTO notice nearly content-free, but it also used the word “mobile” in an extremely awkward way. Gerry pointed out that a succinct writer could simply have used the two-word phrase “authenticator app” throughout the USPTO notice, and that instead the writer went to the special point of inserting the word “mobile” no fewer than seven times into the notice, forming the three-word phrase “mobile authenticator app” all seven times.
Gerry pointed out that most users of USPTO systems like PAIR and EFS-Web and Patentcenter and TEAS (all of which require the use of two-factor authentication) almost certainly do not log in on a mobile phone but instead log in on a desktop or notebook computer. Gerry pointed out, correctly, that the everyday shorthand phrase that most people use as a substitute for the accurate but rather longer phrase “Time-base One-Time Password app” is simply the two-word phase “authenticator app”. Gerry wondered whether the seven-time insertion of “mobile” into the phrase was merely a sort of nervous tic, a completely unnecessary addition of a throwaway word, or whether the three-word phrase seemingly so carefully constructed and so consistently employed from the top to the bottom of the USPTO notice might have some significance. Maybe for example the need for users to go through this complicated process of discarding an existing Secret Code Number and getting a new Secret Code number is limited to that subset of users who use mobile devices for logging in at the USPTO?
Having read Gerry’s comment, and having given the matter quite a bit of thought, I conclude two things.
First, I conclude that the need for users to go through this complicated process does indeed apply to all users of TOTP for 2FA, and not merely to the users who use mobile devices for logging in at the USPTO.
Second, I think that there is a fair chance that I am in an odd way the cause of the nervous tic that prompted the nameless author of this USPTO notice to adopt the awkward and needlessly wordy and indeed inaccurate three-word phrase. There is an odd bit of history behind this. The odd bit of history, by the way, probably actually reveals the identity of the first of the two beltway bandits hypothesized in yesterday’s blog article!
The USPTO was, predictably of course, way behind the curve in belatedly adopting the Time-based One-Time Password standard as one of the types of two-factor authentication available to users of USPTO systems. TOTP was established in 2008 and became an IETF standard in 2011 (Wikipedia article). With the establishment of the IETF standard in 2011, the use of TOTP apps for 2FA quickly became widespread, largely because it is a smart and well-designed standard, and because open-source implementations are widely available and are well understood by the coding community, and because everything about it can be implemented for free, both for the system administrators and for the users. Prior to TOTP, there were expensive and cumbersome 2FA systems using physical tokens displaying rolling passwords, and many system administrators were delighted to be able to stop using such expensive physical-token-based systems.
As I say, the USPTO was, rather predictably, way behind the curve on this, and did not manage to join the TOTP bandwagon until December of 2017. When the USPTO did implement TOTP as one of the available types of 2FA, did the USPTO use one of the many open-source free-of-charge server implementations? Of course not. As I mentioned in yesterday’s blog article, the USPTO picked some proprietary closed-box TOTP 2FA server implementation provided by some beltway bandit government contractor.
The comment by Gerry Peters reminded me that back in December of 2017, when the USPTO first rolled out its user interface for TOTP two-factor authentication, the USPTO wrongly said this:
you must have the Oracle Mobile Authenticator app on your mobile device
to do TOTP one-time passwords. I am not making this up! The USPTO was actually stating that you, the USPTO customer, were required to use an Oracle-branded piece of software on your mobile device to do the Time-based One-Time Password authentication. You can read about this in my December 16, 2017 blog article which has screen shots of the offending USPTO web pages.
In my blog article I scolded the USPTO for wrongly stating that the only authenticator app that could be used was the Oracle-branded app. I also pointed out that in December of 2017 the USPTO was late to the party, given that WIPO, for example, had been making TOTP 2FA available to its users since more than a year earlier. (I pointed out, too, that WIPO had succesfully avoided endorsing any single particular vendor of a branded authenticator app.) In my December 2017 blog article, I listed some of the other well-known non-Oracle-branded TOTP apps that worked just fine for these USPTO logins.
Within a couple of weeks of the publication of my December 16, 2017 blog article, USPTO personnel edited the user interface for its servers, and edited its online user documentation, to excise the offending word “Oracle”. The USPTO personnel also quoted from my blog article, explicitly listing some of the other well-known non-Oracle-branded TOTP apps in its user documentation.
So if you look at the blockquote above, you can see where the awkward phrase “mobile authenticator app” came from. It is what you get when you start with the original bad language that appeared in the USPTO user interface and in its documentation, namely “Oracle Mobile Authenticator app”, and if you then excise the offending branding “Oracle” from the four-word phrase. What remains is “mobile authenticator app”.
All because of my blog article in December of 2017.
And back to the question of which beltway bandit government contractor provided the physical-server-based proprietary TOTP engine that USPTO’s developers selected in December of 2017, and that will be taken out of service on May 1, 2022? Surely we have our answer. It must be Oracle. Why else would it be that back when the USPTO started using TOTP, presumably using user-interface templates provided by the vendor, the branding of Oracle appeared in the user interface? It must be that the proprietary TOTP engine that got placed into service in December 2017, and that is going to be taken out of service on May 1, 2022, was and is from Oracle.
While I agree that every computerized device can make the required OTP calculations, there is still an important distinction between a mobile device and a PC. A mobile device (AKA one’s personal cellphone) is dramatically more personal and secure than a PC. Accordingly, the “what you have” prong of the 2FA is much more trustworthy for a mobile device than for a PC.
The security level required by the USPTO is quite relaxed, already allowing alternative PC-based authentication methods. Therefore, in this case, there is likely no harm in omitting “mobile” from the USPTO requirements. However, one who seeks better security will be happy with keeping the “mobile” requirement intact.
Actually, the PC solution is even worse. As no one remembers the USPTO password, it is gracefully stored in the PC and entered automatically whenever logging in. Accordingly, the “what you know” prong of the 2FA is actually degraded into another “what you have”. With the OTP implemented in the same PC, authentication is actually reduced to a single “what you have” test – merely a poor version of 1FA.
I log into USPTO systems on a desktop computer.
My authenticator app, however, is on my mobile phone, as I use it for other websites on my phone, and occasionally log into my USPTO to check on things when away from my desktop. Since my phone is always with me at work, but my desktop is obviously not with me when I am away from the office, it makes sense for me to have the authenticator app on my phone. I haven’t felt a need to have more than one authenticator app.
Therefore, I took “mobile authenticator app” in the notice to mean that one needed to update one’s authenticator app only if one were using a phone-based one, not a desktop one. I don’t know if that makes any actual sense, but it seemed a reasonable interpretation of the phrase.
I agree with SR–this was my understanding of it as well.