Реально ли перехватить и расшифровать SSL/TLS трафик?
Захотелось мне сделать свою аутентификацию для моего сайта. Нашел несколько статей в которых предлагается кешировать пароль перед отправкой на сервер. И мне, вдруг, стало интересно как передают мои пароли остальные сайты. Посмотрел на три интересных мне сайта Google, Yandex, Bitbucket и увидел, что все они передают пароль в POST запросах в открытом виде.
Насколько реально перехватить и расшифровать зашифрованный трафик? Читал, что китайцы для этого строят ИТ города, но какой-нибудь кулхакер не построит же для этого свой городок?
lynxp9 дорогой пользователь, настоятельно рекомендуем еще раз обратить самое пристальное внимание на п. 3.1 регламента работы сервиса (и, в особенности, на его последний абзац). В противном случае, ваши вопросы будут удаляться по причине тег-спама, а систематические нарушения приведут к блокировке учетной записи.
Не "кешировать", а "хэшировать", причем с солью. Могло бы иметь смысл, если бы это хэширование применялось поверх незащищенного канала. Отправка необработанных данных (пароля текстом) по SSL/TLS не даст возможности перехватить и расшифровать трафик (за разумное время) сидящему на канале передачи данных, поэтому можно не заморачиваться на защиту именно передаваемого текста на уровне L7, если на L4 соединение защищено сильной криптографией.
Не "кешировать", а "хэшировать", причем с солью. Могло бы иметь смысл, если бы это хэширование применялось поверх незащищенного канала
Это кто же хэширует пароли перед отправкой на сервер?? Да еще и с солью?
И самое главное - как хэширование может помочь при передаче поверх незащищенного канала?
АртемЪ, вообще, соль может быть уникальной для конкретного клиента, причем генерироваться независимо клиентом и сервером (а-ля DH, тольько проще в разы). Естественно, безопасность не идет ни в какое сравнение с честным HTTPS, но формально можно хэшировать пароли с солью и авторизоваться.
Само по себе соленое хэширование помогает отсрочить взлом пароля, а привязка хэша к чему-либо помимо айпи позволяет избежать атаки повторной авторизации, например. Хотя граблей, вероятно, будет море... ;)
lynxp9, алгоритм Диффи-Хеллмана для создания сессионного ключа (в данном предположении с помощью подобного алгоритма можно создать общую соль), который не передается по сети в принципе.
Похоже, что вы специалист в ИБ. Я нашел такой алгоритм аутентификации и хочу в нем разобраться. Что вы могли бы сказать на вскидку о таком алгоритме:
* Database stores { username, hash(s), υ } where s = P P F (salt, password, cost, misc)
for each user.
– Each user has a different υ which is generated by a CSPRNG and is at least 128-bits.
– The user’s υ changes whenever his password changes.
– The value s originally comes from the client via TLS when the user sets his password. It is tran- sient on the server.
– hash is a cryptographic hash function such as SHA256.
– The salt is taken to be hash(username ∥ domain- name ∥ υ). It is not stored in the database but instead is recomputed when required. If the salt could be longer than what is allowed for the PPF (such as in bcrypt [20]), then instead use as many bits as possible from the hash.
– cost should be set to about 1 second computation time on the slowest device that is supported.
– The output length of the PPF (which might be part of the misc parameter) should be at least 128-bits.
* Database stores system level secret σ that changes approximately once per year. σ is generated by a CSPRNG and is at least 128-bits.
• For user to authenticate, the following operations hap- pen.
– Client gets username and password from user.
– Client sends a request with username to the server
to get salt, cost, misc.
– Server only accepts usernames within the allowed size limit. If it is not, the server rejects it and does not continue.
– Server looks up username in database. If user ex- ists, then it computes salt as hash(username ∥ do- mainname ∥ υ) for that user’s υ value. If user does not exist, then it computes salt as hash(username ∥ domainname ∥ σ) for the system secret σ value. The salt, cost, and misc are sent to the client.
– The client computes
ς = PPF(salt,p,cost,misc)
where p is the user entered password and sends { ς, username } to server via secure TLS connec- tion.
• Server verifies that ς is the expected length, and if not, it rejects it and does not continue.
• Server computes hash( ς ) regardless of whether or not the user exists in database. Server accepts user if and only if user exists5 and its computation of the hash matches the value in the database.
It accepts if and only if there is a match.
Средний
Простой
