Why can't a password held in a Python str be erased from memory, and what can be?

## Why immutability defeats erasure A Python `str` is immutable by language definition. There is no assignment form that edits one, `s[0] = 'x'` raises `TypeError`, and every method that reads like an edit - `strip()`, `replace()`, `lower()`, slicing - builds and returns a **new** object while leaving the original bytes in the heap exactly as they were. So the usual C habit of overwriting a password buffer the moment you are done with it has no Python equivalent for `str`. The next instinct is to drop the reference: `del password`, or rebind `password = ""`. Neither erases anything. Rebinding just points the name somewhere else. `del` removes one reference, and if it was the last one the object is deallocated, which returns its memory to the allocator's free list **without zeroing it**. The characters remain readable in that region until something else happens to allocate over them. For a short-lived script that hardly matters. For a process that runs for weeks and might be captured in a heap dump, a core file or a container checkpoint, it is exactly the window you were trying to close. ## The copies you did not make Even if you could scrub the object you hold, you would probably be scrubbing one copy of several. A string literal in your source is compiled into the enclosing code object's constants table, so it lives as long as the module does. That alone makes a hardcoded credential unfixable at runtime, which is a good independent reason not to have one. Short identifier-like strings can be interned and shared, and `sys.intern` makes that explicit; an interned object is deliberately kept alive. Reading a secret as bytes and calling `.decode()` produces a second copy while the first still exists. Passing it through a parser, a `.strip()`, an f-string, a dict key, or an HTTP client that builds a header line copies it again. By the time the value reaches the code that uses it, the process may hold half a dozen instances of those characters in unrelated places, and you have references to none of them. ## What a bytearray buys `bytearray` is the mutable counterpart of `bytes`. Its contents can be assigned in place, so a real overwrite is possible: ```python buf[:] = bytes(len(buf)) # writes zeros over the existing storage ``` Slice assignment of the same length does not reallocate, so the zeros land on the storage that actually held the secret. Two disciplines make that meaningful. First, never grow the buffer: `append` or `extend` may reallocate and copy, leaving the previous, unzeroed allocation behind, so allocate the full length once. Second, never decode it - the moment you call `.decode()` you have minted an immutable copy and lost the property you were protecting. Work on the bytes: `memoryview(buf)` hands out slices that share the storage rather than copying it, and `hmac.compare_digest` accepts any bytes-like object, so a comparison never forces a `str`. The practical shape is to keep the secret in bytes from the moment it enters the process - read a mounted file with a bytes read rather than a text read, take socket bytes as they are - and to wrap the whole use in `try` / `finally` so the wipe happens even on an exception path. ## The honest limits This is defence in depth, not a guarantee, and saying so is part of a good answer. The operating system may have paged that memory to swap, where a copy persists beyond your control unless swap is disabled or encrypted. A crash can write a core dump containing the whole heap, which is why disabling core dumps for a process that handles credentials is a more effective control than any amount of scrubbing. A virtual machine snapshot or a container checkpoint captures memory wholesale. And any interactive entry point hands you a `str` to begin with, so the earliest bytes-only boundary you can build is usually the file or socket read, not the prompt. A related non-fix worth naming: reaching for `ctypes.memset` to overwrite a `str` object's internal buffer. It is possible, and it is a bad idea. It mutates an object the language guarantees is immutable, it can corrupt an interned or shared object that other code is still using, and it still does nothing about the copies you do not have references to. ## What actually reduces exposure Rank the controls honestly. Shorten the lifetime: fetch the credential as late as possible, use it, and drop it, rather than parking it in a module-level constant for the life of the process. Reduce the number of copies: pass a single object rather than re-deriving it, avoid string formatting with it, and keep it out of any structure that gets serialized or printed. Prefer bytes end to end so the wipe is at least available. Then, and only then, scrub. A candidate who leads with the scrub and never mentions lifetime has the priorities backwards.