C # Чтение зашифрованных паролей

Question

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

Спасибо

using System.Security.Cryptography;

public static string EncodePasswordToBase64(string password)
{  byte[] bytes   = Encoding.Unicode.GetBytes(password);
   byte[] dst     = new byte[bytes.Length];
   byte[] inArray = HashAlgorithm.Create("SHA1").ComputeHash(dst);
   return Convert.ToBase64String(inArray);
}

Answer 1

SHA1 - это алгоритм hash , а не алгоритм шифрования. Алгоритм хеширования - это односторонняя функция, которая преобразует данные в хеш этих данных, но исходные данные не могут быть получены из хеша. Алгоритм шифрования - это двусторонняя функция, которая преобразует данные в зашифрованные данные, и затем зашифрованные данные могут быть преобразованы обратно в исходные данные.

Answer 2

Чтобы надежно сохранить пароль и прочитать его, используйте класс ProtectedData .

public static string ProtectPassword(string password)
{
    byte[] bytes = Encoding.Unicode.GetBytes(password);
    byte[] protectedPassword = ProtectedData.Protect(bytes, null, DataProtectionScope.CurrentUser);
    return Convert.ToBase64String(protectedPassword);
}

public static string UnprotectPassword(string protectedPassword)
{
    byte[] bytes = Convert.FromBase64String(protectedPassword);
    byte[] password = ProtectedData.Unprotect(bytes, null, DataProtectionScope.CurrentUser);
    return Encoding.Unicode.GetString(password);
}

Answer 3

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

Answer 4

Вы не.

SHA1 - это хэш, а не шифрование. Это односторонняя операция; обратное преобразование невозможно.

(Хорошо, это не совсем верно; если у вас есть таблица возможных значений SHA1 и значений простого текста, радужная таблица, тогда вам может повезти)

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

Answer 5

Хорошо, я знаю, что это не отвечает на ваш конкретный вопрос, но почему вы хотите преобразовать его обратно?

Если сравнивать для обеспечения аутентификации, стандартным подходом является также шифрование этого текста, а также сравнение сохраненного пароля с предоставленным паролем.

Это более безопасно, поскольку это означает, что исходный пароль никогда не нужно расшифровывать.

Answer 6

Чтобы использовать класс System.Security.Cryptography.ProtectedData, необходимо добавить ссылку на System.Security в свой проект.

(Щелкните правой кнопкой мыши папку «Ссылки», выберите «Добавить ссылку ...», найдите System.Security на вкладке .NET)

Answer 7

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

Как сказал кто-то другой, вычислите хеш из пароля пользователя и сравните с сохраненным значением хеша.

Answer 8

Хм, просто любопытно, но разве это не возвращает одинаковый хеш для всех паролей одинаковой длины?

Answer 9

Я заметил недавнее добавление класса XMLEncryptedData. Для шифрования данных в файл XML метод XMLEncryptedData более желателен, чем метод DPAPI?

Answer 10

Вы хотите использовать шифрование, а не хэширование. SHA в порядке, но используйте для этого методы шифрования. Проблема с шифрованием всегда в том, где поставить ключ для него. Вы не упомянули, была ли это рабочая станция или сервер, на котором вы это делали. На сервере я считаю, что лучше использовать ACL для ограничения доступа к ключу reg. Администраторы обычно могут получить доступ к ключу шифрования в любом случае ... вам нужно где-то доверять. На рабочей станции вы можете использовать шифрование и хранить ключ в коде или использовать сертификат и ограничить доступ к нему, по крайней мере, в корпоративной среде ... не для продажи программного обеспечения).

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