Можно ли определить строку ввода пароля в виде открытого текста или хэшированного? - PullRequest
Новая
       14

Можно ли определить строку ввода пароля в виде открытого текста или хэшированного?

3 голосов
/ 31 марта 2010

У меня есть RESTful API, содержащий URI / UserService / Register./ UserService / Register принимает запрос XML, такой как: 

<UserRegistrationRequest>
  <Password>password</Password>
  <Profile>
    <User>
      <UserName>username</UserName>
    </User>
  </Profile>
</UserRegistrationRequest>

У меня есть следующие вопросы с учетом приведенного выше сценария:

  1. Есть ли способ (с использованием C # и.Net 3.5+) для обеспечения / проверки того, что клиенты, вызывающие реестр, передают хешированный пароль, а не открытый текст?Хорошая идея - оставить выбор алгоритма хеширования для использования клиентом?

  2. Мы могли бы предоставить второй URI / UserService / ComputePasswordHash, который клиент будет вызывать перед вызовом / UserService /Регистр.Это дает преимущество, заключающееся в том, что каждый пароль хэшируется с использованием одного и того же алгоритма.Есть ли в REST механизм, обеспечивающий, чтобы клиент вызывал один URI перед вызовом другого?

Надеюсь, я хорошо все объяснил.

Заранее большое спасибо залюбая помощь.

Ответы [ 3 ]

3 голосов
/ 31 марта 2010

Передача хешированного пароля в службу REST не более безопасна, чем очистка пароля. Если пароль прослушан, не имеет значения, хеширован он или нет, его можно использовать.

Лучше всего хешировать пароль на сервере и принимать только безопасные соединения (SSL / https)

0 голосов
/ 31 марта 2010

Хеширование не было бы хорошей идеей. Еще лучше было бы либо использовать SSL, либо использовать его подмножество самостоятельно, используя API шифрования с открытым ключом в .NET Framework.

Вы выставите функцию GetPublicKey (), которая вернет открытый ключ, с помощью которого пользователь зашифрует свой пароль и отправит его вам. Затем используйте свой закрытый ключ, чтобы расшифровать его. И проверьте, правильно ли это. RSA или эллиптические кривые с открытым ключом очень хороши. Просто используйте 1024bit.

UPDATE: проверьте это пример , а также это из MSDN

0 голосов
/ 31 марта 2010

Это плохая идея позволять клиентам самим хэшировать пароли. Вообще говоря, хэширование пароля only не очень надежно: к паролю необходимо добавить случайную соль, чтобы одни и те же пароли приводили к разным значениям хэша. При этом клиент должен будет генерировать солт (предпочтительно с использованием криптографически безопасного алгоритма), вычислять хеш результирующего кода (используя совместимую реализацию хорошо известного алгоритма хеширования) и затем отправлять три части информации обратно на сервер:

  • Имя алгоритма хеширования
  • Соль
  • Хешированный пароль

Что если на сервере нет реализации конкретного алгоритма хеширования? Что делать, если алгоритм хеширования клиента дает другие результаты по сравнению с алгоритмом сервера?

Теперь вернемся к вашим вопросам:

  • Вы можете принудительно ввести пароль в кодировке Base64, а затем проверить, содержит ли эта строка, преобразованная обратно в массив byte, непечатные символы, которые, скорее всего, появятся в хэш-значении. Хотя их там может и не быть
  • Вы можете включить какой-то токен в ответ от ComputePasswordHash, а затем потребовать, чтобы ваши клиенты передали этот токен обратно Register
...