Требования к паролям — полная чушь

https://blog.codinghorror.com/password-rules-are-bullshit/
  • Перевод
Знаете, что самое худшее в паролях (а там есть из чего выбирать)? Требования к их сложности.


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

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

Мир буквально погряз в ужасных правилах создания паролей:

Тупые требования
Примеры плохой политики
Доска позора

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


Видели этот классический комикс о паролях от XKCD?



Разумеется, можно спорить, стоит ли считать «correct horse battery staple» примером хорошей стратегии для создания паролей, но суть аргумента в том, что длина решает.



Нет, серьезно, решает. Скажу даже больше: зуб даю, что ваш пароль слишком короткий. В наше время, учитывая, насколько развиты облачные вычисления и взлом паролей с помощью GPU, ставить пароль в 8 символов или короче — все равно что вообще его не ставить.

Тогда, получается, одно правило у нас уже есть: пароль не должен быть коротким. Длинный пароль с большей вероятностью окажется надежным, чем короткий… правда же?

А что скажете о таком пароле в 4 символа?



Или о таком, в 8 символов?



Или о таком, гипотетическом, но вполне реалистичном, в 7 символов?



«Извините, но ваш пароль должен содержать не менее одного символа из арабского, китайского, тайского, корейского и клингонского, пиктограмму из Wingdings и смайлик».

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



Господи.



Наш старый друг Юникод опять за свое.

Как выясняется, даже простое правило «ваш пароль должен быть разумной длины» работает с оговорками. Особенно если перестать мыслить, как двинутые на ASCII американцы.

Да и если присмотреться ко всем этим славным длинным паролям… всегда ли они надежны?

aaaaaaaaaaaaaaaaaaa
0123456789012345689
passwordpassword
usernamepassword

Конечно, нет. Вы вообще видели живых пользователей в последнее время?



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

  • должны содержать прописные буквы;
  • должны содержать строчные буквы;
  • должны содержать числа;
  • должны содержать специальные символы.

в мире, где есть Юникод и смайлики, значит не иметь воображения.

Когда мы работали над Discourse, я узнал, что окошко авторизации, оказывается, очень сложный компонент софта, несмотря на внешнюю простоту. Главное требование к паролям, которые мы приняли — длина — также было достаточно простым. Пока я писал эту статью, мы уже успели увеличить минимальную возможную длину пароля с 8 до 10 символов. А для модераторов и администраторов и решили поставить нижнюю границу еще выше, на 15 символах.

Кроме того, я настаивал на том, чтобы проверять, не совпадает ли пароль с каким-нибудь из списка 100 000 самых распространенных. Если проанализировать 10 миллионов паролей, которые попали в общий доступ из-за утечек данных, выясняется, что чаще всего используются следующие 25:

123456
123456789
qwerty
12345678
111111
1234567890
1234567
password
123123
987654321
qwertyuiop
mynoob
123321
666666
18atcskd2w
7777777
1q2w3e4r
654321
555555
3rjs1la7qe
google
1q2w3e4r5t
123qwe
zxcvbnm
1q2w3e

Даже эти данные свидетельствуют об излишней зацикленности на системе ASCII. То есть цифры-то, конечно, везде одинаковые, но мне как-то не верится, что среднестатистическому китайцу придет в голову поставить в качестве пароля «password», «quertyuiop» или «mynoob». Так что такие списки необходимо составлять с учетом локализации и прочих параметров.

(Есть еще интересная мысль: искать популярные короткие пароли в составе длинных, но, как мне кажется, получится слишком много ошибок первого рода)

Представленная статистика также свидетельствует в пользу того, чтобы делать пароли длиннее. Обратите внимание: из 25 самых популярных паролей только 5 имеют длину в 10 символов и больше. Соответственно, если мы установим минимум в 10 символов, то уже одним этим отсечем 80% списка. Впервые я это выяснил, когда собрал несколько миллионов паролей из утечек данных в рамках исследования для Discourse и отфильтровал те, которые соответствуют нашему новому требованию, чтобы длина пароля была не меньше 10 символов.



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

Я хотел бы предложить коллегам-разработчикам следующие рекомендации, продиктованные исключительно здравым смыслом:

1. Требования к паролям — полная чушь


  • Они не работают.
  • Они наказывают аудиторию, которую вам нужно привлекать в первую очередь, — тех, кто пользуется рандомными генераторами паролей. Прикиньте, рандомный пароль может и не содержать в себе цифры или символа. Я два раза сверился с учебником по математике, и да, вроде бы такое вполне возможно.
  • Они раздражают основную массу пользователей, отбивая у них охоту с вами сотрудничать и подстегивая искать всякие «остроумные» лазейки. В результате пароли получаются менее надежными.
  • Они часто ошибочны, в том смысле, что предложенный набор правил недостаточен или попросту нелеп. Достаточно посмотреть на любой пример с доски позора, на которую я ссылался выше.
  • Нет, правда, ради всего святого, хватит уже этой ерунды с произвольными требованиями к паролям. Если не верите мне, почитайте рекомендации по требованиям к паролям от NSIT. Вот, так и написано: «избегайте устанавливать правила создания паролей». Хотя, на мой взгляд, тут есть одна неточность, надо было написать: «избегайте устанавливать тупые правила».


