Comments 19
Спасибо!
Побольше бы таких статей!
Побольше бы таких статей!
Не могли бы вы пояснить, что понимается под симметричным алгоритмом аутентификации?
В этой системе, как я понял, при регистрации пользователя у него остаётся H(P), а в базу сервера записывается HN(P). То есть пользователь с помощью своего ключа может определить, что хранится в базе сервера, а обратный процесс невозможен. Похоже на генерацию пары «открытый-закрытый ключ» в ассиметричном шифровании.
В чём тогда заключается симметричность данного алгоритма?
В этой системе, как я понял, при регистрации пользователя у него остаётся H(P), а в базу сервера записывается HN(P). То есть пользователь с помощью своего ключа может определить, что хранится в базе сервера, а обратный процесс невозможен. Похоже на генерацию пары «открытый-закрытый ключ» в ассиметричном шифровании.
В чём тогда заключается симметричность данного алгоритма?
В том, что хотя использование PKI всеже рекоммендуется, без него схема может обойтись.
Да, Вы правы, HN(P) напоминает по характеру использования открытый ключ, хотя и «одноразовый». Используя термин «симметричный», я хотел подчеркнуть тот факт, что в схеме используются только примитивы из «симметричной» криптографии, как гораздо более простые и в реализации и в понимании.
ха, вынес для себя идею не совсем связанную с темой:
пароль следует хэшировать прямо на клиенте, чтобы по каналу вовсе не передавалось кодовое слово в открытом виде. эх, стоило бы в html5 добавить такую фишку, расширяющую стандартный input password:
пароль следует хэшировать прямо на клиенте, чтобы по каналу вовсе не передавалось кодовое слово в открытом виде. эх, стоило бы в html5 добавить такую фишку, расширяющую стандартный input password:
Тогда хеш достаточно будет перехватить один раз и посылать серверу от имени клиента.
блин, ну зачем же теги съедать, можно же просто htmlspecialchars для недостойных.
вот что проглатило
input type=«hashedPassword» type=«соль установленная на сервере» algoritm=«md5»
сорри, я злостный тролль и могу постить лишь раз в час. поэтому отвечаю здесь.
Andrew1000000
там проглатилась часть, оснавная мысль в соли и выборе алгоритма, которые будут более-менее уникальными для разных ресурсов. воровство пароля не даст воспользоваться им на других проектах. пользователи же любят на одном пароле хранить всё.
вот что проглатило
input type=«hashedPassword» type=«соль установленная на сервере» algoritm=«md5»
сорри, я злостный тролль и могу постить лишь раз в час. поэтому отвечаю здесь.
Andrew1000000
там проглатилась часть, оснавная мысль в соли и выборе алгоритма, которые будут более-менее уникальными для разных ресурсов. воровство пароля не даст воспользоваться им на других проектах. пользователи же любят на одном пароле хранить всё.
И как это нас спасет?
Уж если думать в соленом направлении, то клиент должен посылать соль и хэш(соль+пароль). Или, чтобы не требовать от сервера хранения пароля в открытом виде, соль и хэш(соль+хэш(пароль)). А еще лучше — соль1 и хэш(соль1+хэш(пароль+соль2)), где соль2 получена от сервера.
Уж если думать в соленом направлении, то клиент должен посылать соль и хэш(соль+пароль). Или, чтобы не требовать от сервера хранения пароля в открытом виде, соль и хэш(соль+хэш(пароль)). А еще лучше — соль1 и хэш(соль1+хэш(пароль+соль2)), где соль2 получена от сервера.
по каналу будет передаваться уже хэшированный пароль и это решает проблему простого сканирования трафика.
да, а соль можно на клиенте генерировать и посылать вместе с хэшем, это прекрасная идея.
да, а соль можно на клиенте генерировать и посылать вместе с хэшем, это прекрасная идея.
Просто хэшированный пароль можно перехватить и использовать в дальнейшем. Потому как:
1) Сервер не может гарантировать уникальность соли. (И попытки это сделать — серьезное усложнение.)
2) Для того, чтобы каждый раз предлагать новую соль, необходимо держать пароль на сервере в открытом виде. (Что, конечно, используется, но крайне нежелательно. И совсем уж стыдно об этом упоминать в контексте статьи.)
1) Сервер не может гарантировать уникальность соли. (И попытки это сделать — серьезное усложнение.)
2) Для того, чтобы каждый раз предлагать новую соль, необходимо держать пароль на сервере в открытом виде. (Что, конечно, используется, но крайне нежелательно. И совсем уж стыдно об этом упоминать в контексте статьи.)
Или из базы украсть.
Год назад защищал диплом о применении схемы Лесли Лэмпорта в системах двухфакторной аутентификации. Проблему переинициализации тогда решал генерацией новой цепочки.
А что если наоборот, урезать цикл переинициализации до минимума, для слабых клиентов (т. е. JS)? Например, пусть Pk = H (servername || password || k), где k — номер цикла. В самом начале передаём на сервер H²(P1). При следующей аутентификации передаём H(P1) и H²(P2). По H(P1) сервер проверяет, что это и в самом деле мы (беря от него хэш и сравнивая с имеющимся значением H²(P1)), а H²(P2) сохраняет для след. аутентификации. И так далее.
Есть ли тут какие-то подводные камни?
Есть ли тут какие-то подводные камни?
т.е. это что-то вроде клиентского генератора серии одноразовых паролей, из которых сервер хеш-функцией по номеру пароля можно прийти к известному ключу? Занятно!
А что будет когда будет сделано P аутентификаций?
А это разве не разновидность прыгающих кодов, которые запатентованы по самое не могу? И давно применяются в более упрощённом виде во всех нормальных автомобильных сигнализациях.
Sign up to leave a comment.
Lamport hash chain – страховка от кражи базы паролей клиентов