Comments 79
>т.е отфильтруются школьники-дегенераты
да дегенератами их сложно назвать, многие программеры проходят свой путь через этап написания вирусов/троянов или им подобных
да дегенератами их сложно назвать, многие программеры проходят свой путь через этап написания вирусов/троянов или им подобных
Люди, Человеки! А чем вам не нравится использование ssl? 5 минут на настройку и больше нет проблем с перехватом.
нравится… но это спасает если сниферят посередине, еще раз говорю, если ты себе локально поставишь снифер и попробуешь авторизироватся на https то увидишь свой пароль
хм. был неправ.
Хотя… я точно был неправ? для перехвата ssl зашифрованных данных, должен открываться «фальш сервер», который выдает себя за настоящий. А это невозможно с нормальным ssl сертификатом. Кто рассудит?
Зачем? Вирус стоит на стороне клиента, не надо ничего открывать и тд, прочитал спокойно то что должно уйти на сервер и сохранил себе
Я что-то не понимаю, где должен стоять снифер, чтобы перехватывать данные по ssl. Браузер отдает УЖЕ зашифрованные данные. По сети они гуляют также зашифрованные.
Если перехватывать пароль в самом браузере (из полей ввода) — то да, верю.
И если снифер перехватывает данные, то без проблем перехватывает и куки. Посмотрите в telnet как куки передаются.
Если перехватывать пароль в самом браузере (из полей ввода) — то да, верю.
И если снифер перехватывает данные, то без проблем перехватывает и куки. Посмотрите в telnet как куки передаются.
Вот данные со снифера локального
Открыть
HTTPS, ПриватБанк, все видно как на ладоне, мой динамический пароль, который я только что ввел…
Открыть
HTTPS, ПриватБанк, все видно как на ладоне, мой динамический пароль, который я только что ввел…
На скриншоте увидел только URL, где Вы продемонстрировали одноразовый пароль — не нашел.
Ради интереса провел эксперимент, как и ожидалось, на сетевой интерфейс браузер посылает и получает уже зашифрованные данные.
А вот некоторые банк-клиенты, работающие через браузер и собственную шифровальную программку (например, Телебанк от ВТБ-24 использует такую), действительно шлют данные от браузера до локальной программки в открытом виде, там их можно подсмотреть и даже изменить, недаром программка выдает окошко с перечислением всех этих данных перед тем, как их подписать ЭЦП.
Ради интереса провел эксперимент, как и ожидалось, на сетевой интерфейс браузер посылает и получает уже зашифрованные данные.
А вот некоторые банк-клиенты, работающие через браузер и собственную шифровальную программку (например, Телебанк от ВТБ-24 использует такую), действительно шлют данные от браузера до локальной программки в открытом виде, там их можно подсмотреть и даже изменить, недаром программка выдает окошко с перечислением всех этих данных перед тем, как их подписать ЭЦП.
Да, теперь вижу, но все равно не понимаю, как такое может быть. Если это именно отдельный снифер, а не плагин к браузеру (тот же Live HTTP Headers позволяет просматривать отправляемые данные ДО шифрования)…
Какой программой-снифером Вы пользовались?
Какой программой-снифером Вы пользовались?
Да, это отдельный снифер.
Программа — HttpAnalyzer5
Программа — HttpAnalyzer5
Т.е если продолжить тему, то ничто не мешает трояну влезть вместо снифера…
Видимо у людей есть пробел в знаниях на тему SSL и как это работает, иначе бы не писали «используйте ссл» ниже :)
Видимо у людей есть пробел в знаниях на тему SSL и как это работает, иначе бы не писали «используйте ссл» ниже :)
Из описания этого снифера «HTTPS is available if the application uses the Microsoft WININET API(ex.ie, outlook) or Mozilla NSS API(ex. firefox, netscape)» — то есть в Вашем случае показывается не сетевой трафик, а перехватываются и анализируются вызовы функций шифровального API (того, что реализует SSL).
Хотя троян может сделать то же самое, но по механизму работы это уже не снифер, а что-то более вирусоподобное. А на сетевом интерфейса все в порядке — шифрованный трафик.
Хотя троян может сделать то же самое, но по механизму работы это уже не снифер, а что-то более вирусоподобное. А на сетевом интерфейса все в порядке — шифрованный трафик.
Нет, ну это понятно что шифрованный трафик в итоге будет. Вопрос в том где его перехватить, чтобы снять пароль. Прога показывает что это реально встрять между браузером и шифровалкой… значит трой так же может.
Если есть на компе троян — то уж как-нибудь он обязательно придумает как стащить пароль. И не надо для этого никакой JS или еще что. Надо, чтобы вирусов не было.
Slesar, не тупите.
Ну хорошо. У меня Опера. Чтобы перехватить пароли достаточно будет модифицировать opera.dll.
О какой безопасности можно говорить, если на компе вирусы?
О какой безопасности можно говорить, если на компе вирусы?
Господа, что вы привязались ко мне…
я написал как обезопасить хоть как-то, читайте внимательней статью, ЭТО НЕ ПАНАЦЕЯ!!! Зачем вы пишете: А ЕСЛИ У МЕНЯ ОПЕРА, А если я на листочке пароль храню, а если пароль увидят как печатаю, а если НЛО прилетит.
не пишите бред.
ЭТО НЕ ПАНАЦЕЯ! Это один из дополнительных способов отсеят троянов (хотябы тупых)
я написал как обезопасить хоть как-то, читайте внимательней статью, ЭТО НЕ ПАНАЦЕЯ!!! Зачем вы пишете: А ЕСЛИ У МЕНЯ ОПЕРА, А если я на листочке пароль храню, а если пароль увидят как печатаю, а если НЛО прилетит.
не пишите бред.
ЭТО НЕ ПАНАЦЕЯ! Это один из дополнительных способов отсеят троянов (хотябы тупых)
С виртуальной клавиатурой — это уже перебор ;)
Для сервиса, в котором будут крутиться деньги можно использовать SMS пароли.
очорт меня так бесит это нововведение в Альфабанке.
Когда разряжается мобильник — я становлюсь беспомощным при просьбе ввода помимо пароля — ещё и SMS-кода.
Когда разряжается мобильник — я становлюсь беспомощным при просьбе ввода помимо пароля — ещё и SMS-кода.
UFO just landed and posted this here
Это не панацея, это параноя…
> А трояны КУКИ не перехватывают!
Глупо как. Надо просто чтобы кука была одноразовая, а не надеяться на то, что
> А трояны КУКИ не перехватывают!
Глупо как. Надо просто чтобы кука была одноразовая, а не надеяться на то, что
> А трояны КУКИ не перехватывают!
Полный бред.
Очевидно автор не вкурсе ни как работают сниферы ни как SSL.
А предложенная «защита» сродни картонной двери в квартиру.
Очевидно автор не вкурсе ни как работают сниферы ни как SSL.
А предложенная «защита» сродни картонной двери в квартиру.
Вы мелите полную ересь… перечитайте еще раз и посмотрите на скрин снифер снял пароль с SSL.
Так же само работают и трояны
Так же само работают и трояны
Ересь — это как раз ваша «статья».
То, что вы тут демонстрируете это самый что ни на есть класический SSL Man-on-the-Middle-Attack (когда некое звено в цепи, имея возможность управлять роутингами, внедряется в фазу SSL-negotiation, и дальнейшем выступает в качестве прокси).
И снифер тут не причем, потому как то что работает подобным образом — это не снифер.
Попробуйте снять ашим «снифером» SSL-трафик с вашего сетевого интерфеса? Много интересного нашли?
А теперь попробуйте снять SSL-трафик с интерфейса соседа? Получилось?
Вот это и называется «снифинг».
А то, о чем пишете вы — это засевший у пользователя в системе троян и надеяться на то, что «А трояны КУКИ не перехватывают!» — по меньшей мере глупо.
P.S. Ну и перед тем, как с пеной у рта начинать писать опровержения, еще раз перечитайте коментарии ниже — там умных мыслей предостаточно.
То, что вы тут демонстрируете это самый что ни на есть класический SSL Man-on-the-Middle-Attack (когда некое звено в цепи, имея возможность управлять роутингами, внедряется в фазу SSL-negotiation, и дальнейшем выступает в качестве прокси).
И снифер тут не причем, потому как то что работает подобным образом — это не снифер.
Попробуйте снять ашим «снифером» SSL-трафик с вашего сетевого интерфеса? Много интересного нашли?
А теперь попробуйте снять SSL-трафик с интерфейса соседа? Получилось?
Вот это и называется «снифинг».
А то, о чем пишете вы — это засевший у пользователя в системе троян и надеяться на то, что «А трояны КУКИ не перехватывают!» — по меньшей мере глупо.
P.S. Ну и перед тем, как с пеной у рта начинать писать опровержения, еще раз перечитайте коментарии ниже — там умных мыслей предостаточно.
UFO just landed and posted this here
Топик ни о чем. Это все давно известно. Вы пытаетесь спастись от трояна, но забываете, что троян еще как правило и клавиатурный ввод логирует.
Если это вам известно, это не значит что известно всем, верно?
А следовательно писать «топик ни о чем» лишь потому что вы это знаете глупо, нет?
А следовательно писать «топик ни о чем» лишь потому что вы это знаете глупо, нет?
Нет, не глупо. Вы взяли маленький кусочек большой проблемы, но не сообщили об этом остальным, тем самым введя некоторых, которым что-то не известно, и о которых Вы так заботитесь, в заблуждение. Более того, защита от передачи открытого пароля по общедоступным сетям — это азы для тех кто интересуется безопасностью, а другим видимо Ваш пост будет безинтересен. Вы не описали даже в общих чертах проблему работы на скомпроментированной рабочей станции, когда сохраняется и сетевой трафик, и ввод пользователя и скриншоты, иногда. Вы также, расписали какого то трояна, который не в состоянии сохранить или отправить cookies, что для них не является проблемой. Также вы не сообщили о способах генерации хеша, на стороне клиента. Можно еще продолжать.
Резюме: Вы сообщили общеизвестные вещи для интересующихся, и слишком мало написали, для тех кто не в курсе. А вообще Вам плюс за старание, да и просто за поднятие темы.
Резюме: Вы сообщили общеизвестные вещи для интересующихся, и слишком мало написали, для тех кто не в курсе. А вообще Вам плюс за старание, да и просто за поднятие темы.
Вы наверное хороший кодер, но не программист.
Разница в том, что кодеру говорят надо делать так, так и так.
Программист способен сам проанализировать и выбрать лучшее.
Зачем вы требуете от меня осматривать все случаи, зачем вы требуете от меня писать КАК генерировать хеш? Неужели это так сложно выбрать лучший, тот же MD5 давно есть на JS, выбирайте любой, какая разница какой хеш, идея в том чтобы хеш было трудно взломать. Если вы не способны подумать и выбрать алгоритм — ваше дело. Да и потом, зачем эта информация людям, которые только что выучили Hello World? А для тех, кто ищет, развивается эта информация может быть полезна и он дальше сам начнет копать.
Далее, зачем вы пишете про трояны, которые могут передавать куки. Да, есть такие что мониторят ВСЕ, НО! насколько я знаю частоиспользуемые вирусы НЕ сохраняют и НЕ передают куки, ТОЛЬКО данные формы.
В общем я предлагаю закончить это ненужное словоблудие.
Разница в том, что кодеру говорят надо делать так, так и так.
Программист способен сам проанализировать и выбрать лучшее.
Зачем вы требуете от меня осматривать все случаи, зачем вы требуете от меня писать КАК генерировать хеш? Неужели это так сложно выбрать лучший, тот же MD5 давно есть на JS, выбирайте любой, какая разница какой хеш, идея в том чтобы хеш было трудно взломать. Если вы не способны подумать и выбрать алгоритм — ваше дело. Да и потом, зачем эта информация людям, которые только что выучили Hello World? А для тех, кто ищет, развивается эта информация может быть полезна и он дальше сам начнет копать.
Далее, зачем вы пишете про трояны, которые могут передавать куки. Да, есть такие что мониторят ВСЕ, НО! насколько я знаю частоиспользуемые вирусы НЕ сохраняют и НЕ передают куки, ТОЛЬКО данные формы.
В общем я предлагаю закончить это ненужное словоблудие.
Вы что слово способ и алгоритм не различаете? И на критику, не голословную, очень болезненно реагируете, на личности переходите, комплекс какой-то? Кстати очень хороший ход — оскорбить человека и предложить закончить разговор, пять баллов вам за это.
Если вы не заметили, я критикую статью, которая мало информативна и претендует на большее чем она есть, что может ввести в заблуждение. Тручу свое время на это, хотя мог бы даже не заглядывать сюда. А вы вместо того, вместо того что бы принять все что вам тут написали, и доработать статью, сделать из нее что-то полезное, принялись воевать в каментах.
Ну ваше право.
Если вы не заметили, я критикую статью, которая мало информативна и претендует на большее чем она есть, что может ввести в заблуждение. Тручу свое время на это, хотя мог бы даже не заглядывать сюда. А вы вместо того, вместо того что бы принять все что вам тут написали, и доработать статью, сделать из нее что-то полезное, принялись воевать в каментах.
Ну ваше право.
Идея нормальная, я тоже думал много над данной проблемой, фантазии доходили и до дополнительных полях ввода типа капчи от которой и производилось хэширование.
Т.е. кукис – ключ генерируется капчОй, он используется и для самой капчи, и для «подмены» пароля. 2 зайца с базуки: и анти – Брут неплохой и на стороне клиента все ок.
Т.е. кукис – ключ генерируется капчОй, он используется и для самой капчи, и для «подмены» пароля. 2 зайца с базуки: и анти – Брут неплохой и на стороне клиента все ок.
Собственно хэширование здесь не имеет никакого значения, всё так или иначе упирается в дополнительный идентификатор — куку, которую нужно добыть злоумышленнику. Но как будет происходить повторный логин, когда куки на машине уже не будет (или такой вариант не допускается)? Вероятно, в таком случае сервер должен выдавать её же, основываясь на логине? Тогда в чём смысл? — всё это может проделать и злоумышленник, если у него есть передаваемый логин и «хэш».
Кука каждый раз выдается разная. Простой рандом
а потом
md5(cookie.pass)
ну или как угодно.
а потом
md5(cookie.pass)
ну или как угодно.
Да? Может вы ещё подскажете, как получить при каждом таком повторном входе один и тот же хэш, используя разную «соль» (в качестве которой выступает кука)? :)
P. S. Здесь вообще не нужно хэширование, не для того оно придумано.
P. S. Здесь вообще не нужно хэширование, не для того оно придумано.
Он и не должен быть одинаковый, перечитайте внимательнее
Хорошо. Приходит на сервер логин, хэш и имеется рандомная кука, участвовшая в создании хэша. На основе каких из этих данных аутентифицируется пользователь?
по имени пользователя достается пароль из БД
далее берется кука
$controll_hash = md5($_COOKIE['rnd'].$passdb);
if( $controll_hash == $hashfromuser) { return true;}
далее берется кука
$controll_hash = md5($_COOKIE['rnd'].$passdb);
if( $controll_hash == $hashfromuser) { return true;}
Этим вы как минимум автоматически создаёте потенциальную уязвимость на сервере, храня пароль в открытом виде. Оно того стоит?
Ну храните в хеше, какая разница, тогда на стороне клиента будет
md5(cookie.md5(pass))
И на сервере
md5(cookie.$hashpass)
md5(cookie.md5(pass))
И на сервере
md5(cookie.$hashpass)
это не решает проблему описанной уязвимости.
другой вопрос, что: сервер проще защитить и т.п…
другой вопрос, что: сервер проще защитить и т.п…
Почему не решает… от клиента идет хеш пароля, следовательно уже трудней полчить
а зачем тогда нам вообще пароль, если у нас будет его хеш? задумайтесь.
задуйматесь, что хеш без КУК не достаточно для авторизации
но ведь речь изначально (в этом треде) не шла про куки вообще, т.е.:
хранение md5(пароля) не устраняет уязвимости кражи его с сервера и использование с печеньем, которое, конечно, нужно еще перехватить.
аналогично кража пароля ничего не даст без куков.
хранение md5(пароля) не устраняет уязвимости кражи его с сервера и использование с печеньем, которое, конечно, нужно еще перехватить.
аналогично кража пароля ничего не даст без куков.
причем тут вообще сервер.
ЕЩЕ РАЗ ПЕРЕЧИТАЙТЕ ПОСТ.
ЕЩЕ РАЗ ПЕРЕЧИТАЙТЕ ПОСТ.
я говорю про это:
>Этим вы как минимум автоматически создаёте потенциальную уязвимость на сервере, храня пароль в открытом виде. Оно того стоит?
и ваше «решение» этой проблемы.
>Этим вы как минимум автоматически создаёте потенциальную уязвимость на сервере, храня пароль в открытом виде. Оно того стоит?
и ваше «решение» этой проблемы.
ну я и говорю, если вам не нравится хранить в открытом виде — хешируете.
а на стороне клиента
md5(cookie.md5(то что ввел юзер)
как вы зная хеш авторизируетесь то?
перехвачен будет последний хеш, а что он хранить хз
а на стороне клиента
md5(cookie.md5(то что ввел юзер)
как вы зная хеш авторизируетесь то?
перехвачен будет последний хеш, а что он хранить хз
пусть я знаю md5_serverside, client_cookie (его я перехватил положим «злым трояном»).
я НЕ знаю пароля, по которому на клиенте будет построен md5_client.
сервер сверяет пароль по алгоритму: md5(client_cookie.md5_client) — см выше вы писали.
Для успеха авторизации необходимо и достаточно:
md5_client = md5_serverside и client_cookie перехваченный.
я НЕ знаю пароля, по которому на клиенте будет построен md5_client.
сервер сверяет пароль по алгоритму: md5(client_cookie.md5_client) — см выше вы писали.
Для успеха авторизации необходимо и достаточно:
md5_client = md5_serverside и client_cookie перехваченный.
Так можно. Но всё равно, остаются две важные уязвимости, о которых уже писали — кука и кейлоггинг, которые сводят на нет эффективность данного решения.
Кстати, хранение простого md5(pass) на сервере — это на сегодня легкомысленно, если мы говорим о безопасности. А тут ещё злоумышленник из javascript-a вытаскивает алгоритм создания хэша, каким бы сложным он ни был.
Кстати, хранение простого md5(pass) на сервере — это на сегодня легкомысленно, если мы говорим о безопасности. А тут ещё злоумышленник из javascript-a вытаскивает алгоритм создания хэша, каким бы сложным он ни был.
Тут выбор. Либо шифровать у пользователя, либо у сервера. Что-то из этого ВСЕГДА на один уровень хэширования выше (если на одном уровне, то это хэширование не имеет смысла).
Что безопаснее: ваша БД или компьютер пользователя?
Что легче скомпрометировать?
Что безопаснее: ваша БД или компьютер пользователя?
Что легче скомпрометировать?
isAuth = md5(cookie+RealPassword) == client_hash
, где RealPassword в базе сервера для логина client_login хранится.
это же очевидно.
, где RealPassword в базе сервера для логина client_login хранится.
это же очевидно.
Хороший способ. Сам использую. У меня, например, при запросе страницы логина создается сессия, сохраняется и выводится соль.
На странице выходит такой скриптик:
function post_prepare(form) {
form.jsenable.value = '1';
form.password.value = hex_md5(form.password.value);
form.password.value = hex_sha1(';]R~{xOYI@
На странице выходит такой скриптик:
function post_prepare(form) {
form.jsenable.value = '1';
form.password.value = hex_md5(form.password.value);
form.password.value = hex_sha1(';]R~{xOYI@
[Черт! Срезалось все]
function post_prepare(form) {
form.jsenable.value = '1';
form.password.value = hex_md5(form.password.value);
form.password.value = hex_sha1(';]R~{xOYI@Sh1w-M' + form.password.value);
return true;
}
При заходе на страницу входа в сессию загоняется соль. Затем на клиентской стороне все хэшируется и отправляется. Проверяется наличие соли в сессии, хэшируется этой солью настоящий пароль и сверяется с клиентским. Затем соль очищается, для исключения дальнейшего использования. При отсутствии Javascript можно сверить и простой пароль. (да-да, в БД у меня ничего не хэшированно, поскольку я могу гарантировать безопасность server-side в отличие от client-side)
function post_prepare(form) {
form.jsenable.value = '1';
form.password.value = hex_md5(form.password.value);
form.password.value = hex_sha1(';]R~{xOYI@Sh1w-M' + form.password.value);
return true;
}
При заходе на страницу входа в сессию загоняется соль. Затем на клиентской стороне все хэшируется и отправляется. Проверяется наличие соли в сессии, хэшируется этой солью настоящий пароль и сверяется с клиентским. Затем соль очищается, для исключения дальнейшего использования. При отсутствии Javascript можно сверить и простой пароль. (да-да, в БД у меня ничего не хэшированно, поскольку я могу гарантировать безопасность server-side в отличие от client-side)
Кстати, от использования украденной куки вместе с хэшем и логином можно уберечься, ведя на сервере лог аутентификаций, чтобы не принимать использованную куку вторично. Но опять же, ничто не мешает злоумышленнику украсть и использовать сессионную куку.
Всё это наводит на мысль, что пользователь должен сам заботиться о защите своего рабочего места. Теоретически, вирус на машине может делать всё что угодно, и противодействовать ему javascript-ом — не метод в принципе.
Всё это наводит на мысль, что пользователь должен сам заботиться о защите своего рабочего места. Теоретически, вирус на машине может делать всё что угодно, и противодействовать ему javascript-ом — не метод в принципе.
Кстати, интересно Ваше мнение по поводу защиты пароля при первичной регистрации. Тут уже кукой защититься не получится, поскольку на сервер нужно передать именно оригинальный пароль (или его хэш, что практически то же самое). Есть идеи?
UFO just landed and posted this here
Sign up to leave a comment.
Безопасный вход, Secure Login