Comments 136
Эта картинка скорее в юмор надо, чем в факты =)
Хотя наверное небольшой смысл в этом есть: например обозначить шланг для трамваев.
А почему неправильно-то? У вас есть какой-то другой способ обезопасить передачу данных форм по незащищённому каналу? Ну, только не говорите про наколеночную эмуляцию функциональности tls яваскриптом.
И вот вы заходите на свой любимый форум (пусть это будет ixbt) в кафе, вводите логин и пароль и, как ни в чём не бывало, продолжаете сёрфить сеть. А ваш логин и пароль ушли в базу злоумышленника. Теперь эти люди могут использовать ваш аккаунт на форуме в гнусных целях. Скажем если там есть личка — слать людям спам. Или регистрировать спам-топики. Или накручивать голосования. Но вы то IT-ик, у вас, наверное, на ixbt особенный пароль. А вот у вашего знакомого, условно, Пети, на все сайты 1 пароль. И когда он зашёл в этом кафе в свой профиль на ixbt, то тут же подарил злоумышленникам доступ к своей почте, социальным сетям и прочим ресурсам. Продолжать? Замечу, что ixbt как был без уязвимостей, так и остался. Но из-за уязвимости соединения — кто-то хорошо разжился.
неправильно навяливать шифрование там где оно не нужно.
вот скажем был ресурс с некислой посещаемостью и на нем не было никогда взломов итп (хотите пример — forum.ixbt.com, например).
А давайте, вы сходите на этот ресурс, нажмёте там кнопочку логина и внезапно (вот сурпрайз-то!), попадёте на страничку с https :)
Спасибо за такой замечательный пример! Апплодирую стоя!
и на нем не было никогда взломов
Доказательства?
с безопасностью ситуация не улучится
Именно что улучшится. Почитайте что-нибудь по теме, кроме "у меня аккаунт не угоняли, значит ни у кого не угоняли".
А давайте, вы сходите на этот ресурс, нажмёте там кнопочку логина и внезапно (вот сурпрайз-то!), попадёте на страничку с https :)
А теперь давайте мы с вами снова вернемся в кафе, где хакер Va$$ilY, попивая смузи, заканчивает собирать куки сессий залогиненых пользователей сайта ixbt через свой хоспот «Free Cafee Wifi», а его скрипт «make_bad_thing.py» с помощью этих куки рассылает плохой спам.
Именно по этой причине браузеры и не разрешают mixed content.
У меня там нет аккаунта, я не знаю что там дальше происходит :). Меня позабавило лишь то, что сайт приводится как пример того, что они вовсе не используют https, тогда как на самом деле любой может просто нажать на ссылку и убедиться в ошибочности этого утверждения. Так-то понятно, что https сам по себе не уберегает от других способов выстрелить себе в ногу. Он предоставляет лишь одну возможность защиты, а беспокойный ум кое[хк]акеров может выдумать бесконечно много возможностей ею не воспользоваться. %)
Читайте по губам — "А давайте, вы сходите на этот ресурс, нажмёте там кнопочку логина и внезапно (вот сурпрайз-то!), попадёте на страничку с https :) Спасибо за такой замечательный пример! Апплодирую стоя!"
там у сайта очень высокая посещаемость, подозреваю что введение https требует серьезного вложения в апгрейд инфраструктуры
Вас кто-то обманул. Шифрование не так уж чтобы особо ресурсоёмкая операция в наши дни. Тот же aes поддерживается современными процессорами на уровне команд.
Хозяев сайта понять можно — нет времени и сил это делать, но им бы надо понять что сделать это все-таки нужно.
А при чём здесь кука? Речь шла о краже данных из форм. Куки — уже более другая тема.
Ну, а то, что касается данного сайта — ну, я же говорил, что и при использовании самых защищённых технологий идиот найдёт массу поводов выстрелить себе в ногу несмотря на все попытки предоставить ему возможность сделать нормально. :) Похоже, они краем уха слышали что-то про https и даже зачем-то приделали его на страницу логина, но так и не поняли зачем это надо и как это работает :). Понабирают школоту по объявлениям…
Какие деньги, какие силы, вы о чём? Я, опять же, уже говорил, что считать ресурсы на шифрование сейчас просто смешно. И даже ресурсы на обновление — они же УЖЕ подняли https для некоторых страниц сайта. То есть сделали 99% работы. Всё, что осталось — пара строк в конфиге ngnix'а.
зачем красть данные из форм на публичном форуме?
Это называется — кража айдентети и это довольно большая проблема на самом деле. То, что вы об этом не в курсе, вовсе не говорит о том, что это не проблема. "у меня пока ничего не спёрли, значит всё в порядке", ога. Тем не менее, даже идиоты с приведённого вами примером, форума этим вопросом озаботились. То, что не озаботились другими… — ну, на они и идиоты.
Другого применения этим данным из форм нету
Мир отнюдь не ограничен похапешными форумками. Но даже в данном примере, кража аутентификационной информации — гораздо более ценная добыча, чем кража сессионной куки. Даже с точки зрения рассылки спама (но отнюдь ею не ограничена, вам даже как минимум один пример её использования привели, а вообще их больше).
это Вам смешно, потому что Вы видимо сайта с большой посещаемостью не делали.
Похапешный местечковый форумок? Нет, не делал. С высокой посещаемостью — делал. Лет 10 назад. Когда действительно могли быть проблемы с производительностью. И, как раз, по требованию заказчика делал именно подобную систему обхода защиты :). После чего на пальцах объяснял почему так делать не надо, вот прямо как вам сейчас :). Заказчик был более понятливый. Возможно, потому, что там были его деньги и принцип — херак, херак и в продакшн означал для него потерю его денег.
Тем печальнее ситуация для его многочисленных пользователей.
Намного печальней доминутная(От 20 сек.) реакция(Когда должна быть полсекундной) на ответ от такого сервиса.
Всё когда-нибудь бывает в первый раз. Нормально внедрять средства защиты информации при выявлении, а не осуществлении угрозы. Если, конечно, информация того стоит.
- Повторно — какие ваши доказательства? Страусинная позиция — у меня не угоняли учётку, значит этого не может быть никогда? А, ну-ну!
2 и 3 Тем хуже для посителей этоих сайтов - В чём таки сомнительность технологии, вы так часто об этом пишите, но так и не пояснили? В том, что вы не понимаете как и зачем это работает?
Но вот вы такой один и вы знаете что никому ваш сайт не нужен (простите, без обид). Хотя вряд ли вы будете рады если некоторым посетителям вашего сайта будут показывать детское некро-гей-порно с террористами.
Пример, просто притянутый за уши для того чтобы ответить на вопрос: имеем слегка левую точку доступа с маршрутизацией через контролируемый кем-то прокси-сервер. На этом сервере для всего трафика меняем все встречающиеся номера телефонов и email-адреса на свои и смотрим кто нам звонит и пишет.
Другой пример — официальная точка доступа от компании *илайн: всем, кто в кафе/метро заходит на вашу страничку выскакивает баннер с предложением поменять тариф на более выгодный или хотя бы почитать пять страниц очень полезной информации о тарифах. И спасибо что даже в поездке в Питер вы пользуетесь нашей сетью, как и дома в Москве (кстати, мы вам тут куку свою обновили, не благодарите).
Третий пример — я сейчас сижу в кафе, вроде как ограничение wifi в пару часов, после этого показывает заглушку рекламную. Но только на http. https-странички показываются без проблем, а для http приходится vpn поднимать.
Общий ответ: MITM. Поверьте умным дяденькам, которые стоят к основам технологии ближе чем мы с вами, что они не просто от своей блажи продвигают повсеместный https.
По-моему, у вас в голове каша. При чём здесь статический сайт или не статический, сгенерированый он джекилом, да хоть даже хайдом? Вы статью-то читали? Речь идёт о защите пользовательских данных, посылаемых из форм. Из ФОРМ, Карл! Если у вас нет форм, то ни кто вас не заставляет. От слова ВООБЩЕ (хотя, даже в этом случае есть варианты, когда поддержка сайтом ssl'я нужна). Давайте, вы, всё-таки, хоть что-то почитаете по теме. А то ваши надувания щёк в попытке высказать мнение чрезвычайной глупости выглядят крайне убого.
И если вам действительно что-то не нужно, с чего вы взяли, что сама технология от этого стала сомнительной? Мне, вот, ваш сайт не нужен, значит вас сайт — сомнительный?
Да нет никакого принудительного введения, что вы заладили повторять эту чушь? Есть предупреждение о небезопасной передаче данных из форм клиента. Если нет данных из форм, то нет никакого предупреждения и, тем более, "принудительного внедрения". Вы вообще в курсе того, о чём говорите? Такое ощущение, что слышали звон, но вообще не подозреваете о чём речь.
Включил dev panel в firefox, завел аккаунт. При создании юзера все идет по https, какие-то ресурсы грузятся с ulogin.ru — видимо используется для SSO с другими ресурсами (следите за руками!).
Завели юзера, а вот при логине после одного POST запроса на https идет перенаправление на http и сразу несколько GET запросов на адреса ixbt.photo, forum.ixbt.com/?id=loginmake&…, ixbt.video/cgi-bin/login_save_uid.cgi?uid=блабла, и, внимание, www.gametech.ru/cgi-bin/login_save_uid.cgi?uid=блабла
тупо копируем последний URL в адресную строку другого (!) браузера (Chrome) и после захода на сайт www.gametech.ru мы — вуаля — внезапно залогинены в аккаунт юзера.
Правда после короткого времени при переходе по ссылкам сессия пропадает, но просто было лень копаться.
Опять же, если взять единственную cookie с именем uid, наверное, можно много чего сделать, учитывая что в сообществе ixbt еще несколько связанных сайтов (ixbt.photo, komok, ...)
Кстати, ixbt был изначально приведен только как пример. Вектор атаки очевиден, а оставленная на пару дней фейковая точка доступа со сниффером соберет http-трафика достаточно чтобы еще обнаружить десяток ресурсов.
Возможно там много стороннего контента, работающего через HTTP. Например bb-[img/]-коды в постах участников форума. Или какие-нибудь партнёрские программы/баннера/встраиваемые механизмы, которые пока не умеют HTTPS.
Здесь же, скорее всего, в самом деле, просто древний движок на однажды настроенных серверах и куча обвеса на чем-нибудь типа Perl-скриптов. По себе знаю как это выглядит изнутри — заходишь «улучшить»: открываешь скрипт, смотришь, закрываешь скрипт, уходишь.
На самом деле не настолько сложно все перенести на https и даже ссылки в постах заменить — тоже не первые они у кого такое встречается. Ну неделю-другую посидеть.
Просто никому не надо.
Как раз наоборот, безусловный редирект — признак полностью сознательного решения, а вовсе не раздолбайства.
по мне так: https — это то о чем может подумать разработчик того или иного сайта, заталкивать его насильно — неправильно.
Никто и не заставляет разработчиков под дулом пистолета переходить на https.
Просто в случае с https браузеростроители думают в первую очередь о своих пользователях.
А настройки такой не будет, и это хорошо. :)
, а самое главное — в том, что можно подсунуть невдупляющему юзеру под видом сайта с пиццей. :)
Вот не уверен я, что невдупляющему юзеру будет какая-то разница между просто поддельным сайтом с пиццей, или поддельным сайтом с пиццей и перечеркнутым красненьким замочком в строке адреса.
Шифрование гораздо более лёгкая операция, чем рендеринг сложного DOM, просчёт влияния CSS стилей и исполнение JavaScript. Она просто капля в море на их фоне. Плюс скорость сети такова, что данные всегда поступают медленнее, чем обрабатываются. Так что для пользователя разница на уровне плацебо на самом деле.
«Спасибо, я уже знаю, чем мне может грозить передача форм по http»
Во всеми нелюбимом IE было (а наверно и сейчас есть) предупреждение при отправке любой формы примерно такого содержания: "Данные, отправленные в интернет, могут быть доступны третьим лицам, продолжить?" (и опция "больше не спрашивать"). В других браузерах такого не видел. И на мой взгляд оно более честное, чем предупреждения только про http.
Как не заставляют? Ну вот смотрите — на http соединении теперь не работает geolocation API, например. И еще service worker-ы.
Это авторы Chrome позаботились о том, чтобы наша геолокация не утекла к конкурентам. Причем заметьте — это наши пользователи, не их. У меня вот вообще интранет, закрытая сеть, либо пользователи на VPN. Это не их дело, не авторов хрома, как я собираюсь защищать своих пользователей, и нужно ли их вообще защищать.
по мне так: https — это то о чем может подумать разработчик того или иного сайта, заталкивать его насильно — неправильно.
О чём думает разработчик тут не при чём, браузер предупреждает пользователя. А дальше ему решать.
Неправильно то неправильно.
Но подавляющее большинство разработчиков и владельцев сайтов — обычные люди.
Им влом изучать что то новое, если это новое лежит не непосредственно на пути их интересов. Им влом платить пока жаренный петух не клюнул. И пр. И пр.
Работает же? Ну и хорошо. А мы поленимся.
Большая часть людей вообще работает только потому что кушать будет нечего. Поэтому людей нежно пинать
Для этого не нужен никакой хакер. Просто обновляемое ПО для, скажем, роутера. В котором есть база на все популярные сайты. Или даже без базы. Роутер помимо основной задачи высматривает исходящий траффик на предмет полей вроде passwd, password и им подобных. А обнаружив такое — просто шлёт на сервер злоумышленника. А там даже если под конкретный сайт Васи Пупкина поддержки ещё нет, эта информация будет лежать и ждать своего часа. Накопится, условно, критическая масса — на сайт "посмотрят", изучат формы, скажем, авторизации и страница профиля, и добавят в общую базу на общих основаниях. Хотя в принципе достаточно просто пары логин-пароль. У большинства пользователей 1-2 пароля на все сайты. Ещё можно людям подсовывать расширения на установку. А потом из таких вот заражённых ПК устраивать ботнеты. Честно говоря бездна всяких возможностей, вмешиваясь в трафик сайтов без уязвимостей, вершить грязные дела.
Проблема с редиректом, насколько я понимаю, имеет место быть. Но там не всё так грустно. Если я правильно понял суть заголовка Strict-Transport-Security, то он сильно усложняет жизнь таким редиректам, в случае, если этот сайт был открыт ранее в нормальных условиях. Ещё есть некий HSTS preload list, но он выглядит как-то несерьёзно в масштабах всего интернета. Надеюсь нас ждут какие-нибудь более серьёзные механизмы.
Чтобы вернуть редирект, надо внедриться в https-сессию, а если у вас это получится, то редирект будет уже не нужен.
Однако всё же правы и те кто за SSL, и те кто против SSL.
SSL защищает только соединение. (Могу ошибаться.)
Но уязвимыми будут всегда и сервер, и клиент как конечные точки. (Здесь неправ? Всякие случаи бывают.)
За внедрение SSL борются, т.к. это не очень сложно и, при желании, бесплатно. И при этом заметно снижает количество векторов атак.
SSL/TLS в первую очередь защищает именно соединение.
Значит не ошибся.
Плюс может подтверждать пользователю, что он находится на сайте, принадлежащем конкретному юр. лицу (если во-первых это юр. лицо раскошелилось на Extended Validation сертификат, а во-вторых пользователь достаточно грамотный).
Это всего лишь одна из приятных плюшек SSL.
Насчет второго, не все пользователи достаточно грамотные в этом плане.
Если в строке адреса рядом с зелёным замком появляется «плашка» с названием организации (пример: paypal.com) — значит на сайте Extended Validation сертификат и этот сайт правда принадлежит тому юр. лицу, которое указано на «плашке». Если просто зелёный замок (пример: habrahabr.ru) — значит соединение зашифровано и идёт до того сайта, который набран в строке адреса.
Это довольно забавно, потому что «вызвать тревогу у подписчиков и нанести ущерб бизнесу» — именно то, чего добивались разработчики браузеров!
В таком случае компания в полном моральном (а наверно, и юридическом, но тут, к сожалению, не уверен) праве подать на указанных разработчиков в суд за вышеуказанное вредительство.
Нужность/ненужность https — отдельная тема, но браузерописатели сильно наглеют и забывают своё место, и в первую очередь естественно благодаря гуглу. Браузер — это программа для показа сайтов, она вторична и должна выполнять что ей говорит пользователь, вводя адрес, и сайт своим кодом, а не пытаться что-то навязывать как первой, так и второй стороне.
Совсем обнаглели эти бесплатные опенсурсные браузеры.
Какова была бы реакция? А что, open source — могут вешать, что захотят, главное бесплатно…
Не то чтобы я был против HTTPS — мне в общем-то все равно.
Браузер — это программа для показа сайтов, она вторична и должна выполнять что ей говорит пользователь, вводя адрес
Нафига тогда пользователю вообще показывать в строке, https там или нет, лишние буквы только смущают. Так эти наглецы разработчики ещё и картинку рядом ставят!
Поставить ненавязчивое уведомление (которое пользователь, вероятно, захочет видеть) — это одно, а пытаться указывать пользователю "это смотри. а это не смотри" — совсем другое. С тем же https с невалидными сертификатами — ок, показали предупреждение, я нажал кнопку "мне пофиг, показывай и не возражай" — и браузер должен показывать. Но нет, они со временем прячут эту кнопку всё дальше и дальше, чтобы МНЕ затруднить её нажатие. А ещё ff с некоторых пор её вообще не показывает если на сайте было HSTS — пишет что "нельзя". Что это такое? Почему браузер запрещает мне проигнорировать предупреждение? Повторюсь, его первоочередная задача — исполнять указания пользователя, какими бы они ни были. Ну я то пропатчил ему исходник и убрал эту гадость, а многие просто послушаются.
Так суть HSTS как раз в том, что если вдуг получился только http, значит это или mitm, или сервер хакнули и туда (сейчас) идти нельзя.
Не браузеру решать, что можно а что нельзя. Решает пользователь, максимум его можно предупредить.
Боюсь, что в этом случае вы не правы, т.к. спецификация явно требует разрывать не безопасные соединения с hsts хостами. https://tools.ietf.org/html/rfc6797#section-8.4
Надо подсказать роскомнадзору оформить свои списки в виде спецификаций, тогда наверно сразу прекратятся возражения против них, а авторы браузеров встроят блокировки прямо в код браузеров и всем будет хорошо.
А если серьёзно, то в нормальных спецификациях (тот же http) наоборот призывается клиенту/серверу быть максимально толерантными к тем нарушениям протокола с удалённой стороны, которые не создают непреодолимых препятствий к пониманию чего они хотели.
Если роскомнадзор придумает вменяемую спецификацию, её обсудят сообществом и примут как рекомендацию w3c, то почему бы и нет.
Но это представляется маловероятным, ведь сообщество никогда не примет механизм для зацензуривания интернета, не так ли?
Обсуждаемую особенность конечно сложно назвать цензурой, но у неё и ркн-блокировок есть очень важная общая деталь: и там и там за вас решили, что вам это не надо, и какие-то люди по собственному желанию охраняют вас от "опасностей". И там и там они, разумеется, действуют в ваших же интересах, а то вдруг вы по глупости откроете что-то не то, да и пострадаете. Методы реализации этой "охраны" немного разные, да, но это уж кто как может так и делает.
Браузер — это программа для показа сайтов, она вторична и должна выполнять что ей говорит пользователь, вводя адрес, и сайт своим кодом
<sarcasm> И всплывающие окна браузер не должен пытаться блокировать, и редиректы, и без вопросов любому сайту давать доступ к вебкамере и микрофону — а не пытаться что-то навязывать. </sarcasm>
Блокировка неавторизованной ПОЛЬЗОВАТЕЛЕМ активности — хорошее дело. Но решать, что блокировать а что нет, должен именно пользователь, а браузер может только дать ему ненавязчивый и отключаемый в настройках совет.
Если бы компании могли диктовать браузеру что он должен показывать и как, то блокировщики рекламы давно были бы запрещены, как и кастомный цсс и хм… отображение сайта не на том разрешении которое стоит у генерального.
Вообще-то это свинство, у меня есть внутри компании ресурсы, которые не смотрят в интернет. Ещё есть сбербанк онлайн, который весь трафик на usb токене шифрует, а с пользователем взаимодействует через http на локальном порту.
Подобные сообщения просто не соответствуют действительности для таких ресурсов, и сбивает пользователей с толку, а сделать с этим (в случае сбербанка) вообще ничего нельзя.
Пустить через локальный прокси с SSL?
у меня есть внутри компании ресурсы, которые не смотрят в интернет
Это не значит что они сразу стали безопасными. Один сниффер внутри сети — и все.
Митник прав до сих пор.
А если это сисадмин, то против него https и так бессилен :)
security.insecure_field_warning.contextual.enabled;false
Отключить не удается. Приходится открывать через IE.
Причём схема переписывается скрытно, без запроса, без уведомления, тупой безусловный рерайт.
Разработчики упорно навязывают пользователям свои понятия о добре и зле, хорошим это не кончится.
Он объяснял, что из-за плохого кода на бэкенде сайт могут взломать даже при наличии SSL, но зелёный замочек остаётся, вводя пользователей в заблуждение, поэтому HTTPS бесполезен.
Глупость какая, причем тут это? SSL в первую очередь защищает данные от перехвата на пути до того самого бекенда, что стало особенно актуально в некоторых странах в последние годы.
Форум как форум, нашлось много интересной мне инфы, но это не важно.
С самого начала поразило, что все ссылки там циркулируют исключительно как HTTP, таким образом, почти любой переход по форуму ведет к принудительному редиректу на нешифрованную версию. При этом сертификат там есть и даже работает, но, как видно по скрину, практически на каждой странице есть элементы, которые передаются по HTTP. И даже это не такая большая проблема — я просто включил HTTPS Everywhere (там этот форум кстати уже прописан!), позже переключился на встроенное в NoScript средство, но в таком строгом режиме отрубается большинство полезных скриптов, подгружающих контент, типа превьюшек постов, профилей и т.п., так как они там захардкодены на HTTP, судя по всему. %)
Я даже пошел в HTTPS Everywhere и уже почти завел там тикет, чтобы они исключения добавили, но потом передумал, ибо нефиг поощрять раздолбайство… :)
Так вот, у меня вопрос, стоит ли им туда постить тему с просьбой пофиксить это безобразие или то, что в поиске по форуму не нашлось ни одной темы с таким вопросом за годы, уже говорит о том, что всем пофиг и реакция будет как у контор из этой статьи? :)
Так что данные карт на этот сайт не попадают, а только статус транзакции передает сбербанк
Не понимаю откуда такая истерика про введение HTTPS. Его сейчас настроить может любой школьник по гайдам, выписать сертификат на Letsencrypt и получить А+ в ssllabs.
Железо современное с AES NI и прочим позволяет практически бесплатно шифровать. А если выписать ECDSA сертификаты то и хендшейки станут почти бесплатными.
Проблема в том, что бекенд должен генерировать все ссылки правильно, или $scheme://site/path, или //path.
Плюс, весь подгружаемый контент с других ресурсов и ссылки на всякие рекламные пиксели должны быть с такой же схемой (http/https).
А у сайта с большим количеством помета мамонта старого кода, скорее всего, полно мест, которые надо переписать для такого поведения.
Захардкоженные ссылки с http — обычное дело.
Короче, работы там много.
В данном случае кто-то просто решил пойти по пути страуса, сунуть голову в песок и не делать эту работу.
Затея глупенькая, хотя бы потому, что скоро вообще все http ресурсы будут помечаться, как небезопасные.
Я же не зря написал про Letsencrypt — настроил один раз и забыл.
Не во всех ситуациях можно легко настроить Letsencrypt на автоматическое обновление. Скажем, нужно будет настраивать чтобы перед запуском cертбота открывался файерволл для серверов Letsencrypt, прописывались dns, а после обновления всё возвращалось на круги своя. Плюс помнится при попытке настроить Letsencrypt на нескольких серваках на одно имя, балансирующихся по rr, тоже проблемы были. В общем он только для простейших случаев годится, когда есть сервачок с постоянным адресом, с постоянным именем, с рутовым доступом.
Скажем, нужно будет настраивать чтобы перед запуском cертбота открывался файерволл для серверов Letsencrypt, прописывались dns, а после обновления всё возвращалось на круги своя
Зачем так сложно? Паранои ради? Даже если так, то всё без проблем делается через pre/post скрипты.
Плюс помнится при попытке настроить Letsencrypt на нескольких серваках на одно имя, балансирующихся по rr, тоже проблемы были
Никаких проблем — проксируй со всех фронт-серверов URL /.well-known на бэкенд занимающийся обновлением сертификатов. Этот бэкенд уже раскидает их по необходимым хостам.
В общем он только для простейших случаев годится, когда есть сервачок с постоянным адресом, с постоянным именем, с рутовым доступом
См. выше, это заблуждение. Можно сделать любую желаемую топологию, софта для ACME уже куча со всякими разными возможностями. Зачем рут — не очень понятно.
А вот трюк с CSS я пытался воспроизвести на одном проекте, чтобы отключить автозаполнение формы входа. И в ФФ это не работает.
Обход предупреждений браузера с помощью псевдопарольных полей