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

resolved flutter_secure_storage: ^9.0.0 const secureStorage = FlutterSecureStorage( aOptions: AndroidOptions( encryptedSharedPreferences: true, ));

Still experiencing this issue and doing this does not resolve…

resolved flutter_secure_storage: ^9.0.0 const secureStorage = FlutterSecureStorage( aOptions: AndroidOptions( encryptedSharedPreferences: true, ));

Instead of doing

<full-backup-content>
    <exclude domain="sharedpref" path="FlutterSecureStorage"/>
</full-backup-content>

Shouldn’t it be:

For Android up to 11:

<full-backup-content>
    <exclude domain="sharedpref" path="FlutterSecureKeyStorage"/>
    <exclude domain="sharedpref" path="FlutterSecureStorage"/>
</full-backup-content>

For Android 12 and up:

<data-extraction-rules>
    <cloud-backup >
        <exclude domain="sharedpref" path="FlutterSecureStorage"/>
        <exclude domain="sharedpref" path="FlutterSecureKeyStorage"/>
    </cloud-backup>
    <device-transfer>
        <exclude domain="sharedpref" path="FlutterSecureStorage"/>
        <exclude domain="sharedpref" path="FlutterSecureKeyStorage"/>
    </device-transfer>
</data-extraction-rules>

As I see that:

• Android up-to-11 and Android 12-and-up require different formats of the xml backup file
• flutter_secure_storage uses two files

Had the same issue previously. I am fairly certain that at least some Samsung devices sometimes ignore the following Android flags:

android:allowBackup="false"
android:fullBackupContent="false"

What this means is that some Samsung phones store (locally / or on some google/samsung server) app data when the app is deleted ; and it restores it when the app is re-installed.

However, the padding encryption key DOES NOT leave the device and is deleted when the app is initially deleted.

When the user re-installs the app, a new encryption key is generated/returned. The app will attempt to decrypt the old restored data with the new encryption key, leading to the BadPaddingException.

My recommendation (and what I am doing) is to clear all encrypted data when encountering this exception and start fresh. If you encounter this, the existing encrypted data is almost certainly permanently lost anyways, since the decryption key does not exist anymore.

This problem seems to occur only on SM-G991B (S21) and SM-G996B (S21+).

I have a similar issue

Had the same issue previously. I am fairly certain that at least some Samsung devices sometimes ignore the following Android flags:

android:allowBackup="false"
android:fullBackupContent="false"

What this means is that some Samsung phones store (locally / or on some google/samsung server) app data when the app is deleted ; and it restores it when the app is re-installed.

However, the padding encryption key DOES NOT leave the device and is deleted when the app is initially deleted.

When the user re-installs the app, a new encryption key is generated/returned. The app will attempt to decrypt the old restored data with the new encryption key, leading to the BadPaddingException.

My recommendation (and what I am doing) is to clear all encrypted data when encountering this exception and start fresh. If you encounter this, the existing encrypted data is almost certainly permanently lost anyways, since the decryption key does not exist anymore.

I tried this, but the users encounter this exception EVERY time the app is terminated and reopened, not just with a reinstall or a update. As @frankmer stated it only occurs on the S21 and S21+, and seems to occur since the latest android software update for those devices that was released this october.

I have exactly the same issue described above, in the same conditions mentionned by @devswingapplicationcom.

To temporarily solve the problem, I clear the secure storage the first time the user installs a new version. This cannot be done by everyone, but it can help on some cases. I use both Shared Preferences and Flutter Secure Storage.

I call the following code at startup:

String version = // current version of your app, e.g. 1.0.0
if (sharedPreferences.getString("secureStorageCleared") != version) {
    await flutterSecureStorage.deleteAll();
    await sharedPreferences.setString("secureStorageCleared", version);
}

This will be called only once per new version.

I have a similar issue

That is interesting, the first thing we recommended to our customers was to reinstall the app but that didn’t seem to help them… Could it have something to do with android:allowBackup=“false” being deprecated from Android 12 and higher? This is how we have it in our app:

android:allowBackup="false"
android:fullBackupContent="@xml/backup_rules"`

With in the backup_rules:

<full-backup-content>
    <exclude domain="sharedpref" path="FlutterSecureStorage"/>
</full-backup-content>

This was the solution when we encountered this problem a few years back, see: #43 (comment)

The current problem has nothing to do with the old problem from a few years ago. If reinstalling really fixes it, then my guess is that the link between the key and the application itself is broken, and reinstalling the application will reestablish that link. Although reinstalling may cause the other problem if backup is enabled.

android:fullBackupContent=“false” indeed fixed all our problems, thanks! 😄

That is interesting, the first thing we recommended to our customers was to reinstall the app but that didn’t seem to help them… Could it have something to do with android:allowBackup=“false” being deprecated from Android 12 and higher?

This is how we have it in our app:

android:allowBackup="false"
android:fullBackupContent="@xml/backup_rules"`

With in the backup_rules:

<full-backup-content>
    <exclude domain="sharedpref" path="FlutterSecureStorage"/>
</full-backup-content>

This was the solution when we encountered this problem a few years back, see: #43 (comment)

The current problem has nothing to do with the old problem from a few years ago. If reinstalling really fixes it, then my guess is that the link between the key and the application itself is broken, and reinstalling the application will reestablish that link. Although reinstalling may cause the other problem if backup is enabled.

