?

Log in

No account? Create an account

[icon] Три года назад я в своём ЖЖ задавался вопросом, как избавить сайт от… - Давид Мзареулян
View:Свежие записи.
View:Архив.
View:Друзья.
View:Личная информация.
View:Website (Мои фотографии).
View:Иероглиф. hiero.ru/David. RSS2LJ. Здешние теги.

Tags:,
Security:
Time:11:37 am
Три года назад я в своём ЖЖ задавался вопросом, как избавить сайт от необходимости знания паролей пользователей. Хотелось не хранить на сервере (а также не передавать на него, в том числе на этапе регистрации юзера) ничего такого, что, будучи украденным, позволит войти от имени пользователя.

Тогда так ничего толкового и не придумали. А на днях на Хабре появилась статья про цепочки хэшей Лэмпорта, которые именно эту проблему и решают, причём очень просто и изящно. Метод аж 1981-го года (вот что значит отсутствие (у меня) IT-образования).

Я там в комментариях предложил небольшую модификацию метода для слабых клиентов (браузеров с JS). Хотел бы узнать, нет ли в ней какой-нибудь дырки. Если нет, то это выглядит очень симпатичным решением именно для веб-сайтов. Ещё интересно, что этот протокол содержит в себе возможность смены пароля прямо при авторизации (потому что H²(P2) запросто может браться уже от нового пароля).
Комментарии: написать Previous Entry Поделиться Next Entry


lazylonelion
Link:(Link)
Time:2011-06-07 08:06 am
наверное всё же надо не Н(Р) и не Н2(Р2), а НА(Р) и не НА(Р2). Иначе получается не Лэмпорт, а практически обычное хранение хешей пароля.
Или я недостаточно вник в предложенную схему.

Ещё могут быть проблемы с синхронизацией, как-то:
1. Если клиент не понял, что он успешно авторизовался (изза сбоя сети, прокси, и т.п.).
2. Если сервер не понял, что клиент авторизовался.
3. Если у клиента несколько компов (или если взломщик авторизовался вместо честного клиента) -- не сообьётся ли цепочка?
4. наверное есть ещё трудные случаи.
(Ответить) (Thread)


lazylonelion
Link:(Link)
Time:2011-06-07 08:09 am
...а НА(Р) и не НА(Р2)
а НА(Р) и НА(Р2)
(Ответить) (Parent) (Thread)


david_m
Link:(Link)
Time:2011-06-07 08:21 am
Собственно, мой метод — это просто Лэмпорт при N = 2. Соответственно, A у него всегда равно 1.

Нет, это совсем не обычное хранение хэшей. Тут важно именно то, что хранится не хэш, а двойной хэш. Пусть юзер регистрируется и вводит что-то в поле «пароль». Клиент считает P1 = H(seed || password || 1) и посылает на сервер H(H(P1)). Сервер запоминает а) значение счётчика “1” и б) H(H(P1)). Теперь для того чтобы авторизоваться, клиент должен послать на сервер H(P1). Сервер возьмёт от него хэш и сравнит с имеющимся у него. Но если ты не знаешь H(P1), то любое прослушивание трафика и просмотр базы дадут тебе только H(H(P1)). А по нему H(P1) вычислить нельзя. Даже если подслушать сам процесс авторизации (когда передаётся H(P1)), то это всё рано ничего не даст, т. к. при авторизации хранящийся на сервере H(H(P1)) заменяется на H(H(P2)) и всё начинается сначала.
(Ответить) (Развернуть) (Parent) (Thread)


david_m
Link:(Link)
Time:2011-06-07 08:24 am
1. Ну не понял и не понял. Обновит страничку, получит следующее значение счётчика и введёт пароль заново.
2. Опять же, если не понял, значит ничего у себя не трогает, ждёт второй попытки.
3. Если взломщик смог авторизоваться, значит, у него есть пароль. Тут мы ничего сделать не можем, мы не можем различить двух людей, если оба знают пароль. Есть одна проблема — если взломщик как-то узнал пароль, то он может «тихо» его сменить, и это нельзя будет отследить на уровне сервера.
(Ответить) (Parent) (Thread)


