Memory persistence of sensitive authentication strings in Dart

Answer

Dart does not provide a way to force immediate deallocation or zero‑out the memory backing a String. The only reliable approach is to avoid keeping the sensitive data as a String longer than necessary and, when you must work with the raw bytes, use a Uint8List that you can explicitly overwrite after use.

Confirmed facts

• Dart String objects are immutable; once allocated they stay in the heap until the generational garbage collector reclaims the memory.
• The Dart VM does not expose an API to trigger a garbage collection cycle or to manually wipe memory.
• Operations such as substring, + or replaceAll create new String instances, copying the underlying characters and increasing the number of copies that may linger in memory.
• A Uint8List is a mutable buffer; you can overwrite its contents with fillRange (or a loop) and then drop the reference.

Steps for this case

1. When you receive a token (e.g., from secure storage), decode it to a Uint8List immediately:

   final Uint8List tokenBytes = base64.decode(storedBase64Token);

2. Use the bytes only for the operation that needs them (e.g., constructing a header). Keep the variable in the smallest possible scope.
3. After the operation completes, overwrite the buffer:

   tokenBytes.fillRange(0, tokenBytes.length, 0);

4. Set the variable to null (or let it go out of scope) so the GC can reclaim the buffer when it runs.
5. Do not retain the original String representation; if you need a String for API calls, create it just before use and discard it immediately afterward.

Likely explanation

Because the Dart VM cannot be instructed to free or zero memory on demand, relying on String alone leaves credentials in the heap for an indeterminate time. Using a mutable Uint8List gives you control over the buffer’s contents, reducing the window during which the raw credential is readable in a heap dump.

If you need to verify that no remnants remain, you would have to take a heap dump (via Dart DevTools or the Observatory) and search for the known token pattern after the buffer has been cleared and set to null. The absence of the pattern would confirm that the clearing step worked for that instance.