Комментарии 209
Когда-то для защиты пароля было достаточно иметь злую бабушку на входе в машинный зал

На КДПВ злая бабушка, надо полагать.
Пишу сюда для заметности.
Почему в статье нет ни слова про UTF-8 и кириллицу?
Это многократно увеличивает сложность подбора даже трудно запоминаемого пароля, описанного в статье!
Все печатаемые символы ASCII [RFC 20], включая пробел, должны быть допустимыми для ввода в качестве пароля. Символы Unicode [ISO/ISC 10646] также должны быть допустимыми.

На жёлтом фоне
… но что пытается рассмотреть товарищ в шкафу со стороны шгутов, да ещё с такого расстояния?:)
Бэкдор в Нарнию ищет?

Запрет словарных паролей выглядит странно. Я считаю, что сервис вообще не должен требовать ничего от пользователя, если пользователь клиент разумеется. Хоть по IP пусть авторизируется. Но с другой стороны, дать возможность настройки безопасности, предупредив какие могут быть уязвимости. Так, к примеру, многие считают СМС канал очень защищенным.
почему то сразу подумал что он прислушивается, слева от себя, но разве в этих машинах были реле?

Мне больше кажется, что челодой моловек так упоро втыкает в панель управления (что по левую руку от дамы), а стоит так далеко, чтобы всю панель (= весь ряд лампочек, который отражал состояние какого-нибудь регистра) одним взглядом ухватить.

а мне кажется, что их как будто внезапно побеспокоили, но у дамы кольцо если что:)
И совсем плохо, если пользователь верно ввел пароль, но устройство недоверенное, второй фактор не подтвержден и IP принадлежит выходной ноде Тора. Вот в третьем случае пора дергать рубильник с надписью «Аларма! Волк украл зайчат!».

А вот за это бить ногами хочется. Когда в гостях пытаешся показать фото, а гугл кричит «недоверенное устройство».
Да гугл временами вообще охреневает. Меня иногда дома с домашнего компьютера не пускает. «Недоверенное устройство». Вводишь код с только что присланной гуглом же смски, все равно не пускает. Приходите позже, говорит. Скотина!
К сожалению не только гугл. Всяческие майлры и яндексы от него не отстают.

Ой, не надо про майлру))
Несколько дней назад заходил через браузер в почту, ввожу логин-пароль — выкидывает капчу. Капчу я не разгадываю, страница обновляется и я… оказываюсь в своём ящике, где меня ждут письма "подозрительная попытка входа" и "вход с нового устройства".
Вот до сих пор как вспомню, так O_oфигеваю.

А сам светит почту аккаунта на всех своих сервисах, типа ютуба. А если почта была создана ещё до появления ютуба и имеет вид имя.фамилияКод_региона@gmail.com? И поменять её не даёт.
А вы, батенька, гуманииист…
За это надо руки в мясорубке проворачивать по самую задницу!

Гугл правильно предупреждает. У хозяев в компе вполне может оказаться сборщик паролей, о котором они не подозревают.


Для показа фото в гостях давно придумали расшаривание и приватные ссылки.

Поубывав бы! (с)
Почти все почты практически похерили возможность выйти через Тор, что очень напрягает, когда порты закрыты. Более того, периодически начинают подозревать в плохом, когда выходишь с обычного мобильного инета. А гугель и яндекс при поиске из режима приватности прямо заявляют, что ты бот. Им, видите ли, настоящие куки подавай. Скотины.
Гораздо лучше поднять тревогу, если пароль всплывет в одном из многочисленных словарей утечек.

А как сервис об этом узнает?

Можно мониторить крупные базы утекших паролей, как это Firefox и Google делает. Мне кажется, это разумная мера. Понятно, что у нормального сервиса есть только хеши, но это не мешает свериться с хешами в БД.

Не думаю, что алгоритм нахождения хэша пароля в разных базах будет одинаковым, а значит и такие проверки в принципе ничего не дают.
Хотя, никто не мешает проверять пароль в момент входа пользователя (при достаточном быстродействии) и сообщать ему об этом. Но здесь также должен использоваться принцип разумности.
Вы же знаете как вы хешируете пароли у себя. Берите базу утекших паролей (в ней они в открытом виде), хешируйте каждый своим алгоритмом и сравнивайте с хешем в вашей базе.

А как же соль? Разве правильная практика — это не генерить случайную соль на каждый пароль, да еще и хешировать каким-нибудь bcrypt или scrypt, которые намного дольше простого SHA-1 считаются? Вам же под каждую соль придется всю базу утекшую паролей заново хешировать.

Да. Чем лучше у вас защищены пароли, тем сложнее будет их проверить по базам. Но это можно делать неспеша в бэкграунде, но непрерывно, не загружая особенно систему.

Если вы будете сопоставлять пароли пользователей с базой утечек «неспеша и в беграунде», значит вы будете хранить пароли ваших пользователей в открытом виде, или по крайней мере в таком виде, с котором они будут сопоставимы вами, а значит и злоумышленником, скомпрометировавшим ваш сервер.

Тем самым вы нивелируете саму суть хеширования и соления паролей.

Не значит. Это значит, что я буду солить и хешировать пароли из базы утечек и сверять со своими хешами.

В таком случае вам прийдется использовать относительно слабые криптографические функции для хеширования паролей, вроде SHA или BLAKE.

Используя Argon2, bcrypt, scrypt, или PBKDF2 вам понадобятся годы, чтобы перебрать все комбинации словаря утекших паролей и паролей ваших пользователей, с учетом что каждый пароль имеет уникальную соль.

Врядли такое неразумное использование вычислительных ресурсов оправдывает возможность предупредить пользователя об утечке его пароля спустя год.

Просто для справки: сейчас в отрытом доступе находится 573 миллиона утекших паролей. Надежная функция для хешировния паролей должна выполнятся миллисекунды. Допустим, хеширование выполняется за 10ms, что довольно слабо. В таком случае, проверка одного пользовательского пароля будет выполнятся 66 дней. А если у вас их сто тысяч или миллион?
Просто проверяйте пароль пользователя всякий раз в момент регистрации, авторизации и смены пароля. Если используете собственную базу данных – можно, в принципе, сопоставлять даже без хеширования, в открытом виде. Это значительно эфективнее с точки зрения вычислительных ресурсов и не требует снижения мер защищенности хранения паролей у себя.

