auth0
Crash issue in SecureCredentialsManager
Checklist
- [ ] The issue can be reproduced in the Auth0.Android sample app (or N/A).
- [X] I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
- [X] I have looked into the API documentation and have not found a suitable solution or answer.
- [X] I have searched the issues and have not found a suitable solution or answer.
- [X] I have searched the Auth0 Community forums and have not found a suitable solution or answer.
- [X] I agree to the terms within the Auth0 Code of Conduct.
Description
In production got some crash events in SecureCredentialsManager class (Auth0)(Major issue) , Effected 10% of users in production.
Fatal Exception: f5.c: A change on the Lock Screen security settings have deemed the encryption keys invalid and have been recreated. Please try saving the credentials again. at com.auth0.android.authentication.storage.SecureCredentialsManager.saveCredentials(SecureCredentialsManager.kt:196) at com.poqstudio.app.client.auth0.Auth0Configuration.saveCredentials(Auth0Configuration.kt:38)
Reproduction
Can't able to reproduce the issue
Additional context
No response
Auth0.Android version
2.9.1
Android version(s)
11,13,14
Hi @AravinthNagaraj you may be interested in the same issue i had raised https://github.com/auth0/Auth0.Android/issues/644 and the response
Thanks for your update @bennycao . I have already referred to your issue and since the issue is happening again in newer version of Android as well , thought of bringing to the Auth0 team attention as they mentioned in your issue that it wasn't reported before.
@poovamraj I am still experiencing the crash issue in production, and its occurrence is consistently increasing, affecting users through the SecureCredentialsManager. Notably, 90% of the crashes are happening on Android OS 14, specifically on Samsung Galaxy devices. I haven't received a response yet. Could you please take a look and provide some guidance? Any help would be greatly appreciated. Thank you!
As per the log, it throws an exception in the rsaDecrypt method(IllegalBlockSizeException) in the CryptoUtil class.
@bennycao @ppamorim I believe you also experienced the same issue.
@poovamraj I am still experiencing the crash issue in production, and its occurrence is consistently increasing, affecting users through the SecureCredentialsManager. Notably, 90% of the crashes are happening on Android OS 14, specifically on Samsung Galaxy devices. I haven't received a response yet. Could you please take a look and provide some guidance? Any help would be greatly appreciated. Thank you!
As per the log, it throws an exception in the rsaDecrypt method(IllegalBlockSizeException) in the CryptoUtil class.
@bennycao @ppamorim I believe you also experienced the same issue.
If I am not wrong I believe we substantially reduce the occurrences of the issue by safe threading the access to that function.
If I am not wrong I believe we substantially reduce the occurrences of the issue by safe threading the access to that function.
Agreed on considering safe threading or try-catch for reducing crashes. However, to ensure a definitive solution, we must identify the root cause. Just masking it may help temporarily, but understanding and addressing the issue directly is crucial, especially since recurring crashes impact user experience.
@poovamraj I am still experiencing the crash issue in production, and its occurrence is consistently increasing, affecting users through the SecureCredentialsManager. Notably, 90% of the crashes are happening on Android OS 14, specifically on Samsung Galaxy devices. I haven't received a response yet. Could you please take a look and provide some guidance? Any help would be greatly appreciated. Thank you!
As per the log, it throws an exception in the rsaDecrypt method(IllegalBlockSizeException) in the CryptoUtil class.
@bennycao @ppamorim I believe you also experienced the same issue.
Yes we experienced and still experiencing this error. The % is around 1-2%. There was no clear reproduction steps, but was able to reproduce on Android 5, but logs indicate more samsung users with Android 11+. Resorted to handling the error and signing user out in code.
It would be good if we could understand this more from auth0's side as you said.
Hi @AravinthNagaraj , Are you still observing this issue in your production environment?
Facing the same on my flutter project
Device: Pixel 6A Android 15
Error: A change on the Lock Screen security settings have deemed the encryption keys invalid and have been recreated. Please try saving the credentials again.
same here and I am not sure how to mitigate - should I just retry the fetch of the credentials or does the user have to login again?
@wiesnery , Are you able to reproduce this consistently on your end ? If so, could you share the exact steps? As a workaround for now, you can ask the user to login again
@pmathew92 In my case it was reproducible when I changed the passcode of the device and then opened it again. Though tbh I do not completely remember my detailed findings. It occurred to me, I found this issue and worked past it with a single retry when this exception occurs and if then again I ask the user to login again. Though, I was not confident if this is the right thing to do, so I raised this question here.
@wiesnery We are not able to reproduce this issue.Checked in latest android version as well as Android OS 14 after changing the passcode method and passcode. Can you give more details. Also when exception comes you can ask user to retry login.
Hi @utkrishtsahu - time has passed and so my memory about this specific issue. The device I tried it on was a physical device - it always worked without problems in the emulator.
Sure, I could ask the user to retry login, but retrying after he just logged in is not a convenient experience. Tbh I just wanted to know wether from a technical perspective, there could be something wrong in retrying the fetch - maybe tokens get invalid or get corrupted when encrypting with the new encryption keys or some other related stuff.
@wiesnery We also tried to reproduce in physical device ,also i understand hardware backed keystore can be different on other environments(other OEM) To not having this issue you can do as below. 1>Catch this specific exception. 2>Clear any locally stored credentials (using SecureCredentialsManager.clearCredentials()). 3>Prompt the user to log in again. This allows new tokens to be obtained and saved with freshly generated encryption keys that are aligned with the current device security state.
@utkrishtsahu Thank you - this is a really nice instructive summary. From my perspective this issue can be closed for now as there is a good description on how to handle this cause and can be observed in the future.