Зачем, почему и как устроены пароли на сайтах?

но не должно быть киррилических символов

Кодировкопроблемы могут опечалить пользователя.

Кодировкопроблемы могут опечалить пользователя.

А можно поподробнее? Если у меня похапэ снял строку с формы, то она вроде должна быть UTF-8? Разве она может меняться например от кодировки в системе посетителя?

Кириллицу запрещают чтоб с кодировками не водиться наверно.

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

Я на своих сайтиках ставлю ограничение на мин-макс количества символов в пароле. И разрешаю вводить всё что можно ввести с клавиатуры

Сделай лучше автогенерацию.

Жаль что анонимусы не могут постить в толкс =)

Кодировкопроблемы могут опечалить пользователя.

А можно поподробнее? Если у меня похапэ снял строку с формы, то она вроде должна быть UTF-8? Разве она может меняться например от кодировки в системе посетителя?

С чего бы? Она может быть еще в CP1251 или KOI8-R.

Ну даже если не брать случай, когда у тебя виндовый сервер или какой-нибудь линуксовый, но не утфный (а таких встречается по хостингам еще как). Что делать, если тебе туда китайских иероглифов нафигачат, которых нету в UTF? Может до ошибок с БД довести и если на какой-нибудь таблице «комментарии к новостям» это не особо важно, то засветить злоумышленнику структуру users - уже существенно опаснее.

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

Только счас подумал, что мелочь я обычно делал или на Wordpress или на Joomla. А свои поделия хостятся на vps или облаках, где сам себе хозяин. Там текущие версии всякого нужного софта.

В общем они это делают только из соображений обратной совместимости.

Спецсимволы требуют чтоб криптостойкость повысить

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

Сделай лучше автогенерацию.

Зачем сказал? :) Теперь сижу думаю о целесообразности.

＞Что делать, если тебе туда китайских иероглифов нафигачат, которых нету в UTF?

Шо?

Что делать, если тебе туда китайских иероглифов нафигачат, которых нету в UTF? Может до ошибок с БД довести

Кстати интересное наблюдение. Оказывается ZF не поддерживает китайский, корейский и японский. Например не будут работать валидаторы для web-форм. Причиной указано, что часть иероглифов в кодировке UTF-8 может быть представлена кодами двух символов.

А для пароля мне кажется это и не важно, хранить то все равно хэш.

Кодировкопроблемы могут опечалить пользователя.

всегда храню только соленый md5 от пароля. ЧЯДНТ?

Важно не то, что ты хранишь, а то, что другой браузер может передать строку чуть по-другому.

со всем зоопарком браузеров пока ни разу не натыкался на такое.

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

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

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

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

Прошу прощения, видимо мой камент был принят лично. Никоим образом не хотел этого :)

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

многие горе-погромисты не умеют/не хотят делать БД в юникоде. Если же засунуть UTF-8 пароль в поле с 8-битной латиницей, а потом прочитать для сравнения - будет кака. И да, хеш для слабаков

lastpass решает. и не надо помнить о паролях, вообще.

Как минимум желательно придумывать разные пароли к каждому ненужному сайтику.

хм, но зачем? есть же генераторы

не может. как он передаст строку по-другому?

В IT только латиница, запомни уже. За кириллические домены/ники/пароли/etc убивать надо.
Ну а про маленькие-большие буквы-цифры - это, конечно, банальная паранойя.

если передавать запросы в POST, то кодировка должна приходить одинаковая

Причиной указано, что часть иероглифов в кодировке UTF-8 может быть представлена кодами двух символов.

какой мрак. Я за бан.

За кириллические домены/ники/пароли/etc убивать надо.

Хм. Но почему такая нетерпимость к кириллическим никам (логинам)? У меня как раз задача их использовать...

Кодировкопроблемы могут опечалить пользователя.

Ещё больше он опечалится, если когда-то придётся логиниться с некириллизованной машины.

почему такая нетерпимость к кириллическим никам (логинам)?

Потому что совместимости 0.0%.

Потому что совместимости 0.0%.

Совместимости с чем? Уточни пожалуйста.
Со старыми версиями PHP, MySQL, etc? Чтобы можно было гибко подбирать хостинг? Или есть еще какие сакральные несовместимости?

Совместимости с чем?

Решит кто-нибудь кодировку поменять - и кирдык вашей базе паролей. Плюс одну и ту же библиотеку нельзя будет использовать на разных компьютерах.

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

