Comments 69
UFO just landed and posted this here
> Хранимый в БД пароль или хэш пароля позволят воссоздать необходимый для авторизации ответ клиента. Хищение такой БД становится серьезной угрозой безопасности механизма аутентификации.
UFO just landed and posted this here
Согласен, данный протокол также бесполезен.
Думаю тут идея как раз в том, что пароль, при отсутствии https, не передается в открытом виде.
Да, если трафик уже снифается — угроза есть в любом случае, но при использовании данного алгоритма мы не отдаем пароли злоумышленникам на блюдечке.
Да, если трафик уже снифается — угроза есть в любом случае, но при использовании данного алгоритма мы не отдаем пароли злоумышленникам на блюдечке.
Да, вы правы. Однако, задача раскрытия пароля усложняется в разы.
Простите, по сравнению с чем?
Поправьте меня, если я не прав.
Снифер трафика максимум, что получит — это хеш пароля пользователя — H(pwd).
Если учесть, что базу украли — в ней все те же хеши и лежат.
В итоге польза от алгоритма только в том, что пароль не передается в открытом виде, что является дополнительной защитой.
Поправьте меня, если я не прав.
Снифер трафика максимум, что получит — это хеш пароля пользователя — H(pwd).
Если учесть, что базу украли — в ней все те же хеши и лежат.
В итоге польза от алгоритма только в том, что пароль не передается в открытом виде, что является дополнительной защитой.
В этом случае можно будет украв базу логиниться на сервер. Это как если хранить ключи в открытом виде, так как в базе тоже лежит SHA(PASSWORD).
Я по тем же самым причинам (нет возможности использовать https) использовал реализацию rsa на javascript.
Пример можно посмотреть тут:
shop-js.sourceforge.net/crypto2.htm
Основная страница тут:
shop-js.sourceforge.net/
Генерится открытый и закрытый ключи — открытым пароль шифруется на стороне клиента, закрытым на стороне сервера расшифровывается. Плюс вставляется метка времени и привязка к ip (они тоже шифруются вместе с паролем). Можно еще было бы доработать — вставлять случайное число и принимать данные формы с этим числом только один раз — но я подумал что это слишком, хотя и гораздо надежнее.
Пример можно посмотреть тут:
shop-js.sourceforge.net/crypto2.htm
Основная страница тут:
shop-js.sourceforge.net/
Генерится открытый и закрытый ключи — открытым пароль шифруется на стороне клиента, закрытым на стороне сервера расшифровывается. Плюс вставляется метка времени и привязка к ip (они тоже шифруются вместе с паролем). Можно еще было бы доработать — вставлять случайное число и принимать данные формы с этим числом только один раз — но я подумал что это слишком, хотя и гораздо надежнее.
Если я правильно понял, открытый ключ передается клиенту сервером в начале сеанса. В таком случае, возможна атака MitM. Злоумышленник выдающий себя за сервер может отправить клиенту подложный ключ и в результате получить пароль пользователя.
Увы. Так и есть. Но моя логика такая — если у человека не включен js — пароль передается в открытом виде. MitM может в любом случае модифицировать страницу так, что пароль будет передаваться без шифрования (вырежет подгрузку нужных библиотек и их вызовов).
Вообще говоря от MitM даже https не спасет, если промежуточному узлу удастся поймать момент загрузки браузера и заменить открытые ключи сертификационных центров.
Перехват https задача не тривиальная. Реализовывать один раз приходилось, но там была возможность подтвердить подлинность фэйковых сертификатов доменными политиками. При отсутствии такой возможности, я не знаю способа чтения https, если только пользователь сам не согласится на посещение сервера с липовым сертификатом.
Ну я привел в пример совсем фантастический вариант, когда на компьютер пользователя загружается из сети браузер по http и MitM модифицирует сам браузер, меняя сертификаты самих сертификационных центров на свои. Это сможет провернуть только ИИ наверное. А так да, https вещь надежная.
То есть, тут вопрос в том, что если человек общается с миром только через интернет, он не сможет с уверенностью сказать есть ли MitM или нет.
То есть, тут вопрос в том, что если человек общается с миром только через интернет, он не сможет с уверенностью сказать есть ли MitM или нет.
Короче, кейлогер рулит!
Многим пользователям достаточно прислать ссылку или показать баннер, чтобы они скачали «Новый Абсолютно Безопасный Браузер!!!» в который встроить можно всё что угодно. Если уж в ОС так бэкдоры пихали…
а вот тут не поможет и keyloger — habrahabr.ru/blogs/infosecurity/120990/
Да, хорошая статья. Если еще передать открытый ключ при регистрации не через интернет, то можно и MitM атаки не бояться.
Мы у себя тоже думали в сторону eToken, но в статье описывается вариант поинтереснее.
Мне вообще идея с хардварными устройствами нравится. Например, можно делать игры для PC, которые записывать на флешку со встроенным процессором и часть логики работы игры перенести во внутрь флешки (что нибудь простое, но ключевое). И все, игру не спиратить…
Мы у себя тоже думали в сторону eToken, но в статье описывается вариант поинтереснее.
Мне вообще идея с хардварными устройствами нравится. Например, можно делать игры для PC, которые записывать на флешку со встроенным процессором и часть логики работы игры перенести во внутрь флешки (что нибудь простое, но ключевое). И все, игру не спиратить…
Тут, думаю, надо смотреть в сторону ключей защиты ПО. Например Guardant.
Примерно тоже самое реализовал на одном из проектов год назад: сервер отдает JavaScript сгенерированную соль magickey (хранится в базе и обновляется каждые 15 мин.), JavaScript шифрует пароль Base64+соль. А На стороне сервера декодится строка пароля и удаляется соль. Не знаю на сколько это эффективно с точки зрения безопасности, но по-моему тут недалеко до паранойи.
> необходимость покупки сертификата приводит
www.startssl.com/
www.startssl.com/
Для обмена секретным ключом можно использовать Алгоритм Диффи — Хеллмана.
Классический алгоритм Диффи-Хеллмана не устойчив к атаки посредине.
приведете пример?
Эта уязвимость заложена в алгоритм, я не знаю какой пример можно тут привести. ru.wikipedia.org/wiki/Diffie-Hellman
От атаки MitM метод не защищает. Подмена формы ввода пароля, dns spoofing, и т.д.
ээм. от подмены ввода пароля и dns spoofing не защищает и HTTPS. автор писал именно о его временной замене.
Да. вы правы. От подмены форм и прочих подобных ухищрений метод не защищает. Путаница в терминах. MitM термин криптографический, подразумевающий возможность атакующего читать и модифицировать шифрованную информацию находясь между корреспондентами. С этой точки зрения предложенный алгоритм безопасен.
UFO just landed and posted this here
Расшифровать HTTPS нереально. Однако, возможна атака MitM. Для этого необходим специальный прокси. Его можно собрать самому или купить, например такой www.safenet-inc.com/products/data-protection/content-security/ssl-inspection/. И самое главное необходимо иметь сертификат которому доверяет пользователь. В корпоративной среде это делается доменными политиками. В открытых сетях с этим сложнее, но история знает случаи создания фэйковых сертификатов известных сервисов.
Вообще, примерно такая же схема в https и используется. Если, как Вы говорите, https можно расшифровывать (как, интересно?), то и Ваш алгоритм должен быть подвержен той же уязвимости.
В ru.wikipedia.org/wiki/Криптографическая_хеш-функция этот метод уже два года висит.
По Вашей ссылки находится описание одной из разновидностей дайджест аутентификации. Да, действительно, перехват пароля при использовании такого алгоритма невозможен. Однако, как упоминалось выше, данный механизм аутентификации небезопасен. Раскрытие базы данных хешей паролей хранящихся на сервере, даст злоумышленнику возможность аутентифицироваться на сервере. Предложенный мною алгоритм таким недостатком не страдает.
Похоже на попытку сделать HTTPS без самого HTTPS, не решающее главную задачу — борьба с «человеком посередине». Не так и дорого заплатить $20-$50 за хост в год, чем делать и поддерживать подобный, уступающий HTTPS алгоритм собственноручно.
умгум. без третьей доверенной стороны бороться с mitm, насколько я понимаю, еще никто не научился.
А как достоверно узнать, есть Мitm в сети или нет?
https с валидными сертификатами. центры авторизации сертификатов имеют свою подпись, которая «зашита» в браузер и подделать ее нельзя. если центр подтверждает валидность https-сайта, значит mitm нет. что не означает, конечно, что пользователь не лопух и не пропустил каких-то очевидных признаков взлома типа замены https на http или предложения принять как доверенный какой-то новый левый сертификат.
Есть недостаток по сравнению с https в том, что не получится зашифровать процесс регистрации (если предполагается открытая регистрация через сеть).
Есть же CRAM-MD5
Я как-то со знакомым придумывал подобный алгоритм (правда это годится только для авторизации). Прошу оценить его защищённость:
key=$rand&login=username&pass=md5(md5("$pass;$salt")+$rand)
salt — не изменяемое значение.
rand — генерируется на сервере, живёт какое-то время (минут 5) и передаётся клиенту при запросе странички с формой авторизации. После успешной или не успешной авторизации rand срубается и больше его использовать нельзя. В БД соответственно хранится md5("$pass;$salt").
key=$rand&login=username&pass=md5(md5("$pass;$salt")+$rand)
salt — не изменяемое значение.
rand — генерируется на сервере, живёт какое-то время (минут 5) и передаётся клиенту при запросе странички с формой авторизации. После успешной или не успешной авторизации rand срубается и больше его использовать нельзя. В БД соответственно хранится md5("$pass;$salt").
тут правда маленький недостаток — с таким алгоритмом очень легко задосить сервер =) кстати описанный статье алгоритм мне что-то не понравился — он подвешивает нормально так браузер. а что же будет с мобильными устройствами?
Ваша схема это аналог дайджест аутентификации. Перехват действительно ничего не даст, а вот кража БД сервера позволит аутентифицироваться на сервере от имени пользователей.
Не сочтите меня за извращенца, а как насчёт такого:
В бд хранится такое:
login,pass,key
ключ генерится при регистрации
pass=md5(pass+key)
В бд хранится такое:
login,pass,key
ключ генерится при регистрации
pass=md5(pass+key)
Мда. Подумал-подумал. Действительно, от проблемы хищения базы никак не избавиться при помощи только манипуляций с md5.
Пожалуй описанный выше (в статье) способ действительно самый надёжный и не тяжёлый по ресурсам, однако не без недостатков.
В случае хищения бд, злоумышленник сможет расшифровать пароль любого клиента, в случае перехвата трафика. Этим злоумышленником кстати может быть тот, кто имеет доступ к сети до сервера и к бд (например администратор).
Зная хеш пароля он сможет расшифровать rnd число. Затем, зная rnd число для отправленного клиентом пароля, зашифрованного с помощью rnd, можно расшифровать пароль. Хотя понятно, что это гораздо лучше, чем отправка пароля как есть.
Пожалуй описанный выше (в статье) способ действительно самый надёжный и не тяжёлый по ресурсам, однако не без недостатков.
В случае хищения бд, злоумышленник сможет расшифровать пароль любого клиента, в случае перехвата трафика. Этим злоумышленником кстати может быть тот, кто имеет доступ к сети до сервера и к бд (например администратор).
Зная хеш пароля он сможет расшифровать rnd число. Затем, зная rnd число для отправленного клиентом пароля, зашифрованного с помощью rnd, можно расшифровать пароль. Хотя понятно, что это гораздо лучше, чем отправка пароля как есть.
еще одно, весьма безопасное решение — habrahabr.ru/blogs/infosecurity/120990/
Я не очень хорошо разбираюсь в секьюрити и ключах, и мне вот непонятно, а как пароль или хэш пароля попадет в базу в первый раз? Тут как все шифровать и хэшировать, очень ведь легко перехватить.
Это я Вам пытался ответить, но промахнулся. — Обычно при регистрации пароль передается на сервер в открытом виде, затем считается его хэш и хэш сохраняется в базе. Предлагаемая схема не регламентирует процесса регистрации и может быть использована на уже существующих системах, без изменения регистрационных данных пользователей.
Обычно при регистрации пароль передается на сервер в открытом виде, затем считается его хэш и хэш сохраняется в базе. Предлагаемая схема не регламентирует процесса регистрации и может быть использована на уже существующих системах, без изменения регистрационных данных пользователей.
Sign up to leave a comment.
Защита пароля при передаче по открытому каналу (часть 1)