A long-standing piece of advice says to hold a password or key in a mutable byte or character buffer rather than an immutable string type. State the property that advice is really about, why immutable string types are the wrong container for a secret, and how the answer differs across runtimes with different memory management.

## The property behind the folklore "Use a character array, not a string" is repeated so often that candidates recite it without the reason, and the reason is the whole answer. The quantity being managed is **the lifetime of plaintext inside the process**, and the useful mental model is: > exposure ≈ (number of copies) × (how long each copy lives) × (who can observe process memory) Every control in this area moves one of those three factors. Choosing a wipeable container moves the second. It does not make the secret safe against someone who can read your process while it is in use — nothing at this layer does — it shortens the window during which a *later* observer (a heap dump written at 3am, a core file, a crash report, a debugger attached during an incident) finds the value sitting there. ## Why an immutable string is the wrong container An immutable string offers no operation that changes its contents. That single fact has several consequences: - **You cannot erase it.** Setting the variable to null or letting it fall out of scope removes your *reference*; the bytes stay exactly where they were until the memory is reclaimed and eventually reused for something else. "Reclaimed" is not "overwritten" — freed memory typically keeps its contents until the allocator hands it out again, which may be never. - **Its lifetime is not yours.** Collection happens when the runtime decides, under memory pressure you do not control. On a machine with plenty of headroom, a password can sit in the heap for the life of the process. - **Some strings are immortal by design.** Literal or interned strings live in a table that deliberately keeps one instance forever, so a secret that ever reaches that table never leaves memory. This is why hard-coded credentials are memory-resident as well as source-visible. - **It multiplies quietly.** Because strings are the universal interchange type, a secret in a string gets substringed, trimmed, concatenated into a log message, formatted, encoded, put in a map, serialised to JSON for an outbound call — each step making a new copy you did not plan and cannot track. A buffer is awkward to pass around, and that friction is itself a benefit: it discourages accidental copies. A mutable buffer fixes precisely one of these: it gives you a moment of your choosing at which the bytes become zeroes. That is worth having, and it is a smaller win than the folklore implies. ## How runtimes diverge This is where a strong answer separates itself, because the same advice has different force in different environments: - **Managed runtime with a copying/compacting collector** (typical JVM young-generation collection, and comparable designs elsewhere): live objects are *moved* to new addresses during collection. The old bytes remain at the vacated address with no reference pointing at them, so a wipe performed later touches only the surviving copy. Wiping still helps — it removes the copy you can reach — but it cannot promise the plaintext is gone from the address space. - **Managed runtime with a non-moving collector** (a mark-sweep design, as in some other managed languages): no relocation, so a wipe of the buffer you hold is more nearly complete — but strings remain immutable and unwipeable, and interning still applies to small values. - **Reference-counted runtime**: memory is freed deterministically at the last reference drop, which sounds better and is: the dwell time is short and predictable. But freeing is not zeroing, immutable string types are still unwipeable, and short strings are commonly interned for the process lifetime. - **Native, unmanaged code**: you have the most control and the sharpest footgun. You can overwrite the buffer and lock its pages so they are never written to swap. But an optimising compiler is entitled to delete a store to memory that is never read again — the wipe at the end of a function is textbook dead-store elimination — which is exactly why platforms provide dedicated secure-zero routines that the compiler is forbidden to remove. - **Runtimes that offered a dedicated "secure string" container**: several platforms shipped one and then advised against it for new code, on an honest argument worth repeating in an interview — it cannot protect a secret from an attacker who is already inside the process, and it encourages the belief that it can. The guidance that replaced it is the architectural one: do not hold the secret at all where you can avoid it. ## What the rule is worth, honestly Against an attacker with live code execution in the process, none of this matters; they read the buffer while it is populated. What it genuinely buys: - **Heap dumps and core files.** A dump written on out-of-memory, or captured by a profiler, an APM agent or an operator during an incident, contains every live string in plaintext. Those artefacts get copied into ticket systems and object storage and outlive the incident. Shortening the window during which a secret would appear in one is a real, frequently realised win. - **Swap and hibernation images**, which persist memory contents to disk outside the process's control. - **Later-stage disclosure bugs**, where an out-of-bounds read returns whatever happens to be nearby. ## The better move above the buffer The strongest version of the answer says the container choice is the *second* control, not the first. The first is not to materialise the plaintext in this process at all: verify a password by streaming it into a hashing routine rather than parking it; hold a handle or a reference to a key kept by a separate keystore or hardware module and ask that component to perform the operation; keep the secret out of any long-lived object, cache, session, or exception payload. If it never exists as a durable value, there is nothing to wipe and no dwell time to argue about. ## Answering the question Lead with lifetime, not with types. Say that immutable strings cannot be erased, that their lifetime belongs to the runtime, and that interning can make them permanent. Name the runtime divergence — relocating collectors leave stale copies, reference counting frees promptly without zeroing, native code needs a secure-zero routine because the compiler will delete an ordinary one. Then place the control honestly: it shrinks the window that shows up in dumps and swap; it is not protection against an attacker already executing in the process, and the stronger move is not holding the plaintext at all.