Feature #5741


Secure Erasure of Passwords

Added by MartinBosslet (Martin Bosslet) over 10 years ago. Updated over 4 years ago.

Target version:


In other languages it is considered good practice to securely erase
passwords immediately after they were used. Imagine authentication
in a web app - ultimately a String containing the password arrives
at the server, where it will be processed and compared to some
previously stored value. After this is done, there is no need to
store these password Strings any longer, so they should be
discarded right away (more on why later).

In C, you would simply overwrite the array of bytes with zeroes or
random values. In Java, Strings are immutable, that's why there it
is common practice to use char[] for all things password and overwrite
them when done.

Currently, there is no way in Ruby to overwrite the memory that
was used by a String. String#clear and String#replace both use
str_discard internally, which only frees the underlying pointer
without overwriting it.

The problem with not erasing passwords is this: the contents of the
String stay in memory until they are finally GC'ed. But even then
only the pointer will be freed, leaving the contents mostly intact
until the memory is reclaimed and overwritten later on.

This could be exploited if an attacker had access to the memory of
the server. This could happen in many ways: a core dump after a
crash, access to the host if the server runs in a VM, or even by
deep-freezing the DRAM :) [1]

It could be argued that given the examples above, much more
devastating attacks would be possible since in all of those
cases you more or less have physical access to the machine. But
I would still consider this to be a valid concern, if not only
for the reason of never opening additional attack surfaces if
they can be avoided relatively easily.

I also found [2], which seems to show that Python deals with
similar problems and it also contains more background info.

Eric Hodel and I discussed this yesterday and Eric came up with
a C extension that can be used to illustrate the problem (attached).

If you inspect the resulting core dump, you will find the following:

  • the untouched String remains in memory fully intact
  • the String#clear'ed String remains to a large extent, typically the
    first character is missing - so if you typed "PASSWORD", search for
    "ASSWORD" (unintentional pun) instead
  • The String#clear_secure'ed will have been completely erased, no
    traces remain

My questions:

  1. Would you agree that we need this functionality?
  2. Where would we ideally place it? I'm not sure whether
    String is the perfect place, but on the other hand, String
    is the only place where we have access to the implementation
  3. Are there better alternative ways how we could achieve this?



secure_string_clear.tar.gz (514 Bytes) secure_string_clear.tar.gz MartinBosslet (Martin Bosslet), 12/11/2011 06:02 AM
signature.asc (499 Bytes) signature.asc Anonymous, 12/19/2011 02:53 PM

Also available in: Atom PDF