Расшифровка зашифрованного пароля из членства в ASP.NET с использованием RijndaelManaged

Question

Суть заключается в создании custom FTP Authentication Provider. Для этого нужно наследовать от интерфейса IFtpAuthenticationProvider, а затем зарегистрировать эту сборку в GAC. После этого сборка должна быть зарегистрирована в настройках FTP IIS.

Для этого необходимо использовать базу данных, содержащую мою информацию о пользователе в базе данных, из специализированных поставщиков членства и роли, которые мы разработали ранее. Таким образом, это означает, что я должен использовать файл локальной библиотеки app.config и читать его с помощью ConfigurationManager.OpenMappedExeConfiguration(). Я прочитал строки подключения оттуда, и я даже могу provide it to Linq-To-Sql classes dynamically. Нет проблем.

Далее я пытаюсь использовать create a class that inherits from SqlMembershipProvider, чтобы использовать его собственную систему для дешифрования пароля для пользователя. Но проблема в том, что она должна читать значения machineKey из конфигурации. Единственный способ предоставить пользовательскую конфигурацию SqlMembershipProvider - это метод Initialize (который не предназначен для использования в нашем коде). Но в любом случае я пробовал и терпел неудачу. Я смог предоставить ему настройки пользовательского членства, но не настройки machineKey.

Итак, я решил пойти радикально. Я сказал: у меня есть decryptionKey от machineKey, поэтому я попытаюсь дешифровать пароль вручную.

До сих пор я попытался с помощью RijndaelManaged:

private string UnEncodePassword(string encodedPassword, string secretKey) 
    { 
     string password = encodedPassword; 

     var keyBytes = new byte[16]; 
     var secretKeyBytes = Encoding.UTF8.GetBytes(secretKey); 
     Array.Copy(secretKeyBytes, keyBytes, Math.Min(keyBytes.Length, secretKeyBytes.Length)); 

     RijndaelManaged rm = new RijndaelManaged 
     { 
      Mode = CipherMode.CBC, 
      Padding = PaddingMode.PKCS7, 
      KeySize = 128, 
      BlockSize = 128, 
      Key = keyBytes, 
      IV = keyBytes 
     }; 

     var encryptedBytes = Convert.FromBase64String(encodedPassword); 
     password = Encoding.UTF8.GetString(Decrypt(encryptedBytes, rm)); 

     return password; 
    } 

Я вроде знаю, что я буду стрелять пробелы здесь, так как я не уверен, что накануне своего рода дополнения используется и самое главное даже если бы я мог не попасть в правый IV. Лучшее, что я сделал до сих пор, - это получить какой-то неприятный ответ, например: 21l < ( \ t ].

Так что мне нужны указатели. другая точка зрения приветствуется

EDIT:...

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

Answer 1

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

Но так как вы не можете выбрать, почему вы должны использовать Encryption или Decription методы из MembershipProvider (кстати, я даже не думаю, что это возможно).

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

Answer 2

Вы не должны расшифровывать пароли. Вы должны сравнивать хэши паролей.

Пароли не должны храниться с обратимым шифрованием. Пароли предназначены для хранения как хэши (а не MD5, он слишком слаб).

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

Редактировать: Что касается того факта, что вы используете passwordFormat="Encrypted" для поставщика членства SQL.С помощью этого факта вы можете либо зашифровать пароль в том же формате, с тем же дополнением, cipherMode и IV (вам нужно будет запросить это из базы данных SQL), а затем просто сравните зашифрованные значения пароля. Это, скорее всего, ненужная работа. Вы действительно просто хотите вызвать функцию входа в членство в коде с комбинацией имени пользователя и пароля и проверить, успешна она или нет. Вам нужно будет убедиться, что ключи машины и соответствующие элементы совпадают в обеих системах, иначе вы не сможете добиться успеха.

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

Answer 3

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

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

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

Алгоритм Аутентифицировать должен выглядеть следующим образом:

1. Получить соль хэширования (может быть, что вы используете соль, уникальный для каждого пользователя, или глобальный)
2. Генерирование хэш пользователя пароль.
3. Сравните хешированный пароль с тем, который был сохранен в вашей базе данных для указанного имени пользователя (при использовании LINQ-to-SQL простой оператор Any может это сделать).
4. Возвращает значение, указывающее на успех или неудачу.