zhuzhuor

By self-verifiable I mean the half of the code is a random number, the other half is computed based on the secret seed and the random number.

I guess another way without frequent sync is to generate a new code every sec, and the server check if it's one of the 25 codes in the last 25 seconds. But this might be unnecessary and inefficient.

1. If my phone has Internet connections, whenever the screen is turn on, the code is refreshed.

If the code is solely based on time, the app may sync its time tick with the server every time when it's turn on.

If the app sends its time to the server, the synced time value should also be encrypted and authenticated. The only pre-shared credential is the 6-digit pin sent by sms, which might be a little short.

If the app gets the time from the server, it might have a slight time delay before the code is computed and shown due to the network latency.

2. If my phone doesn't have Internet connections, the code is only refreshed in ~5s.

So I guess every 5s the app will generate a new code for the next 0~25s.

When the server wants to verify the received code it will check whether it matches with the codes generated in 0s, 5s, 10s, 15s and 20s.

So at least 5 different codes should work in the same time. This may be a nice way.

It seems to me the authy app refreshes a new code whenever I turn the screen off and on. I don't know how it syncs with the authentication server. The app must not only based on time ticks, like other 2-factor apps.

One way I thought is to notify the authentication server in background network requests. But I guess this isn't the case, because it won't work if you don't have network signal (you can try it in the airplane mode).

The other way I thought is the code must be self-verifiable. That means half of the code is a random number, and the other half is the real code computed based on the rand numb and some credentials. If it is really in this case the security strength is only half of the length of the code, i.e. 3.5 digits. That's not very safe to me, especially the website of authy itself only needs one code to log in (without any `first-factor` password).

Any thoughts?

And programming is like English writing, no one will actually produce the same code. You can try by yourself

You can check the last screenshot in the app page https://play.google.com/store/apps/details?id=com.youdao.dic...

I think at least they can first call you before they attempt to deliver the package. If you are not there, then just keep the package for the next day's delivery. This will avoid the delivery failure and save time of both sides.

If a company can deliver all days in a week (including weekends) and all time in a day (including evenings and nights), and the delivery men really called before they left a note, that company would win the game.

How could the authors know the backdoor design is not the intent of American military?