2. Установите минимальную длину пароля в Юникоде


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



  • Это просто. Пользователи умеют считать. Ну, большинство умеет.
  • Это работает. Статистика подтверждает, что это работает: просто скачайте любой список популярных паролей на ваш выбор и рассортируйте их по длине.
  • Математика не даст соврать. При прочих равных условиях длинный пароль будет более рандомным, чем короткий, а значит, и более надежным.
  • Смиритесь с тем, что даже у этого единственного правила будут исключения. Минимальная длина в 6 символов на китайском сайте — это вполне разумно. С другой стороны, пароль в 20 символов может быть до смешного простым для взлома.
  • Если в ваше поле пароля нельзя ввести (практически) любой символ из Юникода, вы скорее всего что-то делаете не так.
  • Это уже больше относится к частностям реализации, но не забудьте также установить вменяемую максимальную длину пароля.


3. Сверяйтесь со списком самых распространенных паролей


Как я уже говорил, какие из них считать «распространенными», зависит от вашей аудитории и языка, но в любом случае, позволяя пользователям ставить пароли из списка 10 000, 100 000 или миллиона самых популярных паролей из утечек данных, вы оказываете им медвежью услугу. Нет ни малейшего сомнения, что хакер попробует эти пароли при попытке взлома, и, даже если вы ставите жесткие ограничения на количество попыток ввода, достаточно прогнать первую тысячу, чтобы добиться шокирующе хороших результатов.

  • у 1.6% пользователей пароль из числа 10 самых популярных;
  • у 4.4% пользователей пароль из числа 100 самых популярных;
  • у 9.7% пользователей пароль из числа 500 самых популярных;
  • у 13.2% пользователей пароль из числа 1000 самых популярных;
  • у 30% пользователей пароль из числа 10 000 самых популярных.

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

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

4. Контролируйте количество энтропии


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



Я с некоторой грустью осознал, что нас вполне устраивает, чтобы пользователь установил пароль из 10 совершенно одинаковых символов («аааааааааа»). На мой взгляд, самый простой способ избежать такой ситуации — задать минимум в x уникальных символов на общее число y. Так мы и поступаем в последней бета-версии Discourse. Но если у вас есть какие-то другие идеи, будем рады услышать их в комментариях. Чем проще и яснее, тем лучше!

5. Отлавливайте особые типы паролей


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

  • пароль, который совпадает с именем пользователя;
  • пароль, который совпадает с e-mail.

Если у вас стоит Discourse версии 1.3 и ниже — мне очень жаль, пожалуйста, обновите его как можно скорее.

Также, возможно, вам стоит блокировать еще некоторые разновидности:

  • пароль, который совпадает с URL сайта или именем домена;
  • пароль, который совпадает с названием приложения.

Если вкратце, старайтесь мыслить, выходя за рамки поля для ввода — совсем как ваши пользователи.

Пояснение


Некоторые читатели восприняли мои слова как «все правила, кроме этих четырех, которые я сейчас распишу — полная чушь». Я имел в виду другое.

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

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

