А давайте заставим пользователя использовать безопасный пароль +95





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

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

Если у вас есть пользователи и они авторизуются по паролю, я предлагаю еще раз посмотреть на свежие рекомендации от таких организаций как National Institute of Standards and Technologies и National Cyber Security Centre.

В частности, требовать ротации паролей уже не модно. И требовать определенных символов в лучших традициях анекдота про «1ГРЕБАНАЯрозоваяроза» тоже. Давайте пробежимся по основным тезисам и попробуем сделать пользователям удобнее и безопаснее.

Аутентификация не бинарна


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

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

Наша задача, как людей предоставляющих сервис, сделать людям удобно, безопасно и не очень больно, если они ошибаются. Поэтому стоит расставить определенные признаки аномальной активности по порядку, чтобы включать те или иные дополнительные меры защиты аккаунта. Например, после 3-5 неверного ввода пароля предложить пользователю пройти CAPTCHA. Да, ее все ненавидят, но большинство пользователей с ней не столкнется. А те, кто понизил свой рейтинг доверия просто немного замедлятся перед очередным вводом пароля. Зато мы отсечем автоматические атаки на перебор пароля.

Не надо ограничивать максимальную длину пароля



Длинные пароли безопаснее. Дайте пользователям их использовать.

Ну не то, чтобы совсем не надо. Жирные пароли длиной в несколько мегабайт могут потенциально аукнуться переполнением в неожиданном месте или другими странными эффектами. Но условная максимальная длина в 300 символов гарантированно устроит любого типичного пользователя. Более того, этих же рекомендаций придерживается NIST:
Аутентифицирующая сторона должна разрешать пользователю использование запоминаемых паролей длиной не менее 64 символов.

А еще для особо одаренных сервисов NIST также дает еще одну важную рекомендацию:
Усечение пользовательского пароля недопустимо.

Да, есть крайне странные сервисы, которые считают, что и 12 символов хватит, а значит остальные 28 можно спокойно отрезать и проверять хеш только первого фрагмента. Не знаю, что за пораженный разум до такого додумался, но подобным нередко страдают те же банковские организации. Не делайте так. Если пользователь хочет использовать кусок из Иллиады пополам с фрагментами текстов группы Кровосток — пусть использует.

Убедитесь, что любые ASCII символы допустимы


Есть определенные проблемы со спецсимволами. Например, использование "{}/\" или других подобных символов может быть потенциально недопустимым в некоторых ситуациях. Скажем, фигурные скобки могут ломать валидный JSON и вызывать падение обработки пароля. Или символ апострофа, который может использоваться в SQL-инъекциях. Да, форма ввода пароля тоже может быть входными воротами для атаки.

В теории вы могли бы просто запретить использование подобных символов, чтобы сделать себе проще. Но тем самым вы снизите энтропию пароля пользователя и сделаете ему неудобно, если пароль генерируется автоматически. Придется подбирать определенные паттерны для исключений. Опять же обратимся к Марксу NIST:
Все печатаемые символы ASCII [RFC 20], включая пробел, должны быть допустимыми для ввода в качестве пароля. Символы Unicode [ISO/ISC 10646] также должны быть допустимыми.

Да. Все верно. Это ваша головная боль и дополнительное тестирование. Но если пользователь хочет использовать ???? ?????? ?????? или ???? ??? ?????? ???????? — дайте ему это сделать. Или добавить символ буррито в пароль для криптостойкости. Имеет право.

А еще отстаньте от пользователя с требованиями использования специальных символов. Да, вот просто не трогайте его. Пусть использует, что хочет. Исследования массовых утечек говорят о том, что люди все равно используют дурацкие замены со спецсимволами, что совершенно не улучшает ситуацию. В частности Microsoft пишет:
Большинство людей использует однотипные паттерны, например, заглавная буква в качестве первого символа, спецсимволы и цифры на последних двух позициях. Киберпреступники знают об этом и настраивают свои атаки с перебором по словарю с учетом типичных замен, таких как «s» на "$", «a» на "@" и «i» на «l».