How can I do it? (change the flutterSecureStorage.xml) ? Can you provide a short guide or share any reference? 😃 Will be very important simulate it here.

I did it via Android Studio. Device Manager > Run Device > Folder Button under Actions. Then use “Save As…” and “Upload…”

Files found in data/data/{appid}/shared_prefs

I tried this, but the users encounter this exception EVERY time the app is terminated and reopened, not just with a reinstall or a update. As @frankmer stated it only occurs on the S21 and S21+, and seems to occur since the latest android software update for those devices that was released this october.

The real question is whether the error has occurred since or because of the software update. Even if deleting the old data is not a good option. It would be nice to know if this is actually an option or if the error still occurs.

Had the same issue previously. I am fairly certain that at least some Samsung devices sometimes ignore the following Android flags:

android:allowBackup="false"
android:fullBackupContent="false"

What this means is that some Samsung phones store (locally / or on some google/samsung server) app data when the app is deleted ; and it restores it when the app is re-installed.

However, the padding encryption key DOES NOT leave the device and is deleted when the app is initially deleted.

When the user re-installs the app, a new encryption key is generated/returned. The app will attempt to decrypt the old restored data with the new encryption key, leading to the BadPaddingException.

My recommendation (and what I am doing) is to clear all encrypted data when encountering this exception and start fresh. If you encounter this, the existing encrypted data is almost certainly permanently lost anyways, since the decryption key does not exist anymore.

We are seeing the same issue BUT only when building release appbundle and upload to playstore

Not working:

1. Build aab locally and deploy to Playstore
2. install from Playstore
3. –> Boom bad decrypt.
4. uninstall aab.
5. download APK from playstore and install --> Boom, bad decrypt

Working:

1. build apk on dev machine
2. install apk on phone. - everything works as expected.

?

What worked for me was this:

AndroidManifest.xml

    <application
        ...
        android:fullBackupContent="false"
        android:allowBackup="false"
        android:dataExtractionRules="@xml/data_extraction_rules"
...

And as @PieterAelse pointed out:

<?xml version="1.0" encoding="utf-8"?>
<data-extraction-rules>
    <cloud-backup>
        <exclude domain="root" />
        <exclude domain="file" />
        <exclude domain="database" />
        <exclude domain="sharedpref" />
        <exclude domain="external" />
        <exclude domain="sharedpref" path="FlutterSecureStorage"/>
        <exclude domain="sharedpref" path="FlutterSecureKeyStorage"/>
    </cloud-backup>
    <device-transfer>
        <exclude domain="root" />
        <exclude domain="file" />
        <exclude domain="database" />
        <exclude domain="sharedpref" />
        <exclude domain="external" />
        <exclude domain="sharedpref" path="FlutterSecureStorage"/>
        <exclude domain="sharedpref" path="FlutterSecureKeyStorage"/>
    </device-transfer>
</data-extraction-rules>

I’m on flutter_secure_storage: ^9.0.0 and Flutter 3.16.4 if that makes a difference.

Had the same issue previously. I am fairly certain that at least some Samsung devices sometimes ignore the following Android flags:

android:allowBackup="false"
android:fullBackupContent="false"

What this means is that some Samsung phones store (locally / or on some google/samsung server) app data when the app is deleted ; and it restores it when the app is re-installed. However, the padding encryption key DOES NOT leave the device and is deleted when the app is initially deleted. When the user re-installs the app, a new encryption key is generated/returned. The app will attempt to decrypt the old restored data with the new encryption key, leading to the BadPaddingException. My recommendation (and what I am doing) is to clear all encrypted data when encountering this exception and start fresh. If you encounter this, the existing encrypted data is almost certainly permanently lost anyways, since the decryption key does not exist anymore.

This problem seems to occur only on SM-G991B (S21) and SM-G996B (S21+).

Hey @frankmer, how can i test it? I tried a lot of times but never get success, can’t found any log or reference using browser Stack. But a lot of user have been sending a bad review about this issue.

I never tested it on a real device, but I was able to simulate this error by adding an old FlutterSecureStorage.xml to shared_prefs after deleting the appdata. Our customer report only came from these devices, and there were a lot of them. SM-G998B (S21 Ultra) is now also on the list.

Had the same issue previously. I am fairly certain that at least some Samsung devices sometimes ignore the following Android flags:

android:allowBackup="false"
android:fullBackupContent="false"

What this means is that some Samsung phones store (locally / or on some google/samsung server) app data when the app is deleted ; and it restores it when the app is re-installed. However, the padding encryption key DOES NOT leave the device and is deleted when the app is initially deleted. When the user re-installs the app, a new encryption key is generated/returned. The app will attempt to decrypt the old restored data with the new encryption key, leading to the BadPaddingException. My recommendation (and what I am doing) is to clear all encrypted data when encountering this exception and start fresh. If you encounter this, the existing encrypted data is almost certainly permanently lost anyways, since the decryption key does not exist anymore.

This problem seems to occur only on SM-G991B (S21) and SM-G996B (S21+).

Hey @frankmer, how can i test it? I tried a lot of times but never get success, can’t found any log or reference using browser Stack. But a lot of user have been sending a bad review about this issue.