Generating false code

[octvs]

Hey thanks for the great tool!

Today I locked myself out of my bank account while using otp code generated via pass. Then to my surprise I saw a different code was generated via Android Password Store app at the same seconds, which let me unlock the account. They used to generate the same codes before, as one would expect.

There should be a problem ongoing, but I can't debug more than just trying it with another store entry which also had different code generated than the android app.

Let me know if I can provide more information.

$ pass otp --version
1.1.1

Although the version in pacman

pacman -Qs pass-otp
local/pass-otp 1.2.0-2
    A pass extension for managing one-time-password (OTP) tokens.

$ pass --version
============================================
= pass: the standard unix password manager =
=                                          =
=                  v1.7.4                  =
=                                          =
=             Jason A. Donenfeld           =
=               Jason@zx2c4.com            =
=                                          =
=      http://www.passwordstore.org/       =
============================================

System is ArchLinux.

[octvs]

Today I had another go at this. On my computer the code generated was 111111 for example, while on the phone it was 999999 and in after a while passed of trying consecutively the next code on terminal was 222222 but the phone it became 111111 which in turn the working one. Is there any way it is generating it one cycle sooner than it should be?

[nertpinx]

Do you have time synchronized properly on both devices? That seems like the only possible explanation. If it would be off by an hour I'd say that might be a timezone/DST issue, but since it is just one code away it sounds like a time sync inconsistency.

[InigoGutierrez]

I have been using pass-otp for more than a year and lately the OPTs were not working for me. After discovering this issue, I checked with the Android Password Store app, I guess the same used by @octaskin, and discovered that pass-otp is generating the correct code two cycles sooner than the app. The codes from the app work, so pass-otp is generating them two cycles sooner than it should (curiously, not one as for @octaskin).

I just synced my device through the Network Time Protocol and now it has the exact UTC time, adjusted to my timezone (Madrid). It still generates the code two cycles sooner. The phone, which is off UTC time by a couple minutes, generates the correct codes.

Was there an update to a protocol pass-otp uses, or some other change that broke the syncronization? Curious to see @octaskin and me having the same problem around the same time.

My system information is the same as the one provided by @octaskin: Arch Linux operating system with same output for the three commands provided by them, so I won't repeat the output here.

UPDATE (with possible fix).

Well, I should have not posted so quickly. It seems I don't know as much about the OTP protocol as I thought, so I will just comment what I did and it might serve as a fix for @octaskin.

First, I was trying to login into Discord, but in my android phone I only had the OTP for an unrelated email account. I don't condone the use of Discord, but I need to comment on an unrelated project. I was unable to login, even by trying the OTP two password cycles after it was generated, as suggested by the difference between pass-otp passwords and android app passwords for the email account I had android app OTP for.

I restarted the computer after syncing time through NTP. To enable NTP in Arch Linux, or I guess any other system that uses systemctl, do it by starting and/or enabling the systemd-timesyncd service: systemctl start systemd-timesyncd.service or systemctl enable systemd-timesyncd.service to enable it at device power on.

Then, I checked my device time was synchronized with UTC by checking an online UTC clock. I used this one here: https://www.timeanddate.com/worldclock/timezone/utc. Of course, we only care about minutes and seconds here, as long as your device hour is the correct one for your timezone and your timezone settings are correct.

I entered the OTP from pass-otp into discord just as it was generated, without wait. It worked.

Then I tried the mail account. It also worked. Note that I had android OTP for this account just because suddenly, one or two months ago, I found myself unable to log in with the OTP provided by pass-otp. The OTPs provided by pass-otp and the android app were still different, but both let me log in to this mail account. I tested using the two different OTPs at the same time throught two different browsers to confirm this.

Since OTPs were not working for me before NTP synchronization and are working afterwards I assumed this was the problem. But checking again with the android app I still see pass-otp generating the same OTPs two password cycles before. But now I can log in with them to discord and the mail account and before I couldn't. So I have no idea what is happening.

[octvs]

checked with the Android Password Store app, I guess the same used by @octaskin, That is indeed what I use.

I don't know what is different now, but I see the same codes on android app and pass-otp again. I didn't enable any systemd services (systemd-timesync.service was enabled by def). I switched to a new hardware but even with the new setup the error was present up until last week.

I'm sure there is a common pitfall that we both encountered @InigoGutierrez, nevertheless if its working for both I should close the issue.