Owasp on Lessons learned

Offline login in an iOS or Android app: design it as offline unlock

Tue, 03 Nov 2026 18:00:00 +0100

A product request for “offline login” in a mobile app with a cache of sensitive data (customer invoices, HR records, patient notes, credentials) sounds like one feature. On a phone with no network, nothing can check the password against the server, apply MFA, or learn that the device was revoked yesterday. What the app can do is prove a local factor to a device that was enrolled earlier and release keys for ciphertext already on it:

offline login: authenticate the user, apply policy, authorize data (impossible offline)
offline unlock: prove a local factor, release keys for cached data (what you can build)

I researched how to build the second one on iOS and Android. This post collects the parts that are easy to get wrong: where the password path needs a hardware key, why a biometric prompt without a CryptoObject is only a boolean check, which clock keeps counting while the phone sleeps, and what changes for users who have no password at all. It is longer than a usual post here, because the traps sit in different layers.

What an offline unlock can and cannot prove

A connected sign-in lets the server authenticate the user and the device, require MFA, evaluate current policy and revocation, and send newly authorized data. An offline unlock does none of that. So it must never renew a server session, refresh authorization, or make cached data look current. Label the action “Unlock” in the UI and keep “Sign in” for the server. Show “Last checked” (policy) and “Last synchronized” (data) separately, because a recent local unlock is neither.

The trade-off between availability and revocation is unavoidable. While the device is disconnected, a revocation event cannot reach it, and plaintext it already showed cannot be recalled. A long offline window helps users during outages and travel. It also lets a lost or deauthorized device keep unlocking its cache until the window expires or the device reconnects. Pick a maximum offline age per threat model, make it visible, and apply revocation before any sync or key release at the next connection. Managed users should get an administrator-set finite limit. If you offer an unlimited consumer mode, tell the user that remote revocation and policy changes wait for the next reconnect.

First use of a device is always a connected sign-in. It enrolls the device, downloads the encrypted state, and creates the local unlock material. A device that was never provisioned online must never create offline capability, and a network error must never let you skip a required connected step.

A state machine where a stale device never prompts

Write the states down, so a missing transition shows up in review:

UNENROLLED
 └─ connected sign-in + MFA + policy + initial sync ─▶ LOCKED_CURRENT

LOCKED_CURRENT
 ├─ freshness valid, then valid local factor ────────▶ UNLOCKED
 ├─ successful check-in ─────────────────────────────▶ LOCKED_CURRENT (freshness renewed)
 ├─ freshness expires ───────────────────────────────▶ LOCKED_STALE
 ├─ check-in reports device/user revocation ─────────▶ UNENROLLED
 └─ logout/user removal ─────────────────────────────▶ UNENROLLED

UNLOCKED
 ├─ timeout/background/device lock/manual lock ──────▶ LOCKED_CURRENT
 ├─ successful check-in ─────────────────────────────▶ UNLOCKED (freshness renewed)
 ├─ freshness expires ───────────────────────────────▶ LOCKED_STALE
 ├─ check-in reports device/user revocation ─────────▶ UNENROLLED
 └─ logout/user removal ─────────────────────────────▶ UNENROLLED

LOCKED_STALE
 ├─ successful connected reauthentication/check-in ──▶ LOCKED_CURRENT
 ├─ check-in reports device/user revocation ─────────▶ UNENROLLED
 └─ logout/user removal ─────────────────────────────▶ UNENROLLED

A check-in is any authenticated server call that returns current policy, revocation state, and server time. A background call with a refresh token is enough. If policy also wants full reauthentication with MFA after some maximum age, put that in the policy record, not in app logic.

Evaluate freshness before asking for a factor. A stale device shows the reconnect screen and never runs the password KDF, a PIN check, or a biometric prompt. When the window has expired, a biometric prompt that is bound to fail, followed by a generic “wrong password” error, tells the user nothing about the fix.

Losing one local factor does not change state. When a biometric wrapper is invalidated, or the PIN hits its threshold, delete that wrapper and continue with the others.

Wrap keys; never encrypt data with the password

Use envelope encryption:

Generate a random 256-bit account data key (ADK).
Generate a random key per record and per file and wrap each under the ADK. Do not derive them from the ADK. A derived key can always be derived again, so you cannot destroy or rotate it for one object without rotating the ADK.
Encrypt record fields, search indexes, file metadata, thumbnails, and file content with an AEAD: AES-256-GCM or ChaCha20-Poly1305.
Wrap the ADK once per unlock method: password, biometric, optional PIN, recovery key.
Encrypt the password and PIN wrappers a second time under a non-exportable hardware key that needs no user authentication: Secure Enclave on iOS, Android Keystore on Android.
Put version, algorithm, KDF parameters, key ID, account, object ID, field ID, and purpose into the authenticated data.

The field ID in step 6 looks like overkill until a field moves. If an attacker can swap the bank-account field of supplier record A with that of record B and the AEAD still verifies, the app shows a payment destination nobody entered for that supplier. In an autofill provider, the same swap between URL fields offers entry A’s password to site B.

A whole-database encryption layer can hide metadata and WAL contents. It does not replace per-field AEAD, because it usually protects only while the database is closed.

Why the password path needs the device too

The threat model that changes the design is the attacker with a copied sandbox or backup. Assume they hold the database, salts, KDF parameters, wrapped keys, and preferences. If the password wrapper is only KDF(password), they can run the KDF on GPUs, away from the device, for as long as they like.