Даже если пароль пользователя будет скомпрометирован после регистрации, это абсолютно не является проблемой до тех пор, пока кто-то не попытается авторизоваться с использованием этого пароля.

Раз уж зашёл разговор, то решил спросить.


Как это работает в правильном мире?
Получается, что в таблице пользователя три колонки: логин, пароль, соль.
При регистрации пользователя или смене пароля мы создаём новую соль и затем подставляем её к паролю?
Насколько я понимаю, при новой сессии (логине) соль не генерируется? Или после успешной проверки со старой солью лучше перехешировать пароль (который все ещё хранится где-то в переменной) с новой солью?

Получается, что в таблице пользователя три колонки: логин, пароль, соль.
Верно. Если совсем придираться то еще одним обязательным полем должно быть время следующей успешной попытки авторизации, для защиты от брут форса.
При регистрации пользователя или смене пароля мы создаём новую соль и затем подставляем её к паролю?
Да, для каждой пары логин+пароль должна быть уникальная соль.
Насколько я понимаю, при новой сессии (логине) соль не генерируется? Или после успешной проверки со старой солью лучше перехешировать пароль (который все ещё хранится где-то в переменной) с новой солью?
В этом нет необходимости. Пароли солятся, чтобы в случае взлома ваших серверов максимально усложнить злоумышленнику восстановление паролей. Для этого достаточно чтобы соль была уникальной, истинно случайной (/dev/random), и достаточно большой (32 байта).

От того, что вы пересолите пароль 10 раз, жизнь хакера точно не усложнится, а возможно даже упростится, ведь теперь он может узнать несколько результатов хеширования для одного и того же пароля (само по себе это не компрометирует пароль, но в сочетании с другими уязвимостями может упростить атаку).
Получается, что в таблице пользователя три колонки: логин, пароль, соль.

PHP при использовании встроенных функций хранит пароль с солью в одном поле. Там ещё специальная пометка, какой алгоритм использовался, и поэтому нет никаких проблем поменять его в будущем, не потеряв доступа к старым паролям.
На входе пользователя это надо проверять. На входе пароль есть.
В каком смысле? Сервису известен не соленый и не хешированный пароль в момент выбора пароля пользователем.

А если утечка после произошла? Надо хешировать базы паролей и искать аналогичные хеши у себя.

Если вы можете сопоставить пароли, которые уже находятся в вашей базе данных с публичными базами утечек, значит это сможет сделать и злоумышленник, получивший доступ к вашему серверу.

Чтобы сопоставлять пароли, нужно хранить их без соли. Тем самым вы выдадите на блюдце пароли значительной части ваших пользователей в случае компрометации.

Ключевая идея здесь – предупредить пользоваля, что его пароль скомпрометирован во время регистрации или смены пароля. В этот короткий промежуток времени пароль вам известен в открытом виде, и вы можете использовать любой (слабый) хеш для проверки.

Здесь вы пытаетесь решить две задачи, которые отчасти противоречат друг другу:

1. С одной стороны, обезопасить пароль пользователя в случае утечки с ваших серверов.

2. С другой стороны, защититься от несанкционированного доступа к вам в случае утечки пароля по стороннему каналу.

После попадания пароля в базу, надежно перепроверить его (вторая задача), не создав угрозы для компрометации (первая задача), невозможно, кроме моментов авторизации пользователя.

Хорошая новость состоит в том, что вы можете перепроверять пароль в момент каждой авторизации, и тем самым заблокировать потенциальную атаку в случае если пароль подходит И был недавно обнаружен в новых утечках, запросив у пользователя сменить пароль через надежный канал связи (почту), и/или потребовав дополнительный фактор авторизации (мобильный телефон, 2FA и т.п.).
1. "Вот в третьем случае пора дергать рубильник с надписью «Аларма! Волк украл зайчат!»" — этот тезис стоит обосновать.
2. Интересно, как Гугл понимает, что это я куда-то уехал, а не «злые враги» мой пароль украли?
По моему опыту — никак. Поэтому с их почты ушел.
А потом раз — и новую почту в РФ заблокировали. Т.ч. хожу туда теперь через Тор — см. п.1.
Интересно, как Гугл понимает, что это я куда-то уехал, а не «злые враги» мой пароль украли?
Если у вас телефон на Андроиде, то гугл про ваши перемещения знает чуть больше чем все :-)
По моему опыту — никак.

гугл про ваши перемещения знает чуть больше чем все :-)

И при этом в почту не пускает…
Аналогичная ситуация с почтой была. У меня Outlook забирает почту с gmail одновременно дома и в офисе. И вдруг в офисном аутлуке гугл перестал пускать — говорит, что подозрительное устройство. На почту прилетело письмо с просьбой подтвердить, что это я. Подтвердил. Но это не помогло. Единственный способ, после которого заработало — это в настройках google акаунта поставить галочку less secure access. Нифига непонятно, что она значит, но заработало с тех пор. Правда, иногда ругается и предлагает включить заново more secure.
less secure — по паролю, secure — через OAuth. Но это гугл, там могут быть всякие нюансы ещё.
хехе, у меня личный аккаунт забирает почту с рабочего, который принадлежит тоже мне и привязан к личному
так забирать он может, а при попытке отправить говорит «включите недоверенные устройства»
и делать это надо постоянно, не отследил пока периодичность, но довольно часто, несколько раз в год

У Гугла для таких сценариев есть специальная штука — application password. Советую для этого аутлука создать отдельный пароль.

Гугл большой… Правая рука не знает, то, что знает левая. Безопасность!
Сейчас очень многие сервисы создают «отпечаток» устройства (как пример: ОС + браузер + мак-адрес), с которого производится вход. Поэтому если «отпечаток устройства», с которого обычно входят, не именяется — тревогу, как правило, не поднимают. (вы уехали, а не «злые враги» спионерили пароль).

Короче, все сводится к скорингу и вероятности злонамеренного доступа.

Особенно радует заходить с мозиллы с парой дополнений… Вечные машины/светофоры/пожарные гидранты… И это с одного IP :)

