CredentialsManagerException A change on the Lock Screen security settings have deemed the encryption keys invalid and have been recreated. Any previously stored content is now lost. Please, try saving the credentials again.

[shinejosephDev]

Description

Sometimes onFailure is invoked in getCredentials when the the app is in background for log time and resuming from there.

Reproduction

Keep the app in background for sometime say 1 hr then resume. App will restart based on the memory and then onFailureis invoked with following exception - com.auth0.android.authentication.storage.CredentialsManagerException A change on the Lock Screen security settings have deemed the encryption keys invalid and have been recreated. Any previously stored content is now lost. Please, try saving the credentials again.

But i didnt do anything with settings, bt still this comes up. This issue causes my app to logout all of sudden.

I'm not sure this issue has anything to do with keeping app in background, but only noticed in this case.

Environment

Usingimplementation 'com.auth0.android:auth0:1.15.2' OnePlus 6 with android 9

[lbalmaceda]

@shinejosephDev One plus is known for modifying the OS (ROM). Is this issue still happening to you? It's hard to reproduce on our end. It might be Android locking the device after some idle time and if that counts as changing the Screen Lock security, the keys will be invalidated.

[lbalmaceda]

Closing because of inactivity

[stephen1706]

Hi @lbalmaceda, I am facing the same issue at various phone (Samsung, Xiaomi, etc) and OS level as well on production, although I cannot reproduce it on my end. I don't think it only happen to someone who is changing their screen lock security as the occurrence number is quite high Error message returned when calling getCredentials:

The AES encrypted input is corrupted and cannot be recovered. Please discard it.

[lbalmaceda]

@stephen1706 the exceptions are supposed to be handled by you. The only two ways this strategy can fail is if the device is not compatible or if the keys have changed for X reason. The first one is your cue for falling back to a different strategy. But when the second one happens, the keys are removed and the next time you perform the operation, they are recreated. That means that if you were trying to save something and run into this recoverable exception, you can repeat the save operation and it will succeed. However, if you were reading something the contents will be lost. For this "credentials manager" context, that can mean that the user was "logged out".

[stephen1706]

@lbalmaceda do you think this error will persist on certain devices? If yes, I might have to fallback to normal CredentialsManager permanently on this devices instead of using SecureCredentialsManager. What do you think?

[lbalmaceda]

@stephen1706 This error is expected and completely normal as explained previously. You can decide to retry the operation when it happens, since keys have been deleted and it will recreate them the next time you call save or get. Or you can also fallback to the non-secure option or any other storage strategy that you decide. That is also documented on the link I shared above.

[stephen1706]

@lbalmaceda today it happened to my test phone, I didn't change lock screen security, basically just reopening my app from yesterday. It happened when it call secureCredentialsManager.getCredentials. Device type: Xiaomi mi a1, this is a vanilla android OS 9 so I am wondering is there any reason for this behaviour? Stack trace:

SecureCredentialsManager: Credentials were just removed from the storage com.auth0.android.authentication.storage.CredentialsManagerException: A change on the Lock Screen security settings have deemed the encryption keys invalid and have been recreated. Any previously stored content is now lost. Please, try saving the credentials again. at com.auth0.android.authentication.storage.SecureCredentialsManager.continueGetCredentials(SecureCredentialsManager.java:245) at com.auth0.android.authentication.storage.SecureCredentialsManager.getCredentials(SecureCredentialsManager.java:204) ...Caused by: com.auth0.android.authentication.storage.CryptoException: The AES encrypted input is corrupted and cannot be recovered. Please discard it. at com.auth0.android.authentication.storage.CryptoUtil.decrypt(CryptoUtil.java:436) at com.auth0.android.authentication.storage.SecureCredentialsManager.continueGetCredentials(SecureCredentialsManager.java:237)
... Caused by: javax.crypto.AEADBadTagException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT at java.lang.reflect.Constructor.newInstance0(Native Method) at java.lang.reflect.Constructor.newInstance(Constructor.java:343)
at com.android.org.conscrypt.OpenSSLCipher$EVP_AEAD.throwAEADBadTagExceptionIfAvailable(OpenSSLCipher.java:1200)
at com.android.org.conscrypt.OpenSSLCipher$EVP_AEAD.doFinalInternal(OpenSSLCipher.java:1229) at com.android.org.conscrypt.OpenSSLCipher.engineDoFinal(OpenSSLCipher.java:363) at javax.crypto.Cipher.doFinal(Cipher.java:2055) at com.auth0.android.authentication.storage.CryptoUtil.decrypt(CryptoUtil.java:409) ... 27 more

[lbalmaceda]

@stephen1706 From what I could find the error means that either the saved content or the keys changed. How that happened to your testing device, I don't know.

The official docs mention something like this could happen in the event of a change in the lock screen settings, as explained on this other exception class javadocs.

[jrzerr]

This happened to me after we just upgraded to 1.23.0 (from 1.17) to solve so many issues with token expiration date handling. I can get this to happen on my Galaxy Tab Active2 where I have the lock screen set as a pin code. I go into the app and delete all data, uninstall the app, start from scratch with a new build from Android Studio and it happens the very first thing the app does when it loads up. So there should be no data sitting around that it is reading because of those pre-steps I did. I did not get this to happen on a different tablet. By chance I went into the Chrome settings and cleared all data and this issue resolved itself. The error is just a really bad error message and doesn't point to the real issue at all. Probably the step that I will end up taking is to force a logout when I see a really bad error, because I suspect if I was able to clear the webauth cookies it would have been fixed the next time I opened the app.

If this error isn't handled correctly, and you release a new version of the app with 1.23.0 to customers, it will totally brick the app and uninstalling will not fix. So keep that in mind and build some test scenarios around it and try and see if you can get the error and handle it properly. (I need to do this in our app too, haven't yet. Hoping a webauth log out will do it. Will post back here if we figure out how to get it to reproduce)

[AnD010]

Hi, I have a similar issue in my production app with differents users, how could I handler it?

CryptoUtil.java
com.auth0.android.authentication.storage.CryptoUtil.RSADecrypt

[palicka]

I experience this quite often. It happens when there are couple of parallel network calls and token refresh is needed. First call passes but second ends with this exception. It has nothing to do with lock screen security