Как понять «кодировка в PHP», вобще то в PHP строки - последовательность байт. Другое дело что есть ф-ции с поддержкой UTF-8. Про «Что делать, если тебе туда китайских иероглифов нафигачат, которых нету в UTF?» - это LOL. Такого не может быть т.к. в любом случае что получит приложение - поток байт который в конце концов можно разложить по ASCII.

Автор, делай не бойся. Только не забывай всегда указывать кодировку на страницах с формами. Т.к. к примеру в UTF-8 и какой нить KOI8 один и тот же символ может быть представлен разными байтами. Проблема эта относится к client-side, с современными браузерами при установке правильной кодировки HTML документа проблем быть не должно.

не может. как он передаст строку по-другому?

Ну, применение Юникодка способно даже в современном софте устроить полет крокодилов. Иногда совершенно ВНЕЗАПНО софт не поддерживает символов выше BMP, или не проверяет codepoints, нет ли среди них недопустимых кодов. Или у пользователя могут быть проблемы: браузер может в этот пароль вставить контрольные символы какие-нибудь, или у пользователя на разных машинах строки, выглядящие внешне одинаково, могут записываться разными кодами (т.е. разными codepoints). Особенно если речь идет о языках программирования, в которых Юникод вообще прикручен сбоку.

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

но не должно быть киррилических символов

Пережитки прошлого века.

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

Да и вообще с каждым годом всё больше и больше нормальных сайтов разрешают кириллицу. Главное что сайты не русские. Это больше всего радует.

А на русских сайтах это должно быть доступно по дефолту но у нас 80% разработчиков тупые копипастеры и ничего своего не способны запилить.

какая вообще разница какие символы в пароле? причём тут кодировка бд?
он принимается php скриптом и кодируется в какой нибудь md5, и в базу он идёт в виде английских символов и цифр.
а пхп скрипту он будет передан в той кодировки в которой и вся страница.
мета теги указать достаточно.

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

какая вообще разница какие символы в пароле?

В случае использования Unicode/UTF разница может быть существенной.

Например, в зависимости от способа нормализации строк буква ё может быть передана как D1 91 (классическая буква ё в один символ), так и как D0 B5 CC 88 (буква е плюс диакритика сверху). Для русского языка это может быть не сильно актуально (всего-то ё и й), а для всяких там деванагари очень даже.

и какие последствия от этого?
-человек набирает пароль хоть с иероглифами
-пароль передаётся пхп скрипту в том же виде в котором его набрали
-пхп шифрует его в md5 и сохраняет в базе данных
при следующих логинах
-пользователь набирает пароль точно также как и в первый раз
-передает его скрипту в таком же виде как и первый раз
-пхп шифрует его в мд5 и получается хеш такой же как и в первый раз
-сравнивает его с хешем из бд

на каком этапе может возникнуть ошибка?

Или буква й: в Windows это будет U+0419 (CYRILLIC CAPITAL LETTER SHORT I), а на Маке — U+0418 (CYRILLIC CAPITAL LETTER I) + COMBINING BREVE (U+0306).

Если на одной и той же машине, в одном и том же браузере — без проблем. Если сегодня на Винде, завтра на Маке, послезавтра ещё где-нибудь — хэш может не сойтись (пример с буквой й на пост выше).

Чтобы в PHP всё работало примерно одинаково, нужно все данные пропускать через Normalizer::normalize() и договориться о способе нормализации (например, если есть API для интеграции с другими сервисами).

А на практике я видел очень мало кода, использующего Normalizer::normalize() (то ли разработчики не знают, то ли им пофиг).

разные браузеры или операционки могут по разному печатать букву ё? не ужели в UTF-8 нету каких то стандартов на такой случай?

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

Normalizer::normalize()

ну вот решение то есть.

KRoN73

Ещё больше он опечалится, если когда-то придётся логиниться с некириллизованной машины.

Это уже проблемы этого чудо-пользователя.

А на практике я видел очень мало кода, использующего Normalizer::normalize() (то ли разработчики не знают, то ли им пофиг).

Вот спасибо! Уже имел дело с PECL Intl. Устанавливал на хостинг для MediaWiki. Надо потестить с именами (логинами), но еще проблема найти всякие экзотические системы и браузеры...

Почему на некоторых сайтах при регистрации надо придумать пароль где ... не должно быть киррилических символов?

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

Это уже проблемы этого чудо-пользователя.

Довольно распространённое явление на самом деле.

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

Считать пользователя криворуким быдлом это идеология майкрософт

Это объективная реальность. 99.9% пользователей принадлежит именно к этой категории.

Согласен) но ограничивать пользователей в выборе, основываясь на этом, считаю не правильно.