Last week I posted a blog article in which I explained that I had figured out why the check box doesn’t work. What USPTO says is that if you check the box, then for the next 24 hours you won’t have to do the two-step authentication. What really happens is that this almost never works. My explanation, as detailed in that blog article, is that there is a sneeze sensor in the software and if you have the bad luck to sneeze before your next login, this negates the effect of checking the box.
What is very sad about this situation with this poorly designed USPTO software is that judging from the reader comments and from other comments that I received privately, my explanation, which was intended to be humorous, was apparently no less plausible than whatever the (unknown to anyone outside of the USPTO) true explanation is. Many people were taken in.
Yes that previous blog article was meant like a sort of April Fool’s Day article.
I dug around in my cookies and I found what I am confident is the cookie that supposedly protects the user from having to do two-factor authentication for 24 hours. Here is an example of such a cookie:
Name: TwoFactorToken
Content:
LhRlmjFejO7oXhVAsL0ALTLakL0uoSU6EfdQF4vUl+VK+++CkALV+TY8/QuRgPUKmcphLj2KU1xKk+qPK6uvJXGVRLyRmF8UmY0CzjKGR7VJeamcI484moLcci/pqI41RVk4fdCJ5BjomIgoidqUP1n7n3XOd7/zhMXPlS1V0kzagVru9JSHfdSZVwUQDf6jDX4oEbDHDSCiaqACeUyxsGEwnY4Kjvv0egb6Wf7Rdq1uGGE8l4co+5EYlaPLBCt18L3ieisrgwMkRLo5pgJu8HQ3XTB+3+VSKU5F0iaYXsrkn5emalQXzqAVr2Ql+YWwyf3s5jaIac1rXngcFxcMXTm0sfsPHUOPKHPTUmbI0=
Domain: .uspto.gov
Path: /
Send for: Secure connections only
Accessible to script: Yes
Created: Monday, November 4, 2019 at 11:06:24 AM
Expires: Tuesday, November 5, 2019 at 11:06:24 AM
The cookie is called “TwoFactorToken”. It expires 24 hours after being set. Any second-level domain within “.uspto.gov” is able to retrieve the cookie. Clearly USPTO encrypts the “content” field. I consider it very likely that the way it works is this.
At the time the user checks the box, the USPTO script interrogates the user’s web browser asking for every possible piece of information that it can extract from the browser. It turns out that any web site can ask your browser for quite a few things:
- your operating system
- your browser
- what browser plugins you have installed
- your display resolution
- your battery level of charge
- whether it is charging or not right now
- your public IP address
The USPTO script might collect all of these things, combine it with the MyUSPTO user ID, generate a nonce, and assemble this into a data bundle. The USPTO script would then encrypt the bundle, or extract a hash of the bundle, or encrypt a hash of the bundle, something like that. And the result is put it into the cookie such as the one quoted above.
Then of course you get a forced logout after 30 minutes. So now it is time to log in again. The USPTO system asks for your user ID and password, and then the USPTO system has to decide whether or not it will force you to go through the two-factor authentication again. So it looks for the TwoFactorToken cookie. If there is no such cookie, then you have to do the two-factor authentication. If there is such a cookie, but it has expired, then you have to do the two-factor authentication. If there is such a cookie and it has not yet expired, then the USPTO system asks your browser for all of these things:
- your operating system
- your browser and browser version
- what browser plugins you have installed
- your display resolution
- your battery level of charge
- whether it is charging or not right now
- your public IP address
The USPTO system also looks to see what your user ID is that you are using to log in, and looks up the nonce that it stored in its local database relating to your user ID. The USPTO then then compares the answer that your web browser gave an hour ago with the answer that your web browser is giving right now.
Common sense tells you that many of these things are very unlikely to have changed during the past hour. Your operating system has probably not been upgraded during that time. Probably you have not updated your browser during that time. Maybe your list of installed plugins has not changed.
But your public IP address might well have changed. This might be because you logged into or out of a VPN. Or you physically moved from a Starbucks to your office. Maybe just moving from one location in your office to another location in your office could lead to your having a different public IP address. Moving from the secure network in your office to a guest network might well lead to a different public IP address.
And common sense tells you, the state of charge of your notebook computer battery is very likely to have changed during that hour. You may have plugged in your charger, or you may have unplugged your charger.
Also consider that you might have changed your screen resolution during that hour. By this we mean the screen resolution for the active window in your browser where the USPTO login was taking place. You might have resized a browser window for example.
Worse yet, suppose the USPTO local database containing your nonce is flaky. Suppose it often fails to respond promptly to a query from the login authentication software? Suppose it sometimes forgets the nonce?
Depending on how poorly the USPTO selected what to load into the cookie, any change to any of the things just mentioned could conceivably make the poorly designed USPTO software decide that you need to log in the hard way again. Maybe your battery ran down a bit during the past hour. Maybe you resized a browser window. Maybe you moved from your office to a Starbucks.
Or depending on how poorly the USPTO designed the local database that stores the nonces, maybe that by itself would explain why the checkbox often fails to work.
Has anyone tried editing the cookie to change the expiration date?
If this works, it would mean the designer was stupid. A competent designer would have included, in the encrypted content with the nonce and the other things, the expiration date and time. And only that date and time, not the clear-text expiration date and time, would be honored.
Not that this is an important distinction, but I believe the browser does not supply the cookie’s expiration date to the server — instead, the expiration date is only used by the browser to determine how long to continue supplying that cookie to the server (or, equivalently, when to delete the cookie).
So I believe that the competent system designer keeps track of the cookie’s expiration on the server side. After expiration, the server would either delete the cookie or mark it as expired. In any case, the server would not accept the (expired) cookie from the browser to allow the second-factor bypass.
Today (11/25/19), I noticed that the wording changed from “This is a computer that I trust and use regularly” to “Remember this browser and do not ask again for 24 hours.”
Perhaps they read this blog.