ОС + браузер + мак-адрес
Не очень удачный пример. Браузер MAC-адрес не передаёт никуда. А если это приложение вне браузера (которое уже может прочитать MAC-адрес), то браузер тут не при чём.
Вот привязка к устройству или адресу в качестве второго фактора — зло. Гугл особенно этим любит страдать: уехал в другой город, и почту уже не прочесть.

Второй фактор если и делать, то априори восстановимый типа одноразывых кодов.
Гугл особенно этим любит страдать: уехал в другой город, и почту уже не прочесть.

Вероятно, это не у всех (и/или не всегда) так. Я могу совершенно спокойно зайти на почту с адреса в США, при этом мой телефон находится в Германии — никаких вопросов и подозрений от гугла (кроме сообщения о том что "логин с нового устройства").

кроме сообщения о том что «логин с нового устройства»
Ну, обычно там еще приписка, что попытка входа заблокирована в целях безопасности :)

Не-не, логин успешный, приписка есть о том что "если это не вы, то...", и всё.

Приходит на почту при заходе в почту :D
(справедливости ради, приходит еще и на телефон)

Да, есть крайне странные сервисы, которые считают, что и 12 символов хватит, а значит остальные 28 можно спокойно отрезать и проверять хеш только первого фрагмента.


Это обычно выглядит по другому, при регистрации пароль вводится весь, а при логине обрезается. И ты такой сидишь, скопипастив пароль из одного и того же места, и не можешь понять что не так.
НЛО прилетело и опубликовало эту надпись здесь
Боюсь, эта ссылка будет работать только для вас. Насчёт цифр — в пароле от сбербанк-онлайна таких ограничений точно нет (например, у меня пароль из 30 символов, не ограничивающийся буквами и цифрами). Возможно, вы говорите о 2-факторной авторизации, но 5 цифр для второго фактора вполне достаточно.

Однако, в сберонлайне пароли не чувствительны к регистру, так что если пароль полагается на игру с регистром — всё, приехали.


(А на последующий вопрос про то, хешируют ли они пароли, саппорт в твиттере ответил «Нет, надёжный пароль нужно придумать вам самим». Но стоит помнить, что в каждой шутке есть доля шутки :-)

Однако, в сберонлайне пароли не чувствительны к регистру, так что если пароль полагается на игру с регистром — всё, приехали.

Этим многие грешат, да. Например, Blizzard.

А на последующий вопрос про то, хешируют ли они пароли, саппорт в твиттере ответил «Нет, надёжный пароль нужно придумать вам самим»
Ну там вполне очевидно, что SMM-щик не знает, что такое «хэширование».
Это пароль от мобильного приложения, на устройстве, которое было авторизованно через привязанный мобильник и почту. И называется оно пин-кодом. Его цель — защитить от несанкционированного доступа к устройству пользователя. Не знаю, передаётся он куда-либо или хранится на устройстве. Но не суть, паролем в данном случае является отпечаток самого устройства. Тут возникают другие потенциальные опасности, но с длинной пин кода они уже не особо связанны, имхо.
Случайный пароль сложно запомнить, это да. Зато можно придумать удобный способ генерации почти случайных паролей из чего-то простого. Например:
echo "qwerty" | md5sum -
и вот мы уже получаем надёжный пароль (a86850deb2742ec3cb41518e26aa2d89), который шиш кто подберёт, но который при этом запоминать не надо — ведь мы знаем, как его можно сгенерировать из простого запоминаемого набора символов.
Или так:
echo "qwerty" | base64

Вывод: cXdlcnR5Cg==
Без длинной соли — плохой способ. Строка вида a86850deb2742ec3cb41518e26aa2d89 сразу выдаёт в себе md5-хеш, для которых есть радужные таблицы. И qwerty там точно будет.

Ну то есть таким образом можно делать кучу паролей для неважных сервисов.
Считаем md5 от password_url_salt и подставляем адреса сервисов.

Непонятен бонус относительно истинно случайной генерации

Нужно использовать PBKDF2 от соли и имени сервиса


Преимущество, с точки зрения тех, кому это важно — что помнишь наизусть только одну соль. И никакой базы паролей (пусть и шифрованной), которую можно украсть, нет.

Вижу пароль в 25 символов — пароль сгенерирован в CryptoPass — username@url известны — можно угадывать/брутфорсить secret. При успехе — восстанавливаются все пароли.

Ну так secret должен быть не 16 бит, а нормальной длины. Кроме того, PBKDF2 брутфорсить мешает. Для того и придуман, Каждая попытка достаточно медленно вычисляется. Если хочется, можно на Argon2 заменить.

Не очень понятно, в чем проблема с радужными таблицами. Вам же нужно не найти qwerty по строке a86850deb2742ec3cb41518e26aa2d89, а найти a86850deb2742ec3cb41518e26aa2d89 по тому, что лежит в базе у сервиса.


P.S. a86850deb2742ec3cb41518e26aa2d89 — это хэш от qwerty\n. Хэш от qwerty нужно считать как


echo -n "qwerty" | md5sum

Получится d8578edf8458ce06fbc5bb76a58c5ca4.

Без длинной соли — плохой способ. Строка вида a86850deb2742ec3cb41518e26aa2d89 сразу выдаёт в себе md5-хеш, для которых есть радужные таблицы. И qwerty там точно будет

Окей, а если мы возьмём хеш от хеша?
echo "qwerty" | md5sum | md5sum

Не думаю что в радужной таблице найдется хеш на хеш (а может я просто наивный)
в радужной таблице

Говорю же, всё есть в гугле. Первый результат
2 нояб. 2015 г. — Decoded hash md5x2: 897c8fde25c5cc5270cda61425eed3c8: qwerty (unhashed, decoded, lookup, decrypted, decoded)

Безо всяких радужных таблиц.
Безо всяких радужных таблиц.


google проиндексировал радужные таблицы. Теперь радужные таблицы есть в google ;)
Теперь радужные таблицы есть в google ;)