Step 5 fixes that. With the wrapper sealed by a device key that never leaves the Secure Enclave or Keystore, every guess has to run on the original phone, at its speed. The KDF becomes the second barrier, not the only one. A secret stored in plaintext next to the copied files is not a second factor and does not count as one.

For the KDF itself:

Prefer Argon2id with a random salt and versioned parameters, benchmarked on the weakest supported device. It is not part of CryptoKit, CommonCrypto, or the standard Android crypto APIs, so it is a third-party dependency with its own review, pinning, and update process.
If you have to use PBKDF2, both platforms ship it: CCKeyDerivationPBKDF and SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256"). Calibrate the iteration count on real devices instead of copying one from another project.
Store the parameters with the envelope and migrate them after a successful unlock.
Derive separate keys for local wrapping and for any protocol authentication, with domain separation.
On iOS, hold keys in CryptoKit SymmetricKey, which zeroes its storage on release, not in Data that the runtime may copy. A password captured as a Swift String cannot be wiped; turn it into bytes for the KDF right away.

KDF cost does not stop a patient person typing guesses into the unmodified app, so add an increasing delay and a persisted failure counter, and require a connected sign-in after a threshold.

A six-digit PIN is a million candidates

An app PIN is a convenience secret in front of the password. It unlocks its own envelope, and that envelope has to be bound to a non-exportable platform key. Six digits are 10^6 candidates. An unbound PIN envelope falls to offline search, whatever the KDF costs.

The rest of the PIN rules:

At least six digits; off by default for high-assurance or managed profiles.
Never store a PIN verifier that is cheaper to attack than the envelope.
A failure counter scoped to the user that survives process death and reboot, with increasing delay and at most 10 consecutive failures, the upper bound NIST SP 800-63B sets for activation secrets.
At the threshold, delete the PIN wrapper and ask for the password. Wiping the local data would destroy the only copy of anything not yet synced.

The catch: neither iOS nor Android enforces a retry limit in hardware for an app-defined PIN. NIST’s limit assumes the authenticator enforces it, and here the app does. The counter stops the user and a thief using the unmodified app. On a rooted or jailbroken device, an attacker can query the platform key directly at hardware speed, and only PIN length helps against that.

The biometric prompt must unlock a key

Biometric success has to authorize the cryptographic operation that unwraps the ADK. If it only flips an isAuthenticated flag, a hooked callback on a rooted device skips it.

Android: pass a `CryptoObject`

Generate the key inside Keystore and require authentication for every use:

val spec = KeyGenParameterSpec.Builder(
 "offline-data-wrap",
 KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT,
)
 .setKeySize(256)
 .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
 .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
 .setUserAuthenticationRequired(true)
 .setUserAuthenticationParameters(0, KeyProperties.AUTH_BIOMETRIC_STRONG) // API 30+: every use prompts
 .setInvalidatedByBiometricEnrollment(true)
 .setUnlockedDeviceRequired(true) // API 28+
 .setIsStrongBoxBacked(true) // API 28+; on StrongBoxUnavailableException, retry in the TEE
 .build()

KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
 .apply { init(spec) }
 .generateKey()

Then hand the initialized cipher to BiometricPrompt, and decrypt only with the cipher you get back:

val cipher = Cipher.getInstance("AES/GCM/NoPadding")
try {
 cipher.init(Cipher.DECRYPT_MODE, wrappingKey, GCMParameterSpec(128, envelope.iv))
} catch (e: KeyPermanentlyInvalidatedException) {
 deleteBiometricWrapper() // enrolled biometrics changed: fall back to the password
 return
}

val prompt = BiometricPrompt(activity, executor, object : BiometricPrompt.AuthenticationCallback() {
 override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
 val unlocked = result.cryptoObject!!.cipher!!
 unlocked.updateAAD(envelope.aad)
 val adk = unlocked.doFinal(envelope.ciphertext)
 // ...
 }
})

prompt.authenticate(
 BiometricPrompt.PromptInfo.Builder()
 .setTitle("Unlock offline data")
 .setAllowedAuthenticators(BiometricManager.Authenticators.BIOMETRIC_STRONG)
 .setNegativeButtonText("Use password")
 .build(),
 BiometricPrompt.CryptoObject(cipher),
)

Set the accepted authenticators explicitly. A default that includes DEVICE_CREDENTIAL means the device PIN opens the offline data, and so does anyone who watched the owner type it. If you want that fallback, make it a written product decision. Since this is a symmetric key with authentication required, creating the wrapper at enrollment also needs a prompt; ask for the password first, as with any new factor.

iOS: a Secure Enclave key and ECIES

Generate the wrapping key in the Secure Enclave with biometric access control, and wrap the ADK with ECIES:

var error: Unmanaged<CFError>?
let access = SecAccessControlCreateWithFlags(
 nil,
 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, // the OS deletes it if the passcode is removed
 [.privateKeyUsage, .biometryCurrentSet], // no passcode fallback
 &error
)!

let attributes: [String: Any] = [
 kSecAttrKeyType as String: kSecAttrKeyTypeECSECPrimeRandom,
 kSecAttrKeySizeInBits as String: 256,
 kSecAttrTokenID as String: kSecAttrTokenIDSecureEnclave,
 kSecPrivateKeyAttrs as String: [
 kSecAttrIsPermanent as String: true,
 kSecAttrApplicationTag as String: Data("offline-data-wrap".utf8),
 kSecAttrAccessControl as String: access,
 ],
]
let privateKey = SecKeyCreateRandomKey(attributes as CFDictionary, &error)!

