Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 84
А еще они запрещают использовать пароль, который у вас уже когда-то был. «Соление» и хэширование выполняется на стороне сервера, и они наврядли будут дублировать этот функционал со стороны клиента, где он может быть подсмотрен, что в дальнейшем может стать еще большей дырой в безопасности. Так что, скорее всего они сравнивают хэш вашего набранного пароля со всеми вашими предыдущими хэшами (или каким-то их последним количеством, не суть важно).
А нельзя посылать вместо открытых данных хотя бы хеш-идентификатор какой-нибудь, а на стороне сервера уже ковырять бд?
Чтобы лишними данными, все-таки, не светить по оптоволокну.
Чтобы лишними данными, все-таки, не светить по оптоволокну.
Немного не понял про ebay: какие кэширующие сервера, какое нарушение безопасности? Для передачи данных используется https соединение и о передаваемых данных знают только браузер и сервер. Реализация проверки кривая, но никакой безопасности это не может ухудшить.
GET параметры хранятся в логах сервера, поэтому утечка логов становится почти идентичной утечке базы паролей, которые хранятся в открытом виде.
В данном случае, может, это и не так критично, т.к. логин не передается, но все-равно это глупость несусветная. В частности, имея базу паролей, можно перебирать известные логины, т.к. обычно, если известно, что юзер зарегистрирован на сайте, то скорее всего это будет его публичный емейл.
В данном случае, может, это и не так критично, т.к. логин не передается, но все-равно это глупость несусветная. В частности, имея базу паролей, можно перебирать известные логины, т.к. обычно, если известно, что юзер зарегистрирован на сайте, то скорее всего это будет его публичный емейл.
GET параметры хранятся в логах сервера
Логи можно настроить как угодно, отсекая GET-часть или сохраняя вообще все тело запроса, включая POST и куки.
Но я сомневаюсь, что кто-то вообще хранит логи запросов в конкретно этом случае — это не имеет смысла.
В частности, имея базу паролей, можно перебирать известные логины
А если учесть ещё дополнительную информацию, например дату регистрации (если она открыта), то, сопоставив ее с таймштампами логов можно сделать процесс подбора гораздо более незаметным и эффективным.
Https соединение заканчивается на TLS termination proxy, к которым доступ есть у очень ограниченной группы лиц (т.к. ssl сертификат для компании — штука очень ценная, в отличие от логинов и паролей всяких). Дальше данные обычно идут в открытом виде в сети компании.
Так что о ваших данных знают: вы, теоретические спецслужбы с wildcard сертификатом до сетей компании, терминирующий сервер, теоретические спецслужбы с подключением во внутреннюю сеть компании, и только потом backend.
Это в теории. На практике, кроме этого, я не удивлюсь, если браузер сам полезет этот URL с паролем проверять по базе фишинговых ссылок. Всё ведь для защиты пользователя!
Так что о ваших данных знают: вы, теоретические спецслужбы с wildcard сертификатом до сетей компании, терминирующий сервер, теоретические спецслужбы с подключением во внутреннюю сеть компании, и только потом backend.
Это в теории. На практике, кроме этого, я не удивлюсь, если браузер сам полезет этот URL с паролем проверять по базе фишинговых ссылок. Всё ведь для защиты пользователя!
Браузер, сервер и еще правительство Казахстана
Запрещая копипаст пароля, сайты фактически пытаются помешать использованию парольных менеджеров
Ну, за все говорить не буду, но KeePass имеет функцию автозаполнения, при том использует не копипаст, а эмуляцию нажатия клавиш в окне.
А вот ограничения на длину, состав паролей, да и тот же копипаст — бесят жутко.
В случае запрещенного копи-паста в инпуте можно попробовать использовать drag-n-drop выделенного участка текста — его перехватывают значительно реже.
>Удивительно, но этот *нестандартный* ивент до сих пор работает, причём не только в Internet Explorer, но ещё и в Chrome, и в Safari, и в Firefox.
Вот бы еще стандарты так дружно реализовывали бы.
Вот бы еще стандарты так дружно реализовывали бы.
>Вот что совершенно непонятно — так это зачем с каждым POST-запросом на каждое нажатие клавиш в тело POST добавляется имя >пользователя и адрес электронной почты.
Потому что password != username
Потому что password != username
Никогда не понимал заморочек касаемо ограничения минимальной длины пароля, использования спецсимволов, etc. Казалось бы, это мой пароль, и я имею право с ним делать что хочу. Сделали бы просто чекбокс с описанием «да, я понимаю что мой пароль фигня, осознаю всю тяжесть возможных последствий, дайте мне продолжить». К пейпалу у меня, например, привязана виртуальная карта, на которой денег нет. Понадобилось что-то — закинул, оплатил, забыл. При таком подходе двадцатизначный цифро-букво-символьный пароль с разным регистром просто не нужен. Ну стащите с этой карты 20 центов остатка, я не обижусь, заодно и узнаю что поломали.
Возможно это связано с репутацией сервиса. Никому не нравится читать в новостях про хакеров, набрутивших 100500 паролей к твоему сайту. Просто мое предположение.
Да элементарно можно ограничить по минимальной длине (например, 6 символов) и задержку при неправильном вводе (как при ssh-соединении). Сбрутить не выйдет. Но к чему ограничивать по содержимому? Часто встречал, что не пропускает элементарные символы %?;# и т.д. А по максимальной длине зачем?
Эти ограничения не связаны с какими-то особенностями работы базы данных?
Чтобы хранить в базе в открытом виде? Или ещё вариант — использование хренового алгоритма хеширования, который игнорирует большее количество символов?
Но таки да — такие закидоны меня тоже сильно смущают.
Но таки да — такие закидоны меня тоже сильно смущают.
Чтобы хранить в базе в открытом виде?Хоть за это на кол надо сажать, но даже так, какая БД не может сохранить 255 печатных символов? Почему не больше 20? Откуда это 20 взялось? От балды?
Просто ограничения пропорциональны радиусу кривизны рук разработчиков, единственное, что приходит на ум.
Видимо криво спроектированная. Нет ну представьте — пишет такой сервис нуб или говнокодер. Знать не знает о базовых для всех понятий ИБ. Но точно видел, что есть куча сервисов (винда вроде тоже имела/имеет ограничение на длину?), которые ограничивают максимальную длину пароля… А ещё есть куча быдло-пхп-примеров с хранением в чистом виде и! авторизацией! с помощью sql-запроса (стандартная sql-инъекция… да)…
Придумал ещё одно обоснование ограничению: если используется долговычислимое хеширование или шифрование асимметрично-долговычислимое, то количество символов в пароле может сказываться на скорости шифрования (но 20 символов… мне всё равно не понять...) и появляется ограничение с точки зрений производительности.
Ещё один вариант (если быть точным — развитие варианта) — шифрование на отдельном сервисе.
PS каюсь — на заре своего опыта разработки тоже пару проектиков написал без хеширования пароля… правда я использовал мускульный varchar (до 65536 символов, если мне память не изменяет). А в курсовых ещё и авторизацию по sql-запросу делал…
PPS вспоминается бородатый анекдот про школу и имя мальчика:
Школа: Здравствуйте, это из школы, где учится ваш сын. У нас тут неприятности с компьютером.
Мама: О, боже. Он что-то сломал?
Школа: Можно сказать… Вы действительно назвали своего сына Роберт'); DROP TABLE Students;--?
Мама: А, да. Дома мы его зовем Робин-Брось-Таблицу.
Школа: Теперь у нас стерлась база учеников за этот год. Надеюсь, вы рады.
Мама: А я надеюсь, что это научит вас экранировать символы во входных данных.
Придумал ещё одно обоснование ограничению: если используется долговычислимое хеширование или шифрование асимметрично-долговычислимое, то количество символов в пароле может сказываться на скорости шифрования (но 20 символов… мне всё равно не понять...) и появляется ограничение с точки зрений производительности.
Ещё один вариант (если быть точным — развитие варианта) — шифрование на отдельном сервисе.
PS каюсь — на заре своего опыта разработки тоже пару проектиков написал без хеширования пароля… правда я использовал мускульный varchar (до 65536 символов, если мне память не изменяет). А в курсовых ещё и авторизацию по sql-запросу делал…
PPS вспоминается бородатый анекдот про школу и имя мальчика:
Школа: Здравствуйте, это из школы, где учится ваш сын. У нас тут неприятности с компьютером.
Мама: О, боже. Он что-то сломал?
Школа: Можно сказать… Вы действительно назвали своего сына Роберт'); DROP TABLE Students;--?
Мама: А, да. Дома мы его зовем Робин-Брось-Таблицу.
Школа: Теперь у нас стерлась база учеников за этот год. Надеюсь, вы рады.
Мама: А я надеюсь, что это научит вас экранировать символы во входных данных.
По поводу анекдота: да и в моих проектах строки с полей ввода передавались без экранирования, при чём эти модули и сейчас работают, никак руки не дойдут отрефакторить. Никто из нас не рождался опытными программистами, учиться всю жизнь приходится.
Вот только с этим софтом работают 8 с половиной операторов, и это не онлайн-ресурс. Потому я спокоен.
Вот только с этим софтом работают 8 с половиной операторов, и это не онлайн-ресурс. Потому я спокоен.
Вы про это? http://xkcd.ru/327/
Вспоминается история про какую-то американку с настоящей фамилией Null, которую из-за этого не могли зарегистрировать на самолёт, потому что система определяла слово Null как указание на пустое поле и требовала дозаполнить его.
Ограничения на нестандартные символы (в частности кириллицу) обычно оправдывают тем, что однажды может понадобиться ввести пароль на раскладке, на которой этих символов просто нет. Поэтому со спецсимволами «всё не так однозначно» ©
Да черт с ним, с ebay! Как с кобрами то справились?
И много ли паролей было скомпрометировано?
Т.е тебе наплевать на то что
Хотя таким как ты вероятно наплевать
Длинный день был?
А как такой аргумент:
Не бывает надёжных систем. Бывают популярные, в которых выгодно искать уязвимости и ломать. Поэтому аргумент «ломали дважды» не единственный показатель ненадёжности. Ломануть можно и человека, если овчинка стоит выделки.
Не бывает надёжных систем. Бывают популярные, в которых выгодно искать уязвимости и ломать. Поэтому аргумент «ломали дважды» не единственный показатель ненадёжности. Ломануть можно и человека, если овчинка стоит выделки.
У меня нет премиума и я не пользуюсь менеджерами паролей. Я их просто запоминаю.
Мне почему-то показалось, что Вы сторонник точки зрения, что та система, которой пользуетесь — является защищённой. Точнее, Вы считаете (мне так видится), что незащищённость одной системы автоматически делает другие более защищёнными.
Поэтому я и напомнил, что нет абсолютно безопасных систем.
Можно сравнивать надёжность одной системы относительно другой, но от этого надёжными на 100% они не станут.
Мне почему-то показалось, что Вы сторонник точки зрения, что та система, которой пользуетесь — является защищённой. Точнее, Вы считаете (мне так видится), что незащищённость одной системы автоматически делает другие более защищёнными.
Поэтому я и напомнил, что нет абсолютно безопасных систем.
Можно сравнивать надёжность одной системы относительно другой, но от этого надёжными на 100% они не станут.
Я не регистрируюсь на сайтах, где ограничения на длину пароля больше, чем в 25 символов.
Для некритичных использую один простой пароль.
Двухфакторная авторизация для критичных + разные сложные пароли.
Но я не агитирую за\против менеджеров паролей, каждый сам для себя решает, что ему нужно.
И не стоит забывать, что даже если Вы храните пароли локально, не везде авторизация и база паролей\хэшей так же надёжны.
Да и вообще, пароль чаще всего не цель, а инструмент для её достижения, поэтому не надо зацикливаться на надёжности пароля (я не предлагаю обратного — пренебрегать этим), надо думать обо всей безопасности и способах защиты того, где пароль — один из способов.
Для некритичных использую один простой пароль.
Двухфакторная авторизация для критичных + разные сложные пароли.
Но я не агитирую за\против менеджеров паролей, каждый сам для себя решает, что ему нужно.
И не стоит забывать, что даже если Вы храните пароли локально, не везде авторизация и база паролей\хэшей так же надёжны.
Да и вообще, пароль чаще всего не цель, а инструмент для её достижения, поэтому не надо зацикливаться на надёжности пароля (я не предлагаю обратного — пренебрегать этим), надо думать обо всей безопасности и способах защиты того, где пароль — один из способов.
tsya.ru
Этот вопрос элегантно обходица.
Не было там утечек. Была непонятная активность с их бд, поэтому они слали письма о смене мастер пароля для предосторожности.
Ну GET запросы можно выставлять с заголовком private. Что в этом плохого?
Если данный заголовок не спасает от попадания запроса в логи сервера (а скорее всего он не спасает), то плохое есть. Ибо утечка логов будет равняться утечке базы паролей. При этом в логах пароли будут без соли и какого-либо хеширования. Да и вообще могут быть менее защищены (ибо в нормально спроектированном сервисе утечка логов сервера неприятна, но не фатальна для безопасности).
Для пущей феерии осталось только такую гениальную идею реализовать:
«Извините, Вы не можете использовать этот пароль, т.к. он уже используется пользователем vasya.pupkin@email.ru. Придумайте другой пароль»
А вообще, да, такие ограничения бесят, и не только на длину и сложность, но и еще когда заставляют раз в месяц менять пароль, при этом запоминая Х последних и не давая повторяться — вот это квест!
К слову, рабочий VPN за полтора (!) месяца при авторизации начинает донимать напоминалкой, что пароль надо будет сменить: «до истечения срока действия пароля осталось 45...(44...43...42) дней», вызывая цветистую гамму эмоций.
«Извините, Вы не можете использовать этот пароль, т.к. он уже используется пользователем vasya.pupkin@email.ru. Придумайте другой пароль»
А вообще, да, такие ограничения бесят, и не только на длину и сложность, но и еще когда заставляют раз в месяц менять пароль, при этом запоминая Х последних и не давая повторяться — вот это квест!
К слову, рабочий VPN за полтора (!) месяца при авторизации начинает донимать напоминалкой, что пароль надо будет сменить: «до истечения срока действия пароля осталось 45...(44...43...42) дней», вызывая цветистую гамму эмоций.
А мысль-то в общем-то хорошая, если правильную реализацию сделать:
— если набралось больше n человек использующих одинаковый пароль — записать его в список «слишком простых паролей», отрекомендовать всем владельцам такой пароль сменить и не рекомендовать (не блокировать!) его использовать вновь устанавливающим пароль.
— если набралось больше n человек использующих одинаковый пароль — записать его в список «слишком простых паролей», отрекомендовать всем владельцам такой пароль сменить и не рекомендовать (не блокировать!) его использовать вновь устанавливающим пароль.
К чему мелочиться! «Извините, Вы не можете использовать этот пароль, т.к. уже использовали его на сайте geektimes.ru. Придумайте другой пароль. С ув., администрация сайта pupkin.ru»
А вот некоторые отечественные сайты типа сайта МосЭнергоСбыта пошли другим путем — они запрещают не пароли без спецсимволов, а пароли со спецсимволами, например с подчеркиванием. Чем в этом случае руководствовались разработчики я даже предположить не могу.
Вы еще не видели, что делает Samsung!
У меня есть кондиционер с WiFi модулем (Jungfrau AQV09). Задать ему пароль для подключения к точке доступа можно либо приложением (под Андроид), либо через WPS. WPS'а у меня, естественно, нет (OpenWRT), а приложение мало того, что не дает ввести пароль больше 26 символов, так еще и ограничивает набор- нельзя вводить ничего, кроме цифр и символов алфавита, в смысле %&$ — нельзя. Вот такой маразм!
У меня есть кондиционер с WiFi модулем (Jungfrau AQV09). Задать ему пароль для подключения к точке доступа можно либо приложением (под Андроид), либо через WPS. WPS'а у меня, естественно, нет (OpenWRT), а приложение мало того, что не дает ввести пароль больше 26 символов, так еще и ограничивает набор- нельзя вводить ничего, кроме цифр и символов алфавита, в смысле %&$ — нельзя. Вот такой маразм!
Запрет на копипаст в браузере меня не сильно беспокоит, ведь всегда можно выключить яваскрипт, вставить пароль, а потом включить яваскрипт.
Гораздо сильнее напрягает запрет на копипаст в мобильных приложениях, в частности, в некоторых банковских клиентах.
Гораздо сильнее напрягает запрет на копипаст в мобильных приложениях, в частности, в некоторых банковских клиентах.
Ещё бы точки/звёздочки убрать из инпутов паролей. Что-что, а они мало спасают от кражи пароля. Хорошо, что хоть сейчас появилась тенденция делать рядом кнопку [посмотреть пароль].
на ebay на странице смены пароля можно просто отключить js. Только так я смог таки вставить длиннющий пароль с keepass, ибо запоминать пароли мне религия не позволяет.
Вы немного перемудрили с отсылом на ebay «кстати, вместе с драконовским и совершенно ненужным ограничением на длину пароля в 20 символов» ограничение начинается с 8 символов и никто не заставляет ставить 20.
use 8-20 characters (используйте от 8 до 20 символов).
use 8-20 characters (используйте от 8 до 20 символов).
VМожно странный вопрос: а что, туземцам кобры не мешали?
Банковское приложение Райффайзена под Android. Логин случайным образом генерируется банкоматом, при этом приложение его не запоминает. Надо всегда хранить его записанным где-нибудь в мобильнике.
Старый длинковский маршрутизатор (ещё без вайфая): видимых ограничений на длину пароля нет, ввести можно любой. Вот только он втихую обрежется до восьми символов. И потом удивляться будете, что не подходит.
Старый длинковский маршрутизатор (ещё без вайфая): видимых ограничений на длину пароля нет, ввести можно любой. Вот только он втихую обрежется до восьми символов. И потом удивляться будете, что не подходит.
> В принципе, этот JavaScript-модуль обычно работает на стороне клиента, и тогда необходимость в таком кейлоггере и POST-запросах на каждое нажатие клавиш отпала бы.
Как клиентский модуль будет проверять слитый пароль? то что ваш пароль оказался в одной из слитой баз данных например.
> Остаётся только догадываться о причинах, зачем с каждым символом передавать адрес электронной почты.
Чтобы ловить недобросовестных продавцов, очевидно же.
Как клиентский модуль будет проверять слитый пароль? то что ваш пароль оказался в одной из слитой баз данных например.
> Остаётся только догадываться о причинах, зачем с каждым символом передавать адрес электронной почты.
Чтобы ловить недобросовестных продавцов, очевидно же.
Эффект кобры похож на самоотменяющееся предсказание http://profilib.com/chtenie/25032/neyt-silver-signal-i-shum-pochemu-odni-prognozy-sbyvayutsya-a-drugie-net-73.php
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эффект кобры. Кейлоггер на eBay и запрет на копипаст пароля