Всё уже украдено до Вас
Сисадмин желал подобрать себе стойкий пароль для централизованной авторизации через radius-сервер. Он обратился за советом к Инь Фу Во.
— Как вы думаете, Учитель, пароль "史達林格勒戰役" стойкий?
— Нет, – ответил мастер Инь, – это словарный пароль.
— Но такого слова нет в словарях…
— «Словарный» означает, что это сочетание символов есть в wordlists, то есть «словарях» для перебора, которые подключаются к программам криптоанализа. Эти словари составляются из всех сочетаний символов, которые когда-либо встречались в Сети.
— А пароль «Pft,bcm» подойдёт?
— Вряд ли. Он тоже словарный.
— Но как же? Это же…
— Введи это сочетание в Гугле – и сам увидишь.
Сисадмин защёлкал клавишами.
— О, да. Вы правы, Учитель.
Через некоторое время Сисадмин воскликнул:
— Учитель, я подобрал хороший пароль, которого не может быть в словарях.
Инь Фу Во кивнул.
— Я ввёл его в Гугле, — продолжал Сисадмин, — и убедился, что в Сети такого сочетания нет.
— Теперь есть.

Суждения об информационной безопасности мудреца и учителя Инь Фу Во, записанные его учениками

Строка вида a86850deb2742ec3cb41518e26aa2d89 сразу выдаёт в себе md5-хеш, для которых есть радужные таблицы. И qwerty там точно будет.

А если первый символ убрать? Лучше, конечно, несколько, и поменять на соль, но принцип, думаю, понятен

Вы не поняли. Ну и что этот будет *хэш* будет в радужных таблицах и что он соотвествует изначально строке qwerty?

Пользователь на этапе регистрации введёт a86850deb2742ec3cb41518e26aa2d89 в поле «придумайте пароль», и поэтому в базу пойдёт уже либо хэш от a86850deb2742ec3cb41518e26aa2d89, либо хэш от этого + соль.
Из минусов, нужно или уметь считать md5 или base64 на листочке, или обязательно иметь доступ к соответствующему калькулятору.
Ну и быть в определенном смысле стоиком чтобы иногда набирать пароли вида a86850deb2742ec3cb41518e26aa2d89 вручную.
А если есть доступ к «калькулятору», то на него же можно установить и менеджер паролей как правило.
и вот мы уже получаем надёжный пароль (a86850deb2742ec3cb41518e26aa2d89)

Результатов: примерно 448 (0,49 сек.)

Хеши всех простых строк давно уже в интернете. И даже двойные хеши.

А если попробовать сделать не 2 хэша, а 5?


echo -n 'qwerty' | md5sum | md5sum | md5sum | md5sum | md5sum

Результат: 8a46d17ffd17029d460fa1a36c3c98bc


Или миксовать md5 и base64:


echo -n 'qwerty' | md5sum | base64 | md5sum | base64 | md5sum | base64 | md5sum | base64 | md5sum | base64

Результат: N2FkY2UyOGJlZDNiNDczNjkxYjllZGY3ZGI1YzhkN2EgIC0K


Просто нужно запоминать последовательность хэшей (и не только).

eprint.iacr.org/2006/105.pdf
Version 2 of this paper contains the appendix with the description of more tunnels. These tunnels further decrease the average time of MD5 collision to 31 seconds. On PC Intel Pentium 4 (3,2 GHz) it is 17 seconds in average.
Сгенерировать 2 128-байтных сообщения с коллизией != обращение хеш-функции.
Тоже верно. Но там довольно много проблем у функции было помимо коллизий, если я не ошибаюсь.
Если ваш пароль гуглится, значит это плохой пароль.

(пожалуйста, только не гуглите собственные пароли).

Плохо, что нет варианта "Дайте пользователю не использовать пароль".


У каждого в карманах по несколько хардварных токенов авторизации, телефоны которые могли бы таким токеном работать — а задействовать все это для авторизации, там где хочешь, в подавляющем случае нельзя. Тот же WebAuthn вроде приняли — и кто им пользуется?

>У каждого в карманах по несколько хардварных токенов авторизации, телефоны которые могли бы таким токеном работать

Нахер.
Вот сразу нахер.
В головы которые придумывают идеи «а давайте обяжем желающего пользоваться нашим сервисом покупать себе смартфон и ставить на него какую-то левую прогу для авторизации которая тянет с собой полгугля» — надо не то что гвоздь, железнодорожный костыль забить.

Не смартфон, а просто токен (вроде бы предполагается, что он должен для всех сервисов, что WebAuthn умеют). А смартфон — это для тех, у кого уже старый лишний на полках валяется.

А в чем проблема? Смартфоны сейчас есть практически у всех. А у кого нет — пусть по-старинке по паролю заходят. Но остальные смогли бы обойтись вовсе без него, подтверждая, что это реально они с помощью своего смартфона. Это ведь удобно? Что-то похожее уже существует, когда вместо смс-кодов приложения просто просит нажать кнопку во всплывающем на привязанном устройстве окне.

Сейчас оно не стандартизировано и каждый сервис (экосистема) свое приложение-аутентификатор хочет. И смарт для работы должен быть онлайн. А WebAuthn стандартизован и оффлайновую работу обещает.

И смарт для работы должен быть онлайн
Ну, обычно, при работе в интернете (а когда еще нужно пароль вбивать?), есть wi-fi, или что-то еще.

А WebAuthn стандартизован...
Так это вроде бы только с одного устройства можно так заходить, а с другого уже не получится — нет разве?
обычно
Бывают и необычные ситуации: отсутствие мобильной сети при наличии корпоративной проводной, как пример.

Куда устройство-аутентификатор воткнешь/приложишь — оттуда и заходишь.
Это только внутри браузера, что в телефоне, ключи прямо в этом телефоне и хранятся.


Устройств, правда, лучше бы иметь не одно — для восстановления доступа, если первое потеряешь.

Потому что если потеряешь телефон, то всё. Столкнулись недавно с подругой, которая потеряла телефон в аэропорту во время пересадки, а у неё на всём стояла двойная аутентификация. Симку из России она получить не могла, в итоге осталась без доступа ко всем своим аккаунтам. Не говоря уже про более банальные случае, если смартфон разрядился, а войти в аккаунт надо вот прямо сейчас.

Вообще-то при включении двух-факторной аутентификации даются коды сброса.

Которые хранятся на [утерянном] телефоне или в облаках (за двухфакторкой). Вы же не ожидаете от среднестатистического пользователя запомнить коды восстановления?

ну так не надо хранить запасной ключ от машины в машине
распечатать без опознавательных знаков и положить в бумажник, например