Да-да, тот самый Microsoft из-за которого миллионы людей каждый месяц придумывают новый пароль, не совпадающий с предыдущими, содержащие спецсимволы и буквы в разном регистре. Именно они в своих гайдлайнах теперь пишут «Eliminate character-composition requirements».

Ведь в итоге, типичные утилиты вроде cain and abel, hashcat, john the ripper могут подобрать пароль в течение нескольких часов или даже минут на типичной видеокарте, если использовалось стандартное словарное слово и типичный паттерн замены.

Не используйте подсказки для паролей


Забытый пароль гораздо безопаснее похоронить навсегда, чем хранить в БД подсказку для пользователя в открытом виде.

В 2013 году у Adobe утекла база с паролями. Зашифрована она была криво, но самое неприятное, что она содержала подсказки для восстановления, над чем и не преминул поиздеваться Рэндал Манро в xkcd.
Того же мнения придерживается NIST, не рекомендующий хранение подсказок в любом виде. Забыл — восстанавливай через почту со всеми дополнительными проверками.

Снизьте нагрузку на мозг пользователя


National Cyber Security Centre выпустил крутую инфографику. Позволю себе процитировать небольшой фрагмент:

Обратите внимание, что основная проблема с паролями связана с тем, что хороший пароль случаен и его почти нереально запомнить. Если сервисов много, то пользователь почти неизбежно будет использовать один и тот же пароль везде, где можно. Особо продвинутые сделают что-то вроде «myp@ssword_habr.com». Естественно, что компрометация пароля в одном месте автоматически ставит под удар аккаунты во всех остальных сервисах.
Поэтому, дайте пользователю использовать менеджеры паролей. Да, это как специальный кошелек для банковских карт, который позволяет потерять их одновременно. Но тут надо понимать, что компрометация оффлайн хранилища паролей — довольно редкая ситуация, в отличие от компрометации одинаковых паролей на разных ресурсах. Менеджеру паролей не нужно быть идеальным. Ему нужно быть лучше, чем однотипные пароли везде. Не будьте как некоторые нехорошие сервисы, которые блокируют возможность вставки пароля в поле из буфера обмена. Это явно заставляет пользователя отказаться от менеджера паролей и использовать слабый вариант.

Второй пункт говорит о том, что не надо заставлять пользователя менять свой пароль, если нет явных признаков его компрометации. Это лишь мотивирует его использовать паттерн с одним и тем же паролем. Гораздо лучше поднять тревогу, если пароль всплывет в одном из многочисленных словарей утечек. Естественно, что нельзя давать пользователю создавать пароль, который уже попал в словари.

Выводы


  1. Будьте добрее к пользователю. Не надо заставлять его придумывать типовые паттерны и делать глупости. Стандартные привычные требования прям подталкивают его к этому. Просто соблюдайте несколько пунктов:
  2. Используйте аутентификацию по ключу вместо паролей там, где это применимо.
  3. Не давайте пользователю использовать пароль, если он есть в словарных базах. Неважно, он их туда слил или кто-то еще.
  4. Сообщайте пользователю, если его пароль появился в словарных базах. Поднимайте тревогу и требуйте второй фактор при следующем входе. Скомпрометированные пароли будут применены почти сразу.
  5. Требуйте определенной длины паролей и не препятствуйте, если пользователь хочет действительно длинный пароль.
  6. Убедитесь, что вы допускаете любые символы в качестве пароля.