david_m
Link:(Link)
Time:2011-06-07 08:28 am
А, ну и номер итерации, конечно, сообщается клиенту. Иначе всё посыпется после первой же смены браузера:)
(Ответить) (Развернуть) (Parent) (Thread)


1master
Link:(Link)
Time:2011-06-07 08:07 am
Я смотрю первый ответ в виде заминусованного вопроса ты уже получил.

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


david_m
Link:(Link)
Time:2011-06-07 08:10 am
Минус на хабре не имеет информационной ценности. Так что лучше бы поконкретнее:) Пространство чего именно сужается?
(Ответить) (Развернуть) (Parent) (Thread)


dma
Link:(Link)
Time:2011-06-07 08:23 am
Чем ближе хвост - тем меньше вероятность, что на него наступят!

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

Только сервер должен отдавать k клиенту, понятнодело. А то куча проблем с синхронизацией.

И проблема реинициализации не стоит - число k может быть сколь угодно большим, оно ж идёт от 1 до MAXINT.

Там, конечно, может что-то ловиться, потому что у злоумышленника при правильном подходе накапливается массив H(Pn) и H2(Pn)..
(Ответить) (Развернуть) (Parent) (Thread)


basanov
Link:(Link)
Time:2011-06-07 08:27 am
По факту P и является паролем пользователя, ибо его надо как-то хранить.

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

И да, точно так же никакая кража сервера не позволит авторизоваться под клиентом. И даже цепочек не надо инициализировать.

Ну и если не хочется делать честный SSL, то можно считать почти то же самое, но в JS. Смысла никакого, но почему бы и нет, если хочется?
(Ответить) (Thread)


dma
Link:(Link)
Time:2011-06-07 08:29 am
Зачем хранить P?
(Ответить) (Parent) (Thread)


david_m
Link:(Link)
Time:2011-06-07 08:29 am
Он не является паролем в классическом виде (shared secret), поскольку он одноразовый, и при каждом цикле авторизации заменяется на новый.

Ну как ты выдашь простому юзеру-блондинке SSL-сертификат? Это нереально.
(Ответить) (Развернуть) (Parent) (Thread)


dma
Link:(Link)
Time:2011-06-07 08:34 am
Эй, эй, зачем вообще его хранить?
Из хранимого только H2(Pk) и k. Всё остальное прекрасно вычисляется, а вреда от того, что злоумышленнег узнает k нет - ну, не больше, чем вреда в том, что злоумышленник знает соль в классических хэшированых паролях.

Прекращал бы ты читать хабр, а? Он на тебя плохо влияет.
(Ответить) (Развернуть) (Parent) (Thread)


dma
Link:(Link)
Time:2011-06-07 08:35 am
Ну и олсо оба эти параметра хранятся на сервере, на клиенте вообще не хранится ничего.
(Ответить) (Parent) (Thread)


dzz
Link:(Link)
Time:2011-06-07 09:21 am
Из принципиально слабых мест модифицированного алгоритма я вижу только одно - Hk(P) существенно лучше размывает неравномерность P, чем H(F(P,k)) при случайном значении k и обратимом преобразовании F.

Т.е. теоретически если H(P) даёт равномерное распределение на последовательных P, то разницы быть не должно, но на практике бывают корреляции.

От man-in-the-middle оба варианта, понятное дело, не защищают совсем.

Edited at 2011-06-07 09:26 (UTC)
(Ответить) (Thread)


david_m
Link:(Link)
Time:2011-06-07 09:44 am
В принципе (хоть меня dma там выше и ругает) вместо последовательных чисел k можно использовать последовательные хэши какой-нибудь строки (может быть даже с солью на каждом шаге).
(Ответить) (Развернуть) (Parent) (Thread)

[icon] Три года назад я в своём ЖЖ задавался вопросом, как избавить сайт от… - Давид Мзареулян
View:Свежие записи.
View:Архив.
View:Друзья.
View:Личная информация.
View:Website (Мои фотографии).
View:Иероглиф. hiero.ru/David. RSS2LJ. Здешние теги.