Устройств-аутентификатаров должно быть несколько. (Тут, кстати, надо бить тех кто реализует 2FA, но этого не понимает). Или должен быть альтернативный вариант входа, не использующий этого телефона.


Ситуация в точности эквивалентна "забыл пароль или мастер-пароль от менеджера паролей".

Это подходит для посетителей Хабра, а не для массовых пользователей айфонов, которые по каким-то причинам включили двухфакторку, а потом при потере телефона оказались в ловушке. Да, обычно восстановить симку — это не такая большая проблема, однако потеря/кража телефона в поездке — совсем нередкая ситуация, в поездке его потерять пожалуй даже легче, чем в ежедневной рутине у себя на родине.

В поездку как раз имеет смысл брать с собой запасной, пусть и паршивый, но пригодный к использованию смарт. Который хранится где-нибудь отдельно от первого.

Храните данные инициализации аутентификатора в надежно шифрованном хранилище паролей.
Вместе с паролем? А то получается, что оба фактора лежат в одном месте.

Из паранойи. Заблокируют гугловую/фейсбучную учетку, а сервис, в котором ты авторизоваться пытаешься, о такой возможности не подумал — и "Ой".

Если нет способа восстановления аккаунта ты если и пароль забудешь то все
WebAuthn — тоже такое себе… пользуюсь. юзерам оччень нравится (да и мне тоже): ткнул в иконку, приложил палец, работаешь… или в винде: открыл сайт, ввёл пин-код своей же собственной винды, работаешь…
но! мне актитвно не нравятся несколько моментов:
а) подключение к проекту — не самая тривиальная штука, даже при уже готовых библиотеках. там и бэк, и фронт, и БД — джун за полчасика побыстрячку не прикрутит, миддла давай что ли, ну это ещё ладно;
б) производится аутентификация не юзера, а устройства: хорошо если телефона, а можно и десктоп (общий?) так же завести, сервер и не заметит разницы.
т.е. сервер видит только устройство (телефон), а сколько разных людей авторизуют это устройство своим отпечатком — ему уже иррелевантно;
в) когда просишь приложить пальчик, ты уже должен знать, какого именно юзера ты пускаешь. хотелось бы что-то типа «сначала палец, а там уже посмотрим кто ты, и куда тебя пускать», но нет — работает только «юзер Ваше Величество… чо, правда? а ну, докажи!»
ну так ведь:
а) авторизация — серьезный буизнес, нгоже ее на джунов спихивать;
б) не пускайте других людей ксвоим устройствам. Десктоп может быть общим, но учетки укаждого дожны ыбть личные.
в) ээээ, а в чем проблема-то?
Поубивать бы всех кто решает какой сложности пароль должен быть, есть места где мне вообще не важно наличие пароля. И в такие места я всё равно запихаю «часто используемый» пароль.
Да уж, вынужденно генерить пароль с цифрами, древнекитайскими иероглифами, парой слов на квенья и клингонской пословицей на сайте по доставке шавермы из ближайшей подворотни — это прекрасный способ выбесить даже тибетского монаха

И это от людей, к которым постоянно люди заходят по ssh по публичному ключу, без пароля. Короче в очередной раз старая консольная утилита оказывается уже решила все заново всплывшие проблемы)

А идея, что пароль можно иметь один, а вот разных емейлов — много (да, у меня личный почтовый сервер) ни до кого не доходила?


(И да, хозяин сервиса должен солить пароль).

Для этого не обязательно иметь свой сервер Gmail поддерживает алиасы формата username+alias@gmail.com, ещё вариант GMail, Outlook бизнес аккаунт со своим доменом и ловить всю почту на any@domain, цена вопроса 4-6 usd в месяц на одного юзера (больше и не потребуется) со всякими доп. плюшками.

Вот только разные чудорасы, писавшие формы регистрации многих сайтов, считают, что в емейле не может быть не-алфавитноцифровых символов (навроде "+"). Зла не хватает.

А вот это уже всё от того, что правильная регулярка позволяющая отсеять ненужное именно на все случаи жизни для почты имеет вид типа:
регулярка почты
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\0
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|
\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"
(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[
\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-
\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([
^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\"
.\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\
]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\
[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]
|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\\".\[\] \0
00-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]
]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\
]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\
".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".
\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

Да, это самая длинная версия для perl\ruby, но общий смысл вы поняли, думаю. Многие ограничиваются чем-то типа r'\w+@\w+\.\w+' «И так сойдёт!»
Не сойдет и не подходит. Почта типа info@com валидная, но этими регулярками признается некорректной.

Статью не читай @ комментарий пиши?


Вы тестовые примеры из списка "всё это валидные email-адреса" прогнали? Много прошло? (Сам проверять вашей регуляркой боюсь).

а еще есть портал госуслугнекоторые откровенно фанатичные уникумы, которые обязывают пользователей использовать спецсимволы в пароле, а потом подменяют эти спецсимволы… Вот уж безопасность на запредельной высоте — даже зная пароль фиг зайдешь

А можете поделиться ссылкой, чтобы не быть голословным?


Очень интересно, что они и на что подменяют в паролях. И что при этом ломается.

Это ещё классно работает, когда эти волшебные разработчики не подозревают о наличии каких-либо языков, кроме английского.
Часто бывает, что можно регнуться с символами вроде ñ,ç´´´¨ и т.п., а зайти потом нельзя :)
При этом символы могут быть в логине. А логин может быть почтой :) И потом уже никакими способами невозможно зарегаться на эту почту — при создании нового акка говорит, что такой уже есть, а когда заходишь, говорит, что такого нет :)
Сообщайте пользователю, если его пароль появился в словарных базах.
Для некоторых разработчиков ещё следует уточнить, что если и проверяете это, то только в момент авторизации пользователя и не хранить пароль в открытом виде.
Скомпрометированные пароли будут применены почти сразу.
Замечательно. А как корректно, с точки зрения безопасного хранения пароля, «почти сразу» сообщить пользователю?
Но если пользователь хочет использовать ਬਹੁਤ ਮੁਸ਼ਕਲ ਪਾਸਵਰਡ или මෙයද ඉතා දුෂ්කර මුරපදයකි — дайте ему это сделать. Или добавить символ буррито в пароль для криптостойкости. Имеет право.

