В книге Шнайера описывается способ подбора пароля с использованием словаря. Также описывается способ добавления "соли" перед хэшированием. Насколько возможно использование nickname в качестве "соли"?
Комментарии
— SATtva (16/01/2006 16:17) Никнэйм лучше, конечно, в качестве перца. :) Если уж совсем не хотите использовать английское salt, есть русский термин "привязка".
В роли привязки может выступать любая строка, вероятность появления которой в словаре достаточно мала. Лучший вариант — какие-нибудь случайные и всякий раз разные биты. Но может быть и никнэйм. Суть в том, что если Вы используете salt, противнику придётся составлять второй словарь и для этой привязки. (Т.е. для такого словаря ему придётся хэшировать все слова и фразы из первого, конкатенированные с этой привязкой.)
Если же в каждом пароле используется уникальная случайная привязка, оппонент теряет практическую возможность создавать словари и библиотеки хэшей для подбора паролей.
— GraDea (16/01/2006 16:36) Насчет перца не знаю. Книгу качал с данного сайта и там используется именно термин "соль". "Я ж еще не волшебник, я только учусь..." :)
Как я понял: возможность подбора пароля для ОТДЕЛЬНО ВЗЯТОГО пользователя что с привязкой, что без таковой одинакова. И значение привязки для каждого пользователя не представляет тайны. Верно ли?
— SATtva (16/01/2006 16:53) Вы всё поняли верно. Привязка не секретна, как и вектор инициализации алгоритма, к примеру. Главное, что её использование не позволяет оппоненту создать один большой словарь всех возможных паролей и щёлкать с его помощью любое сообщение. Целенаправленную атаку на конкретный пароль это осложняет только в том смысле, что оппоненту придётся выполнять массу предварительных вычислений для создания новой копии своего словаря с данной привязкой.
— Гость (16/01/2006 20:37) Еще одна роль привязки (она же "соль"), чтобы скрыть факт одинаковых паролей у разных пользователей. Для этой цели nickname может быть адекватным выбором. Дело в том, что в некоторых случаях привязку негде хранить, и тогда приходится пользоваться каким-то уникальным идентификатором в качестве привязки.
— GraDea (17/01/2006 09:49) Спасибо!
И еще вопрос!
Если мы используем логин, как привязку, и значение хэш-функции, вычисленной по пароль+логин, есть в БД, то это автоматом означает, что и логин, и пароль верные. То есть по логину можно даже не искать?
Здесь правда вопрос быстродействия, а именно что лучше: найти сначала логин и проверить хэш или сразу искать по хэшу. Учитывая среднюю длину строк, мне кажется, первый вариант быстрее. Но второй хорош тем, что кроме вычисленного хэша с клиента ничего не уходит (в явном виде, т.е. зависит от технологии), а приходит только подтверждение логин+пароль верны или нет.
Я пока не силен в этой теме, буду рад указаниям/замечаниям...
Что, где можно почитать об этом (желательно на русском)? Как это реализовано, например, здесь? Хотя бы в общих чертах...
— SATtva (20/01/2006 00:03)
Если мы используем логин, как привязку, и значение хэш-функции, вычисленной по пароль+логин, есть в БД, то это автоматом означает, что и логин, и пароль верные. То есть по логину можно даже не искать?
Да. Если логин или пароль ошибочны, результат хэширования будет другим.
Здесь правда вопрос быстродействия, а именно что лучше: найти сначала логин и проверить хэш или сразу искать по хэшу.
Для защищённой системы я бы индексировал и сравнивал только хэши. Различия в скорости всё равно незначительны. Конечно, если архитектура Вашей системы не исходит из каких-то особых требований к масштабированию и т.д. В этом случае лучше предварительно оттестировать.
Как это реализовано, например, здесь? Хотя бы в общих чертах...
В этом форуме? Здесь обычный движок phpBB, можете сами посмотреть исходники. Привязка не используется, хэшируется только пароль. Индексом в БД служит имя пользователя, по нему же производится поиск.
Никнэйм лучше, конечно, в качестве перца. :) Если уж совсем не хотите использовать английское salt, есть русский термин "привязка".
В роли привязки может выступать любая строка, вероятность появления которой в словаре достаточно мала. Лучший вариант — какие-нибудь случайные и всякий раз разные биты. Но может быть и никнэйм. Суть в том, что если Вы используете salt, противнику придётся составлять второй словарь и для этой привязки. (Т.е. для такого словаря ему придётся хэшировать все слова и фразы из первого, конкатенированные с этой привязкой.)
Если же в каждом пароле используется уникальная случайная привязка, оппонент теряет практическую возможность создавать словари и библиотеки хэшей для подбора паролей.
Насчет перца не знаю. Книгу качал с данного сайта и там используется именно термин "соль". "Я ж еще не волшебник, я только учусь..." :)
Как я понял: возможность подбора пароля для ОТДЕЛЬНО ВЗЯТОГО пользователя что с привязкой, что без таковой одинакова. И значение привязки для каждого пользователя не представляет тайны. Верно ли?
Вы всё поняли верно. Привязка не секретна, как и вектор инициализации алгоритма, к примеру. Главное, что её использование не позволяет оппоненту создать один большой словарь всех возможных паролей и щёлкать с его помощью любое сообщение. Целенаправленную атаку на конкретный пароль это осложняет только в том смысле, что оппоненту придётся выполнять массу предварительных вычислений для создания новой копии своего словаря с данной привязкой.
Еще одна роль привязки (она же "соль"), чтобы скрыть факт одинаковых паролей у разных пользователей. Для этой цели nickname может быть адекватным выбором. Дело в том, что в некоторых случаях привязку негде хранить, и тогда приходится пользоваться каким-то уникальным идентификатором в качестве привязки.
Спасибо!
И еще вопрос!
Если мы используем логин, как привязку, и значение хэш-функции, вычисленной по пароль+логин, есть в БД, то это автоматом означает, что и логин, и пароль верные. То есть по логину можно даже не искать?
Здесь правда вопрос быстродействия, а именно что лучше: найти сначала логин и проверить хэш или сразу искать по хэшу. Учитывая среднюю длину строк, мне кажется, первый вариант быстрее. Но второй хорош тем, что кроме вычисленного хэша с клиента ничего не уходит (в явном виде, т.е. зависит от технологии), а приходит только подтверждение логин+пароль верны или нет.
Я пока не силен в этой теме, буду рад указаниям/замечаниям...
Что, где можно почитать об этом (желательно на русском)? Как это реализовано, например, здесь? Хотя бы в общих чертах...
Да. Если логин или пароль ошибочны, результат хэширования будет другим.
Для защищённой системы я бы индексировал и сравнивал только хэши. Различия в скорости всё равно незначительны. Конечно, если архитектура Вашей системы не исходит из каких-то особых требований к масштабированию и т.д. В этом случае лучше предварительно оттестировать.
В этом форуме? Здесь обычный движок phpBB, можете сами посмотреть исходники. Привязка не используется, хэшируется только пароль. Индексом в БД служит имя пользователя, по нему же производится поиск.