Так что, если в двух словах: правило одно — длина. Вводите что ваша душа пожелает, лишь бы количество символов тянуло на нормальный пароль.
Everyday Tools 218,57
Утилиты на все случаи жизни
Поделиться публикацией
Комментарии 279
  • +50
    Я пользователь.
    Я хочу свободно заходить на этот сайт не задумываясь над паролем.
    Я не введу никогда сюда свои персональные данные или номер банковской карты.

    Почему. Мне. Нельзя. Использовать. Простой. Словарный. Пароль?
    • +7

      На самом деле вопрос должен звучать так:


      Почему. Мне. Вообще. Нужно. Придумывать. Пароль?


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

      • 0
        Не уверен насчет входа через соцсеть. Единый вход для всего — да, я бы обеими руками за. Пока приходится радоваться, если можно прицепить гугл-аккаунт.
        • +1

          Ну, Google+ — тоже какбысоцсеть. В общем-то, про него в первую очередь и писал.

          • 0
            Но на сколько я знаю G+ не самый популярный способ логина, практически везде только либо FB. Либо FB + 1 любой альтернативный способ. Либо твитер, либо G+, либо тот же Vk.

            Было бы неплохо наверно сделать что-то похожее на сервисы, которые выдают сертификаты для HTTPS. Типа стандарт общий (да да я знаю про OAuth). То есть ты заходишь на сайт и говоришь, что вот такой-то провайдер знает меня под ID таким-то. А у провайдера подтверждать свою личность через несколько степеней защиты, типа биометрии. Эх… Мечты мечты…
            • 0
              Но на сколько я знаю G+ не самый популярный способ логина

              В случае телефонов на Android приложения используют сервис гугля как основной способ авторизации.

              • 0
                Ну приложения-то да, а вот с сайтами все не так здорово.
                • 0
                  OpenID, же

                  Раньше почти все его поддерживали например яндекс. Но через какое-то время решили делать свое Яндекс.Паспорт
              • +2

                Такой стандарт есть, OpenID называется (не путать с OpenID Connect, который есть дальнейшее развитие OAuth 2), да как-то не получил распространения. Основная проблема — требуется помнить свой URL-идентификатор (например мой — это https://me.yahoo.com/envek для Yahoo (в форму можно вводить просто me.yahoo.com — будет работать), а для гугла его вообще не запомнить никогда)

                • 0

                  OpenID Connect — это соединение механизма OAuth2 с идеей OpenID


                  Основное отличие OpenID Connect от OpenID с точки зрения пользователя — вы говорите не "такой-то провайдер знает меня под ID таким-то", а просто "такой-то провайдер знает меня".

                • –1
                  imageА так и делают, например, при доступе на Госуслуги, именно на сертификатах и токенах/смарткартах PKCS#11
                  • 0

                    Нет, они так не делают. Они не разрешают использовать любого популярного провайдера.


                    Попробуйте зайти туда через Google+, Facebook или хотя бы VK.

            • +4
              С соцсетями есть тонкий момент — если заблокируют ваш аккаунт (facebook) или всю соцсеть (linkedin), вы останетесь без логина. Не страшно для проходного сайта, но есть реальные истории, как люди теряли деньги из-за блокировки того же facebook.
              • +1
                С тем же успехом могут и почтовый аккаунт заблокировать на gmail из-за левой пятки третьего алгоритма, а у вас на почту подтверждение приходит (2FA).
                • 0
                  Поэтому есть смысл регать свой домен и юзать почтовый ящик на нём, с помощью google mail или yandex mail. При блокировке сервиса, просто делегируем MX записи на другой сервис.
                  • 0

                    И как это поможет, если авторизация по гугл-аккаунту?

                    • 0
                      Если мы для регистрации использовали email на своём домене, привязанный к gmail и потом этот gmail-акк был забанен, то просто привязываем домен к новому gmail или любому другому почтовому сервису и получаем 2FA-токен на старый майл.
                      • +2
                        Осталось разобраться с паролем для управления доменом… :)
              • 0

                А в соцсети как входить? Просто перекладываем свои проблемы на них? :)


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


                То есть я как раз бы не доверял соцсетям (собственно и не доверяю), если даже индивидуальная разовая ложноположительная аутентификация может стоить заметную для прибыли/оборотов сумму.

                • 0

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


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


                  В-третьих, обратите внимание на вот это уточнение:


                  Вход на сайт через социальные сети рулит. Если, конечно же, это не единственный способ входа.
                  • 0
                    Во-первых, если человек использует вход на важный сайт через соцсети — он и к паролю в соцсети отнесется внимательнее.
                    Это работает только в том случае, если человек не совсем полный клинический идиот и в состоянии вывести следствие одной сущности из другой. Обычно это слишком уж оптимистичные ожидания. Либо ему нужно об этом постоянно напоминать так, чтобы он это понял, не пропустил, задумался, поработал головой и принял решение, исходя из всего вышеперечисленного. И всё это ещё надо на нескольких уровнях несколько раз проконтролировать. Тогда ещё можно утверждать, что человек, в теории, возможно, если его прямо направить, вероятно, таки сможет оказаться в числе тех 10%, которые лишь чуть-чуть более внимательно обратят внимания на что-то (при этом, не важно на что — на анимированный логотип, гавкающую собачку за углом и на пролитый на брюки горячий чай).
                • –1
                  Вход на сайт через социальные сети рулит

                  "Брелок: маленькая штуковина, которая предоставляет Вам возможность потерять ключи от всех Ваших дверей одновременно."

                  • 0

                    Да ещё с подписью, какой ключ откуда.

                    • 0

                      Пожалуйста, прочитайте эту ветку комментариев сначала.

                    • 0
                      А почему бы не использовать личные сертификаты, хранящиеся на токенах/смарткартах PKCS#11?
                      • 0

                        Если разрешать любые сертификаты — пропадает смысл регистрации как ограничителя нехороших личностей.


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

                      • 0
                        1. Для многих сервисов обязательные удостоверенные государством или каким-то сторонним ЦА сертификаты пользователей с их личными данными приведут к потере аудитории как по причине замороченности получения и использования, так и по причине потери даже иллюзии анонимности. Это не касаясь проблем совместимости и не символической стоимости.


                        2. Утрата ключа (допустим без рисков компрометации) приводит к длительной невозможностью пользоваться любыми приватными сервисами.
                        • 0
                          Утрата ключа (допустим без рисков компрометации) приводит к длительной невозможностью пользоваться любыми приватными сервисами.


                          Трудно возразить! Хотя, если хранить личный сертификат с ключевой парой в контейнере PKCS#12 в бронированной сейфе и при «Утрате ключа (без рисков компрометации)» восстанавливать на токене… Да, паранойя!
                          • 0

                            Сейф может оказаться на другой стороне земного шара в тот момент, когда утратил.

                    • +28
                      Дошли бы ваши слова до всех авторов сайтов…
                      Уже с полгода ловлю себя на мысли, что на паре параноидальных сайтов, на которые приходится заходить примерно 1 раз в месяц я чаще пользуюсь кнопкой «восстановить пароль», чем обычным входом на сайт с первого раза.
                      • +2
                        Как же бесит при этом требование «новый пароль не должен совпадать ни с одним предыдущим». Первые 4-5 раз обязательно высветиться, потом со словами «горите в аду» начинаешь придумывать действительно новый пароль.
                        • 0
                          При чем даже не стараешься запомнить — все-равно в следующий раз новый сгенерировать легче. Они б лучше одноразовый пароль на емейл высылали.
                          • –1

                            Пользуюсь сто лет уже статическими генераторами (т.е. ни запоминать ни записывать не нужно от слова вовсе).
                            Не сочтите за рекламу к примеру вот мой самописный плагин под лиса

                            • 0
                              Тоже самое, уже не делаю свой пароль, оставляю тот что пришлют, через месяц сброшу, устал заводить кучу разных паролей от всего на свете.
                            • +7
                              Розовые розы
                              — Извините, ваш пароль используется уже более 30 дней, необходимо выбрать новый!
                              — Розы.
                              — Извините, в вашем новом пароле слишком мало символов!
                              — Розовые розы.
                              — Извините, пароль должен содержать хотя бы одну цифру!
                              — 1 розовая роза.
                              — Извините, не допускается использование пробелов в пароле!
                              — 1розоваяроза.
                              — Извините, необходимо использовать, как минимум, 10 различных символов в пароле!
                              — 1гребанаярозоваяроза.
                              — Извините, необходимо использовать, как минимум, одну заглавную букву в пароле!
                              — 1ГРЕБАНАЯрозоваяроза.
                              — Извините, не допускается использовать несколько заглавных букв, следующих подряд!
                              — 1ГребанаяРозоваяРоза.
                              — Извините, пароль должен состоять более чем из 20 символов!
                              — 1ГребанаяРозоваяРозаБудетТорчатьИзТвоейЗадницыЕслиТыНе ДашьМнеДоступПрямоБлядьСейчас!
                              — Извините, но этот пароль уже занят!
                            • +2
                              Вы только что описали мой сценарий входа на Пикабу! И вот интересный момент — зачем так параноить сайту со смешными историями?
                              • 0
                                Ой, это не Пикабу, это dirty паранойей страдает)
                              • 0
                                Есть сайты, которые не позволяют установить простой пароль или даже вообще придумать свой. Там я просто всегда восстанавливаю пароль для входа.
                              • +2
                                Почему. Мне. Нельзя. Использовать. Простой. Словарный. Пароль?

                                Неплохой пароль и Вы его уже запомнили xD

                                • +5

                                  Увы, он длиннее 20 символов...

                              • 0
                                Вопрос скорее всего риторический, но если нет, то. Потому что есть куча пользователей, которые введут туда персональные данные или номер банковской карты.
                                • 0
                                  Да какие проблемы, можете вообще не использовать пароль!!!
                                • +3
                                  стоит ли считать «верно лошадь батарейка скрепка» примером
                                  Взяли бы тогда уж перевод комикса для статьи-перевода

                                  • 0
                                    Кстати, KeePass считает, что в пароле «Tr0ub4dor&3» на самом деле 63 бита энтропии. А в «correcthorsebatterystaple» — 81 бит.
                                    • 0

                                      Я думаю, в комиксе учтены факторы: "в основе нераспространенное осмысленное слово" и "четыре случайных обычных слова". А KeePass считает энтропию как-будто это бессмысленные наборы символов.

                                      • 0
                                        Злоумышленник будет подбирать по словарю, с учётом вероятности слов, начиная с паролей в одно распространённое слово («the», «he» и т.д.), затем комбинация двух распространённых слов, затем одно менее распространённое слово, и т.д. по мере уменьшения вероятности. Если игнорировать регистр, цифры и спецсимволы, то можно узнать, какое минимальное количество паролей потребуется перебрать, чтобы подобрать заданный пароль. Если грубо, то можно перемножить rank всех слов пароля: 1508*1332*5881*14189=1.68e14, или примерно 47 бит.
                                    • +20
                                      Автор живет в мире космических единорогов, где юникод поддерживается всеми устройствами и вводится в любые поля прямо из воображения.
                                      На самом деле, ввести что-то, кроме 7-битного ASCII до сих пор очень сложно на абсолютном большинстве сайтов, устройств и всего остального, и добавлять с свои пароли юникод означает практически гарантированно остаться без возможности входа на любой хоть немного нестандартной/несовременной системе.
                                      • +9

                                        Ещё хуже. Автор не представляет себе что такое юникод на самом деле и то, что в его примере получилось, что длина "символа" равна двум — это не проблема юникода, а проблема того языка программирования, которым он воспользовался. Даже если все наши устройства поддерживают юникод и мы придумали способ ввести нужный символ (ну, хоть копипастой из программы управления паролями) остаётся нехилая проблема множественности вариантов представления одинаковых юникодных глифов в отсутствие контроля со стороны пользователя за этим. Мы не знаем в каком из вариантов будет представлен один и тот же юникодный символ в том или ином браузере/устройстве/операционке и не изменится ли эта ситуация со сменой версии.

                                        • +1
                                          А еще веселее, что в некоторых системах кол-во введенных символов не всегда равно кол-ву звездочек, а в консоли Linux так и вообще звездочки не отображаются.
                                          • +1
                                            иногда это фича, специально реализованная, подсматривающий за вводом пароля не узнает количество символов!
                                            • +1
                                              Помнится, в клиенте Лотуса число крестиков в поле пароля было случайным, а для контроля рядом рисовались весёлые иероглифы:

                                              image
                                            • +1
                                              Потому что под видом кодировки зачем-то изобрели новый язык разметки, по сложности стремительно догоняющий HTML.
                                              • 0

                                                Ну, зачем изобрели — понятно. Помните времена, когда только общераспространённых кодировок кириллицы было пять штук? ;). И ещё несколько чуть более редких. А половина программ работала при этом так, словно в мире сушествует только 7-и битный ascii. На самом деле в рамках уникода предусмотрено решение всех этих проблем. Проблема, как обычно, в головах разработчиков. Как тогда считали, что все в мире тексты в 7-и битном ascii, так и сейчас считают… Да так же ничего не считают, как-то работает — херак, херак и в продакшн.

                                              • –1
                                                Мы не знаем в каком из вариантов будет представлен один и тот же юникодный символ в том или ином браузере/устройстве/операционке и не изменится ли эта ситуация со сменой версии.

                                                Та какая разница? Вы получаете просто массив байт, который сразу же отдаете в хеш-функцию. Пусть они там хоть член анси-артом рисуют. Главное, чтобы ваш сайт не мешал пользователям рисовать все, что они хотят, об этом автор и говорит. Потому что задрали сайты дибилов, которые ставят ограничение «меньше 8 символов» и обязательно большая буква. А я не хочу большую букву, я хочу 20 символов кириллицей.
                                                • +3

                                                  Так пользователь будет наезжать, что на компе под виндой он вводит "ЁЁЁЁЁЁ" и всё работает, а на айфоне то же самое не работает.

                                                • +4

                                                  Потому что сегодня глиф "й" ваша версия браузера пошлёт одной двубайтовой последовательностью и у вас будет один хэш, а завтра версия браузера сменится или апдейт операционки произойдёт и этот глиф пошлётся как "и", плюс отдельная кратка. Четыре (или больше) совершенно других байта. И ваш пароль перестанет работать. И вы обвините в этом владельца сервиса. Есть варианты с нормализацией/канонизацией, но там всё сложно и есть куча подводных граблей на которые разработчик обязательно наступит.
                                                  Почему про "й" вспомнил, недавно на медузе в некоторых браузерах на некоторых операционных системах в одной из статей кратки отделились от своих "и". Выглядело психоделично. Просто потому, что программа, в которой текст набирали, решила, что именно такой вариант представления буквы "й" будет лучшим. И она была права, так тоже можно. А то, что некоторые растеризаторы в некоторых операционках глупые...

                                                  • –1
                                                    Так нельзя. У нас есть буква Й и это никак не И с каким-то знаком (как минимум из-за того, что она согласная, а не гласная).
                                                    • +2

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

                                                      • 0
                                                        И в ворде выравнивание можно делать пробелами и табами. И новую страницу начинать при помощи пустых строк. И о от o визуально ничем не отличается. Не всё что с перьями, на двух ногах и крякает является уткой.
                                                        • +2

                                                          При чём здесь это??? Вы нажимаете на клавиатуре "й", а в файле получаете любой из допустимых способов представления этого глифа. Они все равноправны и все допустимы в рамках спецификации. И этому есть объективные причины. Программа обработки должна обрабатывать все возможные варианты приблизительно одинаковым способом (но, поскольку, тема крайне сложная, а людей, как и вы, совершенно не понимающих как там всё устроено, тоже много, ошибок хватает и будет хватать ещё долго). Давайте вы сначала хоть немного почитаете чего-нибудь на эту тему, тогда мне не придётся отвечать на вопросы не имеющие ничего общего с темой.

                                                          • 0
                                                            При том, что i украинское и i английское это две разные буквы, хотя графически ничем не отличаются. И если кто-то сделал для й представление через два раздельных знака, то это не означает что он был прав, но нам теперь придётся с этим жить. Это примерно как заменять ё на йо — звуки-то одинаковые, или на е — не маленький, должен знать где какой звук. Хотя ё вполне себе самостоятельная буква, а не е с умляутом.
                                                            Не надо мне читать, я уже это знаю, но со спецификацией не согласен.
                                                            • 0
                                                              И если кто-то сделал для й представление через два раздельных знака, то это не означает что он был прав

                                                              С чего вы взяли?


                                                              Это примерно как заменять ё на йо — звуки-то одинаковые, или на е — не маленький, должен знать где какой звук.

                                                              Вы опять какую-то ересь несёте. Какое отношение звуки имеют к глифам? Мы про глифы говорим, а про звуки. Юникод не предназначен для представления звуков.


                                                              Хотя ё вполне себе самостоятельная буква, а не е с умляутом.

                                                              Разницы нет.


                                                              Не надо мне читать, я уже это знаю

                                                              Зачем тогда то ворд с пробелами приплетаете, то звуки?


                                                              но со спецификацией не согласен

                                                              (пожимая плечами) вы просто не умеете её готовить.

                                            • +4
                                              У Yahoo запрещено иметь в пароле имя или фамилию пользователя. Т. е. когда я представился Enver O — уже не могу использовать букву О в пароле :(
                                              • +3
                                                Интересное правило…
                                                • +1
                                                  Что там про сливы данных, в т.ч. паролей у Яхи?
                                                • +1
                                                  Я тоже считаю, что ограничения, когда надо использовать одну заглавную, одну строчную, цифру и ещё какой-нибудь специальный знак — это полная чушь. Если пароль нельзя надёжно запомнить, это резко снижает безопасность, потому что твою бумашку либо текстовый файл, где этот пароль будет записан вместо головы подсмотрят или скачаются с компьютера, причём, без каких-либо проблем. Нужна большая надёжность? Двухфакторная авториазция нас спасёт, а пароль должен запоминаться, и все люди в этом плане уникальны, так что чем меньше ограничений, тем лучше, разьве что длинну надо контролировать.
                                                  • +1

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

                                                    • 0
                                                      если следовать правилу неповторения паролей, то запомнить около сотни длинных паролей (даже если легко запоминающихся по отдельности) в сочетании с сайтами и сервисами к которым они относятся, да еще и с различными логинами туда… В общем, ну его нафик.
                                                      А двухфакторная авторизация хороша дома. И очень напрягает при путешествиях по миру.
                                                      Это не говоря о том, что в принципе невероятно напрягает необходимость кому-ни-попадя давать номер своего мобильника. Потом спамеры звонят по 8 раз в сутки :(
                                                    • +6
                                                      Напомнило:

                                                      — Пароль у меня такой… мама сшила мне штаны из березовой коры
                                                      — Молодой человек, кто вас такие пароли учил делать?.. Набирать также?
                                                      — Хакер один знакомый. Да, также… Только вместо символов нижнего
                                                      подчеркивания ничего не ставьте.
                                                      — Вы ошибаетесь — пробелов в пароле быть не может.
                                                      — А пробелы и не надо — все слитно пишется.
                                                      ...
                                                      • +2

                                                        Напомнило классику:


                                                        сорок тысяч обезьян в жопу сунули банан

                                                        © Чингиз (из «Фальшивых зеркал»)

                                                        • 0
                                                          Точно, точно :) Как я мог забыть…
                                                          • 0
                                                            А мне до сих пор интересен пароль Падлы. Вроде даже конкрус устраивали на этот счёт, кто-нибудь знает чем дело кончилось? :)
                                                          • +1
                                                            А как же «гарцующие гениталии»? :)

                                                            Shocking nonsense is unlikely to be duplicated anywhere because it does not describe a matter-of-fact that could be accidentally rediscovered by anyone else and the emotional evocation makes it difficult for the creator to forget. A mild example of such shocking nonsense might be: «mollusks peck my galloping genitals» (...) Even relatively short phrases offer acceptable entropy because the far larger «alphabet» pool of word symbols that may be chosen than the 26 characters that form the Roman alphabet. Even choosing from a vocabulary of a few thousand words a five word phrase might have on the order of 58 to 60 bits of entropy

                                                            alt.security.pgp — Passphrase FAQ, Grady Ward, 2/10/1993
                                                            • 0
                                                              Неправильный пароль:
                                                              Это фраза, первая буква строчная, все остальные прописные. Пробелы значимы. В конце должна стоять точка.
                                                            • +2
                                                              [sarcasm]Ага, и на телефоне очень удобно вводить где раскладки надо переключать чтобы увидеть буквы другого языка, а количетство клавиш и соответствие может различаться.[/sarcasm]
                                                            • –2

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


                                                              Именно так будто делать для https://DebtsTracker.io

                                                              • +1

                                                                А еще лучше — вход через oauth/openid. Тот же google+...


                                                                Ну и для тех у кого нет google+ — "присылать новый пароль на email и ссылку для одноразовой авторизации"

                                                                • +1
                                                                  Пользователь будет ужасно рад набирать этот пароль на мобильном.
                                                                  А копировать пароль через clipboard на мобильном — это не есть хорошо
                                                                  • 0

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

                                                                  • +5

                                                                    Зачем вам тогда вообще пароль? Просто присылайте одноразовую ссылку при каждом логине. Например, Medium так делает.

                                                                    • 0

                                                                      Ну почему бы и нет если кому то так удобнее? Одно другому не мешает?

                                                                    • 0
                                                                      Отправлять пароли в e-mail не безопасно.
                                                                      • 0
                                                                        «просто присылайте одноразовую ссылку»
                                                                        • 0
                                                                          Почему не безопасно?
                                                                          • 0
                                                                            Потому что даже если ваш сервер использует безопасное соединение, то при пересылке адресату могут использоваться промежуточные сервера с нешифрованным протоколом, все равно что выложить его в открытый доступ. Одноразовая и короткоживущая ссылка более безопасна, но опять же не 100% в виду вышесказанного. Еще безопаснее ответ на секретный вопрос (легко забыть или взломать ч-з соц.хак) или же код через смс.
                                                                      • 0
                                                                        и таким образом у тебя всё вообще защищено единственным паролем от почты. Потерял почту — потерял вообще всё, мессенджеры, банки, социальные сети, гос. структуры…
                                                                        не, я не согласная :)
                                                                      • +5

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


                                                                        12-символьный пароль, содержащий только строчные буквы и цифры, набирать быстрее, чем традиционный 8-символьный пароль. При этом надёжность такого 12-символьного пароля все равно будет выше.


                                                                        Ну и прочий идиотизм: ограничение на максмиальную длину пароля (где-то 8 символов — это максимум), запрет на использование ASCII спецсимволов.

                                                                        • +9
                                                                          Бесят сайты, которые требуют букву, БУКВУ, с&мвол, ц1фру, но, блин, зн@к нельзя, а ещё первым символом должна быть буква. И при вводе пароля ведь никак не подсказывают какие же символы тут запрещены. И ты восстанавливаешь пароль, а при смене видишь подсказку и вспоминаешь какой же всё-таки был пароль. Но «введённый пароль совпадает с предыдущим».
                                                                          • –1
                                                                            есть каноническая форма записи:
                                                                            пользователь: пароль@ресурс
                                                                            кто-то её учитывает, а то потом внезапно окажется, что всё работает, кроме отдельного приложения чата и т.п.
                                                                            • 0
                                                                              Это не обязательно @, кто-то ещё % _? не любят. Всё зависит от степени кривизны рук разработчиков.
                                                                          • +1
                                                                            это должно происходить в рамках проверки данных после ввода, а не в соответствии с предварительно разъясненным правилом.

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

                                                                            • +2
                                                                              Только обучение общей грамотности в области безопасности спасёт пользователей. На подавляющем большинстве сайтов я использую пароль qwerty. Это те сайты, компрометация аккаунтов на которых меня вообще не волнует. Сложные пароли нужны для банкинга и сайтов которые представляют хоть какую-то ценность.
                                                                              Ещё одно забавное явление — восстановление пароля часто спасает меня на тех сайтах где в пароле было необходимо придерживаться множества правил. Вводишь новый соблюдая все парвила и, невероятно, оказывается что это и был пароль.
                                                                              • +5
                                                                                Я могу понять любые правила для паролей, кроме идиотского ограничения максимальной длины.
                                                                                Какого черта до сих пор встречается максимальная длина в 16 или 20 символов?! Они там что, в открытом виде хранятся? В массивах константной длины?
                                                                                • +4
                                                                                  Они там что, в открытом виде хранятся? В массивах константной длины?

                                                                                  Вы не поверите ...


                                                                                  Даже Яндекс хранил пароли в открытом виде. Иначе как объяснить факт, что при запросе забытого пароля от сайта на народе мне его просто прислали.

                                                                                  • +1
                                                                                    Я вот только что проверил, paypal не дает при регистрации указать пароль длинее 20 символов. Вы же не хотите сказать…
                                                                                    • –3

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

                                                                                      • 0

                                                                                        Ого. Что не так?

                                                                                        • 0

                                                                                          Нет никакого смысла так извращаться — хранить хеши в базе попросту проще.

                                                                                          • 0

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

                                                                                            • 0

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

                                                                                            • 0
                                                                                              то, что вы подменили пароль хэшем защищает ДРУГИЕ сервисы от одной единственной ситуации: у вас слили БД

                                                                                              во всех прочих случаях, такая подмена ни на что не повлияет
                                                                                              • 0

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

                                                                                                • –1
                                                                                                  При таком подходе данные авторизации гуляют внутри организации в явном виде, и их можно собирать используя уязвимости периферийных служб. Если же в БД пароль хранится явно, можно его ещё на клиенте захэшировать с уникальной для сессии солью, и слив транзитных данных ничего не даст злоумышленнику.
                                                                                        • 0
                                                                                          Только тут недавно столкнулся с этим при настройке почтовой системы.
                                                                                          Если нужна поддержка разных типов аутентификации одновременно(например CRAM_MD5 и DIGEST_MD5), то единственный выход хранить пароли в базе без шифрования. На Яндексе-то почта тоже имеется )
                                                                                          • 0

                                                                                            Почему не хранить зашифрованным? не хэшированным, а именно зашифрованным и расшифровывать когда надо?

                                                                                            • 0
                                                                                              Конечно я хеширование имел ввиду. Зашифровать-то можно поверх как-нибудь, не вопрос. Просто из почтовых программ должен быть доступ к паролю в чистом виде чтобы это работало, и перехватить его конечно можно будет, при желании.
                                                                                          • 0

                                                                                            Здесь-то как раз объяснение простое — народ не всегда принадлежал яндексу

                                                                                            • 0
                                                                                              LiveInternet до сих пор так делает. На состояние лета 2016 года ничего не изменилось. Хотя статья то аж 2011 года.
                                                                                            • 0
                                                                                              Чем длиннее пароль, тем больше ресурсов нужно, чтобы построить его хэш. При желании, можно сильно нагрузить бэкэнд, заставляя его генерировать хеши для длинных паролей.
                                                                                              • +6
                                                                                                Конечно, какой-то разумный предел сверху нужен, не надо позволять делать пароли в килобайт длиной, но 20 символов — это, все-таки, перебор. Даже отдельные слова бывают длиннее.

                                                                                                Вот, скажем, 255 символов — вполне разумный предел.
                                                                                                • 0
                                                                                                  Зависит от реализации конечно, но подозреваю, что 255 символов будут хешироваться несколько секунд. Нет возможности проверить, но это уже много.
                                                                                                  • 0
                                                                                                    golang + sha512 = 10мс (сугубо ненаучно)
                                                                                                    • 0
                                                                                                      А кол-во итераций было какое?
                                                                                                      • 0

                                                                                                        Похоже, что много… потому что 1 итерация даже в Ruby около 20 микросекунд занимает.
                                                                                                        Вот bcrypt уже гораздо медленнее, аж 70 милисекунд для 255 символов занимает.

                                                                                                    • +2
                                                                                                      У меня хэш гигабайтного файла за несколько секунд получается))
                                                                                                      • 0
                                                                                                        Речь шла о чем-то вроде bcrypt, если мы говорим о паролях. А то ведь можно и crc32 в пример поставить :)
                                                                                                        • 0
                                                                                                          md5 и sha1, но таки для файла, не для пароля.
                                                                                                  • +2
                                                                                                    У распространённых хэш-функций размер блока хэширования — 64 байта.
                                                                                                  • 0
                                                                                                    В канадском банке BMO.COM не больше 8 символов, никаких спецсимволов.
                                                                                                    • +1
                                                                                                      Скорее всего это из-за использования какого-то старого программного обеспечения. В Канаде с этим довольно плохо. (Вернее я бы сказал так, что тут работает то, что создано лет 20 назад. А зачем переделывать и тратить деньги на то, что работает?!).
                                                                                                      • 0

                                                                                                        В Беларусбанке — максимум 12 символов. Разработчики пару лет назад обещали обратить внимание, но воз и ныне там.

                                                                                                      • 0
                                                                                                        Интересно, какие ограничения на длину паролей у самих браузеров (наверняка же есть)?
                                                                                                        • 0

                                                                                                          Для браузера — пароль это обычное поле, которое надо чуть по особенному показывать пользователю. Так что очень большое.

                                                                                                      • +11
                                                                                                        В мире, может, и есть юникод и смайлики, а вот на клавиатуре — не всегда
                                                                                                      • +7
                                                                                                        Пара советов абсолютно бредовая.

                                                                                                        1. Юникод? Серьёзно? Автор слышал про понятие «standard by implementation»? Единственный вид паролей, который гарантированно поддерживается всеми системами авторизации, это ASCII — так сложилось исторически. Автору может это не нравиться и он может разглагольствовать про «двинутых американцев», но факт остаётся фактом.

                                                                                                        2. У среднестатического пользователя есть аккаунты на 15 и больше ресурсах. Типовые правила безопасности советуют иметь по 1 уникальному паролю на ресурс. И чем же 15+ паролей из скрепок и смайлов лучше, чем то же число нормальных случайных ASCII паролей скажем втрое большей длины, при том, что их запоминанием всё равно займётся скорее всего менеджер паролей?

                                                                                                        > Прикиньте, рандомный пароль может и не содержать в себе цифры или символа
                                                                                                        Прикиньте, есть генераторы рандомных паролей, от которых можно это условие явно потребовать.
                                                                                                        • 0

                                                                                                          Потребовать-то можно — но запомнить такой пароль это не сильно поможет.

                                                                                                          • 0
                                                                                                            Запоминание — уже другой вопрос. Как я уже написал, его можно решить менеджером паролей.

                                                                                                            Проблема изначально была в том, что автор говорит «рандомный пароль может не содержать цифры». Ну и чо дальше?)) Автору как будто лень сгенерировать пароль ещё несколько раз до достижения нужного результата (вряд ли многие генераторы паролей создадут пароль без цифр много раз подряд) или использовать/написать другой генератор паролей, который гарантирует наличие нужных ему символов в пароле.
                                                                                                          • –1

                                                                                                            Менеджер паролей это плохо — нужно как минимум дополнительно думать над бекапом, над защитой от утечки данных менеджера.

                                                                                                            • 0

                                                                                                              Лучше забыть пароль, ага

                                                                                                              • +1
                                                                                                                Лучше его забыть, чем отдать, очевидно.
                                                                                                              • 0

                                                                                                                Если вы думаете о безопасности, то вы и так делаете бэкап данных и защищаете их безопасность.

                                                                                                                • 0
                                                                                                                  Большинство пользователей ни о чём таком не думают и не хотят думать.
                                                                                                                  • +1
                                                                                                                    Значит их не волнует безопасность и «дополнительно думать над бекапом, над защитой от утечки данных менеджера» они не будут.
                                                                                                                  • 0

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

                                                                                                              • +2
                                                                                                                Я для себя решил эту проблему раз и навсегда:

                                                                                                                1. Генерирую случайный пароль каким-нибудь pwgen
                                                                                                                2. Сохраняю его в Keepass
                                                                                                                3. Всегда копирую его с Keepass