let wrapped = SecKeyCreateEncryptedData(
 SecKeyCopyPublicKey(privateKey)!,
 .eciesEncryptionCofactorX963SHA256AESGCM,
 adk as CFData,
 &error
)

To unwrap, fetch the key with a fresh LAContext passed as kSecUseAuthenticationContext, with touchIDAuthenticationAllowableReuseDuration left at 0, and call SecKeyCreateDecryptedData. The prompt the user sees then authorizes this key use. That is the iOS counterpart of Android’s per-use authentication.

Two details to get right:

The accessibility class goes into SecAccessControlCreateWithFlags. It cannot be combined with a separate kSecAttrAccessible attribute on the same item.
.biometryCurrentSet invalidates the key when Face ID or Touch ID enrollment changes. Handle that by deleting the wrapper and requiring the password. A .devicePasscode or .userPresence fallback lets anyone who knows the device passcode into the offline data.

Data Protection classes that fail after lock

Set a Data Protection class per store instead of relying on container defaults. The complete class key is discarded about 10 seconds after the device locks, which bites in three places:

Plaintext temporaries should use complete.
Background downloads of offline files need completeUnlessOpen.
A SQLite database in WAL mode under complete fails when anything touches it after lock. Either stop database access on protectedDataWillBecomeUnavailable, or use completeUntilFirstUserAuthentication for the database and rely on field-level AEAD.

Files in tmp/ and elsewhere in the container default to completeUntilFirstUserAuthentication unless you set otherwise.

Offline expiry needs a clock that counts sleep

Enforcing maximum offline age with wall-clock time alone fails the moment someone sets the clock back. I covered that half in An offline cache TTL needs a clock-rollback policy . The research added three things.

The freshness record has two parts. A server-signed part (check-in time, policy version, expiry duration), verified with the server’s public key. A local part (wall time at check-in, monotonic time at check-in, boot reference, accumulated elapsed time), authenticated with a keystore device key. Do not protect it with the ADK: freshness is evaluated before accepting any factor, so the record must verify while the app is locked.

The monotonic clock must keep counting while the phone sleeps, because a phone is asleep most of the time:

Platform	Use	Stops during sleep
iOS	`mach_continuous_time()`, `clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW)`	`mach_absolute_time()`, `ProcessInfo.systemUptime`
Android	`SystemClock.elapsedRealtime()`	`SystemClock.uptimeMillis()`

Verify the chosen clock on a device by letting it sleep.

Reboots reset the monotonic clock. Android has Settings.Global.BOOT_COUNT. iOS has no documented boot identifier: kern.boottime moves when the user changes the wall clock, so it detects clock changes, not boots. On iOS, detect a reboot by a monotonic reading lower than the stored one. Then:

update accumulated elapsed time on every foreground, unlock, and lock

same boot: elapsed from the monotonic clock, cross-checked against wall time
after reboot: elapsed = max(accumulated + monotonic_since_boot,
 wall_now - wall_at_checkin)
wall_now < last stored wall time → rollback → stale

A rollback across a reboot can then hide at most the time between the last update and the reboot.

Fail closed on a missing, rolled-back, or inconsistent record, and exclude it from backup. A restore, to another device or to the same one, then leaves the record missing and forces a check-in. Otherwise, a same-device restore brings back an older valid record together with the ThisDeviceOnly Keychain items it belongs to.

These controls resist clock rollback, not state rollback. Nothing stops someone from replacing the current record with an older valid copy, and the expiry is application logic. Like the PIN counter, it binds the unmodified app, not an attacker running their own code against the device keys.

Documents: chunked AEAD and plaintext that outlives the app

Offline documents, such as invoice PDFs or scanned contracts, need more than per-record encryption. CryptoKit’s AES.GCM and ChaChaPoly seal a whole message in memory. Streaming playback and seeking viewers need chunks, and naive chunking lets an attacker truncate, reorder, or drop chunks without failing authentication. Use a format in the style of the STREAM construction:

fixed-size chunks (say 64 KiB), each sealed separately;
a nonce built from a random per-file prefix and the chunk index;
file ID, format version, chunk index, and a final-chunk flag in each chunk’s authenticated data;
an authenticated header with the prefix, chunk size and version;
a new per-file key or nonce prefix whenever the file changes, so no key and nonce pair is ever reused.

Prefer decrypting into memory or a pipe for an in-app viewer. QLPreviewController wants a file URL, so some formats force a plaintext file. When one is unavoidable, put it in a dedicated private directory under complete, with an unpredictable name, excluded from backup and indexing, shared only through a narrow, non-exported FileProvider grant on Android.

The trap is cleanup. A suspended iOS app runs no code, so no timer deletes the file on schedule, and cancellation, render errors, crashes, process death, and reboot all skip view-level cleanup. Make the launch path enumerate and delete expired temporaries before it allows an unlock.

Lock, logout, and Keychain items that survive uninstall

Lock keeps the encrypted state and destroys the usable keys: release the ADK and derived keys, close plaintext streams, blank the app-switcher snapshot, invalidate decrypted caches, and stop background jobs from quietly recreating an unlocked session. A suspended app cannot clear the clipboard later, so set the expiry when you copy:

