search

paolostivanin / OTPClient

Highly secure and easy to use OTP client written in C/GTK3 that supports both TOTP and HOTP
GNU General Public License v3.0
472 stars 46 forks source link

Application does not prompt for password on launch #264

Closed blueorignal closed 1 year ago

blueorignal commented 1 year ago

Current Behavior: Recently when I launch OTPClient, I am not prompted to enter my password, rather the application opens directly into the OTP display screen and presents all the OTP codes for access.

Expected Behavior: OTPClient should prompt for the user password at launch before displaying the OTPcodes.

Other Observations: If I manually lock OTPClient, it will then prompt me for my code, which when entered unlocks the application (expected behavior). If I allow the application to lock automatically as per settings, it will then subsequently prompt me for my code, which when entered unlocks the application (expected behavior).

Current System: Arch Linux, 6.0 Kernel.

paolostivanin commented 1 year ago

Hello, This is expected starting with 2.6.0. You should have seen a message the first time you opened the application after the upgrade 🤔 However, please have a look at the secret service integration (https://github.com/paolostivanin/OTPClient/wiki/How-to-use-OTPClient#secret-service-integration)

blueorignal commented 1 year ago

Thank you. In all likelihood I just did not read the message on the first run 😴 I appreciate your clear and concise answer and secret service integration does indeed work as documented 😀

ronjouch commented 1 year ago

@paolostivanin hmmm is this really expected behavior? I recently upgraded from 2.4.x to 3.1.x, read about the new Secret service integration feature, left it on, and was surprised to see I got:

  1. No password at startup ...
  2. ... but got asked for a password after an Auto lock (because I was migrated from a 2.4 with Auto Lock options on) ...
  3. ... which was defeated by simply restarting the app!

→ What's the point of enabling options Auto lock on system lock and Auto lock when inactive for ... if all you have to do to unlock the app is to restart it?!

Said differently, it feels like options Auto lock vs. Secret service integration are mutually exclusive:

  1. The app should GTK-disable the two Auto lock options ("grey them out") when the Secret service feature is enabled. Rationale: the lock is meaningless security-wise if you have Secret service integration, and only adds bogus friction.
  2. The app should GTK-disable Secret service integration if one of the two Auto lock options are enabled. Rationale: if you use Auto lock, then you want control over when to lock/unlock, and you want to be prompted at startup.

Does that make sense? Am I missing something?

paolostivanin commented 1 year ago

Hello Ronan, thanks for reporting this! Good catch, you are absolutely right. Those options should be mutually exclusive, since having both of them active at the same time doesn't make any sense.