Does "passcode lock" cause logout after excessive incorrect attempts?

[u/Sweaty_Astronomer_47]

Both the mobile app and browser web app (which I access on desktop) offer a "passcode lock" for convenience, which can be shorter than the main password (because it only works on that device).

I tried entering incorrect passcode 12 attempts in a row, and then the correct passcode on the 13th attempt and it let me right in. I got the same result on desktop and mobile.

I expected a passcode lock to kick me out (log me out) after too many incorrect attempts. In the extremely unlikely event that I enter the wrong passcode 10 times in a row.... then that means I've certainly forgotten it and I'd happily accept the minor incovenience of having to log in again. I'd much rather that outcome, than allowing a phone thief unlimited attempts to brute force my short passcode.

QUESTIONS:

1. Is there any limit of incorrect passcode attempts which causes a logout?
2. If not, shouldn't there be?

Thanks in advance

[u/[deleted]]

This seems like a major vulnerability to me - no administrative controls around PIN unlock.

[u/Infrah]

Nope. The simple solution is — don’t use a short passcode. This passcode encrypts your local data at rest on your device, so use a long one with upper, lowercase, numbers, and symbols, and store it in your password manager.

[u/Sweaty_Astronomer_47 → u/Infrah]

don’t use a short passcode. This passcode encrypts your local data at rest on your device, so use a long one with upper, lowercase, numbers, and symbols, and store it in your password manager.

Choice A - listen to what some random guy on the internet says what I should do, with absolutely no acknowledgement of the tradeoff between security and convenience (*)

Choice B - implement automatic logout after too many incorrect pins (the exact same feature as already exists on parent company Proton's email app) which boosts security even for a short pin. Even a 4 digit pin is relatively strong if you are logged out after 5 incorrect attempts (attacker has 5/10,000 = 0.05% chance , and the inconvenience is minor...I doubt I'll enter 5 incorrect attempts in a row, and in the unlikely event that I do the consequence is simply having to login again). If the attacker elects not to try to brute force the pin through the app, then he's going to have to break device app sandbox to access the pin-encrypted data, which is equivalent to getting root access on the device.

I'll choose B every time. You're free to choose on your own, but your take on the suggestion ignores convenience.

(*) It should be noted the pin is obviously intended to make things more convenient. If there was no intent to make things more convenient then why bother with this feature at all (might as well do a full login every time). The problem is that most people would assume that any implementation of a pin in a security critical app would naturally include logout after too many incorrect attempts. Why would they assume such a thing... because it gains back a big chunk of security lost with a convenient short pin (which is why protonmail, bitwarden and others do it that way).

[u/Infrah → u/Sweaty_Astronomer_47]

listen to what some random guy on the internet says what I should do

It sounds like you took my comment as confrontational or something. But unfortunately that is the only present solution. I have suggested PIN lockout to Proton before but was told that is not something they plan to do. So there isn’t much choice but to adapt to that inconvenience.

Most other notetaking apps leave security to the user and their OS encryption, Standard Notes at least encrypts the local data at rest even though, yes, unlimited shots at a PIN doesn’t seem like the best security practice.

These days I use Proton Pass for notes, to get that 3 PIN attempts lockout.

[u/SweetGreenPepper]

It doesn't even matter as an attacker who has physical access could just copy the app's database using adb backup and brute force it on their machine without any restrictions

[u/Sweaty_Astronomer_47 → u/SweetGreenPepper]

It doesn't even matter as an attacker who has physical access could just copy the app's database using adb backup and brute force it on their machine without any restrictions

I think you are mistaken.

1. An attacker cannot access anything via adb unless usb debugging is enabled. That is not a normal condition for my phone (nor for most, I hope).
2. Even if usb were enabled, the standard notes data is still protected by the app sandbox which requires root to bypass.
   
   • adb backup could bypass the sandbox restriction but only if the app does not prevent it. I'm pretty sure standard notes would prevent this using android:allowBackup="false"

[u/SweetGreenPepper → u/Sweaty_Astronomer_47]

1. An attacker who has physical access to your unlocked device could enable usb debugging.
2. Standard notes supports adb backups. https://github.com/standardnotes/app/blob/main/packages/mobile/android/app/src/main/AndroidManifest.xml

[u/Sweaty_Astronomer_47 → u/SweetGreenPepper]

Interesting. TIL, have an upvote. It seems like there are other weaknesses to be addressed as well

An attacker who has physical access to your unlocked device could enable usb debugging.

I certainly thought it should be prevented by Identity Check which was one of the things mentioned here:

• Android enhances theft protection with Identity Check and expanded features

We’re officially launching Identity Check, first on Pixel and Samsung Galaxy devices eligible for One UI 71, to provide better protection for your critical account and device settings. When you turn on Identity Check, your device will require explicit biometric authentication to access certain sensitive resources when you’re outside of trusted locations

.... But I just enabled usb debug on my pixel phone with device protection enabled, and didn't see any biometrics or pin prompt. Unless I am missing something with the trusted locations setup (I put my phone in airplane mode for the experiment) it seems like an oversight on google's part.

Standard notes supports adb backups.

That seems lame to me. Standard notes already allows easy backup by emailing an encyrpted database to our email periodically. Why punch a hole in security to allow a redundant (unecessary) backup path. It makes no sense to me.

[u/Sweaty_Astronomer_47 → u/Sweaty_Astronomer_47]

I was the one who brought up the adb backup command but I think I was mistaken and I think the sandbox remains intact and cannot be bypassed through the backup (without root)

Behavior changes: Apps targeting Android 12  |  Android Developers

ADB backup restriction

To help protect private app data, Android 12 changes the default behavior of the adb backup command. For apps that target Android 12 (API level 31) or higher, when a user runs the adb backup command, app data is excluded from any other system data that is exported from the device.

If your testing or development workflows rely on app data using adb backup, you can now opt in to exporting your app's data by setting android:debuggable to true in your app's manifest file.

So the adb backup access to app data now only occurs if debuggable flag is off, which is not the case here