Комментарии (206):

  1. ZakharS
    /#22130284

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

    На КДПВ злая бабушка, надо полагать.

    • Kopilov
      /#22130338

      В её лучшие годы

      • 0pt1muS
        /#22136700

        Пишу сюда для заметности.
        Почему в статье нет ни слова про UTF-8 и кириллицу?
        Это многократно увеличивает сложность подбора даже трудно запоминаемого пароля, описанного в статье!

        • TheShock
          /#22136708

          Все печатаемые символы ASCII [RFC 20], включая пробел, должны быть допустимыми для ввода в качестве пароля. Символы Unicode [ISO/ISC 10646] также должны быть допустимыми.

          На жёлтом фоне

    • sim2q
      /#22131290 / +1

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

      • DGN
        /#22133240 / +1

        Бэкдор в Нарнию ищет?

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

      • rPman
        /#22133596

        почему то сразу подумал что он прислушивается, слева от себя, но разве в этих машинах были реле?

        • Wesha
          /#22133642

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

          • sim2q
            /#22134498

            а мне кажется, что их как будто внезапно побеспокоили, но у дамы кольцо если что:)

  2. schetilin
    /#22130412 / +1

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

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

    • Neusser
      /#22130512

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

      • jedecuz
        /#22131564

        К сожалению не только гугл. Всяческие майлры и яндексы от него не отстают.

        • S-trace
          /#22132924

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

      • fpir
        /#22134144

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

    • jedecuz
      /#22131310

      А вы, батенька, гуманииист…
      За это надо руки в мясорубке проворачивать по самую задницу!

    • ComodoHacker
      /#22134536

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


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

    • Fr0sT-Brutal
      /#22144670 / +1

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

  3. Deosis
    /#22130494

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

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

    • Meklon
      /#22130710

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

      • Arimefu
        /#22130964

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

        • vnkr
          /#22131132 / +1

          Вы же знаете как вы хешируете пароли у себя. Берите базу утекших паролей (в ней они в открытом виде), хешируйте каждый своим алгоритмом и сравнивайте с хешем в вашей базе.

          • Ddnn
            /#22132742 / +1

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

            • vnkr
              /#22132750

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

              • defuz
                /#22133204

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

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

                • vnkr
                  /#22133210 / +1

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

                  • defuz
                    /#22133228

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

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

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

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

                  • defuz
                    /#22133290

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

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

            • Meklon
              /#22133186

              Bcrypt, кстати, уже прошел аудит?

            • razielvamp
              /#22133440

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


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

              • defuz
                /#22133496

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

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

              • sumanai
                /#22134148

                Получается, что в таблице пользователя три колонки: логин, пароль, соль.

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

      • bolk
        /#22133614

        На входе пользователя это надо проверять. На входе пароль есть.

      • trawl
        /#22136244

        В момент авторизации можно сырой пароль сверить

    • defuz
      /#22131302

      Одним запросом к API haveibeenpwned.

      • Meklon
        /#22132256

        Это если не солёный. Хотя соль у сервиса должна быть.

        • defuz
          /#22132872

          В каком смысле? Сервису известен не соленый и не хешированный пароль в момент выбора пароля пользователем.

          • Meklon
            /#22133092 / +1

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

            • defuz
              /#22133150

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

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

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

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

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

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

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

              Хорошая новость состоит в том, что вы можете перепроверять пароль в момент каждой авторизации, и тем самым заблокировать потенциальную атаку в случае если пароль подходит И был недавно обнаружен в новых утечках, запросив у пользователя сменить пароль через надежный канал связи (почту), и/или потребовав дополнительный фактор авторизации (мобильный телефон, 2FA и т.п.).

  4. bvvbvv
    /#22130506

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

    • ZakharS
      /#22130526 / +1

      Интересно, как Гугл понимает, что это я куда-то уехал, а не «злые враги» мой пароль украли?
      Если у вас телефон на Андроиде, то гугл про ваши перемещения знает чуть больше чем все :-)

      • bvvbvv
        /#22130558

        По моему опыту — никак.

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

        И при этом в почту не пускает…

        • ZakharS
          /#22130596

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

          • force
            /#22131248

            less secure — по паролю, secure — через OAuth. Но это гугл, там могут быть всякие нюансы ещё.

          • Lennonenko
            /#22153430

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

        • vsergoog
          /#22133868

          Гугл большой… Правая рука не знает, то, что знает левая. Безопасность!

    • Yuriy_krd
      /#22130588

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

      • Meklon
        /#22130718

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

      • nikolayv81
        /#22133000

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

      • dartraiden
        /#22133414

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

  5. unwrecker
    /#22130706

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

    Второй фактор если и делать, то априори восстановимый типа одноразывых кодов.

    • Tangeman
      /#22132098

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

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

      • schetilin
        /#22132140

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

        • Tangeman
          /#22132300

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

          • ShadowTheAge
            /#22132446

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

  6. geov
    /#22131510

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


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

  7. MrMarc
    /#22131516

    «Злая бабушка»- первая капча, получается?

  8. 3aBulon
    /#22131768

    2020 год. у МТС банка длина пароля 10 символов! максимум!

  9. podde
    /#22132066

    Пффф!
    У Сбера 5. ЦИФР. Только 5. Не символов. Цифр.

    Я сам спрашивал:
    image

    • dartraiden
      /#22133416

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

      • vladkorotnev
        /#22134208 / +1

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


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

        • dartraiden
          /#22135212

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

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

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

      • fpir
        /#22134214

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

    • AlienJust
      /#22133584

      убрир — 4 цифры, кто меньше? =\

  10. Alexey2005
    /#22132132 / +1

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

    echo "qwerty" | md5sum -
    и вот мы уже получаем надёжный пароль (a86850deb2742ec3cb41518e26aa2d89), который шиш кто подберёт, но который при этом запоминать не надо — ведь мы знаем, как его можно сгенерировать из простого запоминаемого набора символов.
    Или так:
    echo "qwerty" | base64

    Вывод: cXdlcnR5Cg==

    • ShashkovS
      /#22132616

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

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

      • Meklon
        /#22132632

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

        • inkelyad
          /#22132662

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


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

          • unsignedchar
            /#22132844 / +1

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

            • inkelyad
              /#22132868 / +1

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

      • Ddnn
        /#22132826 / +1

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


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


        echo -n "qwerty" | md5sum

        Получится d8578edf8458ce06fbc5bb76a58c5ca4.

        • vvzvlad
          /#22133246 / +1

          это хэш от qwerty\n.

          Случайно посолили

      • SnikeMK
        /#22136588

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

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

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

        • sumanai
          /#22136738

          в радужной таблице

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

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

          • unsignedchar
            /#22137148

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


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

            • Wesha
              /#22137180

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

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

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

      • raduysa
        /#22145402

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

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

      • white_nigga
        /#22145404

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

        Пользователь на этапе регистрации введёт a86850deb2742ec3cb41518e26aa2d89 в поле «придумайте пароль», и поэтому в базу пойдёт уже либо хэш от a86850deb2742ec3cb41518e26aa2d89, либо хэш от этого + соль.

    • 9660
      /#22133548

      Из минусов, нужно или уметь считать md5 или base64 на листочке, или обязательно иметь доступ к соответствующему калькулятору.
      Ну и быть в определенном смысле стоиком чтобы иногда набирать пароли вида a86850deb2742ec3cb41518e26aa2d89 вручную.

      • K0styan
        /#22134130

        А если есть доступ к «калькулятору», то на него же можно установить и менеджер паролей как правило.

    • sumanai
      /#22134174

      и вот мы уже получаем надёжный пароль (a86850deb2742ec3cb41518e26aa2d89)

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

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

      • zvam1
        /#22145406

        А если попробовать сделать не 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


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

        • Meklon
          /#22146304

          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.

          • unsignedchar
            /#22146348

            Сгенерировать 2 128-байтных сообщения с коллизией != обращение хеш-функции.

            • Meklon
              /#22146406

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

    • defuz
      /#22137910

      Если ваш пароль гуглится, значит это плохой пароль.

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

  11. inkelyad
    /#22132278

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


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

    • jedecuz
      /#22132412 / +1

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

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

      • inkelyad
        /#22132482

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

      • vsh797
        /#22132658

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

        • inkelyad
          /#22132674

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

          • stokker
            /#22133390

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

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

            • EnotP
              /#22133500

              обычно
              Бывают и необычные ситуации: отсутствие мобильной сети при наличии корпоративной проводной, как пример.

            • inkelyad
              /#22133612

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


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

        • tcapb1
          /#22133386

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

          • Interreto
            /#22133410 / +1

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

            • Physmatik
              /#22141266

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

              • Lennonenko
                /#22153474

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

          • inkelyad
            /#22133616

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


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

            • tcapb1
              /#22145970

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

              • inkelyad
                /#22147134

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

          • Endeavour
            /#22135470

            Храните данные инициализации аутентификатора в надежно шифрованном хранилище паролей.

            • sumanai
              /#22135476

              Вместе с паролем? А то получается, что оба фактора лежат в одном месте.

    • Viceroyalty
      /#22132950

      Почему забыли про авторизацию через Гугл/Фейсбук/etc?

      • inkelyad
        /#22132974

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

        • Viceroyalty
          /#22132996

          Если нет способа восстановления аккаунта ты если и пароль забудешь то все

    • maxx_es
      /#22133404

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

      • Fedorchik
        /#22152536

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

  12. jetcar
    /#22132648

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

    • Fr0sT-Brutal
      /#22144722

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

  13. MKMatriX
    /#22132812 / +2

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

  14. Wesha
    /#22132980 / +1

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


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

    • Interreto
      /#22133418

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

      • Wesha
        /#22133512

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

        • DrrRos
          /#22135592

          А вот это уже всё от того, что правильная регулярка позволяющая отсеять ненужное именно на все случаи жизни для почты имеет вид типа:

          регулярка почты
          (?:(?:\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*)

          • ursaa
            /#22136084 / +1

            Не сойдет и не подходит. Почта типа info@com валидная, но этими регулярками признается некорректной.

          • Wesha
            /#22136998

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


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

            • DrrRos
              /#22137062

              upd. Да, ссылку не увидел.

  15. Antervis
    /#22133392

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

    • SlavniyTeo
      /#22133838

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


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

    • El_Kraken_Feliz
      /#22133978

      Это ещё классно работает, когда эти волшебные разработчики не подозревают о наличии каких-либо языков, кроме английского.
      Часто бывает, что можно регнуться с символами вроде n,c???? и т.п., а зайти потом нельзя :)
      При этом символы могут быть в логине. А логин может быть почтой :) И потом уже никакими способами невозможно зарегаться на эту почту — при создании нового акка говорит, что такой уже есть, а когда заходишь, говорит, что такого нет :)

  16. rowaxi
    /#22133458 / +1

    Сообщайте пользователю, если его пароль появился в словарных базах.
    Для некоторых разработчиков ещё следует уточнить, что если и проверяете это, то только в момент авторизации пользователя и не хранить пароль в открытом виде.
    Скомпрометированные пароли будут применены почти сразу.
    Замечательно. А как корректно, с точки зрения безопасного хранения пароля, «почти сразу» сообщить пользователю?

  17. 9660
    /#22133508

    Но если пользователь хочет использовать ???? ?????? ?????? или ???? ??? ?????? ???????? — дайте ему это сделать. Или добавить символ буррито в пароль для криптостойкости. Имеет право.

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

    • EnotP
      /#22133794

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

      • 9660
        /#22133822

        Заметьте, я не писал о своей клавиатуре.

        • EnotP
          /#22134062

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

          • vladkorotnev
            /#22134238

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


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

            • EnotP
              /#22135146

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

            • klirichek
              /#22138184

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

          • rowaxi
            /#22134362

            Если «строго говоря», то есть управляющие символы ASCII.
            Ввести, конечно, формально можно, но вот получится ли использовать в пароле NULL, BACKSPACE или возврат каретки.

            • EnotP
              /#22135156

              Если это предусмотрено функционалом движка — получится.

          • 9660
            /#22134458

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

            • EnotP
              /#22135190

              Изначально статья про интернет-сервисы. Так что ситуации, когда какого-то символа нет — исключена на андроиде, линуксе, винде и макаке. «Алиса, спроси у гугля, как выглядит символ рубля».

              • JPEGEC
                /#22135286

                И молчание было ему ответом. Напоминаю что «иногда приходится с того что есть».
                В базовом функционале как ситуация со всем этим? Охотно допускаю что нормально, но не уверен.

                • EnotP
                  /#22135332

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

                  • JPEGEC
                    /#22135464

                    входить на сайт, то у вас точно есть интернет, а вместе с ним гугл, яндекс, дакдакго, байду и прочая-прочая-прочая

                    Совершено не факт, в том то и дело. Но в целом я вашу мысль понял.

                    • EnotP
                      /#22135550

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

                      • JPEGEC
                        /#22135566

                        Я мысль понял, хоть и не поддерживаю ее совершено. Но страдать то если что не мне? :)

                        • EnotP
                          /#22135706

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

                          • JPEGEC
                            /#22135904

                            А вы реально используете пароли с эмодзи? И прочим санскритом? Или разговор чисто теоретический?

                            • EnotP
                              /#22136556

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

              • klirichek
                /#22138188

                del
                (привёл пример с эмодзи, но хабр их не отображает)

      • inkelyad
        /#22133886

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

        • EnotP
          /#22134050

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

          • inkelyad
            /#22134092

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

            • EnotP
              /#22135210

              Уверены, что ввести jopajopa проще, чем жопа? Я вот абсолютно уверен, что первый вариант в словарях встречается чаще, чем второй, но второй вводится быстрее и проще.

  18. catBasilio
    /#22133692

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

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

    • Meklon
      /#22133742

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

      • JPEGEC
        /#22135292

        А где грань разумности? Если ему очень хочется пароль 3 символа, разрешать?

        • Meklon
          /#22136062

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

          • sumanai
            /#22136086

            Представил себе напротив пароля «Энтропия должна быть минимум 80 бит», и бедных пользователей, которые вообще не поняли, о чём это.

            • Lennonenko
              /#22153500

              пользователям обычно говорят «ваш пароль слишком короткий/ненадёжный»
              бесить начинает, когда это не форма ввода делает, а нажатие кнопки

              • sumanai
                /#22153526

                Веселее, если форма отправляется, страница перезагружается, а там только эта надпись и пустые поля.

  19. vvbob
    /#22133986

    У меня недавно (работаю на удаленке) был забавный случай с этими паролями. Пришло письмо от админов, о том что я обязан сменить пароль, иначе секир башка аккаунт будет уничтожен. Все-бы ничего, но я в это время был в отпуске и после него еще была пара выходных, в общем когда я добрался до этого письма, у меня оставалось всего что-то около пятнадцати минут до конца дня на его смену. Указанный в письме адрес для смены не работал, просто недоступен, пока я там бился, часы перешли нулевую отметку и аккаунт мне автоматически грохнули вместе со всеми доступами, удаленными рабочими столами и прочей тряхомудией.
    Далее был целый набор веселых квестов: напиши письмо в поддержку, разберись почему тебя послали, выясни кто руководитель этих обезьян уважаемых коллег-админов, напиши ему письмо, пообщайся с наконец-то снизошедшими до твоей проблемы аристократами от системного администрирования, разберись почему уже неделю они не могут сделать такое простое дело как восстановление аккаунта, напиши их начальнику…
    В общем восстанавливал я все три недели, а вы про лучшие практики безопасности… тут бы просто блин не мешали людям работать.

    • Neusser
      /#22134480

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

      • bvvbvv
        /#22134696

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

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

        • vvbob
          /#22134832

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

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

        • sergey-b
          /#22136242

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

      • vvbob
        /#22134820

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

  20. sumanai
    /#22134136

    И совсем плохо, если пользователь верно ввел пароль, но устройство недоверенное, второй фактор не подтвержден и IP принадлежит выходной ноде Тора.

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

    • bvvbvv
      /#22134710

      Предлагаю добавить заболевание «безопасность головного мозга».

  21. sergey-b
    /#22134252

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


    Сбер

    • sumanai
      /#22134288

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

    • Dima_Sharihin
      /#22135942

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

      • sumanai
        /#22135974

        Печать паролей?

        • Dima_Sharihin
          /#22136008 / +1

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

        • sergey-b
          /#22136114 / +1

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

  22. Lestok
    /#22134420

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

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

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

    Поэтому пользователь, защищающий свои учётные записи с помощью одного лишь пароля, может с тем же успехом считать, что не защищает их вовсе!

    • sumanai
      /#22134452

      Жуткая чушь.

      • Lestok
        /#22134460

        Жуткая чушь.
        Почему?

        • sumanai
          /#22134594

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

          • bvvbvv
            /#22134740

            И даже если подберут, то это мои проблемы, а не Microsoft.

            Я как-то в гуглофоруме на эту тему общался. Там было высказано мнение, что потеря аккаунта это компрометация сервиса. Но вот обоснование такой позиции мне получить не удалось…

          • JPEGEC
            /#22135300

            А если эти пароли не рэндом а по списку?

            • sumanai
              /#22135342

              В смысле? Пароль 00000000000000000000 скорее всего не является безопасным, не нужно его использовать.

              • JPEGEC
                /#22135472

                Объясню. Пароль может быть вполне стойким но не уникальным и уже скомпроментированным.

                • sumanai
                  /#22135480

                  Это как не уникальным? У меня каждый пароль уникален.

                  • JPEGEC
                    /#22135496

                    Уверены что не совпадает ни с чьим паролем во всем мире?

                    • sumanai
                      /#22135522

                      Уверен. Нет, коллизии бывают, но блин, их вероятность крайне низка. Вот если генерировать 100000000000 паролей в секунду и подождать примерно 200 миллионов лет… Тогда да, с вероятностью 50% совпадёт.

          • czz
            /#22135658

            Только его не подберут, а украдут.

            • sumanai
              /#22135714

              От кражи ничего не спасёт.

        • denonlink
          /#22134758

          Только что сгенерировал новый рандомный пароль своим password manager-ом. Скажите пожалуйса, какая может быть небезопасность у пароля «qd9LyL00WCN1xs8MOcs1#IAi» и сколько его надо брутфорись при наличии соли и криптостойкого хеша при хранении в БД?

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

          • inkelyad
            /#22134792

            Уже довольно давно нарисовали такую картинку (reddit/imgur)

            • denonlink
              /#22134822

              В пароле, который я привел для примера, этропия примерно 150 бит — а в той таблице максимум 120. Вобщем, стойкие пароли существуют, расходимся.

          • czz
            /#22135692

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

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

            Поэтому в современном мире любая аутентификация по паролю без второго фактора считается небезопасной, независимо от сложности пароля.

            • sumanai
              /#22135720

              Эх, мир катится куда-то не туда.

            • Lestok
              /#22135950

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

  23. 0pt1muS
    /#22135096

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

    • sergey-b
      /#22136168

      У вас недопустимые символы в пароле. Попробуйте позже.

  24. EagleXK
    /#22136096

    Вот бы к таким пожеланиям прислушались в Salesforce, а то как же они задолбали со своими требованиями к паролям и постоянными ротациями :(

  25. drobzik
    /#22136108

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

  26. qyix7z
    /#22136530

    Вот прям в тему получил только что письмо от палки:

    Заголовок спойлера

    • stokker
      /#22136918

      Классический пример того, как не надо делать
      Почему? Ведь имеется в виду, что доступ к почте постороннему невозможен.

      • qyix7z
        /#22139078

        Потому что не было никакой активности. Что за активность такая необычная? Если она была, то где сообщение о попытке входа в аккаунт?
        То есть на ровном месте мне предложили сменить пароль, о чем сабж.

  27. R000M
    /#22136584

    Тоже бесят сервисы, ограничивающие длину пароля. И при этом еще и не пишут требования к паролю в окне ввода. Практически всегда приходится авторизовываться через восстановление…
    Сам стараюсь не ограничивать.

  28. ReinRaus
    /#22151622

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


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

  29. apcsb
    /#22151770

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

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

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

    • sumanai
      /#22152346 / +1

      единая точка контроля

      Это называется «единая точка отказа».

    • jedecuz
      /#22152698

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


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