UIPasteboard.general.setItems(
 [[UTType.utf8PlainText.identifier: secret]],
 options: [.localOnly: true, .expirationDate: Date().addingTimeInterval(60)]
)

.localOnly keeps it off Universal Clipboard. On Android, mark the clip with ClipDescription.EXTRA_IS_SENSITIVE (API 33+) and clear it with ClipboardManager.clearPrimaryClip().

Logout makes the state permanently unusable. Physical overwrite on flash is unreliable, so the primary boundary is cryptographic erasure: destroy every usable wrapping key, then delete tokens, databases with their WAL and journal files, indexes, cached files, temporaries, pending operations, and shared-container state.

On iOS, uninstalling the app deletes its container but leaves its Keychain items, and no app code runs during uninstall. Keep a marker file in the container. When it is missing at launch, delete every Keychain item the app owns, shared access groups included, before doing anything else. Otherwise, a reinstall can find the previous install’s wrappers.

Autofill is offline unlock under another name

If the cached data includes credentials and the app offers an autofill provider, that provider releases secrets from the local cache with no server call, so every rule above applies to it. The platforms constrain it differently.

On iOS, the Credential Provider extension is a separate process with its own unlock session. It sees the app’s state only through a shared Keychain access group and an App Group container, so every key and wrapper it needs, including the Secure Enclave device key and the freshness record, must live in the shared group. It runs under a memory limit Apple describes as only slightly lower than an app’s. That limit caps the Argon2id memory parameter, so benchmark inside the extension on the weakest device. Do not give the extension a cheaper copy of the password envelope: the weakest wrapper sets the strength of all the data it protects. If parameters that fit are too weak, let the extension offer biometrics only and send password users to the app.

An LAContext evaluated in the app does not carry over to the extension. Within one request, the extension can pass one evaluated context to several Keychain reads, so a single prompt covers a list. The system may reuse the extension process for the next request, so nothing decrypted may stay in a static.

On Android, the AutofillService runs in the app’s own process unless the manifest says otherwise. Its authentication activity still needs a CryptoObject, and it should accept the same authenticators as the app.

Rules for both:

Give the provider its own key that wraps only what a fill needs (username, password, URL), so a faulty extension cannot decrypt documents, notes, or indexes.
Share the failure counter between app and provider. Otherwise, an attacker doubles the allowed attempts by alternating between them.
The provider reads freshness and never checks it itself. When stale, it fills nothing and says which app to open.
On iOS, the identity store shows registered usernames next to their domains in the QuickType bar to anyone holding the unlocked phone, with the app locked. Replace the whole identity set after each sync instead of removing and re-adding the current ones, so deleted entries disappear, and consider a managed policy that registers none.

Verify who is asking

The requester check is where autofill phishing happens (Aonzo et al., Phishing Attacks on Modern Android, CCS 2018 ). iOS identifies websites and apps through associated domains. On Android, the provider has to do it:

Verify the requesting app’s signing certificate against the domain’s Digital Asset Links , not its package name. An app named com.examplebank.evil is not Example Bank.
Trust browsers by package name and certificate digest together. On a device without a listed browser, a sideloaded app can take that browser’s package name and report any web domain.
Derive registrable domains from the Public Suffix List , not a hand-written list of suffixes. Otherwise, an entry saved for victim.github.io collapses to github.io and fills in attacker.github.io.

Users without a password

Everything above assumes every user has a password. Users who sign in through enterprise SSO or a partner’s authenticator app do not. In this design, the password has five jobs:

the baseline wrapper of the ADK;
the fallback when a biometric wrapper is invalidated;
the authorization for a new biometric wrapper;
the replacement when the PIN hits its threshold;
the recent password entry that sensitive actions require.

Each job needs a new owner. The options I found:

Connected sign-in takes every fallback role. This one always applies. A user who loses their last local factor while offline has no offline access until they reconnect.
A mandatory app passcode becomes the baseline factor. Set it during connected provisioning and wrap the ADK with it like the password (KDF, then device key). Three PIN rules change. Six digits stop being enough, because nothing stands behind the passcode: at 0.5 seconds per guess on a compromised device, 10^6 candidates take under six days. Allow alphanumeric passcodes with a real minimum length. The threshold sends the user to connected sign-in, and choosing a new passcode needs one too. The user gets a second secret to remember; that is the price of an offline knowledge factor.
The device passcode can back up the biometric wrapper. It avoids losing offline access at the first biometric change and reopens the “watched the owner type it” risk. Make it explicit, let administrators forbid it, and check on a device whether iOS still releases a biometryCurrentSet or devicePasscode item through the passcode after enrollment changes.
A recovery key can have enough entropy that a copied wrapper is safe even without device binding. Users lose these, and nobody can reset one, so offer it only where a lost factor can cost data.

What does not work is anything the identity provider issued. A cached refresh token or ID token proves the device holds a token, not that the user is holding the device. Don’t wrap the ADK under it, and delete the identity provider’s token cache after the server exchange.

Check one thing in your own protocol. If the server opens a passwordless user’s data without any secret from the user, it can provision the ADK again at the next sign-in. A lost factor then costs offline access, not data, as long as offline records stay read-only. Unsynced offline edits are the exception, because they exist only on the device.

Decide the factor set at provisioning from the login method, and store it with the policy. If the same user later provisions through a password login, re-enroll; don’t bolt a password wrapper onto a passwordless enrollment.

