Unhandled Exception: PlatformException(Exception encountered, read, javax.crypto.BadPaddingException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT

[NamanShergill]

Issue is reproducible in release mode where an existing app backup is restored, using Google One or a rooted device.

This issue was being tracked in #161 and still exists in the latest version, yet the issue was closed and still remains closed to this day even after many people confirming the issue was never fixed in the replies.

E/flutter (23800): [ERROR:flutter/lib/ui/ui_dart_state.cc(209)] Unhandled Exception: PlatformException(Exception encountered, read, javax.crypto.BadPaddingException: error:1e000065
:Cipher functions:OPENSSL_internal:BAD_DECRYPT
E/flutter (23800):      at com.android.org.conscrypt.NativeCrypto.EVP_CipherFinal_ex(Native Method)
E/flutter (23800):      at com.android.org.conscrypt.OpenSSLEvpCipher.doFinalInternal(OpenSSLEvpCipher.java:152)
E/flutter (23800):      at com.android.org.conscrypt.OpenSSLCipher.engineDoFinal(OpenSSLCipher.java:374)
E/flutter (23800):      at javax.crypto.Cipher.doFinal(Cipher.java:2055)
E/flutter (23800):      at com.it_nomads.fluttersecurestorage.ciphers.StorageCipher18Implementation.decrypt(StorageCipher18Implementation.java:103)
E/flutter (23800):      at com.it_nomads.fluttersecurestorage.FlutterSecureStoragePlugin.decodeRawValue(FlutterSecureStoragePlugin.java:231)
E/flutter (23800):      at com.it_nomads.fluttersecurestorage.FlutterSecureStoragePlugin.read(FlutterSecureStoragePlugin.java:213)
E/flutter (23800):      at com.it_nomads.fluttersecurestorage.FlutterSecureStoragePlugin.access$500(FlutterSecureStoragePlugin.java:37)
E/flutter (23800):      at com.it_nomads.fluttersecurestorage.FlutterSecureStoragePlugin$MethodRunner.run(FlutterSecureStoragePlugin.java:302)
E/flutter (23800):      at android.os.Handler.handleCallback(Handler.java:938)
E/flutter (23800):      at android.os.Handler.dispatchMessage(Handler.java:99)
E/flutter (23800):      at android.os.Looper.loopOnce(Looper.java:201)
E/flutter (23800):      at android.os.Looper.loop(Looper.java:288)
E/flutter (23800):      at android.os.HandlerThread.run(HandlerThread.java:67)
E/flutter (23800): , null)

[NamanShergill]

Please, either open the previous issue or keep this one open. This is a major bug and should be tracked.

[NamanShergill]

The current best workaround according to my research is:

  static Future<String?> getAccessTokenFromDevice() async {
    const _storage = FlutterSecureStorage();
    try {
      final accessToken = await _storage.read(key: 'accessToken');
      return accessToken;
    } on PlatformException catch (e) {
      // Workaround for https://github.com/mogol/flutter_secure_storage/issues/43
      await _storage.deleteAll();
    }
  }

This way you don't have to lose out on the shared preferences being backed up like in the other suggestions which are honestly, a bit hacky.

It would be good if the library could be updated to handle this issue on its own?

[vlkonoshenko]

@NamanShergill Which version of the package are you using? Does this issue still persist?

[NamanShergill]

@NamanShergill Which version of the package are you using? Does this issue still persist?

5.0.2, and yes, it still happens.

[vlkonoshenko]

@NamanShergill Which version of the package are you using? Does this issue still persist?

5.0.2, and yes, it still happens.

I have a report from the sentry but can`t reproduce it. Do you get this error every time when trying to read from storage?

[NamanShergill]

@NamanShergill Which version of the package are you using? Does this issue still persist?

5.0.2, and yes, it still happens.

I have a report from the sentry but can`t reproduce it. Do you get this error every time when trying to read from storage?

The reproduction method is restoring an app backup from Google after a factory reset/new phone setup or if you have root, through backup apps like Swift backup.

The error will show up everytime you try to access the storage, until the user manually clears the app data.

[peterhijma]

Got the same error today.

[amitBlueVine]

Got the same error today

[MiroLiebschner]

Same error today.
@NamanShergill there a reason you use _storage.deleteAll() instead of just deleting the key with _storage..delete(key: "accessToken")? I am a bit hesitant to delete all data in secure storage

[NamanShergill]

Same error today.
@NamanShergill there a reason you use _storage.deleteAll() instead of just deleting the key with _storage..delete(key: "accessToken")? I am a bit hesitant to delete all data in secure storage

No specific reason, I am only storing an access token in it so both would be the same for me.

However, is there any point in not deleting everything if the plugin will throw an exception every time you try accessing that data?

[jeff-odopass]

I'm also experiencing the same issue, happened for 12 of my end-users in production. I noticed that most of these issues were with Samsung phones, specially the ones named 'SM-G...'.
It appeared only for Android 11 & 12 for now. Same stacktrace as mentioned above, let me know if you need anything.

[jtmuller5]

This is happening on my Samsung S22. Adding allowBackup and fullBackupContent did not fix the issue.

[SithumDilanga]

The current best workaround according to my research is:

  static Future<String?> getAccessTokenFromDevice() async {
    const _storage = FlutterSecureStorage();
    try {
      final accessToken = await _storage.read(key: 'accessToken');
      return accessToken;
    } on PlatformException catch (e) {
      // Workaround for https://github.com/mogol/flutter_secure_storage/issues/43
      await _storage.deleteAll();
    }
  }

This way you don't have to lose out on the shared preferences being backed up like in the other suggestions which are honestly, a bit hacky.

It would be good if the library could be updated to handle this issue on its own?

this solved my issue

[senenpalanca97]

Got the same error today.

[juliansteenbakker]

It would be good if the library could be updated to handle this issue on its own?

I will look into this, thanks

[tal-nir]

Got the same error today.

[EhabSalah]

Any Updates ????

[fionues]

The current best workaround according to my research is:

  static Future<String?> getAccessTokenFromDevice() async {
    const _storage = FlutterSecureStorage();
    try {
      final accessToken = await _storage.read(key: 'accessToken');
      return accessToken;
    } on PlatformException catch (e) {
      // Workaround for https://github.com/mogol/flutter_secure_storage/issues/43
      await _storage.deleteAll();
    }
  }

This way you don't have to lose out on the shared preferences being backed up like in the other suggestions which are honestly, a bit hacky.

It would be good if the library could be updated to handle this issue on its own?

A user with a pixel 4a had the same problem after a reinstall. deleteAll() did not help (I had this implemented already) only a manual clear of app data did.

[AlgoritmoDelCambio]

The current best workaround according to my research is:

  static Future<String?> getAccessTokenFromDevice() async {
    const _storage = FlutterSecureStorage();
    try {
      final accessToken = await _storage.read(key: 'accessToken');
      return accessToken;
    } on PlatformException catch (e) {
      // Workaround for https://github.com/mogol/flutter_secure_storage/issues/43
      await _storage.deleteAll();
    }
  }

This way you don't have to lose out on the shared preferences being backed up like in the other suggestions which are honestly, a bit hacky.
It would be good if the library could be updated to handle this issue on its own?

A user with a pixel 4a had the same problem after a reinstall. deleteAll() did not help (I had this implemented already) only a manual clear of app data did.

Same here.

In our case, anything called through _storage is what gives the PlatformException. So, if we catch this exception and we try to call the .deleteAll() over the same _storage, the exception is thrown again and the App crashes completely 😭

[georgiosd]

So there's no workaround for this? 😭

[royvangeel]

Any updates on this?

[Yongle-Fu]

Samsung

same issue in
Xiaomi 2201122C, X-Client-Version: Android 12 / SDK 31

[gerritwitkamp]

Any progress on this?

[ghost]

Just to make sure, its safer not to use flutter_secure_storage for android unless this problem is fixed, right?

[jfahrenkrug]

If you use version 5.0.2, make sure you use this option when creating the instance:

FlutterSecureStorage(aOptions: AndroidOptions(
    encryptedSharedPreferences: true,
));

This causes the package to use Android's built-in EncryptedSharedPreferences. The crash only seems to occur when not using this setting, because then the package uses a different way of encrypting and decrypting the prefs. You can see that by reading the source code here:

flutter_secure_storage/flutter_secure_storage/android/src/main/java/com/it_nomads/fluttersecurestorage/FlutterSecureStoragePlugin.java

Line 101 in 26efe91

if (useEncryptedSharedPreferences &&

Also see #328 (comment)

[DamienMrtl]

If you use version 5.0.2, make sure you use this option when creating the instance:

FlutterSecureStorage(aOptions: AndroidOptions(
    encryptedSharedPreferences: true,
));

This causes the package to use Android's built-in EncryptedSharedPreferences. The crash only seems to occur when not using this setting, because then the package uses a different way of encrypting and decrypting the prefs. You can see that by reading the source code here:

flutter_secure_storage/flutter_secure_storage/android/src/main/java/com/it_nomads/fluttersecurestorage/FlutterSecureStoragePlugin.java

Line 101 in 26efe91

if (useEncryptedSharedPreferences &&

Also see #328 (comment)

Fixed it for me. Thanks :D

[simplenotezy]

If you use version 5.0.2, make sure you use this option when creating the instance:

FlutterSecureStorage(aOptions: AndroidOptions(
    encryptedSharedPreferences: true,
));

This causes the package to use Android's built-in EncryptedSharedPreferences. The crash only seems to occur when not using this setting, because then the package uses a different way of encrypting and decrypting the prefs. You can see that by reading the source code here:

flutter_secure_storage/flutter_secure_storage/android/src/main/java/com/it_nomads/fluttersecurestorage/FlutterSecureStoragePlugin.java

Line 101 in 26efe91

if (useEncryptedSharedPreferences &&

Also see #328 (comment)

Is there a way to enable this globally? We use storage in quite a few different widgets

[justincbeck]

The current best workaround according to my research is:

  static Future<String?> getAccessTokenFromDevice() async {
    const _storage = FlutterSecureStorage();
    try {
      final accessToken = await _storage.read(key: 'accessToken');
      return accessToken;
    } on PlatformException catch (e) {
      // Workaround for https://github.com/mogol/flutter_secure_storage/issues/43
      await _storage.deleteAll();
    }
  }

This way you don't have to lose out on the shared preferences being backed up like in the other suggestions which are honestly, a bit hacky.

It would be good if the library could be updated to handle this issue on its own?

Why not use a different SecureStorage (one that uses encryptedSharedPreferences: true,) for the deleteAll() call? That way you won't crash the app completely and you won't be faced with the performance issues I described above. For now, this is what I'm going to do.

[AhmedKhattab95]

This causes the package to use Android's built-in EncryptedSharedPreferences. The crash only seems to occur when not using this setting, because then the package uses a different way of encrypting and decrypting the prefs. You can see that by reading the source code here:

is it will be backward compatible if the user already has saved data or will crash?

[kmoreau]

This causes the package to use Android's built-in EncryptedSharedPreferences. The crash only seems to occur when not using this setting, because then the package uses a different way of encrypting and decrypting the prefs. You can see that by reading the source code here:

is it will be backward compatible if the user already has saved data or will crash?

Same question here, can we activate 'EncryptedSharedPreferences' without any risk for users ? thx

[AristideVB]

Still having this issue on v8.0.0

[mirkomartino]

Continuo a riscontrare questo problema su v8.0.0

I also had the same problem as you on that version.

I just added to the manifest these rules on the application node to solve:

<application 
android:allowBackup="false" 
android:fullBackupContent="false" ...>

[bahman2000]

Still an issue.

flutter_secure_storage 9.0.0 in Android 9.

[acheronian]

Got the issue randomly on Android 14 devices, LogCat shows following error in production app:

[ERROR:flutter/lib/ui/ui_dart_state.cc(198)] Unhandled Exception: PlatformException(Exception encountered, read, javax.crypto.BadPaddingException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT
	at com.android.org.conscrypt.NativeCrypto.EVP_CipherFinal_ex(Native Method)
	at com.android.org.conscrypt.OpenSSLEvpCipher.doFinalInternal(OpenSSLEvpCipher.java:152)
	at com.android.org.conscrypt.OpenSSLCipher.engineDoFinal(OpenSSLCipher.java:374)
	at javax.crypto.Cipher.doFinal(Cipher.java:2056)
	at w6.h.b(Unknown Source:35)
	at v6.a.c(Unknown Source:11)
	at v6.a.k(Unknown Source:17)
	at v6.e$b.run(Unknown Source:233)
	at android.os.Handler.handleCallback(Handler.java:958)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loopOnce(Looper.java:230)
	at android.os.Looper.loop(Looper.java:319)
	at android.os.HandlerThread.run(HandlerThread.java:67)
, null)
#0      StandardMethodCodec.decodeEnvelope (package:flutter/src/services/message_codecs.dart:607)
#1      MethodChannel._invokeMethod (package:flutter/src/services/platform_channel.dart:167)

[joabsantos]

Got same today

flutter_secure_storage: ^8.1.0

[Nithsua]

Also curious does it happen on other operations like write() for anyone?

[nemanja-nikolic-goldbear]

I am still having issues on Samsung S23 Ultra and Samsung A54 5G mostly, users have to login couple times a day because app looses token from the storage (unable to read the token). Using version ^8.1.0 . And using crashlytics I have proved that randomly device can not read the storage by key, just return null, but key is in the storage. Same app version, 95% of the users have never complained.

[brandon-watkins-avcrm]

Any news on this? I am seeing it happen today on Android 9

[juliansteenbakker]

This issue is probably caused by the JetSec Crypto library. I am trying to rewrite this library because it is deprecated, and progress will be tracked in #769 . It would be great if someone could test this implementation when the first beta will be released.

[bahadirarslan]

I am still having issues on Samsung S23 Ultra and Samsung A54 5G mostly, users have to login couple times a day because app looses token from the storage (unable to read the token). Using version ^8.1.0 . And using crashlytics I have proved that randomly device can not read the storage by key, just return null, but key is in the storage. Same app version, 95% of the users have never complained.

Same situation, instead of only Samsung devices MI devices have also problems with this library. They can not read token from storage.

[sanjaycdev]

i was facing the same issue while debugging in my Samsung device. after struggling for a while i tried a different app id and booom its fixed!@
hope it saves some time for some one :)

[NamanShergill]

i was facing the same issue while debugging in my Samsung device. after struggling for a while i tried a different app id and booom its fixed!@ hope it saves some time for some one :)

I’m pretty sure because that’s because the new app ID is letting it have fresh new prefs now. Once you have encrypted data in there and it fails to decrypt like above, you’ll likely be back to square one.

[AlgoritmoDelCambio]

Bon dia! Actualment estic fora de l'oficina i no tornaré fins al dia 6 de novembre. Si m'escrius per un tema tecnològic, et recomano escriure a ***@***.*** En cas que necessitis alguna altra cosa, dirigeix-te a ***@***.*** o directament truca al +34 937 371 513, que és el telèfon general d'eAgora. Espero que tot vagi bé, ens veiem a la tornada. Abraçades! 🤗

…

-- eAgora @import ***@***.***;700&display=swap'); Julià Navarrete CTO & Co-founder +34 937 371 513 ***@***.*** www.eagora.app Av. de la Cambra de Comerç 42, Redessa, Ed. CEPID, Reus (ES) Los datos y textos (incluyendo direcciones de correo electrónico y archivos adjuntos) de este mensaje puede contener información confidencial. Si usted no es el destinatario final o ha recibido este mensaje por error, le rogamos nos lo comunique y lo elimine. Los datos personales serán tratados bajo la responsabilidad de eAgora Algorisme del canvi S.L. Para ejercer sus derechos de protección de datos puede mandar un mensaje a ***@***.*** Si considera que el tratamiento no se ajusta a la normativa vigente, puede reclamar en agpd.es. (CA) Les dades i textos (incloent-hi adreces de correu electrònic i arxius adjunts) d'aquest missatge poden contenir informació confidencial. Si vostè no és el destinatari final o ha rebut aquest missatge per error li preguem que ens ho comuniqui i l'elimini. Les dades personals seran tractades sota la responsabilitat d'eAgora Algorisme del canvi S.L. Per a exercir els seus drets de protecció de dades pot enviar un missatge a ***@***.*** Si considera que el tractament no s'ajusta a la normativa vigent, pot reclamar a agpd.es.