CODEWITHSUNDEEP
c++stringpasswordssecure-coding
ajd.
ajd.

Reputation: 659

how does one securely clear std::string?

How does one store sensitive data (ex: passwords) in std::string?

I have an application which prompts the user for a password and passes it to a downstream server during connection setup. I want to securely clear the password value after the connection has been established.

If I store the password as a char * array, I can use APIs like SecureZeroMemory to get rid of the sensitive data from the process memory. However, I want to avoid char arrays in my code and am looking for something similar for std::string?

Upvotes: 26

Views: 14020

Answers (7)

Rushabh
Rushabh

Reputation: 1

For Windows:

std::string s("ASecret");
const char* const ptr = s.data();
SecureZeroMemory((void*)ptr, s.size());

This shall securely clear the data from the stack or the heap depending on the STL internals.

Works on all sizes of the string no matter small or large.

Caution !

DO NOT USE ptr for altering the data of the string which might result in increasing or decreasing the length.

Upvotes: 0

Philipp Claßen
Philipp Claßen

Reputation: 43989

It is a complicated topic, as an optimizing compiler will work against you. Straightforward approaches like looping over the string and overwriting each character are not reliable, as the compiler might optimize it away. Same with memset, however, C11 added memset_s, which should be secure but might not be available on all platforms.

For that reason, I would strongly recommend to use a trusted crypto library for that task and let their authors take care of portability. Secure wiping is a basic operation (taking a C-array and overwriting it securely), which all libraries will have to implement at some point. Note that the underlying data in a std::string is contiguous (as mandated by the C++11 standard, but in practice even in C++98/03 you could assume it). Therefore, you can use the secure wiping facilities of the crypto library by treading the std::string as an array.

In OpenSSL, secure wiping is provided by the OPENSSL_cleanse function. Crypto++ has memset_z:

std::string secret;
// ...

// OpenSSL (#include <openssl/crypto.h> and link -lcrypto)
OPENSSL_cleanse(&secret[0], secret_str.size());

// Crypto++ (#include <crypto++/misc.h> and link -lcrypto++)
CryptoPP::memset_z(&secret[0], 0, secret.size());

As a side-note, if you design the API from scratch, consider avoiding std::string altogether when it comes to storing secrets. It was not a design goal of std::string to prevent leaking the secret (or parts of it during resizing or copying).

Upvotes: 6

ericcurtin
ericcurtin

Reputation: 1717

openssl went through a couple of iterations of securely erasing a string until it settled on this approach:

#include <string.h>
#include <string>

// Pointer to memset is volatile so that compiler must de-reference
// the pointer and can't assume that it points to any function in
// particular (such as memset, which it then might further "optimize")
typedef void* (*memset_t)(void*, int, size_t);

static volatile memset_t memset_func = memset;

void cleanse(void* ptr, size_t len) {
  memset_func(ptr, 0, len);
}

int main() {
  std::string secret_str = "secret";
  secret_str.resize(secret_str.capacity(), 0);
  cleanse(&secret_str[0], secret_str.size());
  secret_str.clear();

  return 0;
}

Upvotes: 10

mark
mark

Reputation: 5469

For posterity, I once decided to ignore this advice and use std::string anyway, and wrote a zero() method using c_str() (and casting away the constness) and volatile. If I was careful and didn't cause a reallocate/move of the contents, and I manually called zero() where I needed it clean, all seemed to function properly. Alas, I discovered another serious flaw the hard way: std::string can also be a referenced-counted object... blasting the memory at c_str() (or the memory the referenced object is pointing to) will unknowingly blast the other object.

Upvotes: 4

ajd.
ajd.

Reputation: 659

Based on the answer given here, I wrote an allocator to securely zero memory.

#include <string>
#include <windows.h>

namespace secure
{
  template <class T> class allocator : public std::allocator<T>
  {
  public:

    template<class U> struct rebind { typedef allocator<U> other; };
    allocator() throw() {}
    allocator(const allocator &) throw() {}
    template <class U> allocator(const allocator<U>&) throw() {}

    void deallocate(pointer p, size_type num)
    {
      SecureZeroMemory((void *)p, num);
      std::allocator<T>::deallocate(p, num);
    }
  };

  typedef std::basic_string<char, std::char_traits<char>, allocator<char> > string;
}

int main()
{
  {
    secure::string bar("bar");
    secure::string longbar("baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaar");
  }
}

However, it turns out, depending on how std::string is implemented, it is possible that the allocator isn't even invoked for small values. In my code, for example, the deallocate doesn't even get called for the string bar (on Visual Studio).

The answer, then, is that we cannot use std::string to store sensitive data. Of course, we have the option to write a new class that handles the use case, but I was specifically interested in using std::string as defined.

Thanks everyone for your help!

Upvotes: 17

Tomek
Tomek

Reputation: 4659

std::string mystring;
...
std::fill(mystring.begin(), mystring.end(), 0);

or even better write your own function:

void clear(std::string &v)
{
  std::fill(v.begin(), v.end(), 0);
}

Upvotes: -2

Andrew Rasmussen
Andrew Rasmussen

Reputation: 15099

std::string is based on a char*. Somewhere behind all the dynamic magic as a char*. So when you say you don't want to use char*'s on your code, you are still using a char*, it's just in the background with a whole bunch of other garbage piled on top of it.

I'm not too experienced with process memory, but you could always iterate through each character (after you've encrypted and stored the password in a DB?), and set it to a different value.

There's also a std::basic_string, but I'm not sure what help that would do for you.

Upvotes: -1

Related Questions