Caveats

The ADK’s scope is a protocol decision. If the ADK only protects this device’s cache, logout and revocation destroy it. If it is the user’s end-to-end key shared with the server and other devices, a device revoked while offline keeps a copy that decrypts future data, and revoking it means rotating the key.
Offline edits are a separate project. Ship read-only offline records first. Editable mode needs an encrypted operation log separate from server-confirmed state, conflict rules that keep both versions when a merge could lose data, and an authorization recheck for each operation on reconnect.
On rooted and jailbroken devices, hardware-backed keys and integrity signals raise the cost. Retry counters and expiry are app logic and don’t bind an attacker who runs their own code against the keys. Don’t claim otherwise.

Test the failure paths

Happy-path testing says nothing about whether keys and plaintext stay contained. The release gates I would not skip:

Area	Test
Provisioning	A never-enrolled device fails offline; restoring a backup to another device, or an older backup to the same one, forces a check-in
Crypto	Copied password and PIN wrappers cannot be opened off the device; ciphertext swapped between records or between fields of one record fails authentication
Biometrics	Add and remove enrolled biometrics, change and remove the passcode, reboot, process death
Retries	Counters survive relaunch and reboot; the PIN threshold removes only the PIN wrapper
Freshness	Clock forward and back, time zone change, reboot, a long sleep counted toward expiry, a replayed older record, the exact boundary; a stale device never prompts
Documents	Truncated, reordered, and dropped chunks fail; kill the app mid-preview and confirm the temporary is gone before the next unlock
Deletion	Uninstall and reinstall leave no usable Keychain state; removing one user leaves another intact
Autofill origin	A look-alike package name gets no match; `victim.github.io` is not offered on `attacker.github.io`

OWASP MASVS and MASTG , NIST SP 800-63B , NIST SP 800-132 for PBKDF2, and RFC 9106 for Argon2id set the baseline. They don’t decide where your keys live or what happens when a preview crashes.

Takeaway

Offline, the app can only answer “is this the enrolled user, on the enrolled device, within the allowed window?” Every unlock path, including the password, should require the device’s hardware key; every biometric prompt should gate a key operation; and the window should be measured by a clock that keeps counting while the phone sleeps.

If your app already has an offline mode, copy its sandbox to another machine and try to open the password wrapper there. If that attempt gets as far as a KDF, the password path is missing its device key.

iOS jailbreak protection in 2026: detection is a risk signal, not a security boundary

Mon, 26 Oct 2026 23:20:00 +0100

An iOS app had jailbreak detection, passed an external pentest, and still spent more than a year accepting every jailbroken device because an asynchronous result was discarded. After that bug was fixed, the checks were still a 2025 list of Cydia-era paths that missed current rootless and hidden jailbreaks.

If the requirement says “the app must not run on a jailbroken phone,” the useful answer in 2026 is not a longer path list. Treat jailbreak detection as a bypassable risk signal, decide what sensitive operation the signal protects, enforce that decision at the server where possible, and test the whole policy against current jailbreak and bypass tools.

The short version

A defensible implementation today has five parts:

Write a threat model that explains why a compromised device materially changes this app’s risk.
Combine independent local signals and run them near sensitive operations, not only at launch.
Apply a proportional policy: observe, step up, restrict sensitive data, or refuse service according to confidence and impact.
Put the final authorization decision on a server and use App Attest to protect app-to-server requests. Do not call App Attest to prove that a device is not jailbroken.
Test the release binary statically, dynamically, and by trying to bypass it on representative clean and jailbroken devices.

This is also the difference between “the code contains a jailbreak check” and an engineering conclusion that can survive review.

How a working check silently stopped working

The first implementation was conventional:

sysctl checked P_TRACED and terminated a release build under a debugger;
known paths such as /Applications/Cydia.app, /bin/bash, /usr/sbin/sshd, and /etc/apt were checked;
the app tried to write /private/jailbreak.txt outside its sandbox;
cydia:// was passed to canOpenURL;
loaded Mach-O images were searched for MobileSubstrate.

It ran only in non-Debug builds on physical devices. That was sensible, and the pentest team verified it.

One probe had never worked in the affected app targets: canOpenURL returns false for schemes that are not declared under LSApplicationQueriesSchemes, and cydia was not declared. An app extension could not use UIApplication.shared at all. Current IOSSecuritySuite also removed the cydia:// check because an App Store app registered the scheme and caused false positives. URL-scheme probes are weak evidence even when configured correctly.

Then the check moved behind a function that started a Task, returned from the function immediately, and ignored the task’s Bool. The user interface always received true. The debugger check still appeared to work because fatalError happened inside the task, masking the control-flow bug. Later refactors moved the broken call without changing its behavior.

The eventual fix was not another jailbreak signature. It was to make validation genuinely asynchronous, await it, and test the production call site as well as the checker.

That history produced three reusable lessons:

Test enforcement, not just detection. A perfect signal whose result is ignored protects nothing.
Test every app entry point and extension. The main app, credential provider, widget, and background path do not necessarily share a process or API surface.
Test the release configuration on hardware. A Debug simulator test proves code structure, not production behavior when the checks are compiled out there.

When OWASP says to implement jailbreak detection

