Rfc2898DeriveBytes + PBKDF2 + SecureString можно ли использовать безопасную строку вместо строки?

После некоторого исследования и просмотра предыдущих ответов на stackoverflow, в которых упоминается SecureString, этот ответ почти наверняка: «Нет». Только создатели API могут принять SecureString и правильно обработать его внутри. И они могут сделать это только с помощью платформы.

Если бы вы - как пользователь - могли получить простой текст String, вы бы в первую очередь свели на нет большинство преимуществ использования SecureString. Это было бы даже немного опасно, поскольку вы создавали бы безопасный код, который на самом деле был бы совсем небезопасным.

Мне показалось интересным, что Rfc2898DeriveBytes не поддерживает SecureString перегрузка для передачи пароля, используемого при получении ключа.

WPF позволяет обрабатывать пароли как SecureString объекты с _ 4_ контроль. Казалось, что дополнительная безопасность, которую предлагает этот элемент управления, была потеряна из-за того, что мы не могли передать SecureString конструктору. Однако erickson поднял отличный момент использования byte[] вместо string перегрузки, поскольку относительно легче правильно управлять содержимым byte[] в памяти, чем string.

Вдохновленный предложением Эриксона, я придумал следующую оболочку, которая должна позволять использовать значение пароля, защищенного SecureString, с минимальным раскрытием значения открытого текста в памяти.

private byte[] DeriveKey(SecureString password, byte[] salt, int iterations, int keyByteLength)
{
    IntPtr ptr = Marshal.SecureStringToBSTR(password);
    byte[] passwordByteArray = null;
    try
    {
        int length = Marshal.ReadInt32(ptr, -4);
        passwordByteArray = new byte[length];
        GCHandle handle = GCHandle.Alloc(passwordByteArray, GCHandleType.Pinned);
        try
        {
            for (int i = 0; i < length; i++)
            {
                passwordByteArray[i] = Marshal.ReadByte(ptr, i);
            }

            using (var rfc2898 = new Rfc2898DeriveBytes(passwordByteArray, salt, iterations))
            {
                return rfc2898.GetBytes(keyByteLength);
            }
        }
        finally
        {
            Array.Clear(passwordByteArray, 0, passwordByteArray.Length);  
            handle.Free();
        }
    }
    finally
    {
        Marshal.ZeroFreeBSTR(ptr);
    }
}

В этом подходе используется тот факт, что BSTR - это указатель, указывающий на первый символ строки данных с четырехбайтовым префиксом.

Важные моменты:

• Заключая Rfc2898DeriveBytes в оператор using, он обеспечивает его детерминированное удаление. Это важно, поскольку у него есть внутренний HMACSHA1 объект, который является KeyedHashAlgorithm, и для его обнуления при вызове Dispose требуется копия ключа (пароля), которым он обладает. Для получения полной информации см. Справочный источник.
• Как только мы закончим с BSTR, мы обнуляем его и освобождаем через ZeroFreeBSTR.
• Наконец, мы обнуляем (очищаем) нашу копию пароля.
• Обновление: добавлено закрепление byte[]. Как обсуждалось в комментариях к этому ответу, если byte[] не закреплен, то сборщик мусора может переместить объект во время сбора и у нас не останется возможности обнулить исходную копию.

Это должно сохранить пароль в виде открытого текста в памяти в течение кратчайшего времени и не ослабить слишком много преимуществ использования SecureString. Хотя, если у злоумышленника есть доступ к оперативной памяти, у вас, вероятно, проблемы посерьезнее. Другой момент заключается в том, что мы можем управлять только нашими собственными копиями пароля, API, который мы используем, вполне может неправильно управлять (не обнулять / очищать) их копии. Насколько мне известно, это не относится к Rfc2898DeriveBytes, хотя их копия byte[] ключа (пароля) не закреплена, и поэтому следы массива могут остаться, если он был перемещен в кучу до обнуления. Сообщение здесь в том, что код может выглядеть безопасным, но проблемы могут быть скрыты под ним.

Если кто-нибудь обнаружит серьезные дыры в этой реализации, дайте мне знать.

Очевидно, вы можете нарушить защиту, предоставляемую SecureString и раскрыть его внутреннее состояние с помощью функции Marshal.SecureStringToBSTR().

Вместо того, чтобы создавать String из результата, скопируйте содержимое в Byte[], чтобы передать Rfc2898DeriveBytes. Создание String не позволит вам уничтожить информацию о пароле, позволяя ему оставаться в куче на неопределенное время или выгружаться на диск, что, в свою очередь, увеличивает шансы того, что злоумышленник сможет его найти. Вместо этого вы должны уничтожить пароль, как только вы закончите его использовать, заполнив массив нулями. По той же причине вы также должны присвоить ноль каждому элементу BSTR, когда вы копируете его в Byte[].

Соль следует выбирать случайным образом для каждого хешированного пароля, а не фиксированного предсказуемого значения, в противном случае возможна атака по заранее вычисленному словарю. Вы должны повторить много десятков тысяч раз, чтобы предотвратить атаки методом грубой силы.