Ты видно не вчитался.
Если пароль правильный и это первая попытка ввести правильный пароль, выдавать "пароль/логин неправильные".
То есть когда брутфорсер, который просто перебирает по очереди пароли, введёт правильный, зайти у него не получится, и он пойдёт дальше перебирать пароли.
А юзер, который пароль знает, просто введёт его второй раз.
Если пароль правильный и это первая попытка ввести правильный пароль, выдавать "пароль/логин неправильные".
То есть когда брутфорсер, который просто перебирает по очереди пароли, введёт правильный, зайти у него не получится, и он пойдёт дальше перебирать пароли.
А юзер, который пароль знает, просто введёт его второй раз.
Ты видно не вчитался.
Если пароль правильный и это первая попытка ввести правильный пароль, выдавать "пароль/логин неправильные".
То есть когда брутфорсер, который просто перебирает по очереди пароли, введёт правильный, зайти у него не получится, и он пойдёт дальше перебирать пароли.
А юзер, который пароль знает, просто введёт его второй раз.
Если пароль правильный и это первая попытка ввести правильный пароль, выдавать "пароль/логин неправильные".
То есть когда брутфорсер, который просто перебирает по очереди пароли, введёт правильный, зайти у него не получится, и он пойдёт дальше перебирать пароли.
А юзер, который пароль знает, просто введёт его второй раз.
Ну так это гениально!!! Только надо будет как-то объяснить пользователям, почему не сразу работает - на сайте идёт профилактика.
Ничего не надо объяснять: у пользователя включен CapsLock/лишний пробел/забыл перейти на латиницу. Так поддержка всегда и будет отвечать.
Ох уж этот блядский тысячу раз перезагруженный рутер, но ниправильная без звонка в саппорт, они сразу скажут, что да, видим ваш рутер завис надо ЕЩЁ раз перезагрузить. И вот видите, это ваш рутер глючил, чотвы так переживаете.
А сами в тихую свои маршрутерезаторы ребутают по быстрому...
А сами в тихую свои маршрутерезаторы ребутают по быстрому...
ну и что ты предлагаешь говорить клиенту? ой это мы вам порт хуевый маршрутизатор поставили и он виснет постоянно? или может у него там кз в кабее или в порту пока не передернешь не проходит. клиенту это знать не надо. это ему надо ротуер передернуть.
Ну я бы начал узнавать уровень технической грамотности. И если не прям ламер, то можно и признать, оно же постоянно виснет.
На самомо деле клиенты просто постоянно пиздят, что роутер уже перезагрузили (Ставят себе всякое говно, но упорно думают, что проблема на стороне провайдера). По этому всегда просим ещё раз перезагрузить (Ну нельзя в ебало сказать, что пихдишь ты, я же вижу. Это ведь некультурно).
Даже если роутер - это коробочка от провайдера, в которую оптика вставляется?
Как правило дропают сетевую регу на брасе или типа того, а ребут марша просто как доп страховка, вдруг он тоже выпендривается. так сказать 2 зайцев одним выстрелом.
И тут я который вводит пароль при помощи мышки с макросами
Ага, особенно когда пароль вводишь не руками, а копипастом, или через менеджер паролей.
либо начнет вспоминать свой пароль, а когда дойдет до смены пароля получит сообщение что нельзя использовать старый пароль
Кстати, мне кажется, что некоторые так и сделали, например, мой банк, когда я в говно :)
В Лиге Легенд так сделали. Первый ввод всегда в отказ.
Скорее у юзера будет реакция "чё, бля?" и пойдёт звонок местному админу "ваш сайт не работает!" "какой у меня пароль?"
Может лучше капчу показать?
Может лучше капчу показать?
За некоторые виды капчи хочется убивать.
Это другой вопрос, к обсуждаемой теме не относится
Какая вероятность, что при брутфорсе именно первая попытка логина будет с правильным паролем?
Я бы написал isPasswordCorrect and isFirstCorrectPasswordAttempt {Error('Wrong logipass')}
Я бы написал isPasswordCorrect and isFirstCorrectPasswordAttempt {Error('Wrong logipass')}
Тут любая попытка : если пароль и пасс правильный - первый раз пиши "нихуя подобного". человек еще раз попробует то-же самое, робот попиздит перебирать дальше.
Это пока не утечёт наружу, что пароль нужно дважды вводить. Перепишут робота, будет по два раза пробовать. Только дольше будет перебирать и всё. Лучше уж тогда сделать несколько паролей. Угадал первый, угадывай теперь второй. И чтобы требования по сложности у этих паролей были разные. А а в промежутках попросить одноразовый код из смс.
и фотку с паспортом и флажком
и данные с анального зонда
режется банальным fail2ban-ом который мониторит доступ к урлу логина. слишком много логинов с одного ип - в jail и досвиданья.
В локалке, допустим, это сработает. Можно ещё сразу отправлять охрану. А из интернета? Писать белый список айпишников? А как быть с тем, что у клиентов не обязательно белый айпи и даже скорее всего серый. Можно спокойно забанить правильного клиента.
ну тогда впендюрить капчу на ввод пароля, что ли...
isFirstLoginAttemt - первая попытка логина, не первая успешная, а первая просто.
Имеется в виду первая попытка ввода правильного пароля
Хуевые названия переменных даже в комиксах, сука.
Брутфорсера проще ловить на переборе (или по атаке по словарю), ввёл X раз пароль неправильный - подожди Y минут.
Или более жёсткий кейс - сброс пароля после X неправильных паролей.
А если идёт вход по скомпрометированной базе, то и вводящий может ещё раз попробовать, особенно если в курсе что такая фича есть. (Такие люди делают несколько фиктивных аккаунтов чтобы понять поведение работы системы, а это легко вычисляется)
Или более жёсткий кейс - сброс пароля после X неправильных паролей.
А если идёт вход по скомпрометированной базе, то и вводящий может ещё раз попробовать, особенно если в курсе что такая фича есть. (Такие люди делают несколько фиктивных аккаунтов чтобы понять поведение работы системы, а это легко вычисляется)
У нас делали не просто задержку, а экспоненциальную. Т.е. второй раз ты уже попробуешь через секунду, третий - через 3 секунды, и так далее. И блокировка аккаунта через 15 подряд неверных попыток.
Причём на экран при вводе пароля пользователю выводится история попыток входа с твоего аккаунта (на глубину последних 5 дней, когда ты пользовался системой), это помогло ловить варианты, когда взлом распределён по времени, некоторые злоумышленники, прежде чем качать данные, вначале после входа должны ознакомится с информационной средой, чтобы понять, где что лежит, и маскировали, а это время, не всё делали сразу.
После введения таких мер, уже 4-е года, не совру - нет фактов взлома через подбор. А на прежней системе они были. У нас абонентская база "сладкая" для конкурентов, потому пытаютися её стянуть перманентно...
Причём на экран при вводе пароля пользователю выводится история попыток входа с твоего аккаунта (на глубину последних 5 дней, когда ты пользовался системой), это помогло ловить варианты, когда взлом распределён по времени, некоторые злоумышленники, прежде чем качать данные, вначале после входа должны ознакомится с информационной средой, чтобы понять, где что лежит, и маскировали, а это время, не всё делали сразу.
После введения таких мер, уже 4-е года, не совру - нет фактов взлома через подбор. А на прежней системе они были. У нас абонентская база "сладкая" для конкурентов, потому пытаютися её стянуть перманентно...
А можно мэйлы тоже в виде хэшей с солью хранить?
а смысл? емейлы бывают нужны сайту не только для логина. их иногда показывают в качестве имени пользователя, генерят тебе же разные ссылки, например на сброс пароля, или mailto:-ссылки, и т.д.
Стащил кулхакер базу, а она вся в хэшах и солёных. И даже мэйлы не получить...
На здоровье, но это разные уровни защиты данных уже. Обфускация и прочая - это отдельный слой защиты непосредственно данных авторизационных учёток, с защищённостью самой процедуры логона его смешивать не надо.
Сброс пароля это жоска, если нет двухфакторно авторизации ещё могу понять...
за сброс принудительный сброс пароля вам отдельное увлажнение народа.
прикинь расклад: доброумышленники спалили на каком-то сайте такую фишку. далее берётся база похаченых где-то-как-то ящиков электропочты к которым есть доутуп, с каждого идёт попытка входа X раз, и тебе на ящик прилетает ссылка на сброс пароля! ай спасибо!
прикинь расклад: доброумышленники спалили на каком-то сайте такую фишку. далее берётся база похаченых где-то-как-то ящиков электропочты к которым есть доутуп, с каждого идёт попытка входа X раз, и тебе на ящик прилетает ссылка на сброс пароля! ай спасибо!
Всё зависит от уровня доступа к системе.
Если это интернет-магазин, то такая штука там не нужна, а если вход в бекоффис с важной информацией, то там много разных вещей используется для пресекания несанкционированного входа, в том числе и сброс пароля может использоваться.
Если это интернет-магазин, то такая штука там не нужна, а если вход в бекоффис с важной информацией, то там много разных вещей используется для пресекания несанкционированного входа, в том числе и сброс пароля может использоваться.
Вообще не важно, сама практика что ты можешь каким-то образом вызывать на известный адрес почты форму сброса пароля которую ты не запрашивал явно - порочна. В идеале запрос сброса пароля на сайте у тебя должен требовать ввод почтового адреса куда (если мы говорим именно о таком способе сброса) и не говорить тебе было ли отправлено письмо или нет, т.е. не подтверждать что пользователь с таким мылом в системе вообще есть.
Сознайся, тебя тоже задолбали ежемесячные смены паролей, даже с наличием 3-факторной аутентификации? :D
А по поводу сабжа, если атака идёт целенаправленно на один аккаунт в критической инфраструктуре, то иногда бывает лучше совсем сбросить пароль, может тогда юзер не только пароль, но и логин сменит.
А ещё и телефон с почтой себе новый заведёт. Так, на всякий случай...
А по поводу сабжа, если атака идёт целенаправленно на один аккаунт в критической инфраструктуре, то иногда бывает лучше совсем сбросить пароль, может тогда юзер не только пароль, но и логин сменит.
А ещё и телефон с почтой себе новый заведёт. Так, на всякий случай...
Или! Или...
Или юзер начнет в панике восстанавливать/менять пароль, а прога ему такая "новый пароль не может совпадать со старым".
Или юзер начнет в панике восстанавливать/менять пароль, а прога ему такая "новый пароль не может совпадать со старым".
Да, да "просто введет его второй раз" с точки зрения разраба (-__- )
А с практики:
Полезет менять пароль через почту и получит "Это ваш старый пароль, используйте новый" и начнет пригорать...
А с практики:
Полезет менять пароль через почту и получит "Это ваш старый пароль, используйте новый" и начнет пригорать...
А после смены пароля -- снова столкнётся с той же ловушкой
"Ваш новый пароль не может совпадать с одним из двадцати предыдущих"
Если это так, то что мешает настроить брутфорс на повторное введение одного и того же пароля 2 -3 раза подряд?
ловите хакера
Учитывая, что флаг первого ввода он внутри блока не изменяет, юзера тоже ждёт облом.
Просто очень хорошая защита от логина. Абсолютная.
Просто очень хорошая защита от логина. Абсолютная.
Я тот, у кого один удобный и запомненный пароль развился кучей вариаций из-за "слишком легкий" и "пароль должен содержать буквы, цифры и рог единорога", а потом поди вспомни у какого сервиса какие требования к паролю, и какой в итоге пароль именно у этой учётки.
Просто записываешь куда-нибудь себе и всё. Только не сами пароли, а шифровки к ним. Утащит кто-нибудь мой файлик, а там GMAIL - 45h3jfy436, ну и думай теперь ,что это значит. А я знаю, как это легко превратить в правильные 35 символов с нужными регистрами и символами.
Хуже всего конечно было с рабочими учётками. Нет более тупой и вредной системы, чем "прошло N дней, меняем пароли". Треть пользователей начинают рабочий день со сброса пароля через заявку в поддержку, треть имеет стикер с паролем на мониторе, остальные лепят один и тот же пароль, наращивая цифру в конце. Вплоть до смешного, когда для расчёта "стажа" лезут не в личный кабинет, а смотрят какая там цифра в пароле на стикере монитора.
Хуже всего конечно было с рабочими учётками. Нет более тупой и вредной системы, чем "прошло N дней, меняем пароли". Треть пользователей начинают рабочий день со сброса пароля через заявку в поддержку, треть имеет стикер с паролем на мониторе, остальные лепят один и тот же пароль, наращивая цифру в конце. Вплоть до смешного, когда для расчёта "стажа" лезут не в личный кабинет, а смотрят какая там цифра в пароле на стикере монитора.
тут скорее всего нужно первая попытка ввода правильно пароля, а не вообще ввод пароля как такового
при следующей попытке ввода пароля брутфорсом, будет использован новый пароль, один и тот же пароль дважды не будет подбираться
выше ValD описал
В итоге получится, что твой пароль не взломают. Скрипт подбора просто наткнувшись на правильный пароль получит ошибку и пойдет искать дальше. Не будет же он по два раза один и тот же пароль проверять. А вот юзер будет
да я уже понял
но тут больше смущает идея что сайт вообще позволяет себя брутфорсить, а не увеличивает время между следующими попытками зайти для этого логина
но тут больше смущает идея что сайт вообще позволяет себя брутфорсить, а не увеличивает время между следующими попытками зайти для этого логина
Всегда найдётся приколист, который по приколу начнёт перебирать логины, заранее вводя неправильный пароль. Просто чтобы у реальных пользователей случились проблемы со входом.
Ловить по адресу? Так у приколиста может быть весьма обширный пул адресов, да и реальный пользователь не на статике обычно сидит.
Ловить по адресу? Так у приколиста может быть весьма обширный пул адресов, да и реальный пользователь не на статике обычно сидит.
Если мы будет рассматривать нормальную, по уму написанную систему, то у реальных людей проблем не будет никаких. Реальные люди уже залогинены, им пофиг на попытки зайти под тем же логином, сессия то не сбрасывается. А те кто не залогинен, например у них та же сессия кончилась, вообще могут не заметить работы такой антибрут системы. То что тебя вылогинило, ещё не значит что у тебя сессия сбросилась или что кукиза в браузере удалилась. И вот ты приходишь логиниться с сессионной кукизой, и если антибрут система её видит, она просто не применяет по началу к тебе правила замедления. Ты для не её знакомый клиент. А брутфорсить пасс имея пусть и истёкшую но кукизу, это уже история из другой категории.
Чуть подушню. Эта хуйня по факту не работает - это просто внешняя по отношению к мощности пароля процедура входа, которая становится известна злоумышленнику даже чуть раньше, чем всем обычным пользователям. Намного эффективнее экспоненциальный рост задержки ответа системы при ошибочных попытках. С блокировкой аккаунта через 10-15-ть подряд неправильных.
Решаем одну проблему, создаем другую.
Представь, злоумышленник и узнал твой емейл, теперь ему достаточно 15 раз вести любой пароль и он заблокирует твой аккаунт. А если ты связался с администрацией и смог их убедить разблокировать твой аккаунт, то он сделает это повторно.
Представь, злоумышленник и узнал твой емейл, теперь ему достаточно 15 раз вести любой пароль и он заблокирует твой аккаунт. А если ты связался с администрацией и смог их убедить разблокировать твой аккаунт, то он сделает это повторно.
15-й раз - это надо ждать сутки. Первые 3 попытки можно сделать в пределах 5 секунд. Экспонента - она такая.
Да, действительно, так можно пакостить, но по факту таких случаев пока не было. Всё же намеренно пакостить - это дезавуировать себя, зловредам же важно и прийти, и уйти незамеченными. Зачем волновать отдел ИБ, они же насторожатся, взведут свои большие мушкеты, расставят силки и прочая...
Получить же список учёток (без паролей) - это тоже надо суметь, логин-то принимается по хешу, в открытом виде его в БД нет.
В общем, пока таких инцидентов не было.
Зато пользователи сказали отдельное спасибо, что после введения такой системы мы сняли драконовские меры к длине пароля, спецсимволам, уменьшили кардинально требования по частоте смены и прочая (проверка на качество пароля есть, но она лайтовая). Потому что слабая сложность пароля теперь парируется сложностью процедуры логона.
Да, действительно, так можно пакостить, но по факту таких случаев пока не было. Всё же намеренно пакостить - это дезавуировать себя, зловредам же важно и прийти, и уйти незамеченными. Зачем волновать отдел ИБ, они же насторожатся, взведут свои большие мушкеты, расставят силки и прочая...
Получить же список учёток (без паролей) - это тоже надо суметь, логин-то принимается по хешу, в открытом виде его в БД нет.
В общем, пока таких инцидентов не было.
Зато пользователи сказали отдельное спасибо, что после введения такой системы мы сняли драконовские меры к длине пароля, спецсимволам, уменьшили кардинально требования по частоте смены и прочая (проверка на качество пароля есть, но она лайтовая). Потому что слабая сложность пароля теперь парируется сложностью процедуры логона.
Иногда пакость это просто пакость, а не желание своровать. Тут за примерами далеко ходить не надо. Знаете как убер устранял конкурентов? Делал сотни и тысячи заказов у них и отменял их. Пока машины конкурентов были заняты фальшивыми заявками, свободный убер забирал клиентов. Так же и пиццерии воевали и много кто ещё. Гадить конкуренту, чтобы переманивать. Можно много способов борьбы с этим придумывать, но оно всё равно какую-то часть реальных пользователей заденет.
Как можно пакостить - методов море. Но если внимательно следить за методами, то всегда можно, очень гибко парировать.
ИБ - это постоянно работающая служба, которая постоянно (в нормальном режиме - на упреждение) анализирует потенциальные векторы угроз.
Но мы анализируем только то, что угрожает именно нам, хотя и почитываем, разумеется, чужие кейсы. Для расширения кругозора и развлечения.
В примере того же Убера конкуренты, попавшие под такого рода атаку могли бы сделать очень многое (создать верификационную базу, ввести встречные звонки, кросс-валидацию и прочая). Могли, определив вектор, создать встречные проблемы уже самому Уберу в таких недобросовестных атаках (в нашей конторе такого кейса атак не было, но я знаю по личным связям контору, которая при обнаружении примерно такого рода атаки против себя через руководство сделали прямой звонок конкурентам с предложением "вы хотите, чтобы мы действовали также против вас?", и это, внезапно, проблему как рукой сняло). Многое можно. Если думать и действовать.
Пакостники есть всегда, но когда ты планомерно максимально усложняешь им работу и ломаешь кайф, не поверите, упорных "за просто так" крайне мало...
ИБ - это постоянно работающая служба, которая постоянно (в нормальном режиме - на упреждение) анализирует потенциальные векторы угроз.
Но мы анализируем только то, что угрожает именно нам, хотя и почитываем, разумеется, чужие кейсы. Для расширения кругозора и развлечения.
В примере того же Убера конкуренты, попавшие под такого рода атаку могли бы сделать очень многое (создать верификационную базу, ввести встречные звонки, кросс-валидацию и прочая). Могли, определив вектор, создать встречные проблемы уже самому Уберу в таких недобросовестных атаках (в нашей конторе такого кейса атак не было, но я знаю по личным связям контору, которая при обнаружении примерно такого рода атаки против себя через руководство сделали прямой звонок конкурентам с предложением "вы хотите, чтобы мы действовали также против вас?", и это, внезапно, проблему как рукой сняло). Многое можно. Если думать и действовать.
Пакостники есть всегда, но когда ты планомерно максимально усложняешь им работу и ломаешь кайф, не поверите, упорных "за просто так" крайне мало...
> Получить же список учёток (без паролей) - это тоже надо суметь
Ackchyually, говно вопрос, посмотреть в слитые базы емейлов популярного сервиса, или базу телефонов от оператора купить у нужных людей
при переборе в ширину (фиксируется пароль и перебирается по большому кол-ву пользователей, задержки не дадут вообще никакой защиты
поэтому кому нужна безопасность - как минимум второй фактор сразу прикручивают
Ackchyually, говно вопрос, посмотреть в слитые базы емейлов популярного сервиса, или базу телефонов от оператора купить у нужных людей
при переборе в ширину (фиксируется пароль и перебирается по большому кол-ву пользователей, задержки не дадут вообще никакой защиты
поэтому кому нужна безопасность - как минимум второй фактор сразу прикручивают
> базы емейлов или телефонов
в смысле берешь базу пользователей одного сервиса и прикладываешь к другому, если он популярен в том же регионе, то будет много пересечений
в смысле берешь базу пользователей одного сервиса и прикладываешь к другому, если он популярен в том же регионе, то будет много пересечений
Базу логинов чтобы слить на сторону - её нужно знать, а если мы храним только хеш - как вы её получите? Я вот (архитектор системы, на минутку) получить её не могу никак. Собрать по сусекам у пользователей? Ну, теоретически можно, но рисков там, чтобы прошло мимо ИБ незамеченным - воз и тележка.
Взять всю базу номеров региона и попытаться стучать на наш авторизационный сервис, перебирая в ширину - на здоровье, но вы правда думаете, что это пройдёт незамеченным? DDoS мы отсекаем, у нас пользователи довольно стабильны по сетевым путям. В сеансовой части протокола верификации есть инфа по последней успешной сессии, если её нет, мы даже не примем запрос. Вы установите снифер на каждвй комп клиента, чтобы собирать сеансовую инфу, для её моделирования и подмены? Ну, знаете ли... Анализируется КАЖДЫЙ неуспех ошибки логона. По учёткам хранятся частотные профили времён сессий. Нарушение частотности сессий - анализируется. Как и многое другое.
И это я так, по верхам.
Я не говорю, что нельзя проломить нашу защиту. Но пока справляемся...
Взять всю базу номеров региона и попытаться стучать на наш авторизационный сервис, перебирая в ширину - на здоровье, но вы правда думаете, что это пройдёт незамеченным? DDoS мы отсекаем, у нас пользователи довольно стабильны по сетевым путям. В сеансовой части протокола верификации есть инфа по последней успешной сессии, если её нет, мы даже не примем запрос. Вы установите снифер на каждвй комп клиента, чтобы собирать сеансовую инфу, для её моделирования и подмены? Ну, знаете ли... Анализируется КАЖДЫЙ неуспех ошибки логона. По учёткам хранятся частотные профили времён сессий. Нарушение частотности сессий - анализируется. Как и многое другое.
И это я так, по верхам.
Я не говорю, что нельзя проломить нашу защиту. Но пока справляемся...
А как вы пользователям письма шлёте? Или вы не шлёте? А если шлёте, значит непохешеные электропочты у вас лежат где-то. Или у вас что инфа о пользователях на разные базы разнесена? Логины отдельно, посты отдельно? Или как оно вообще работает? А номера телефонов, если храните, тоже похешены?
Надо отделять мух от котлет.
Злоумышленнику, чтобы получить доступ к системе - нужен именно логин (хотя бы). С паролем он плясать отдельно будет.
А почта, как и телефоны, если желаете (или обязаны по штатному расписанию) получать от нас рассылки - это атрибут клиента, его контактные данные, они есть в БД, но совершенно не обязательно это его логин. В качестве логина мы примем что угодно (уникальную строку длиной более 10 символов). Просто, если уровень доступа и требуемых запрошенных сервисов роли высок, мы потребуем валидации аккаунта через его контакты (телефон с двухфакторкой или корпоративную почту, ни в коем случае не бесплатные помойки).
Если пользователь введёт свою почту как логин, у нас сработает эмпирика на качество аккаунта, и мы сразу предложим заменить логин. Надо 3 раза будет нажать условно "Да блять хочу, хочу я почту как аккаунт!" - чтобы система приняла это даже для аккаунта, которому доступно чуть менее чем нихуя (например, есть куча пользователей, которым нужен только визуальный мониторинг чего-то там, без прав на изменение и активные действия, там эмпирики слабые). А для ролей с высокими правами доступа мы никогда не примем почту как логин. Даже корпоративную. Именно потому, что мы знаем о таком звере как поиск по отрытым базам личной информации.
Вообще эмпирики на качество как атрибутов аккаунта, так и на сессионную статистику - великая вещь! 90% проблем можно избежать, если внимательно смотреть на то, что, как и когда именно пользователи используют в качестве логинов/паролей. И логины хранить у нас не нужно, всё, что мы знаем, что мы проверили, и хеш (с хлебом-солью, конечно) по логину не совпадает с хешами ни одного из атрибута клиентов (имя, фамилия, почта, телефон, имя кошки и прочая).
Злоумышленнику, чтобы получить доступ к системе - нужен именно логин (хотя бы). С паролем он плясать отдельно будет.
А почта, как и телефоны, если желаете (или обязаны по штатному расписанию) получать от нас рассылки - это атрибут клиента, его контактные данные, они есть в БД, но совершенно не обязательно это его логин. В качестве логина мы примем что угодно (уникальную строку длиной более 10 символов). Просто, если уровень доступа и требуемых запрошенных сервисов роли высок, мы потребуем валидации аккаунта через его контакты (телефон с двухфакторкой или корпоративную почту, ни в коем случае не бесплатные помойки).
Если пользователь введёт свою почту как логин, у нас сработает эмпирика на качество аккаунта, и мы сразу предложим заменить логин. Надо 3 раза будет нажать условно "Да блять хочу, хочу я почту как аккаунт!" - чтобы система приняла это даже для аккаунта, которому доступно чуть менее чем нихуя (например, есть куча пользователей, которым нужен только визуальный мониторинг чего-то там, без прав на изменение и активные действия, там эмпирики слабые). А для ролей с высокими правами доступа мы никогда не примем почту как логин. Даже корпоративную. Именно потому, что мы знаем о таком звере как поиск по отрытым базам личной информации.
Вообще эмпирики на качество как атрибутов аккаунта, так и на сессионную статистику - великая вещь! 90% проблем можно избежать, если внимательно смотреть на то, что, как и когда именно пользователи используют в качестве логинов/паролей. И логины хранить у нас не нужно, всё, что мы знаем, что мы проверили, и хеш (с хлебом-солью, конечно) по логину не совпадает с хешами ни одного из атрибута клиентов (имя, фамилия, почта, телефон, имя кошки и прочая).
При нажатии на значок глаза поменять местами два рандомных символа в введённом пароле.
Тем временем я, который вставляет пароль из буфера
из паролехранилки*
Не, у меня там шифровки. Так что сперва прописываю его в блокноте, и из него копирую.
Но во второй раз же прокатывает?
Добавляешь пробел в конце пасса, и при даблклике в блокноте пасс будет выделяться, копироваться и вставляться с пробелом, при нажатии на глазок -с виду все ок :)
будет работать до первой функции .trim() которая обрабатывает форму логина
Слушал рассказ в "Модель для сборки". Там было про двоих мошенников, которые один из которых как бы вживался в мысли человека и похитил у него пароль от учётки. И попался на том, что тот человек всегда вводил пароль со второй попытки. Не могу вспомнить название
Нормальная штука класса security-by-obscurity если применяется к личной игрушке, а не к публичному сервису
И как это будет работать? Чтобы написать скрипт, злоумышленник изучает атакуемый сайт. Уже на этом этапе он поймет, что верный пароль надо вводить 2 раза.
А как? Это хранимая процедура. Ты сюда с мастер-логином от мускула вломился?
Просто руками, на этапе изучения сайта, попробует войти с легального акка. Зачем в код то лезть? Это и так будет видно, что с первого раза никогда не заходит.
Что он там собрался изучать для тупого брутфорса?
Чтобы написать коммент, необходимо залогиниться
Отличный комментарий!