Изменение пароля на веб-интерфейсе с защитой от повторных атак - PullRequest
Новая
       34

Изменение пароля на веб-интерфейсе с защитой от повторных атак

2 голосов
/ 22 февраля 2011

У меня есть веб-приложение (ExtJS + perl), в котором есть диалог «Изменить пароль».Я хочу реализовать изменение пароля таким образом, чтобы, даже если трафик прослушивался и хеш нового пароля перехватывался, злоумышленник ничего не мог с этим поделать.

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

  • клиент запрашивает запрос с сервера (например: 031fee1c)

  • клиент шифрует пароль с помощью этого алгоритма:

    hash = sha1 (sha1 (clearPassword) + вызов)

  • клиент отправляет хэш и аутентифицируется сервером

Это предотвращает атаки воспроизведения, посколькухеш не будет работать без вызова (сервер знает только sha1 (clearPassword).

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

Любые идеи / предложения о том, как мне отправить новый зашифрованный пароль обратно на сервер?

1 Ответ

0 голосов
/ 22 февраля 2011

Вы можете реализовать свой собственный криптографический ключ с открытым ключом. Например, сделайте обмен ключами Диффи-Хеллмана и зашифруйте ваш SHA-1(new password). Я не уверен, есть ли хорошая библиотека для этого, но это относительно просто, как показывает этот пример . Обратите внимание, что в реальном коде вы бы использовали различные значения (выделите "Диффи-Хеллман") для p и g и выбирали a и b случайным образом между 2 и p-2.

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

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

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

...