Во времена Британской империи у англичан возникла маленькая проблема на Индийском субконтиненте — кобры. Оказалось, что повсюду чертовски много этих рептилий. А ещё выяснилось, что они ядовиты. Это не нравилось колонистам, некоторые из них умирали. Поэтому британские власти придумали отличный выход. За каждую убитую кобру туземцам стали выплачивать небольшое вознаграждение. Казалось бы, проблема решена.
К сожалению, индийцы иначе интерпретировали условия выплаты вознаграждений. Они посчитали это отличной причиной, чтобы разводить ядовитых змей и сдавать их за деньги. Осознав проблему в изначальной логике, британские власти отменили выплату вознаграждений. Ну, а индийцам ничего не оставалось, кроме как выпустить огромное количество кобр на свободу. В результате, их количество в индийских лесах выросло многократно.
Оттуда пошло выражение эффект кобры. Ситуация, когда принятое для исправления проблемы решение не исправляет эту проблему, а ведёт к прямо противоположному результату.
Об эффекте кобры приходится вспоминать, глядя на некоторые меры безопасности, которые реализуются для защиты пользователей на отдельных сайтах. Например, сайты заставляют использовать пароли со специальными символами и цифрами, тем самым отсекая максимально надёжные парольные фразы 40-50 символов с наибольшей энтропией. Или ещё более странная «мера безопасности» — запрет на копипаст в поле ввода пароля.
Запрет на копипаст в поле ввода пароля
Судя по всему, таким способом сайт защищается от хакеров, которые копипастом вставляют чужие пароли из базы с украденными паролями.
Объяснение несуразное, но в реальности многие сайты уже запретили копипаст в поле ввода пароля. Например, на сайтах GE Capital невозможно скопировать пароль в поле ввода при авторизации. Разумеется, это сделано для безопасности. Но пользователям не объясняются причины. Не появляется никаких сообщений «Ради вашей безопасности» или тому подобных. Пароль просто исчезает.
На сайте PayPal аналогичная блокировка действует на странице изменения пароля (кстати, вместе с драконовским и совершенно ненужным ограничением на длину пароля в 20 символов).
Ну здесь хотя бы объясняют, ради чего всё затеяно.
Самое интересное, что блокировка ввода пароля часто реализована с помощью onpaste — нестандартного ивента, которое когда-то придумала компания Microsoft для своего браузера Internet Explorer.
<input type="password" name="j_password" class="DataPasive"
maxlength="14" size="23" onkeypress="return logonWithEnter(event)"
autocomplete="off" onpaste="return false">Удивительно, но этот нестандартный ивент до сих пор работает, причём не только в Internet Explorer, но ещё и в Chrome, и в Safari, и в Firefox. Да и если бы он не работал, есть другие светлые идеи, как «хакнуть» функциональность Ctrl+V (Shift+Ins) в браузерах.
Такая «защита от хакеров» просто абсурдна, считает известный специалист по безопасности Трой Хант (Troy Hunt), потому что единственный по-настоящему безопасный пароль — это такой, который вы не можете запомнить (без учёта длинных парольных фраз, которые и так заблокированы другими парольными ограничениями). Соответственно, для генерации пароля с максимальной энтропией лучше использовать специализированные генераторы паролей и парольные менеджеры вроде 1Password, KeePass или LastPass. Смысл в том, что вы делегируете функцию «запоминания» пароля своему парольному менеджеру, а десятки сгенерированных уникальных паролей храните в надёжном месте под защитой одного мастер-пароля.
Запрещая копипаст пароля, сайты фактически пытаются помешать использованию парольных менеджеров, то есть де-факто они снижают уровень безопасности пользователей (хотя некоторые парольные менеджеры умеют обходить такую блокировку копипаста).
Кейлоггер eBay
Ещё один интересный пример, как сайты заботятся о безопасности своих пользователей — функция кейлоггера в форме переустановки пароля на сайте eBay.
В консоли браузера можно убедиться, что при вводе пароля браузер отправляет десятки POST-запросов на серверы eBay.
Хорошо ещё, что кейлоггер работает по HTTPS.
При каждом нажатии клавиши в окне ввода пароля отправляется запрос. Судя по тому, что они уходят на /PWDStrength, можно предположить, что таким своеобразным образом работает модуль проверки надёжности пароля, который оценивает его энтропию и сообщает пользователю результат: «хороший» у него пароль или «плохой».
В принципе, этот JavaScript-модуль обычно работает на стороне клиента, и тогда необходимость в таком кейлоггере и POST-запросах на каждое нажатие клавиш отпала бы.
Вот что совершенно непонятно — так это зачем с каждым POST-запросом на каждое нажатие клавиш в тело POST добавляется имя пользователя и адрес электронной почты.
В принципе, такой кейлоггер не очень опасен, ведь вся информация отправляется по защищённому соединению HTTPS, хотя как-то странно чувствовать, что с каждым нажатием отправляется запрос с твоим адресом электронной почты и именем пользователя.
В компании eBay действует программа выплаты вознаграждений за найденные уязвимости. Когда один из хакеров сообщил о баге, сотрудник компании прислал официальный ответ:
Здравствуйте, Дэвид!
Спасибо за ваше письмо. Есть некоторые причины, из-за которых работает текущая реализация, но я не смогу предоставить вам дополнительную информацию об этом.
Спасибо,
eBay Security Research
Остаётся только догадываться о причинах, зачем с каждым символом передавать адрес электронной почты.
Но это ладно. Хуже другое: в некоторых других местах на сайте eBay при смене пароля кейлоггер отправляет уже не POST-запросы, а GET-запросы на каждое нажатие клавиши.
Хотя здесь в теле запроса нет адреса электронной почты и имени пользователя, но это уже опаснее, потому что GET-запросы могут кэшироваться на прокси-серверах и сохраняются в логах.
В общем, разработчикам всегда желательно помнить об опыте британских колонизаторов в Индии — они тоже хотели как лучше…
Комментарии (84)
tmin10
29.06.2016 20:32Немного не понял про ebay: какие кэширующие сервера, какое нарушение безопасности? Для передачи данных используется https соединение и о передаваемых данных знают только браузер и сервер. Реализация проверки кривая, но никакой безопасности это не может ухудшить.
Nepherhotep
29.06.2016 23:44+1GET параметры хранятся в логах сервера, поэтому утечка логов становится почти идентичной утечке базы паролей, которые хранятся в открытом виде.
В данном случае, может, это и не так критично, т.к. логин не передается, но все-равно это глупость несусветная. В частности, имея базу паролей, можно перебирать известные логины, т.к. обычно, если известно, что юзер зарегистрирован на сайте, то скорее всего это будет его публичный емейл.Hellsy22
30.06.2016 03:54GET параметры хранятся в логах сервера
Логи можно настроить как угодно, отсекая GET-часть или сохраняя вообще все тело запроса, включая POST и куки.
Но я сомневаюсь, что кто-то вообще хранит логи запросов в конкретно этом случае — это не имеет смысла.Nepherhotep
30.06.2016 10:08Проблема в том, что, скорее всего, логи никто не будет специально настраивать. А как правило, логи хранят от любых запросов, включая сотни попыток автоматических скриптов зайти в админку или выполнить эксплоит.
Hellsy22
30.06.2016 23:13-2скорее всего, логи никто не будет специально настраивать
Мы вроде как говорим про сайты уровня ebay, а не про студенческую поделку за два бутерброда и пиво.
Thero
30.06.2016 12:58+1боюсь новые законы позаботятся о том чтоб логи сохранялись и текли куда надо…
trapwalker
30.06.2016 11:06+1В частности, имея базу паролей, можно перебирать известные логины
А если учесть ещё дополнительную информацию, например дату регистрации (если она открыта), то, сопоставив ее с таймштампами логов можно сделать процесс подбора гораздо более незаметным и эффективным.
rlidwka
30.06.2016 01:56+2Https соединение заканчивается на TLS termination proxy, к которым доступ есть у очень ограниченной группы лиц (т.к. ssl сертификат для компании — штука очень ценная, в отличие от логинов и паролей всяких). Дальше данные обычно идут в открытом виде в сети компании.
Так что о ваших данных знают: вы, теоретические спецслужбы с wildcard сертификатом до сетей компании, терминирующий сервер, теоретические спецслужбы с подключением во внутреннюю сеть компании, и только потом backend.
Это в теории. На практике, кроме этого, я не удивлюсь, если браузер сам полезет этот URL с паролем проверять по базе фишинговых ссылок. Всё ведь для защиты пользователя!
ploop
29.06.2016 20:48+6Запрещая копипаст пароля, сайты фактически пытаются помешать использованию парольных менеджеров
Ну, за все говорить не буду, но KeePass имеет функцию автозаполнения, при том использует не копипаст, а эмуляцию нажатия клавиш в окне.
А вот ограничения на длину, состав паролей, да и тот же копипаст — бесят жутко.
venyaz
29.06.2016 21:02+5В случае запрещенного копи-паста в инпуте можно попробовать использовать drag-n-drop выделенного участка текста — его перехватывают значительно реже.
gearbox
29.06.2016 21:22+4>Удивительно, но этот *нестандартный* ивент до сих пор работает, причём не только в Internet Explorer, но ещё и в Chrome, и в Safari, и в Firefox.
Вот бы еще стандарты так дружно реализовывали бы.
x4uDaK
29.06.2016 22:27+2>Вот что совершенно непонятно — так это зачем с каждым POST-запросом на каждое нажатие клавиш в тело POST добавляется имя >пользователя и адрес электронной почты.
Потому что password != username
mxms
29.06.2016 23:05+2Но это не даёт ответа на вопрос отчего бы это не делать на стороне клиента, а не наяривать сервер.
Hayabusa
29.06.2016 23:09Никогда не понимал заморочек касаемо ограничения минимальной длины пароля, использования спецсимволов, etc. Казалось бы, это мой пароль, и я имею право с ним делать что хочу. Сделали бы просто чекбокс с описанием «да, я понимаю что мой пароль фигня, осознаю всю тяжесть возможных последствий, дайте мне продолжить». К пейпалу у меня, например, привязана виртуальная карта, на которой денег нет. Понадобилось что-то — закинул, оплатил, забыл. При таком подходе двадцатизначный цифро-букво-символьный пароль с разным регистром просто не нужен. Ну стащите с этой карты 20 центов остатка, я не обижусь, заодно и узнаю что поломали.
ABy
29.06.2016 23:30+4Возможно это связано с репутацией сервиса. Никому не нравится читать в новостях про хакеров, набрутивших 100500 паролей к твоему сайту. Просто мое предположение.
ploop
29.06.2016 23:47Да элементарно можно ограничить по минимальной длине (например, 6 символов) и задержку при неправильном вводе (как при ssh-соединении). Сбрутить не выйдет. Но к чему ограничивать по содержимому? Часто встречал, что не пропускает элементарные символы %?;# и т.д. А по максимальной длине зачем?
webkumo
30.06.2016 00:01Чтобы хранить в базе в открытом виде? Или ещё вариант — использование хренового алгоритма хеширования, который игнорирует большее количество символов?
Но таки да — такие закидоны меня тоже сильно смущают.ploop
30.06.2016 00:09+1Чтобы хранить в базе в открытом виде?
Хоть за это на кол надо сажать, но даже так, какая БД не может сохранить 255 печатных символов? Почему не больше 20? Откуда это 20 взялось? От балды?
Просто ограничения пропорциональны радиусу кривизны рук разработчиков, единственное, что приходит на ум.webkumo
30.06.2016 00:21Видимо криво спроектированная. Нет ну представьте — пишет такой сервис нуб или говнокодер. Знать не знает о базовых для всех понятий ИБ. Но точно видел, что есть куча сервисов (винда вроде тоже имела/имеет ограничение на длину?), которые ограничивают максимальную длину пароля… А ещё есть куча быдло-пхп-примеров с хранением в чистом виде и! авторизацией! с помощью sql-запроса (стандартная sql-инъекция… да)…
Придумал ещё одно обоснование ограничению: если используется долговычислимое хеширование или шифрование асимметрично-долговычислимое, то количество символов в пароле может сказываться на скорости шифрования (но 20 символов… мне всё равно не понять...) и появляется ограничение с точки зрений производительности.
Ещё один вариант (если быть точным — развитие варианта) — шифрование на отдельном сервисе.
PS каюсь — на заре своего опыта разработки тоже пару проектиков написал без хеширования пароля… правда я использовал мускульный varchar (до 65536 символов, если мне память не изменяет). А в курсовых ещё и авторизацию по sql-запросу делал…
PPS вспоминается бородатый анекдот про школу и имя мальчика:
Школа: Здравствуйте, это из школы, где учится ваш сын. У нас тут неприятности с компьютером.
Мама: О, боже. Он что-то сломал?
Школа: Можно сказать… Вы действительно назвали своего сына Роберт'); DROP TABLE Students;--?
Мама: А, да. Дома мы его зовем Робин-Брось-Таблицу.
Школа: Теперь у нас стерлась база учеников за этот год. Надеюсь, вы рады.
Мама: А я надеюсь, что это научит вас экранировать символы во входных данных.ploop
30.06.2016 00:33По поводу анекдота: да и в моих проектах строки с полей ввода передавались без экранирования, при чём эти модули и сейчас работают, никак руки не дойдут отрефакторить. Никто из нас не рождался опытными программистами, учиться всю жизнь приходится.
Вот только с этим софтом работают 8 с половиной операторов, и это не онлайн-ресурс. Потому я спокоен.
StjarnornasFred
30.06.2016 17:28Вспоминается история про какую-то американку с настоящей фамилией Null, которую из-за этого не могли зарегистрировать на самолёт, потому что система определяла слово Null как указание на пустое поле и требовала дозаполнить его.
BlessMaster
30.06.2016 09:02Ограничения на нестандартные символы (в частности кириллицу) обычно оправдывают тем, что однажды может понадобиться ввести пароль на раскладке, на которой этих символов просто нет. Поэтому со спецсимволами «всё не так однозначно» ©
ploop
30.06.2016 13:45Поэтому со спецсимволами «всё не так однозначно» ©
Какая кириллица, когда не пропускают стандартный ASCII в виде всяких тильд, апострофов, кавычек?
ABy
29.06.2016 23:22+12Да черт с ним, с ebay! Как с кобрами то справились?
impetus
30.06.2016 04:30+6Предоставили Индии независмость и теперь это проблема индусов?
Впрочем, избыток кобр сильно сократил численность крыс,
которые не только поедатели урожая, но и переносчики кучи жутких болезней.
Так что не всё столь однозначно.
Loriamar
29.06.2016 23:34+2Да почему же LastPass постоянно считают НАДЁЖНЫМ хранилищем? У них уже как минимум ДВЕ!!! утечки было. Надежная онлайн хранилка паролей это оксюморон!
bubuq
30.06.2016 01:16И много ли паролей было скомпрометировано?
Loriamar
30.06.2016 02:08-1Т.е тебе наплевать на то что проприетарный онлайновый продукт уже минимум дважды (это то что я помню, что помнит гугл одному гуглу известно). Тебе главное сколько скомпрометированно? Пока гром не грянет мужик не перекрестица, да?
Конечно же ластпасс не выдаст инфу о том сколько было слито. Это итак уже удар по репутации солидный. А если раскрыть масштабы… Потому они и ограничились в обоих случаях общими словами да советом сменить пароль.
Хотя таким как ты вероятно наплевать на надежность хранения ключницы. А я пожалуй продолжу пользоваться KeePass в TrueCrypt контейнере в собственном OwnCloud'еbubuq
30.06.2016 02:39+8Т.е тебе наплевать на то что
Хотя таким как ты вероятно наплевать
Длинный день был?Loriamar
30.06.2016 08:53-1Стандартный. 24 часа. Как у всех на этой планете. А что какая либо аргументация по предмету обсуждения кончилась и теперь главное хоть както придратся к собеседнику? Это уже разговор уровня /b/ какой-то.
LoadRunner
30.06.2016 10:07+1А как такой аргумент:
Не бывает надёжных систем. Бывают популярные, в которых выгодно искать уязвимости и ломать. Поэтому аргумент «ломали дважды» не единственный показатель ненадёжности. Ломануть можно и человека, если овчинка стоит выделки.Loriamar
30.06.2016 10:16Да но локальный клиент всё равно в разы надежней, т.к за его сохранность отвечаешь только ты. Ты и никто другой. Ни дядя с дырявыми и проприетарными разработаками, ни зондирующие браузеры.
А сломанный секурный сервис который подразумевает под собой полную безопасность — это нонсенс. А ломать человека можно и с lastpass. Но в отличии от keepass где ломать можно только человека, в lastpass можно и человека и сервис и среду работы. Точек отказа в разы больше.
А что у вас куплен премиум в ластпассе? Вы его так рьяно защищаете…LoadRunner
30.06.2016 11:33У меня нет премиума и я не пользуюсь менеджерами паролей. Я их просто запоминаю.
Мне почему-то показалось, что Вы сторонник точки зрения, что та система, которой пользуетесь — является защищённой. Точнее, Вы считаете (мне так видится), что незащищённость одной системы автоматически делает другие более защищёнными.
Поэтому я и напомнил, что нет абсолютно безопасных систем.
Можно сравнивать надёжность одной системы относительно другой, но от этого надёжными на 100% они не станут.Loriamar
30.06.2016 12:42Вы запоминаете 25 символьный пароль? Для каждого логина уникальный? Каждый раз?
Я сторонник той точки зрения что сервис БЕЗОПАСНОСТИ который себя уже дважды скомпрометировал не достоин не того чтобы даже упоминаться в списке, не говоря уже о том чтобы считаца надежным.
А простите локальный сервис зависит от меня. И пока я надёжен, то и локальный сервис — надежен. Это же очевидно. Я поражаюсь такой зашорености и тому что абсолютно очевидные утверждения вызывают какието вопросы.
Любая информация хранящаяся онлайн по умолчанию являеца слитой. Рано или поздно.LoadRunner
30.06.2016 12:58Я не регистрируюсь на сайтах, где ограничения на длину пароля больше, чем в 25 символов.
Для некритичных использую один простой пароль.
Двухфакторная авторизация для критичных + разные сложные пароли.
Но я не агитирую за\против менеджеров паролей, каждый сам для себя решает, что ему нужно.
И не стоит забывать, что даже если Вы храните пароли локально, не везде авторизация и база паролей\хэшей так же надёжны.
Да и вообще, пароль чаще всего не цель, а инструмент для её достижения, поэтому не надо зацикливаться на надёжности пароля (я не предлагаю обратного — пренебрегать этим), надо думать обо всей безопасности и способах защиты того, где пароль — один из способов.Loriamar
30.06.2016 13:47Я вообще стараюсь нигде не регестрироватсья. Но в ключнице храняца не только от сайтов пароли. И да пароль — это инструмент. И лучше бы этот инструмент был надежным а не сделаным из говна и палок.
ydaf
30.06.2016 11:43+1Не было там утечек. Была непонятная активность с их бд, поэтому они слали письма о смене мастер пароля для предосторожности.
keydon2
30.06.2016 00:13Ну GET запросы можно выставлять с заголовком private. Что в этом плохого?
KivApple
30.06.2016 01:14+1Если данный заголовок не спасает от попадания запроса в логи сервера (а скорее всего он не спасает), то плохое есть. Ибо утечка логов будет равняться утечке базы паролей. При этом в логах пароли будут без соли и какого-либо хеширования. Да и вообще могут быть менее защищены (ибо в нормально спроектированном сервисе утечка логов сервера неприятна, но не фатальна для безопасности).
Lure_of_Chaos
30.06.2016 02:32+4Для пущей феерии осталось только такую гениальную идею реализовать:
«Извините, Вы не можете использовать этот пароль, т.к. он уже используется пользователем vasya.pupkin@email.ru. Придумайте другой пароль»
А вообще, да, такие ограничения бесят, и не только на длину и сложность, но и еще когда заставляют раз в месяц менять пароль, при этом запоминая Х последних и не давая повторяться — вот это квест!
К слову, рабочий VPN за полтора (!) месяца при авторизации начинает донимать напоминалкой, что пароль надо будет сменить: «до истечения срока действия пароля осталось 45...(44...43...42) дней», вызывая цветистую гамму эмоций.webkumo
30.06.2016 09:27А мысль-то в общем-то хорошая, если правильную реализацию сделать:
— если набралось больше n человек использующих одинаковый пароль — записать его в список «слишком простых паролей», отрекомендовать всем владельцам такой пароль сменить и не рекомендовать (не блокировать!) его использовать вновь устанавливающим пароль.ftkvyn
30.06.2016 10:12Уже встречал такое на Steam, кажется, где мне на все мои попытки установить один из своих любимых паролей и их модификаций выдавало «ваш пароль слишком популярный, придумайте что-то посложнее». Я-то придумал, но запомнить так и не запомнил, приходится входить каждый раз через восстановление пароля.
proDOOMman
30.06.2016 10:32К чему мелочиться! «Извините, Вы не можете использовать этот пароль, т.к. уже использовали его на сайте geektimes.ru. Придумайте другой пароль. С ув., администрация сайта pupkin.ru»
Samoglas
30.06.2016 02:36+1Как же задалбывает, когда сайт не хочет запоминать пароль в поле ввода. Из-за пресловутой безопасности, как они это понимают или кривых рук, как у разработчиков Сбербанк Онлайн или orfogrammka.ru, где в Firefox пароли не запоминаются.
Lure_of_Chaos
30.06.2016 03:03Или сделано при помощи ExtJS. Разрабатываем систему, тоже, сцуко, не запоминает пароли (
m1n7
30.06.2016 11:43+1Гораздо хуже, когда сайт запоминает не то.
Плачу за электричество, так там номер карты и цвц запоминается, а имя/фамилия — нет.
Hellsy22
30.06.2016 03:56А вот некоторые отечественные сайты типа сайта МосЭнергоСбыта пошли другим путем — они запрещают не пароли без спецсимволов, а пароли со спецсимволами, например с подчеркиванием. Чем в этом случае руководствовались разработчики я даже предположить не могу.
VaHG
30.06.2016 07:41+2Вы еще не видели, что делает Samsung!
У меня есть кондиционер с WiFi модулем (Jungfrau AQV09). Задать ему пароль для подключения к точке доступа можно либо приложением (под Андроид), либо через WPS. WPS'а у меня, естественно, нет (OpenWRT), а приложение мало того, что не дает ввести пароль больше 26 символов, так еще и ограничивает набор- нельзя вводить ничего, кроме цифр и символов алфавита, в смысле %&$ — нельзя. Вот такой маразм!
Eugney
30.06.2016 09:43Запрет на копипаст в браузере меня не сильно беспокоит, ведь всегда можно выключить яваскрипт, вставить пароль, а потом включить яваскрипт.
Гораздо сильнее напрягает запрет на копипаст в мобильных приложениях, в частности, в некоторых банковских клиентах.
foxmuldercp
30.06.2016 11:50Именно. у меня нет паролей короче 40 символов со спецсимволами, я их ни одного не знаю и даже никогда не видел, и вводить такое руками — суперсекьюрно… попытки до второй
ploop
30.06.2016 13:52Особенно на смартфоне. Даже 20-значный выбешивает так, что все прелести «мобильного онлайна» кроются трёхэтажными словами…
foxmuldercp
30.06.2016 20:58Поэтому я на смартфоне логинюсь в винду + скайп и дальше все пароли передаю через скайпик…
ну или в гугль акк + скайпик
inoyakaigor
30.06.2016 11:53Ещё бы точки/звёздочки убрать из инпутов паролей. Что-что, а они мало спасают от кражи пароля. Хорошо, что хоть сейчас появилась тенденция делать рядом кнопку [посмотреть пароль].
force
30.06.2016 14:19+1Демонстрации, или дубовый вход по VNC сильно намекают, что звёздочки использовать по умолчанию стоит.
Lure_of_Chaos
30.06.2016 14:22Да, такая вот традиция набора вслепую. Впрочем, пальцы хорошо запоминают знакомые движения.
donvictorio
30.06.2016 13:21на ebay на странице смены пароля можно просто отключить js. Только так я смог таки вставить длиннющий пароль с keepass, ибо запоминать пароли мне религия не позволяет.
ploop
30.06.2016 13:53Да я выше писал — keepass поддерживает автозаполнение эмуляцией нажатия клавиш. Настройте один раз и забудьте.
Alter116
30.06.2016 17:10Вы немного перемудрили с отсылом на ebay «кстати, вместе с драконовским и совершенно ненужным ограничением на длину пароля в 20 символов» ограничение начинается с 8 символов и никто не заставляет ставить 20.
use 8-20 characters (используйте от 8 до 20 символов).ploop
30.06.2016 18:23+1ограничение начинается с 8 символов и никто не заставляет ставить 20.
Как раз ограничение, только сверху. Почему нельзя 25? Ограничение снизу хоть логично, его можно понять (безопасность), а сверху?
sumanai
30.06.2016 18:32+1Вы немного перемудрили с отсылом на ebay «кстати, вместе с драконовским и совершенно ненужным ограничением на длину пароля в 20 символов» ограничение начинается с 8 символов и никто не заставляет ставить 20.
Вообще- то автор намекает на то, что 20 символов- это мало, и ограничение в 20 символов ничем не обосновано и в общем то не нужно.
И там PayPal.
P.S. Я буду обновлять комментарии.
betrachtung
01.07.2016 05:38Банковское приложение Райффайзена под Android. Логин случайным образом генерируется банкоматом, при этом приложение его не запоминает. Надо всегда хранить его записанным где-нибудь в мобильнике.
Старый длинковский маршрутизатор (ещё без вайфая): видимых ограничений на длину пароля нет, ввести можно любой. Вот только он втихую обрежется до восьми символов. И потом удивляться будете, что не подходит.
Fedcomp
01.07.2016 08:05> В принципе, этот JavaScript-модуль обычно работает на стороне клиента, и тогда необходимость в таком кейлоггере и POST-запросах на каждое нажатие клавиш отпала бы.
Как клиентский модуль будет проверять слитый пароль? то что ваш пароль оказался в одной из слитой баз данных например.
> Остаётся только догадываться о причинах, зачем с каждым символом передавать адрес электронной почты.
Чтобы ловить недобросовестных продавцов, очевидно же.
W__W
06.07.2016 23:24Эффект кобры похож на самоотменяющееся предсказание http://profilib.com/chtenie/25032/neyt-silver-signal-i-shum-pochemu-odni-prognozy-sbyvayutsya-a-drugie-net-73.php
alexkunin
Но, конечно же, это нужно делать на стороне клиента, с этим нельзя не согласиться.
sylvix
А еще они запрещают использовать пароль, который у вас уже когда-то был. «Соление» и хэширование выполняется на стороне сервера, и они наврядли будут дублировать этот функционал со стороны клиента, где он может быть подсмотрен, что в дальнейшем может стать еще большей дырой в безопасности. Так что, скорее всего они сравнивают хэш вашего набранного пароля со всеми вашими предыдущими хэшами (или каким-то их последним количеством, не суть важно).
alexkunin
Очень даже логично. А раз какие-то проверки нельзя с клиента перенести на сервер, то можно вообще их все перенести на сервер и не дублировать функциональность.
Кстати, скриншот в статье очень старый, пейпал давно (вроде бы, я так-то не слежу) не так выглядит. Сейчас зашел в аккаунт — https://www.paypal.com/myaccount/settings/password/edit/ — ничего никуда не шлется пока Enter не нажмешь.
Wanderer12
А нельзя посылать вместо открытых данных хотя бы хеш-идентификатор какой-нибудь, а на стороне сервера уже ковырять бд?
Чтобы лишними данными, все-таки, не светить по оптоволокну.
alexkunin
Ну, они по хттпс «светят», а такое свечение так просто не уловить. Кроме того, в какой-то момент этот пароль все равно будет послан — когда человек закончит вводить форму. Так что они решили, что хэшировать бесполезно, я так думаю.