С одной стороны да, с другой же разрешать в паролях символы которые невозможно ввести с клавиатуры это создавать приключенческий задел на будущее.
То, что их невозможно ввести на вашей клавиатуре — не аргумент. Среднестатистический американец не сможет с клавиатуры ввести «ЯоЬот».

Строго говоря, символов, которые, вообще невозможно ввести с клавиатуры, не существует. Всё сводится к тому, что нужно либо знать как, либо иметь настроенную для этого клавиатуру.

Правда есть весёлые маки, у которых в парольных полях раскладка гвоздями прибивается к латинице, и надо пароль копипастить из предварительно набранного в адресную строку или блокнот.


Запомнилось багом во времена 10.6, где на первой установке раскладка почему-то оставалась русской, а вот на экране логина работала как и везде. И поля, чтоб набрать и скопировать, там тоже нет. Товарищ отца купил аймак, привёз домой, настроил — и попал, благо сброс пароля делается с загрузочного сидюка.

Пользователи маков — отдельная категория людей, которая сама выбрала свой путь слёз и страдания.

У маков частенько веселье случается с банальной диакритикой.
Задал простейший пароль, типа "ёжик" — и всё. И даже когда знаешь, в чём дело, не всегда есть возможность отдельно набирать диерезисӹ.

Если «строго говоря», то есть управляющие символы ASCII.
Ввести, конечно, формально можно, но вот получится ли использовать в пароле NULL, BACKSPACE или возврат каретки.
Если это предусмотрено функционалом движка — получится.
Верно. Но попробую донести свою мысль. Есть раскладки которые можно добавить в систему. Вполне штатно, не нужно быть хакером.
Если символа в них нет как быть? Не всегда логинишся со своего устройства, иногда приходится с того что есть. И вот тут экзотика может вылезти боком.
Фокусы с цифровым вводом кодов требует знания кода нужного символа и практической возможности такого действия. Это точно работает где угодно и похожим образом на мак, андроид, линукс и виндовс?
Изначально статья про интернет-сервисы. Так что ситуации, когда какого-то символа нет — исключена на андроиде, линуксе, винде и макаке. «Алиса, спроси у гугля, как выглядит символ рубля».
И молчание было ему ответом. Напоминаю что «иногда приходится с того что есть».
В базовом функционале как ситуация со всем этим? Охотно допускаю что нормально, но не уверен.
Напоминаю, что если «иногда приходится с того что есть» входить на сайт, то у вас точно есть интернет, а вместе с ним гугл, яндекс, дакдакго, байду и прочая-прочая-прочая. Если вы с их помощью за две минуты не найдёте нужный вам символ, то и слава богу — нечего дошкольникам в интернете делать.
входить на сайт, то у вас точно есть интернет, а вместе с ним гугл, яндекс, дакдакго, байду и прочая-прочая-прочая

Совершено не факт, в том то и дело. Но в целом я вашу мысль понял.
Поисковики могут заблокировать разве что внутри корпоративной сети, но там и шансы встретиться с незнакомым рабочим окружением стремятся к нолю — всё оборудование и настройки ОС соответствуют политике партии.
Я мысль понял, хоть и не поддерживаю ее совершено. Но страдать то если что не мне? :)
Да не будет никаких страданий. Вся эта ситуация «а что если мне сломают все пальцы на руках, а ногами набирать не-ANSI сложно» притянута за уши. Просто вся эта ситуация с кучей разрозненных требований к паролю нереально накаляет меня как пользователя: один требует обязательно спецсимволы в пароле, другой не допускает спецсимволы в пароле, третий требует спецсимволы обязательно, но из его особого перечня — и всё это для сайтов, на которые ты логинишься два раза в год.
А вы реально используете пароли с эмодзи? И прочим санскритом? Или разговор чисто теоретический?

Я реально хотел бы использовать пароли с кириллицей, но я не могу сейчас назвать ни одного сайта, где эта возможность имеется.

'Приключенческий задел' — это когда ты приезжаешь к американцем и пытаешься ввести этот самый «ЯоЬот», который у себя замечательно вводил.

И в чём там проблема? Как-то же я смог ввести на китайской капче слово 黑, хотя на клавиатуре моего компьютера такой кнопки нет.

Лишние хлопоты. Удлинение пароля проще в жизни, чем увеличения словаря символов.

Уверены, что ввести jopajopa проще, чем жопа? Я вот абсолютно уверен, что первый вариант в словарях встречается чаще, чем второй, но второй вводится быстрее и проще.
Длина пароля 64-300 символов где будут большие, маленькие буквы, цифры, спец символы, и при этом не будет содержать осмысленного текста и еще и менять его раз в месяц — это конечно круто, но вы реально думаете, что пользователи будут запоминать это? Готов поспорить, что они (пользователи) ограничатся бумажкой с паролем прикленной к монитору (ну или под клавиатурой — если админ ругается на стикеры с паролем).

Ну и для статистики не хватает данных, скажем за последние 10 лет. сколько систем были взломаны через подбор паролей, а сколько через фишинг или эксплуатацию уязвимостей разных?

Текст как раз о том, что не нужно требовать ротации. А пользователь может, но не обязан использовать очень длинные пароли.

