Encryption in a mobile app gives a false sense of safety when it is done with a weak algorithm or, worse, a key baked into the app. A hardcoded key is the classic example: the data is encrypted, the box is checked, but the key ships inside the binary where anyone can extract it, so the encryption protects nothing. Weak cryptography, outdated algorithms, custom schemes, predictable values, fails more quietly but just as completely. Here is what counts as weak crypto, why a hardcoded key voids your encryption, and how to do it right.
Short answer
Weak cryptography means using broken or outdated algorithms, custom-built crypto, or poor parameters, while a hardcoded encryption key means embedding the key in the app, where it can be extracted by decompiling the binary. Per OWASP MASVS, both defeat the purpose of encryption: a weak algorithm can be broken, and a hardcoded key lets anyone who recovers it decrypt your data, since the binary is not private. The fix is to use strong, standard algorithms from the platform's crypto libraries, never roll your own, and manage keys through the device's secure key store rather than embedding them. Encryption only protects data when both the algorithm and the key handling are sound.
What you should know
- Weak algorithms can be broken: outdated or custom crypto is not safe.
- A hardcoded key voids encryption: it ships in the binary and is recoverable.
- Do not roll your own crypto: use vetted platform libraries.
- Manage keys in the secure store: the Keystore or Keychain, not the code.
- Both the algorithm and the key matter: either one weak breaks the protection.
What counts as weak cryptography?
Anything that makes the encryption breakable or predictable. That includes using outdated or broken algorithms, such as MD5 or SHA-1 where a secure hash is needed, DES, or a weak cipher mode like ECB that leaks patterns; using key sizes that are too small; reusing or using predictable initialization vectors; and, most commonly among small teams, writing your own cryptographic scheme instead of using a vetted one. Custom crypto is a particular trap, because it usually looks like it works, encrypting and decrypting correctly, while being trivial for an expert to break. The common thread is that the encryption appears to function but does not actually provide the secrecy it implies, which is exactly why weak cryptography is on the list of critical mobile risks.
Why does a hardcoded key void your encryption?
Because the key ships with the lock. The table makes the failure concrete.
| Practice | Result |
|---|---|
| Strong algorithm, key in the secure key store | Data is protected |
| Strong algorithm, key hardcoded in the app | Key is recoverable; encryption is void |
| Weak or custom algorithm | Breakable regardless of key handling |
| Key bundled alongside the ciphertext | Anyone with the app can decrypt |
The hardcoded-key case is the one developers underestimate. Because an app's binary can be decompiled and its strings extracted, a key embedded in the code or resources is recoverable in plain form, so an attacker who pulls the key can decrypt anything it protected. Encrypting data with a key that ships in the same app is like locking a door and taping the key to it. The algorithm can be perfect and the protection is still zero, which is why key management, not just the cipher, determines whether your encryption means anything.
How do you do mobile cryptography right?
Use strong standard algorithms and keep keys in the platform's secure store. Choose vetted, current algorithms, authenticated encryption such as AES in GCM mode with an adequate key size, and a secure hash where hashing is needed, from the platform or a reputable crypto library, rather than writing your own. Generate keys properly and store them in the device's secure key management, the Android Keystore or the iOS Keychain and Secure Enclave, so the key is not embedded in the app and ideally never leaves secure hardware. Use a fresh, random initialization vector per encryption, and avoid insecure modes. Where data does not need to live on the device at all, keep it server-side instead. The principle is that strong crypto plus sound key management is what protects data; either one done poorly undoes the other.
What to watch out for
The first trap is a hardcoded key, which makes encryption decorative since the key is recoverable from the binary; keys belong in the secure key store. The second is custom or outdated crypto, which can look functional while being breakable; use vetted standard algorithms. The third is good intentions undermined by detail, a reused IV, ECB mode, or a tiny key size, so the parameters matter as much as the algorithm name. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK, AAB, or IPA against OWASP MASVS and surfaces weak algorithms and hardcoded keys in your build, so you can find these before they ship. Moving keys to the secure store and switching to strong algorithms is the fix.
What to take away
- Weak cryptography, broken or custom algorithms and poor parameters, and a hardcoded encryption key both defeat the purpose of encryption.
- A hardcoded key ships in the binary and is recoverable, so it voids the protection no matter how strong the algorithm is.
- Use vetted, current algorithms like authenticated AES with adequate key sizes and fresh random IVs, and never roll your own crypto.
- Manage keys in the Android Keystore or iOS Keychain rather than the code, and use a pre-submission scan such as PTKD.com to find weak crypto and hardcoded keys.
