Почему часто запрещен юникод в паролях?

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

Версий Unicode много.

Потому что ascii прост и однобайтов. А юникод может быть с bom / без bom, в одной из трех разных вариаций канонизации и так далее.

Намного более глупый запрет: ограничение длины пароля 15-20 символами.

Беда начинается уже там, что глиф 'ä' можно записать и как \u00e4 но и как \u0061\u0308 и ещё несколькими способами.

Беда начинается уже там, что глиф 'ä' можно записать и как \u00e4 но и как \u0061\u0308 и ещё несколькими способами.

Для сравнения так и так положено нормализовывать.

Zero-width characters?

Зачем нужен юникод если в действительно важных местах надо использовать ключи, а в остальных можно просто pwgen 20 1?

Для сравнения так и так положено нормализовывать.

Но в базу-то должен будет уйти хэш.

Ну и я вот думаю. Пароль из Emoji — это было бы круто 😁 и легко запомнить

Вот есть у тебя пароль легкий и удобный для запоминания «английскими буквами глядя на русские». И надо тебе его ввести с убогой стандартной клавиатуры телефона, например...

А с юникодом задница будет еще глубже.

А ключи это супер-надежно, да?

с убогой стандартной клавиатуры телефона

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

Для сравнения так и так положено нормализовывать.

В какую форму? Их несколько.

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

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

Так в чем проблема?

ни в чём, я разрешаю, в том, где я приложил руку, ограничивается только минимальная длинна.

Я бы вообще разрешал только base64 или даже base16. Потому что юникод неправильно задизайнен (написали выше) и это уже не исправить.

Запрещают в основном те сайты, которые работают не на utf8 например.

1) Большинство людей печатает пароли на клавиатуре. Набирать всякие редкие символы юникода с клавиатуры - такое себе удовольствие.

2) Один и тот же символ может быть представлен кучей способов (в том числе в зависимости от того, с помощью чего он был введён).

Но в базу-то должен будет уйти хэш.

Значит надо перед хэшированием нормализовать. Как в своё время TCP/IP стек от MS все пароли приводил к верхнему регистру. Да, пароль легче подбирать. Зато предотвращает разночтения.

В какую форму? Их несколько.

Главное, чтобы единообразно. Сайт unicode.org рекомендует для внутреннего представления NFD или NFKD. NFKD длиннее, значит по хешу сложнее восстановить.

Главное, чтобы единообразно. Сайт unicode.org рекомендует для внутреннего представления NFD или NFKD. NFKD длиннее, значит по хешу сложнее восстановить.

Ну вот поэтому никто и не заморачивается :)

Почему?

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

Вот да, зашел чтобы оставить этот комментарий. Но я видел ограничение еще круче: 12 символов, из которых разрешены только маленькие буквы и цифры.

NFC или NFD, как тебе удобнее.

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

очень удобно использовать юникод

Все удобство ХРЮНИКОДА и всяких знаков пунктуации в паролях хорошо понимаешь после того, как приходится набирать такой пароль на телефоне. Теперь только латиница и цифры.

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

Вот банально сдохнет у меня комп (например соседи сверху затопят, или коты кусок штукатурки на него уронят, или я буду на каком-нибудь Бали верхом на шлюхе), и мне вдруг срочняк-срочняк понадобится зайти на условно панель управления условнохостинга чтобы оплатить, или еще чего. А уменя, как привел в пример @Im_not_a_robot, под рукой только телефон. Все, приплыли.

Нафиг-нафиг. Я считаю что длинного пароля из ASCII символов достаточно. Хочешь секъюрности - делай длиннее, ибо размер имеет значение.

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

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

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

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

Я считаю что длинного пароля из ASCII символов достаточно. Хочешь секъюрности - делай длиннее, ибо размер имеет значение.

я тоже так считаю, и 99.999999% пользователей тоже, вот только зачем усложнять систему ради 0.0000001% ?

Более интересны другие цифры. Например:

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

Соотношение количества пользователей, знающих, что юникод в паролях разрешён, к количеству пользователей, знающих слово «юникод».

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

Ну, и так далее.

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

Никогда такого не видел. Соглашусь — это пиздец.

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

не в курсе, не знаю паролей пользователей

Соотношение количества пользователей, знающих, что юникод в паролях разрешён, к количеству пользователей, знающих слово «юникод».

из-за п1 не могу сказать

п2 не связан напрямую с п1

пароль - это просто последовательность байт. какая баня, что там? он вообще может быть бинарным, строго говоря.

ограничения накладывает только способ ввода этого самого пароля.

введите первую, вторую и пятую букву вашего пароля

это где такой маразм?

Всё может, только вот зависит от способа ввода.

если клиент поддерживает юникод, то серверу должно быть по барабану.

это где такой маразм?

Знать бы где его нет... Lloyds, FirstDirect, Halifax, Barclays, TescoBank, у Amexов наверное только логин и пароль нормальные.

а они про брутфорс не слышали?

впрочем, в банках редкостный заповедник странных технологий. все эти коды из трёх цифр...

Юникод — он не униформен. Для одного и того же глифа могут быть несколько предствалений на байтовом уровне. Т.е. в зависимости от, у тебя могут быть разные представления одного и тогоже символа. Ergo и «пароли» у тебя будут разные, хоть и выглядят одинаково.

http://unicode.org/faq/char_combmark.html

это ты мне рассказываешь? я какбэ 20 с гаком лет программирую. я в курсе. и про все особенности тоже.

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

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

если у тебя клиент юникодовый и ты можешь её повторить

Вот верность этого утверждения вызывает у меня сомнения.

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

Вот верность этого утверждения вызывает у меня сомнения.

и какие же это «сомнения»? ввод данных - текст, на выходе N байт.

Я не зря привёл ссылку. Вот ещё на затравку: https://en.wikipedia.org/wiki/Unicode_equivalence

TL;DR: эквивалентные символы уникода совсем не эквивалентны на байтовом уровне. И в зависимости от разных нормализация могут быть совсем разные. Поэтому это таки больше интрепретация, а не только просто последовательность байт.

От восьми до двенадцати, обязательно цифра и буква в верхнем регистре. Онлайн-банкинг

Просто шикарно, лол.

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

Но я видел ограничение еще круче: 12 символов, из которых разрешены только маленькие буквы и цифры.

А ровно 8 цифр не хочешь? Да, один банк правда еще совсем недавно так делал.