OWASP MASTG 2.0, released in July 2026 , makes the trade-off unusually explicit. MASTG-BEST-0030 is currently tagged Android and says “root detection,” but its risk principle applies directly to the equivalent iOS control: it is a bypassable, cost-raising environment signal. It should be used only when compromised-device risk materially affects the app. The selection and response should follow the threat model and risk tolerance.

That points toward jailbreak protection when a compromised platform makes a concrete abuse case easier, for example:

extracting high-value secrets or regulated data from the app process or local cache;
instrumenting transactions, credential filling, cryptographic operations, or fraud controls;
changing a game, licensing, payment, or content-access decision made locally;
automating a protected API through a modified client;
defeating controls that depend on the sandbox, Keychain access policy, or trusted user interaction.

It does not make jailbreak detection a universal mobile-app baseline. A low-risk public-content app may gain little while inheriting false positives, support work, accessibility problems, and an exclusion policy it cannot reliably enforce.

MASVS-RESILIENCE-1 states the security concern: many other controls assume that the platform’s sandboxing, secure storage, and biometrics can be trusted. But the wider MASVS resilience guidance treats anti-tampering and runtime self-protection as defense in depth, never a replacement for the baseline security architecture.

The current techniques are rootless and designed to hide

The old signature list described rootful Cydia and MobileSubstrate installations. Current jailbreaks changed the filesystem layout and then added explicit concealment.

Dopamine is a rootless jailbreak. Its bootstrap commonly appears below /var/jb, with ElleKit providing tweak injection. Dopamine 1.1 introduced JB_ROOT_PATH in the environment of processes with tweaks enabled, while noting that /var/jb might become optional to impede detection. Palera1n has its own loader and helper artifacts. Frida may appear as frida-server, Frida Gadget, a loaded image, or merely runtime behavior after its obvious names have been changed.

At the time of this review, Dopamine’s current upstream release was 3.0.12, published October 20, 2026 . A signature inventory that stops at Cydia or even Dopamine 2 is already historical.

Dopamine 2.4’s release notes are the more important evidence: “Hide Jailbreak” was changed specifically to hide the jailbreak to the point where it should be undetectable. RootHide’s Dopamine integration randomizes the jailbreak root and selectively keeps jailbreak changes away from blacklisted apps. Its purpose is jailbreak-detection bypass.

A 2026 local detector should therefore look across different classes of evidence, for example:

rootful and rootless files, directories, symlinks, package-manager state, and randomized .jbroot-* roots;
whether the sandbox permits a collision-safe write to a protected path;
debugger state and failure of the debugger-status query itself;
suspicious environment keys such as DYLD_INSERT_LIBRARIES and JB_ROOT_PATH;
loaded images associated with Frida, ElleKit, Substrate, Substitute, libhooker, RootHide, or Dopamine’s system hook;
behavior that should be prohibited by the sandbox, where the API is appropriate for App Store software;
server-side anomalies and app-integrity assertions.

Use more than one API for important filesystem evidence. A FileManager.fileExists check, a POSIX lstat, and directory enumeration do not create certainty, but an attacker now has more hooks to maintain consistently.

Do not equate more signatures with “state of the art.” Public signature lists are useful coverage for unsophisticated and accidentally exposed jailbreaks. RootHide, renamed Frida components, or a patch to the function that aggregates all checks can make every local answer say “clean.” OWASP’s jailbreak detection knowledge article says the same thing: these defenses are not effective by themselves, although distributing them through the app increases the cost of bypassing them.

The response matters more than the Boolean

“Jailbroken: yes or no” is too weak a model for a fallible set of signals. Record an internal risk result with the evidence and confidence, then map it to a product policy.

Situation	Reasonable response
One weak or ambiguous signal	Telemetry, retry, or step-up authentication
Several independent local signals	Block sensitive operations; avoid disclosing the exact failed probe
Debugger or injected runtime tool in a high-risk flow	Refuse the operation and invalidate relevant server state
Unsupported App Attest on an otherwise supported device	Treat as a risk signal according to the documented policy
Enterprise-managed fleet with a strict posture requirement	Evaluate Managed Device Attestation at the relying service

OWASP recommends proportional responses and warns that aggressive lockout can affect legitimate users. For an app that stores documents and credentials, a useful soft block can allow login and folder metadata while refusing document bodies, downloads, offline queues, and credential release.

That restriction must be in application logic, not just a screen with a Close button. Better still, the server should not return the sensitive payload. Otherwise, a hook can dismiss the screen or call the same API directly.

A hard process exit is appropriate only if the threat model justifies denial of all functionality and the product accepts false positives. Crashing also gives poor observability and can turn an operational failure into a permanent lockout. A generic refusal with server-side telemetry is usually easier to operate.

App Attest authenticates app instances, not clean devices

Apple’s WWDC26 App Attest session describes the current protocol:

the server initiates enrollment and issues a challenge;
the app creates a Secure Enclave-bound key and attests it;
the server validates and stores the attestation and public key;
sensitive requests include a fresh server challenge in an assertion over the payload;
the server validates the signature and requires a strictly increasing counter to reject replays.

This is valuable. It lets the server distinguish a valid published app instance, detect unexpected signing or launch categories, and bind authorization to a payload that has not been altered in transit.

It is not a jailbreak oracle. The same 2026 session says that a compromised device can still pass attestations and broker valid attestations for modified clients. Apple provides the fraud metric to help detect that pattern. Use App Attest as another server-verified signal, with retry and onboarding policy for legitimate failures.