А где грань разумности? Если ему очень хочется пароль 3 символа, разрешать?
Нет, разумеется. Энтропия должна быть в районе 80 бит минимум. При условии, что пароль не бьется по базам утечек и словарям.
Представил себе напротив пароля «Энтропия должна быть минимум 80 бит», и бедных пользователей, которые вообще не поняли, о чём это.
пользователям обычно говорят «ваш пароль слишком короткий/ненадёжный»
бесить начинает, когда это не форма ввода делает, а нажатие кнопки
Веселее, если форма отправляется, страница перезагружается, а там только эта надпись и пустые поля.
У меня недавно (работаю на удаленке) был забавный случай с этими паролями. Пришло письмо от админов, о том что я обязан сменить пароль, иначе секир башка аккаунт будет уничтожен. Все-бы ничего, но я в это время был в отпуске и после него еще была пара выходных, в общем когда я добрался до этого письма, у меня оставалось всего что-то около пятнадцати минут до конца дня на его смену. Указанный в письме адрес для смены не работал, просто недоступен, пока я там бился, часы перешли нулевую отметку и аккаунт мне автоматически грохнули вместе со всеми доступами, удаленными рабочими столами и прочей тряхомудией.
Далее был целый набор веселых квестов: напиши письмо в поддержку, разберись почему тебя послали, выясни кто руководитель этих обезьян уважаемых коллег-админов, напиши ему письмо, пообщайся с наконец-то снизошедшими до твоей проблемы аристократами от системного администрирования, разберись почему уже неделю они не могут сделать такое простое дело как восстановление аккаунта, напиши их начальнику…
В общем восстанавливал я все три недели, а вы про лучшие практики безопасности… тут бы просто блин не мешали людям работать.
Это какая-то дебильная политика — уничтожать учетную запись, если пароль не был сменен.
Ну и я бы не писал начальнику админов, а писал бы своему, а он уже пусть решает — разбираться с начальником админов самостоятельно или поднимать вопрос еще выше.
Автору поста стоило бы опрос прикрутить: сколько из ИБ — вменяемые люди.
Пока у меня мнение такое: это бездельники с синдромом вахтера — запретить, не пущать…
Других я не видел. Хотя допускаю, что где-то вменяемые встречаются.
Вот ситуация была: хотел на работе статью прочитать про комп. вирусы (сейчас уже ссылку не дам — с месяц назад дело было). Касперский ендпоит секьюрити ее блокирует — контент для взрослых! WTF??? Выясняется: там аналогия про беспорядочные незащищенные связи была…

Кстати, может кто не знает. Каспер ставит корневой сертификат и весь ваш трафик читает. Т.ч. о паролях можно уже не беспокоиться.
Каспер ставит корневой сертификат и весь ваш трафик читает. Т.ч. о паролях можно уже не беспокоиться.

Может я что-то не понимаю… Сертификат просто удостоверяет что ваш публичный ключ принадлежит вам, имея его ваш трафик расшифровать нельзя, в этом суть несимметричного шифрования, которое является основой всей этой технологии сертификатов.

Он ставит свой CA доверенным и выполняет MitM для всех соединений

Спасибо, это интересно. Почитаю сейчас.

Хорошо что на Линуксе пока что можно и без Касперского и прочих антивирусов, нормально жить :)
Это еще что. Касперский — это ерунда. Ну купили продукт, который глючит, это неприятно, но хотя бы объяснимо. А бывает так, что у них работает 2 отдела. 1-й отдел «воспитывает» бдительность к фишингу и рассылает подметные письма типа «приглагашаем принять участие в тестировании нового корпоративного портала», кто пройдет по ссылке и чего-нибудь введет на этом «портале», на того жалуются начальству, что сотрудник режим ИБ не умеет соблюдать. В это время 2-й отдел проводит плановое обучение информационной безопасности силами какой-то левой конторки и рассылает всем по списку приглашение с какого-то левого адреса со ссылкой на сайт этой конторки. А потом жалуется начальству на тех, кто по ссылке из приглашения не прошел, что они саботируют мероприятия по повышению безопасности.
Писал и своему (точнее все алармы слал с копией ему), мне то один хрен кроме этой войнушки заняться нечем было, с отключенным аккаунтом я даже проект собрать не мог (репа мавена за впн спрятана).
Политика дебильная — не спорю, даже выразился бы покрепче, да не хочу на бан нарываться.
И совсем плохо, если пользователь верно ввел пароль, но устройство недоверенное, второй фактор не подтвержден и IP принадлежит выходной ноде Тора.

О Боги, как же я это ненавижу. Вся эта показная забота о безопасности на самом деле скрытое вымогательство номера телефона. Вот Гугл не однажды такое выдал при правильном пароле, и поле для ввода телефона. Поле для ввода любого телефона, потому что я ничего не привязывал.
Просто дайте мне войти по моим сраным логину и паролю! Об их безопасности и сохранности я позабочусь сам. Хочу настройку «Я не дурак».
Предлагаю добавить заболевание «безопасность головного мозга».

Не знаю, правда или нет, но вот что про пароли в сбере рассказывают


Сбер

Правда, в части регистронезависимости. А вот в плане безопасности…

Я думал это расчет на термопринтеры, у которых нижнего регистра в шрифтах может и не оказаться. Хотя сейчас возможно таких уже и не осталось

Ну вообще в сбербанк-онлайн первый пароль именно что печатался банкоматом. А было еще время — и печатался второй чек с одноразовыми паролями.

Да, было дело. Получал свой 1-й пароль к личному кабинету сбербанка в банкомате. Еще, помнится, сменил его сразу, как только появилась «услуга» смены пароля. А потом с удивлением обнаружил, что старый пароль по-прежнему работает. Не удивлюсь, если он и сейчас продолжает работать, просто теперь я его уже настолько основательно забыл, что и проверить не смогу.

Работает. К моему SBOL подходят все три распечатанных когда-то в мохнатые времена пароля, и два (!) установленных самостоятельно. Это несколько удручает.

...использовать безопасный пароль.
Microsoft ещё в 2019 году публично сообщила, что в настоящее время пароль уже не является средством, достаточным для надёжной защиты, каким бы сложным он ни был!

Такой вывод основывается на имеющихся у неё огромных объёмах данных, при ежедневном использовании облачных сервисов которой фиксируется порядка 300 миллионов попыток несанкционированного входа в аккаунты.

И лишь многофакторная аутентификация (multi-factor authentication — MFA) делает почти все эти попытки бесполезными, потому что она защищает от 99,9% всех попыток взлома.

Поэтому пользователь, защищающий свои учётные записи с помощью одного лишь пароля, может с тем же успехом считать, что не защищает их вовсе!
На подбор 20-ти значного пароля уйдут годы, даже если все эти 300 млн попыток входа будут совершены в один аккаунт.
И даже если подберут, то это мои проблемы, а не Microsoft.

Я как-то в гуглофоруме на эту тему общался. Там было высказано мнение, что потеря аккаунта это компрометация сервиса. Но вот обоснование такой позиции мне получить не удалось…
В смысле? Пароль 00000000000000000000 скорее всего не является безопасным, не нужно его использовать.
Объясню. Пароль может быть вполне стойким но не уникальным и уже скомпроментированным.
Уверены что не совпадает ни с чьим паролем во всем мире?
Уверен. Нет, коллизии бывают, но блин, их вероятность крайне низка. Вот если генерировать 100000000000 паролей в секунду и подождать примерно 200 миллионов лет… Тогда да, с вероятностью 50% совпадёт.
Только что сгенерировал новый рандомный пароль своим password manager-ом. Скажите пожалуйса, какая может быть небезопасность у пароля «qd9LyL00WCN1xs8MOcs1#IAi» и сколько его надо брутфорись при наличии соли и криптостойкого хеша при хранении в БД?

