LINUX.ORG.RU

авторизация пользователей


0

2

Не хочу передавать пароль открытым текстом. Поэтому сделал такую схему:

1) на сервере генерятся строку их случайных символов (например, abcdef), она передается клиенту.

2) клиент вводит логин и пароль, к полученным символам дописывает пароль, получая abcdefpassword.

3) полученная строка хешируется и передается серверу

4) сервер тоже хеширует строку с паролем, взятым из базы.

5) сравниваем хеши, если хорошо - записываем вход и выдаем куку.

Какие потенциальные проблемы при такой схеме, кроме возможности кражи куки?

Какие используются варианты без кук?

★★★★★

блять да где же в беретесь-то?? три звезды, а потом скандалы со сворованными паролями...

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

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

val-amart ★★★★★
()
Ответ на: комментарий от val-amart

да где же в беретесь-то??

Физик он :}

Deleted
()

Причём тут авторизация вообще?

Apple-ch ★★
()
Ответ на: комментарий от val-amart

при авторизации снова считай и сравнивай.

Ну и чем этот посчитанный хэш отличается от пароля простым текстом?

Напоминает перехват хеша пароля в SMB. Автор статьи потом модифицировал smbclient, чтобы она хеши не хешировала второй раз — и получал доступ к ресурсу.

i-rinat ★★★★★
()
Ответ на: комментарий от val-amart

Какой толк от постоянной соли на стороне клиента?

Что-то мне кажется, что если нельзя хранить пароль в открытом виде, то без алгоритма Диффи-Хеллмана не обойтись (и то, от человека посередине не защитит).

crowbar
()
Ответ на: комментарий от val-amart

cразу на клиенте считай хеш с солью, так и записывай в базу

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

cvs-255 ★★★★★
() автор топика
Ответ на: комментарий от crowbar

Нужно защитить от перехвата пароля при mitm.

cvs-255 ★★★★★
() автор топика

Используй ssl, Люк.

anonymous
()

По сути такие же, как и при передаче пароля plain-text'ом. Имей ввиду, что всё, что есть на клиенте (включая алгоритм хэширования и контрольную серверную строку), доступно всем.

Лучше либо шифровать само соединение, либо использовать, как тебе уже сказали, отдельный сервис авторизации.

barti_ddu
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.