For managed organizational devices, Managed Device Attestation provides Secure Enclave-backed evidence about device identity and security posture. That is stronger input for a managed-fleet trust decision, but it is not a general capability that a consumer app can require from every unmanaged phone.

Test implementation, behavior, and bypass resistance

OWASP MASTG 2 separates two questions that teams often collapse into one.

MASTG-TEST-0240 is static: extract the shipped app package and inspect the binaries for jailbreak-detection mechanisms. This catches missing code, build flags that compiled it away, or a check that never reached a target. OWASP warns that automated static analysis is not exhaustive; manual reverse engineering may be necessary.

MASTG-TEST-0241 is dynamic: run the app, identify the checks, and try to bypass them. A test fails when detection is absent, but passing a single predefined bypass tool doesn’t prove resilience because its scripts may be incomplete or outdated.

For a real release, I would keep this matrix with the evidence from each run:

Test	Expected evidence
Clean supported iPhones and iOS versions	No false refusal; all sensitive flows work
Release build on physical hardware	Checks execute; Debug/simulator exclusions do not leak into the archive
Rootful and current rootless jailbreaks	Each applicable signal fires; policy is enforced
Dopamine Hide Jailbreak and RootHide blacklist	Document what remains visible and what becomes undetectable
Frida server and embedded/renamed Gadget	Known artifacts are detected; renamed forms challenge bypass resistance; outcomes are recorded
Hook the aggregate result and individual APIs	Sensitive server operation still requires valid authorization and assertions
Main app, extensions, background entry points	Each entry point validates before releasing its protected capability
Async and error paths	Results are awaited; query failures follow the documented fail-open or fail-closed policy
Pentest bypass configuration	It cannot enter a production archive; CI tests that invariant

Unit-test injected signals, cleanup failures, query failures, and clean-device results. Then add integration tests around the call site: the protected operation must not run after validation fails. Finally, let a tester attack the binary rather than merely demonstrating a known file on a jailbroken test phone.

A reviewable 2026 “lege artis” baseline

“State of the art” is not established by citing one library or by counting checks. For an engineering review, the conclusion should be reproducible, dated, scoped, and explicit about uncertainty. This is the practical baseline I would use when assessing whether an iOS app’s jailbreak protection was implemented with professional care in October 2026:

Define the question and date. State which app version, release configuration, iOS range, device classes, sensitive operations, and attacker capabilities are in scope. Practice changes as jailbreaks and iOS change.
Identify the risk before prescribing the control. Connect compromised-platform capabilities to actual assets and abuse cases. Explain why jailbreak detection materially affects this app.
Select authoritative and current sources. Record versions and access dates for OWASP MASVS/MASTG, Apple platform documentation, relevant jailbreak release notes, and the implementation under review. Treat public detection libraries as examples, not normative standards.
Preserve and identify the evidence. Record the source commit, archive hash, build settings, entitlements, tool versions, device/iOS versions, jailbreak version, and test logs. Work from a reproducible copy.
Separate facts from interpretation. “The production binary contains /var/jb and JB_ROOT_PATH checks” is a fact. “Those checks make bypass harder but cannot establish a clean device” is the interpretation supported by OWASP and current bypass projects.
Analyze the whole control path. Review signal collection, aggregation, async propagation, every entry point, the product response, server authorization, telemetry, and release-lane exceptions. Include negative findings and dead code.
Test both presence and effectiveness. Perform static inspection, clean-device compatibility tests, dynamic execution on relevant jailbreaks, and bypass attempts. A unit test or a pentest on one jailbreak version is not enough.
Consider alternatives and false positives. Explain why a detected artifact could be benign, why a missing artifact does not establish cleanliness, and why the chosen response is proportional.
State limitations. Local checks can be hooked or patched; hidden jailbreaks may expose no artifact; App Attest can succeed on a compromised device; the tested device set is finite.
Make a bounded conclusion. Say whether the examined implementation follows the documented risk policy and raises attacker cost for the tested scenarios. Do not conclude that it guarantees a non-jailbroken device.

This structure mirrors a sound software expert analysis: sources and methods are identified, observations remain distinguishable from interpretation, contrary evidence is not hidden, limitations reduce the stated certainty, and the conclusion answers only the technical question examined. It is guidance for an engineering assessment, not a legal conclusion about liability, contractual compliance, or negligence.

Takeaway

The old implementation failed twice: first because application control flow discarded a valid result, then because its threat model had aged past its Cydia-era signatures. The durable fix is a process—current layered signals, proportional server-enforced policy, and repeated adversarial testing—not a permanent isJailbroken function.

Take one sensitive operation in your app and trace it today from device signal to server authorization. If any step can ignore, hide, or locally override the result, that is the next protection to fix.

References

OWASP MASVS: Resilience against reverse engineering and tampering , accessed October 26, 2026.
OWASP MASTG 2.0.0 release announcement , July 4, 2026.
OWASP MASVS-RESILIENCE-1: Platform integrity , accessed October 26, 2026.
OWASP MASTG-BEST-0030: Implementing Root Detection , accessed October 26, 2026.
OWASP MASTG-KNOW-0084: Jailbreak Detection , accessed October 26, 2026.
OWASP MASTG-TEST-0240: Jailbreak Detection in Code , accessed October 26, 2026.
OWASP MASTG-TEST-0241: Runtime Use of Jailbreak Detection Techniques , accessed October 26, 2026.
Apple: Secure your apps with App Attest, WWDC26 , accessed October 26, 2026.
Apple Platform Security: Managed Device Attestation , accessed October 26, 2026.
Dopamine 2.4 release notes: Hide Jailbreak , February 16, 2025.
Dopamine 1.1 release notes: JB_ROOT_PATH , June 16, 2023.
Dopamine releases , accessed October 26, 2026.
Dopamine 3.0.12 release , October 20, 2026.
RootHide integration for Dopamine 3 , accessed October 26, 2026.
IOSSecuritySuite jailbreak checker , accessed October 26, 2026.