Вот только что посчитал сколько вариантов перебора: допуспим у нас 23x2(буквы в 2х регистрах)+10(цифры)+10(базовые спрецсимволы)=72 знака рандомно используется в пароле. 24 символа в каждом вариант из 72 знаков это 72^24 = 3.7668638e+44. То есть примерно 37668638000000000000000000000000000000000000 вариантов пароля с такими параметрами. Плюс соль и хеш.
В пароле, который я привел для примера, этропия примерно 150 бит — а в той таблице максимум 120. Вобщем, стойкие пароли существуют, расходимся.
Стойкость к брутфорсу не имеет значения. Если не рассматривать утечки, то уже давно пароли к сервисам не брутфорсят (это практически невозможно даже для слабых паролей), а получают преимущественно через фишинг либо с помощью троянов.

Вам это, вероятно, не грозит, но огромное количество людей попадается.

Поэтому в современном мире любая аутентификация по паролю без второго фактора считается небезопасной, независимо от сложности пароля.
...уже давно пароли к сервисам...получают преимущественно через фишинг...
Даже в настоящее время весьма эффективно происходит такая масштабная фишинговая операция похищения имен и паролей корпоративных пользователей Microsoft Office 365, особенностью которой является защита фишинговых страниц каптчей, также предохраняющей поддельные страницы от индексирования автоматическими защитными решениями.

СорокТысячОбезьянВНебоСунулиБанан додумались до этого ещё 15 лет назад, однажды и до компаний дойдёт! =)

Вот бы к таким пожеланиям прислушались в Salesforce, а то как же они задолбали со своими требованиями к паролям и постоянными ротациями :(
Передаю пламенный привет одному крупному коммерческому банку и его онлайн-банкингу, которая при генерации и сохранении нового пароля (а) отбрасывает спецсимволы, если они стоят в начале пароля и (б) не предупреждает об этом пользователя. Т.е. если у вас, например, был вбит пароль "!password", то система запомнит его как "password". Весь цимес в том что при смене пароля система впускает вас еще по старому паролю и не заставляет перелогиниваться после смены пароля, а значит, прикол с неправильным паролем выплывет уже в следующий раз.
После третьего восстановления доступа к онлайн-банкингу (а это отдельный квест), у меня возникло подозрение, что симптомы один-в-один похожи на поведение китайских wi-fi камер, когда используются пароли со спецсимволами. Проверил — таки да, спецсимволы в начале пароля отбрасываются как незначащие 8-0
Вот прям в тему получил только что письмо от палки:
Заголовок спойлера

И это при том, что последняя активность на счете была две недели назад — совершенно обычная оплата в steam.
Классический пример того, как не надо делать. Рукалицо.жпг
Классический пример того, как не надо делать
Почему? Ведь имеется в виду, что доступ к почте постороннему невозможен.
Потому что не было никакой активности. Что за активность такая необычная? Если она была, то где сообщение о попытке входа в аккаунт?
То есть на ровном месте мне предложили сменить пароль, о чем сабж.
Тоже бесят сервисы, ограничивающие длину пароля. И при этом еще и не пишут требования к паролю в окне ввода. Практически всегда приходится авторизовываться через восстановление…
Сам стараюсь не ограничивать.

Я бы ещё предложил такое правило для создателей окошек с вводом пароля: Если Вы всё же решили, что надо наложить на пароль пользователя кучу тупых требований вроде символов, не повторяющихся символов, букв разного регистра при регистрации, то дайте уже зарегистрированному пользователю при входе вспомнить все эти правила. Что-то вроде не ввёл пользователь пару раз пароль правильно, то помимо сообщения о неверном пароле покажите, что не исключена возможность, что при регистрации на пароль было наложено некое правило, а введённый пароль этому правилу не соответствует.


Зачем это нужно: стабильно раз в пару месяцев восстанавливаю пароль от "госуслуги" из-за того, что там куча нелепых требований к паролю и я его не могу вспомнить, но если при входе видеть какие требования на меня налагали при регистрации, то можно будет легко вспомнить какой пароль был в итоге установлен.

Вообще-то, для решения этих проблем (и особенно «нагрузки на мозг пользователя» и был придуман SSO во всевозможных вариантах (SAML, OAuth2, OpenID Connect): один аккаунт защищенный по самое нехочу для доступа ко всем сервисам (в идеале так, что ни в какие страницы не нужно вводить пароль вообще), единая точка контроля, кому какие данные отдаются. И что немаловажно — если эти сервисы взломают — там тупо нет пароля, который может утечь! Не нужны менеджеры паролей, не нужно париться если потеряно устройство с закешированными паролями и т.д. Разрабам сервиса не нужно париться с хранением и безопасностью всей этой лабуды — можно потратить эти ресурты на полезные фичи. А если сделать вообще правильно, то и GDPR будет проще.
Короче, красота и икебана!

Проблема в том, что никто уже не верит, что «Войти с помощью Google|Facebook|Apple|etc» были сделаны именно для того, чтобы повысить безопасность и удобство пользователя, и не надоить еще бабла. Так что имеем то, что имеем.

Хотя в корпоративных условиях не иметь SSO через федерацию в 2020 — это позор. У нас в конторе это один из критериев отбора сервисов, чего и вам желаю.
единая точка контроля

Это называется «единая точка отказа».
один аккаунт защищенный по самое нехочу для доступа ко всем сервисам (в идеале так, что ни в какие страницы не нужно вводить пароль вообще)… Войти с помощью Google


Доооо.
А потом гугль внезапно банит тебя потому что ему не понравилось твое местоположение(а вот нечего за границу на отпуск ездить!), и ты лишаешься разом доступа ко всему вообще…
Нахер-нахер.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

27 июля 2015 г.

Местоположение

Россия

Сайт

ruvds.com

Численность

11–30 человек

Дата регистрации

18 марта 2016