ahusan/fksar
1
0
Fork 0
forked from shihaam/thijooree
Code Pull Requests Activity

update docs

Browse Source
This commit is contained in:
shihaam
2026-06-13 21:30:12 +05:00
parent 281864347e
commit a8cd22cbe1
51 changed files with 1830 additions and 469 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/thijooree/02-lock-screen.md
+8 -4
View File
@@ -53,13 +53,17 @@ On mismatch the attempt counter increments and an error shake animation plays.
## Brute-Force Protection
Constants live in `LockActivity.kt:44-45`: `MAX_ATTEMPTS = 5`, `LOCKOUT_MS = 30_000L`.
| Threshold | Behaviour |
|---|---|
| 1–4 wrong attempts | Error label shown, counter visible |
| 5 wrong attempts | 30-second lockout; keypad/pattern disabled |
| After lockout | Counter resets; user may try again |
| 1–4 wrong attempts | Error label shows remaining attempts |
| 5 wrong attempts | 30-second lockout; further entries are rejected by `checkAndShowLockout()` until `LOCKOUT_MS` has elapsed since the last fail |
| After 30 s | Lockout expires (purely time-based, via `last_fail_time`) — the counter itself does **not** reset until a successful unlock |
The attempt counter and lockout timestamp are stored in **plain** `SharedPreferences` (not encrypted) — a known limitation documented in the security audit. The app does not wipe credentials after repeated failures.
The fail counter resets to zero only inside `resetFailures()` (`LockActivity.kt:313-315`), which is called from the success paths of biometric, PIN, and pattern entry. A user who repeatedly fails will hit the 30-second wait again on the very first failure after each lockout window expires.
The attempt counter and last-fail timestamp live in a dedicated `lock_attempts` `SharedPreferences` file (`LockActivity.kt:41`) — plain (not encrypted), which is a known limitation documented in the security audit. The app does not wipe credentials after repeated failures.
---