Для того чтоб затруднить поиск пароля соответствующего некоторой хеш-сумме, хеш-функцию "затравливают" некоторой "солью". Вопрос в том что для этого при логине юзера нужно из БД выбирать соль соответствующую введеному логину + отсылать соль клиенту + хешировать пароль вместе с солью + отсылать результат серверу.
В этом мне не нравится то что сервер должен по любому введеному логину высылать соль(если такой логин имеется). Это можно использовать для подтверждение наличия зарегистрированого логина и получения соли использующейся для хэширования пароля, т.е. вся идея с солью становится бесмысленной.
Подскажите как такой трюк(соль + пароль) реализуется на самом деле? Врядли используется одна соль на всех.
09.09.16 21:32: Перенесено из 'Информационная безопасность'
09.09.16 21:33: Перенесено из 'Информационная безопасность'
Здравствуйте, Tasheehoo, Вы писали:
T>Для того чтоб затруднить поиск пароля соответствующего некоторой хеш-сумме, хеш-функцию "затравливают" некоторой "солью". Вопрос в том что для этого при логине юзера нужно из БД выбирать соль соответствующую введеному логину + отсылать соль клиенту + хешировать пароль вместе с солью + отсылать результат серверу. T>В этом мне не нравится то что сервер должен по любому введеному логину высылать соль(если такой логин имеется). Это можно использовать для подтверждение наличия зарегистрированого логина и получения соли использующейся для хэширования пароля, т.е. вся идея с солью становится бесмысленной.
T>Подскажите как такой трюк(соль + пароль) реализуется на самом деле? Врядли используется одна соль на всех.
Здравствуйте, Tasheehoo, Вы писали:
T>В этом мне не нравится то что сервер должен по любому введеному логину высылать соль(если такой логин имеется).
Сервер аутентификации не должен высылать соль.
T>Врядли используется одна соль на всех.
Разумеется нет, это лишено смысла. Нужно, чтобы для разных пользователей с одинаковым «оригинальным» паролем "p@$$w0rd" в базе хранились разные значения хэша. Чтобы злоумышленник, получивший доступ к базе, не мог по равенству хэшей заключить совпадение паролей у некоторых пользователей. Поэтому и соль у всех индивидуальная.
Здравствуйте, Qbit86, Вы писали:
Q>Сервер аутентификации не должен высылать соль.
В таком случае клиент должен отправлять серверу пароль в открытом виде?
Здравствуйте, Tasheehoo, Вы писали:
T>Здравствуйте, Qbit86, Вы писали:
Q>>Сервер аутентификации не должен высылать соль. T>В таком случае клиент должен отправлять серверу пароль в открытом виде?
Подозреваю, что так обычно и делается, хоть это и не совсем правильно, зато просто.) Но для вдохновения можно почитать что-нибудь про протоколы аутентификации, CHAP, MS-CHAP, тому подобные вещи. Ну, и Вы,вроде как в вопросе рядом писали про обмен ключами по Диффи-Хеллману, по шифрованному каналу уже можно передать плейнтекст-пароль. Как я понимаю, такая схема и считается сейчас правильной (варианты EAP, в которых обычно сначала организовывается защищенный канал, а по нему уже передаются чувствительные данные). В такой схеме передавать ли в явном виде пароль будет зависеть от доверия клиента к серверу, это уже определяется спецификой Вашей задачи.
Здравствуйте, Qbit86, Вы писали:
Q>Почему в открытом? По защищённому каналу SSL/TLS (HTTPS).
Имел ввиду что сервер будет получать пароль юзера в открытом виде. Это плохо потому что нельзя доверять серверу.
Здравствуйте, Tasheehoo, Вы писали:
T>Имел ввиду что сервер будет получать пароль юзера в открытом виде. Это плохо потому что нельзя доверять серверу.
Надумал еще такой вариант: перед отправкой на сервер применять к паролю хеширующую функцию и потом отправлять хеш на сервер и там применять еще раз хеширование с солью.
Здравствуйте, Tasheehoo, Вы писали:
T>Подскажите как такой трюк(соль + пароль) реализуется на самом деле? Врядли используется одна соль на всех.
Во-первых, можно хешировать не пароль отдельно, а логин вместе с паролью. Тогда даже при совпадении паролей у разных пользователей, хеш будет разным.
Во-вторых, можно отсылать соль всегда, независимо от того, есть ли такой пользователь. Желательно еще, чтобы время ответа не зависило от наличия пользователя (разницу во времени ответа в полпроцента можно надежно усреднить и замерить, если послать несколько тысяч запросов).
В третьих, лучше не изобретать самодельные протоколы авторизации, а найти и использовать готовый, проверенный временем. Лучше вместе с реализацией. Потому что в самодельном протоколе вы наверняка ошибетесь, да еще и не один раз.
Здравствуйте, Pzz, Вы писали:
Pzz>Во-первых, можно хешировать не пароль отдельно, а логин вместе с паролью. Тогда даже при совпадении паролей у разных пользователей, хеш будет разным.
Логично!
Pzz>Во-вторых, можно отсылать соль всегда, независимо от того, есть ли такой пользователь. Желательно еще, чтобы время ответа не зависило от наличия пользователя (разницу во времени ответа в полпроцента можно надежно усреднить и замерить, если послать несколько тысяч запросов).
Тоже верно!
Pzz>В третьих, лучше не изобретать самодельные протоколы авторизации, а найти и использовать готовый, проверенный временем. Лучше вместе с реализацией. Потому что в самодельном протоколе вы наверняка ошибетесь, да еще и не один раз.
Это что-то типа того о чем писали выше?: CHAP, MS-CHAP
Здравствуйте, Tasheehoo, Вы писали:
T>Надумал еще такой вариант: перед отправкой на сервер применять к паролю хеширующую функцию и потом отправлять хеш на сервер и там применять еще раз хеширование с солью.
Захешированный пароль⁰ будет в свою очередь просто паролем¹ с точки зрения сервера. В чём смысл клиенту хэшировать пароль на своей стороне перед отправкой?
Например, мой пароль "313d685670b03b9b36017d730fa41a5f83ce955a", но я не доверяю серверу, и поэтому в качетве пароля передаю ему хэш: "30dc6ba19605a422acefeac61c28385d4b9e4abf". И чем это отличается от ситуации, когда я просто считаю "30dc6ba19605a422acefeac61c28385d4b9e4abf" изначально своим паролем вместо "313d685670b03b9b36017d730fa41a5f83ce955a" с последующим хэшированием?
Серверу от применения хэширования на клиенте ни холодно, ни жарко.
T>Надумал еще такой вариант: перед отправкой на сервер применять к паролю хеширующую функцию и потом отправлять хеш на сервер и там применять еще раз хеширование с солью.
Тогда злоумышленнику не нужно будет угадывать пароль, а нужно будет просто получить его хеш.) лучше действительн поискать готовый протокол.) ну или на крайний случай — почитать книжку Шнайера, там как раз начало про протоколы, можно за день осилить.)
Здравствуйте, Qbit86, Вы писали:
Q>Захешированный пароль⁰ будет в свою очередь просто паролем¹ с точки зрения сервера. В чём смысл клиенту хэшировать пароль на своей стороне перед отправкой?
Q>Например, мой пароль "313d685670b03b9b36017d730fa41a5f83ce955a", но я не доверяю серверу, и поэтому в качетве пароля передаю ему хэш: "30dc6ba19605a422acefeac61c28385d4b9e4abf". И чем это отличается от ситуации, когда я просто считаю "30dc6ba19605a422acefeac61c28385d4b9e4abf" изначально своим паролем вместо "313d685670b03b9b36017d730fa41a5f83ce955a" с последующим хэшированием?
Q>Серверу от применения хэширования на клиенте ни холодно, ни жарко.
Если сервер не знает открытый пароль юзера то от утечки БД пара [никнейм+пароль] не станет общественным достоянием.
Здравствуйте, Tasheehoo, Вы писали:
T>Если сервер не знает открытый пароль юзера то от утечки БД пара [никнейм+пароль] не станет общественным достоянием.
Если мы подозреваем, что сервер реализован некорректно и хранит в базе прямо пароли, то хэширование на стороне клиента нам ничем не поможет. Если злоумышленник утащит базу с паролями, то ему никак не помешает тот факт, что в нашей учётке в этой базе будет храниться не некий «исходный пароль», а его хэш. Он-то будет передавать серверу аутентификации то, что видит в базе. То же самое, как если бы он знал наш «исходный пароль» и посчитал его хэш — только считать ничего не надо, хэш-то вот он уже посчитанный в базе лежит.
Здравствуйте, Pzz, Вы писали:
Pzz>Во-первых, можно хешировать не пароль отдельно, а логин вместе с паролью. Тогда даже при совпадении паролей у разных пользователей, хеш будет разным.
Индивидуальная соль в любом случае нужна, потому что у пользователей могут быть одинаковые пары логин/пароль на разных ресурсах. Если утащат базу пользователей на двух ресурсах, по ней не должно быть понятно, что на втором ресурсе у пользователей тот же пароль, что и на первом.
Pzz>Во-вторых, можно отсылать соль всегда, независимо от того, есть ли такой пользователь. Желательно еще, чтобы время ответа не зависило от наличия пользователя (разницу во времени ответа в полпроцента можно надежно усреднить и замерить, если послать несколько тысяч запросов).
Одна из задач соления/хэширования (но не главная) — это замедленение проверки. Обычно используется что-то вроде PBKDF2/RFC2898 с количеством итераций 10000, например. Когда пользователь шлёт в штатном режиме пароль серверу, то ожидание в течение, например, секунды для него некритично. Когда перебирает злоумышленник, то для него это важно. Если же подразумевается подобное хэширование с солью на клиенте, то злоумышленник, украв базу, конечно не будет перебирать «пароли» за один раз в секунду; он будет перебирать сразу хэши.
Pzz>В третьих, лучше не изобретать самодельные протоколы авторизации, а найти и использовать готовый, проверенный временем. Лучше вместе с реализацией. Потому что в самодельном протоколе вы наверняка ошибетесь, да еще и не один раз.
Здравствуйте, Qbit86, Вы писали:
Q>Если мы подозреваем, что сервер реализован некорректно и хранит в базе прямо пароли, то хэширование на стороне клиента нам ничем не поможет. Если злоумышленник утащит базу с паролями, то ему никак не помешает тот факт, что в нашей учётке в этой базе будет храниться не некий «исходный пароль», а его хэш. Он-то будет передавать серверу аутентификации то, что видит в базе. То же самое, как если бы он знал наш «исходный пароль» и посчитал его хэш — только считать ничего не надо, хэш-то вот он уже посчитанный в базе лежит.
Если для аторизации на этом же сервере — то да. Зато он не сможет использовать этот хеш на других сервисах/сайтах потому что там может быть совсем другой принцип или совсем другой алгоритм хеширования.
Здравствуйте, Tasheehoo, Вы писали:
T>Если для аторизации на этом же сервере — то да. Зато он не сможет использовать этот хеш на других сервисах/сайтах потому что там может быть совсем другой принцип или совсем другой алгоритм хеширования.
Во-первых, согласно принципу Керкгоффса, алгоритмы на других сайтах не стоит считать неизвестными злоумышленнику. Если ты разрабатываешь сайт, то делать его надо так, чтобы утечка его исходного кода и/или базы пользователей не позволяла злоумышленнику аутентифицироваться на твоём сервере, не зная пароля (соль, кстати, тоже несекретный компонент системы).
Во-вторых, если ты не доверяешь серверу, например, Вконтакте, то ты просто не используешь для него пароль от Одноклассников "my-p@$$w0rd-for-odnoklassniki", а используешь отдельный пароль для Вконтакте "my-p@$$w0rd-for-vkontakte". Это проще, и ничем не хуже, чем использовать в качестве пароля для Вконтакте sha-1("my-p@$$w0rd-for-odnoklassniki").
Здравствуйте, Tasheehoo, Вы писали:
T>Врядли используется одна соль на всех.
Помимо соли (дополнительно к ней) может использоваться один на всех «перец». В отличие от соли это уже секретный компонент, и при компрометации сервера должен быть отозван (revoked). Поэтому он выступает ключом не однонаправленного хэширования, а двунаправленного шифрования захэшированных с солью паролей. (Чтоб можно было зашифрованные солёные хэши расшифровать и перезашифровать с другим «перцем»).
Здравствуйте, Qbit86, Вы писали:
Q>Во-вторых, если ты не доверяешь серверу, например, Вконтакте, то ты просто не используешь для него пароль от Одноклассников "my-p@$$w0rd-for-odnoklassniki", а используешь отдельный пароль для Вконтакте "my-p@$$w0rd-for-vkontakte". Это проще, и ничем не хуже, чем использовать в качестве пароля для Вконтакте sha-1("my-p@$$w0rd-for-odnoklassniki").
Не-не-не, этим опасности передачи паролей на сервер не ограничиваются. Если кто-то осилит устроить MITM с прослушиванием канала (а свои команды, например, встраивать в сессию не осилит), то в случае с передачей пароля открытым текстом он мало того что сможет поиметь все твои данные, так потом просто зайдёт под твоим именем и ченить деструктивное учинит. А вот если пароль не доверять серверу, то утекут только данные за прослушиваемую сессию. Иногда это может иметь значение.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
