If you lost the password to an Android keystore but still have the .jks file, look for the password before you attack the file, because the signing config needs it and it is very often written down in your gradle.properties or keystore.properties, your CI secret variables, a password manager, or your build scripts. Brute-forcing your own keystore is legitimate but only realistic if the password was weak or you remember most of it, since a long random password is computationally infeasible to crack. If the password is truly gone and you use Play App Signing, you can reset the upload key, because Google holds the app signing key. A self-managed app signing key whose password is lost cannot be reset.
Short answer
A lost keystore password is more recoverable than a lost keystore file, because the key material is intact and you only need the passphrase that opens it. Start by searching every place the password could be stored, since Android signing configs need it at build time and most projects keep it in a properties file or a secret store. If that fails, an offline dictionary or mask attack on your own keystore can work when the password was weak or partly remembered, but not against a strong random one. If it is unrecoverable and you use Play App Signing, reset the upload key. Per Android's app signing docs, a self-managed app signing key cannot be reset if you lose access to it.
Lost password versus a lost or corrupted file
A lost password is a different problem from a missing or damaged keystore, and it is usually less severe. The .jks file still holds your signing key and certificate intact; what is missing is the secret that opens it. So none of the file-recovery work applies here, because there is nothing wrong with the file. The task is to find or recover the passphrase, and if you cannot, to fall back to the same reset path a lost file would need.
It also helps to know that a keystore has two kinds of password. There is the store password that protects the keystore as a whole, and each key inside has its own key password. In many Android setups the two are set to the same value, but not always, so a tool that accepts the store password can still fail at signing if the key password differs. Keeping this distinction in mind matters, because half of these incidents are really a case of knowing one password and trying it in the wrong place.
Where the password is probably written down
Because a build cannot sign without the password, most projects record it somewhere the build can read, which is the first place to look. Check your gradle.properties for storePassword and keyPassword entries, a separate keystore.properties or signing.properties file, and the signingConfig block or build scripts that reference them. Look in your local.properties and any developer setup notes. The password for the release key is required by the signing config, so it is frequently sitting in one of these files on the machine that builds releases.
Then check the places a team stores secrets deliberately. Your CI or CD system almost certainly holds the keystore password as a secret variable or masked environment value, since automated builds sign without a human typing it. A shared password manager or vault is the next candidate, followed by Fastlane configuration, and even your shell history if a build command once included it. Between the build-config files and the secret store, the password is recovered far more often than it is truly lost, so exhaust these before considering anything harder.
Brute force options
Because it is your own keystore, running an offline password attack against it is a legitimate recovery step, not an intrusion, and the outcome depends entirely on how strong the password was. The approach is to convert the keystore into a crackable hash and run a dictionary or mask attack: John the Ripper provides a keystore-to-hash helper for Java keystores, and hashcat supports the Java KeyStore format directly, so both can test candidate passwords offline against your file.
The realistic part is the constraint. If the password was a weak word, a short pattern, or something you remember most of, a targeted mask attack that fixes the parts you recall and varies only the rest can find it quickly. If it was a long random string from a generator, it is computationally infeasible and no tool will change that, so brute force is a real option only in the weak or partially-remembered case. Feed the attack everything you know, such as length, likely words, and character set, and treat it as a possibility rather than a guarantee.
The errors you will see
The exact error tells you whether the wrong password is the store password or the key password, which narrows where to look. The table below maps common messages to cause and next step.
| Error message | Likely cause | Action |
|---|---|---|
| keystore was tampered with, or password was incorrect | Wrong store password (file is intact) | Try other known passwords; search config |
| Cannot recover key | Wrong key password, right store password | Try the store password as the key password |
| Given final block not properly padded | Wrong key password during signing | Recover the key password specifically |
| Keystore password was incorrect (Gradle) | Config has an old or wrong password | Fix storePassword in gradle.properties |
Read the middle column as the split between the two passwords: a store-password error opens the file, while a key-password error blocks the actual signing.
Play App Signing reset
If you cannot recover the password and you are enrolled in Play App Signing, you are not locked out, because the key you can no longer use is only the upload key while Google holds the app signing key. Create a new upload key in a fresh keystore, this time recording its password in your secret store, export the new certificate to PEM format, and have your account owner request an upload key reset through the Play Console help form. After the reset, you sign uploads with the new upload key and Google keeps signing delivered updates with the unchanged app signing key.
This is why Play App Signing turns a forgotten password from a dead end into a support request. The upload key is a replaceable credential for getting builds into Play, so losing access to it, whether the file is gone or the password is, is recoverable. The app signing key that your installed app depends on stays safe with Google, so your users continue to receive updates without reinstalling.
If you self-manage the key
If you are not enrolled in Play App Signing and you manage the app signing key yourself, a lost password is as serious as a lost key, because without the password you cannot use the key to sign an update. Per Android's documentation, a self-managed app signing key cannot be reset if you lose access to it, and a password you cannot recover is exactly that loss. There is no second copy and no reset path outside Play App Signing.
In that case, if recovery and brute force both fail, the only way forward is to publish a new app under a new package name with a new key, which existing users must install as a separate listing rather than an update. Because that outcome is so costly, the takeaway for self-managed keys is to enroll in Play App Signing while you still have a working password, so a future lapse becomes an upload key reset instead of a lost app.
A safe retry path for your pipeline
Once you have recovered the password or reset the upload key, restore your pipeline in a way that prevents a repeat. Put the password into your CI or CD secret store and a password manager immediately, alongside the keystore backup, so the next build does not depend on anyone's memory. Then re-run the signing step and verify the result before uploading, using apksigner verify on the signed artifact to confirm it is properly signed.
Confirm the identity as well as the signature. Compare the certificate fingerprint of the signed build against the fingerprint Google Play expects for the app, so a wrong key or a mixed-up password is caught on your machine rather than at upload.
Prevent losing it again
Working through these steps keeps a forgotten password from blocking a release. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Store the password in a vault | Keep it in a password manager or secret store | [ ] |
| Keep it with the keystore backup | Back up the file and its passwords together | [ ] |
| Use CI secrets | Hold the password as a masked CI variable | [ ] |
| Avoid throwaway passwords | Do not set a release key password you will forget | [ ] |
| Document the store and key passwords | Note whether they differ | [ ] |
| Enroll in Play App Signing | So a lost upload key or password is resettable | [ ] |
The step teams skip most is enrolling in Play App Signing, which is what makes a future forgotten password a reset rather than a rebuild.
Where a scan fits
While you are moving the password into a proper secret store, it is worth checking that it and other signing secrets are not exposed in the app or repository, since a password in a committed file is both how you recover it and how it leaks.
A scanner like PTKD.com analyzes your build and flags issues such as signing passwords or keystores committed into the repo, hardcoded secrets, and over-broad permissions by severity, mapped to OWASP MASVS. To be clear about the boundary: PTKD does not recover your password or reset your upload key. It helps you confirm the password you just recovered is stored as a secret rather than sitting in a file that ships or leaks.
What to take away
- A lost keystore password is usually more recoverable than a lost file, because the key material is intact and you only need the passphrase.
- Search first: the password is very often in gradle.properties, keystore.properties, CI secret variables, a password manager, or your build scripts.
- Remember there are two passwords, the store password and each key password, and a tool can open the file yet still fail to sign if the key password differs.
- Brute-forcing your own keystore with John the Ripper or hashcat works only for a weak or partly-remembered password, never a long random one.
- If the password is truly gone and you use Play App Signing, reset the upload key; a self-managed key cannot be reset, so enroll in Play App Signing while your password still works.