Adapt security skills to your project's risks: from Go to OWASP LLM and iOS

Sun, 25 Oct 2026 21:50:00 +0100

A security skill written for Go covers different questions than one written for an LLM application or an iOS app. I started with golang-security from samber/cc-skills-golang , asked Claude to adapt it using the OWASP Top 10 for LLM Applications, and later carried that approach into production iOS development.

The most useful part of the adaptation was aligning the review questions with the project’s risks and the company’s values.

Start with a review method

I was working in Go, a language I was unfamiliar with. I used my security skills alongside other Go skills to keep the implementation in check.

The security skill provided a repeatable method: separate modes for coding, reviewing changes, and auditing a codebase; questions about trust boundaries and attacker-controlled input; and instructions to trace data through surrounding code before reporting a finding. Its references and checklist gave the agent somewhere to look beyond the main instructions.

Adapt OWASP categories to the application

I asked Claude to create a new skill using the OWASP Top 10 for LLM Applications (2025) , adapted to the project’s LLM and Model Context Protocol (MCP) surfaces.

The resulting llm-security skill kept the review modes and evidence requirements. It mapped the categories to tools, resources, prompts, and content returned to the model. The Go checklist stayed active for the code underneath.

For prompt injection , the reviewer needs to identify whose text reaches the model and what an attacker can control. A returned document body or filename can carry instructions. For excessive agency , the questions concern tool permissions, reachable side effects, and authorization enforced outside the model.

Those questions give the agent a path through the repository. It can follow a tool result back to its data source, then follow a tool call forward to the operation it performs. The skill also asks it to account for existing protections when assessing impact.

Repeat the adaptation for iOS

Later, I applied the same approach to an iOS app using the OWASP Mobile Top 10 (2024) . That mobile security skill became part of production development.

The review method carried over. The mapping changed to platform APIs and the code responsible for them:

Mobile risk	Concrete review question
Improper credential usage	Where are tokens stored, and which Keychain access settings apply?
Insufficient input/output validation	What can a deep link or share-extension input cause the app to do?
Insecure data storage	Which protection classes apply to cached and temporary user files?
Inadequate privacy controls	Where can sensitive data appear outside its intended screen, including logs and notifications?

Repository context matters here. If a shared SDK owns authentication or networking, the skill needs to direct the reviewer into that SDK. Stopping at the changed Swift view would leave the relevant behavior unexamined.

For a mobile adaptation, MASVS supplies verification controls, and MASTG provides testing guidance for checking them.

Turn company values into review rules

Company values need concrete instructions too. For example, a company that prioritizes privacy can require reviewers to trace user data into logging, analytics, and crash reporting. That turns a broad preference into something an agent can inspect.

The mobile skill also records settled product decisions. An intentional tradeoff needs a rationale and the protections that still apply so that each review can assess the implementation against that decision. New evidence or changed assumptions can justify reopening it.

Severity needs the same local reasoning. OWASP provides risk categories; the product’s data, attacker access, and existing controls determine a finding’s impact.

A fresh adaptation request could be:

Use the existing security skill as a template. Keep its review workflow
and evidence requirements. Adapt the relevant OWASP categories to this
repository's entry points, data flows, and platform APIs. Link each check
to the responsible code and a primary reference. Record product decisions
with their rationale. Preserve the language-level checks alongside it.

Tailoring a security skill gives the agent concrete questions about the product it is building. Take one OWASP category in your current skill and map it to the code, data, and product decision the reviewer should examine.

Owasp on Lessons learned

Offline login in an iOS or Android app: design it as offline unlock

What an offline unlock can and cannot prove

A state machine where a stale device never prompts

Wrap keys; never encrypt data with the password

Why the password path needs the device too

A six-digit PIN is a million candidates

The biometric prompt must unlock a key

Android: pass a CryptoObject

iOS: a Secure Enclave key and ECIES

Data Protection classes that fail after lock

Offline expiry needs a clock that counts sleep

Documents: chunked AEAD and plaintext that outlives the app

Lock, logout, and Keychain items that survive uninstall

Autofill is offline unlock under another name

Verify who is asking

Users without a password

Caveats

Test the failure paths

Takeaway

iOS jailbreak protection in 2026: detection is a risk signal, not a security boundary

The short version

How a working check silently stopped working

When OWASP says to implement jailbreak detection

The current techniques are rootless and designed to hide

The response matters more than the Boolean

App Attest authenticates app instances, not clean devices

Test implementation, behavior, and bypass resistance

A reviewable 2026 “lege artis” baseline

Takeaway

References

Adapt security skills to your project's risks: from Go to OWASP LLM and iOS

Start with a review method

Adapt OWASP categories to the application

Repeat the adaptation for iOS

Turn company values into review rules

Android: pass a `CryptoObject`