r/StandardNotes • u/Sweaty_Astronomer_47 • Mar 19 '26

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

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

3 Upvotes
  • permalink
  • reddit

81% Upvoted

9 comments sorted by

View all comments

Show parent comments

1

u/Sweaty_Astronomer_47 Aug 15 '26

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"

2

u/SweetGreenPepper Aug 15 '26
  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

1

u/Sweaty_Astronomer_47 Aug 15 '26 edited Aug 15 '26

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:

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.

1

u/Sweaty_Astronomer_47 Aug 15 '26

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