в пароле нельзя использовать кириллицу
Комбинация цифр строчных и заглавных. Прописная буква в пароле и другие секреты надежной защиты
Сайт gosuslugi.ru – один из самых популярных в России порталов, позволяющих получить от государства различные формы услуг. Здесь вы можете проверить свою задолженность по налогам, оплатить штрафы ГИБДД, получить справку об отсутствии судимости и многое другое. Но, как это часто бывает, многие государственные сервисы сделаны и работают кое-как. Это же и относится к порталу Gosuslugi, регистрация на котором может превратиться в захватывающий квест на проверку терпения, силы воли и стрессоустойчивости пользователя. Ниже мы разберём, как зарегистрироваться на сайте, как подобрать прописные и строчные латинские буквы для создания пароля на портале Госуслуг. Также рассмотрим, какие негласные секреты подбора password существуют на данном сайте.
Порядок регистрации на сайте Госуслуг
Как известно, регистрация на государственном портале услуг gosuslugi.ru происходит в три основных этапа:
Поля ввода при регистрации в Госуслугах
И если с первым шагом обычно не возникает никаких проблем (подтверждающая смс приходит вовремя), то с подбором пароля у многих пользователей возникает масса проблем.
Читайте также: Дневник.ру через Госуслуги.
Базовые требования для подбора пароля для сайта Gosuslugi.ru
После прохождения первого шага пользователь переходит на экран подбора пароля для входа на портал. Шифр должен соответствовать следующим требованиям:
При подборе password необходимо учитывать все перечисленные требования. Выполненное требование будет окрашиваться в зелёный цвет в перечне справа, невыполненные будут отмечены красным. Когда все пункты будут окрашены зелёным, ваш пароль получит статус «Надёжный пароль», вы сможете пользоваться им для работы на Госуслугах.
Убедитесь, что пароль соответствует всем заявленным требованиям
Пример пароля для Gosuslugi.ru может быть таковым:
Выберите «Сгенерировать пароль» для генерации пароля в системе
Это может быть полезным: Как поменять пароль в ВК.
Проблемы с вводом пароля из строчных и прописных латинских букв
Пользователь начинает и так и этак вводить свой пароль, менять его структуру, даже генерировать шифр в системе и вводить его на сайте – ничего не помогает. Некоторые пытаются ввести заданную комбинацию на протяжении нескольких суток, терпят неудачу, после чего бросают бесплодные попытки регистрации на сайте.
Итак, что же делать в данной ситуации? Разберём лайфхаки регистрации на портале Госуслуг:
Каждый из подобных приёмов доказал свою эффективность, потому можете смело использовать их при подборе кода для сайта Госуслуг.
Заключение
Подбор password всегда должен соответствовать перечисленному ряду требований, одним из которых являются прописные и строчные латинские буквы для создания корректного пароля для портала Госуслуги. При этом рекомендуется вводить каждый символ для лично, а также в конце нажать на Enter – это позволит благополучно создать шифр для использования на портале.
На самом деле все просто. Строчными буквами называют те буквы, которые написаны в нижнем регистре. Иными словами, это маленькие буквы: a, b, c, d, e и т.д.
Прописными называют те буквы, которые написаны в верхнем регистре, то есть заглавные буквы: A, B, C, D, E и т.д.
Если со строчными буквами все понятно, то как быть с прописными? Покажем пример на клавиатуре iPhone. Если вам нужна одна прописная буква, нажмите на клавишу с изображением стрелки один раз и выберите нужную букву, она будет написана в верхнем регистре, дальнейшие буквы — в нижнем.
Если же вам нужно написать несколько прописных букв, нажмите на стрелку два раза, тогда все буквы будут прописными. Для отключения функции нажмите на стрелку еще раз.
А как быть с компьютерной клавиатурой? Для написания прописной буквы нужно нажать на клавишу Shift. Вот она:
Для написания нескольких прописных буквы вы можете нажать клавишу Caps Lock — в этом случае все буквы будут написаны в верхнем регистре, либо удерживайте клавишу Shift.
Советы по созданию пароля
Несколько советов по созданию пароля. Они простые, но придерживаться их стоит, чтобы никто не смог узнать ваши данные.
Строчные и прописные буквы
Строчными буквами в айфоне называют буквы, написанные в нижнем регистре, т.е. маленькие буквы. Например, следующие буквы – строчные, написаны в нижнем регистре: a, b, c.
Прописными буквами называются буквы, написанные в верхнем регистре, т.е. заглавные, большие буквы. Например, следующие буквы – прописные, написаны в верхнем регистре: A, B, C.
Надеюсь, вы поняли, что значат строчные и прописные буквы при создании пароля для вашего мобильного iOS гаджета, будь то айфон или айпад.
Как включить прописные буквы
Для того чтобы включить написание прописных букв, вам нужно выполнить следующее:
Ниже, я дам несколько рекомендаций для того, чтобы придумать максимально безопасный пароль, а также как с помощью пароля обезопасить ваш аккаунт.
Советы
От надежности и качества придуманного вами пароля, напрямую зависит безопасность вашего Apple аккаунта. Я думаю не стоит напоминать насколько это важно, т.е. к вашему Apple аккаунту привязывается кредитная карта, а ее безопасность превыше всего. Так что уделяйте максимальное внимание безопасности и надёжности пароля. Выполняйте следующие рекомендации:
На этом у меня все, если остались, какие либо вопросы относительно сегодняшнего материала, то вы можете задать их в комментариях к этой записи. До встречи в следующих статьях.
Советы, какой сделать хороший пароль с прописными и строчными буквами
Пароль, как секретное слово для идентификации свой-чужой, появилось еще в Древнем Риме. Вначале это было просто слово, которое обозначало, например название города. В таком виде пароль до сих пор используется в войсках, когда при смене караула новый начальник караула называет секретное слово, свидетельствующее о том, что он действительно тот, кто будет руководить охраной объектов в течении следующих суток.
Подобный пароль не сложно даже угадать, но вся фишка в том, что устанавливается он всего на сутки, и по истечении этого времени теряет свою силу.
В современном виртуальном пространстве пароль устанавливается на длительное, исчисляемое годами время, а то и остается неизменным постоянно. Однако для того, чтобы составить пароль один раз на всю жизнь, нужно иметь определенные знания, как это сделать, проявить смекалку и, конечно же, не предаваться мысленной лености.
Чтобы понимать, что нужно и чего нельзя, вначале о том, что не следует делать. Сразу один интересный факт, позаимствованный на одном из сайтов, где приводились самые глупые пароли. Первое место заняла комбинация цифр 11111. Есть еще abcdefg, или Samsung, или (верх изощренности) knopka123. Смешно? Наверное, да.
Грустно будет, если такой незамысловатый набор разгадает хакер (а подобное доступно даже неопытному новичку) и взломает электронную почту или, что еще печальнее, проникнет в банк онлайн и похитит имеющиеся там сбережения. Поэтому пароль должен быть надежным – и это основополагающее требование.
Принципы надежности почти всегда определяет созданный с этой целью робот сайта. Происходит это следующим образом: вы придумываете пароль, который изначально, скажем, должен состоять из не менее, чем 8 знаков с использованием латинских букв, цифр, знаков препинания, других знаков и символов, имеющихся на клавиатуре компьютера.
Если робот доволен вашей абракадаброй (а хороший пароль иначе не назовешь), ниже появляется зеленая полоска, свидетельствующая, что пароль надежный. Если пароль не очень надежный строчка будет окрашена в желтый или коричневый цвет. Это предупреждение: пароль неплохой, но до совершенства не дотягивает.
Теперь о том, какие буквы и в каком виде должны обязательно быть в пароле. Если в поисковой строке на экране компьютера или при написании электронного адреса вы используете прописные (заглавные, большие) или строчные (маленькие) буквы английского или русского алфавита, то робот между ними различия не делает и воспринимает как абсолютно одинаковые.
В пароле строчная и прописная буква, причем только английские, – совершенно разные символы. Перепутать их – значит неправильно указать пароль. Обратите внимание: при наборе заглавных букв, особенно если их несколько подряд, обычно включают клавишу Caps Lock.
Как только вы нажимаете на эту клавишу, рядом со строкой набора пароля появляется окошко с надписью «Включена Caps Lock». Тем самым робот предупреждает, что вы вводите прописные буквы.
Чтобы пароль был надежным, в нем необходимо использовать следующие элементы: прописные и строчные английские буквы, цифры, знаки препинания, символы. Чем «уродливей» смотрится ваше секретное слово, тем оно надежней. О плохих и смешных (если не сказать, грустных) паролях уже было сказано.
Теперь о паролях не очень хороших. Вот пример такого неказистого пароля: SMND3190. Слабость такого набора в том, что использованы только прописные буквы, нет строчных, нет символов. К тому же буквы и цифры идут подряд, не чередуясь.
А так выглядит отличный пароль с соблюдением всех правил и норм составления, в котором автор не нарушил ни единого требования, предъявляемого системой. Посмотрите на это сочетание букв, цифр и знаков – разница очевидна: @jT9w%5lnR4?.
Особенности этого пароля в том, что есть прописные и строчные буквы, они идут вразброс, то есть бессистемно. Цифры так же бессистемно чередуются с буквами и символами. Из четырех символов три набраны с использованием клавиши Shift.
Такой пароль по-настоящему сложный и его крайне тяжело запомнить. В отличие, например, от такого “mYlOve4yOu!. С виду этот набор цифр и букв ничего не значит, но если прочитать внимательно, то получится следующая фраза My love for you. Кавычки вначале и восклицательный знак в конце придают ей даже высокий эмоциональный смысл. Красиво, ничего не скажешь.
Возможно, надежность тоже присутствует, но все-таки ее степень не очень высока. Поэтому, и так советуют специалисты, пусть ваш пароль будет казаться галиматьей из букв и символов, зато взломать его вряд ли кто сможет.
Что значит прописная и строчная буквы в пароле айфона?
Все мы знаем, что у Apple безопасность всегда была на первом месте. Это начинаешь видеть сразу, как покупаешь любое их устройство и начинаешь создавать Apple ID. 
Казалось, все данные заполнил правильно, но когда дело доходит до пароля, то не хочет пропускать не в какую и требует прописные буквы. В принципе такую ситуацию можно встретить не только в этой системе, много где сейчас могут потребовать от вас в пароле такой тип букв. В целом, ничего сложно особо нету. Ваша ошибка заключается в том, что вы пишите пароль только из строчных букв и возможно добавляете цифры. Итак, примером строчных букв являются «абвгд», в то время как прописные — это «АБВГД». Это значит, что в вашем пароле должны встречаться большие буквы.
Как писать строчными и прописными буквами на айфоне?
С половиной вопроса разобрались и теперь давайте расскажу, как именно ставить на айфоне или айпаде тот или иной тип букв. По умолчанию вы обычно набираете текст строчными буквами. Чтобы поставить одну прописную букву, вам нужно нажать кнопку в виде стрелочки вверх. Она находится слева. 
Если вам нужно писать только прописными буквами, то два раза подряд нажимаем на эту клавишу и появляться закрашенная стрелочка с палочкой внизу. 
Точно также этот режим отключается и вы снова сможете нормально печатать текст. Это по сути тоже самое, если бы вы нажали CAPS LOCK на компьютерной клавиатуре. Пользоваться клавиатурой на любом гаджете от Apple достаточно удобно. Со временем вы удивитесь, насколько быстро вы умеете печатать на мобильном устройстве.
Как исключить ввод кириллицы, спецсимволов и пробелов?
Есть ТЗ:
Валидация пароля.
Пароль может содержать только буквы латинского алфавита (любого регистра) и цифры. Не может содержать кириллицу, спецсимволы и пробелы.
Но проблема в том что qweFrty123 йцу # тоже пройдет валидацию
Какой должен быть паттерн/набор для выражения что полностью исключить кириллицу, спецсимволы и пробелы?
[a-zA-Z0-9]+
Но у вас плохие требования к паролю.
Они выдают непрофессионализм разработчиков, которые внедряют такие требования.
Это признак того, что пароль лежит в открытом (не хешированном) виде в БД.
Это провоцирует делать слабые пароли.
Это выглядит как поделка студентов.
Если и вводить ограничения, то минимальные:
— пароль должен быть не пустым. Всё.
Однако следует делать предупреждения если:
— пароль содержит кириллицу, или любые символы, которые сложно набрать на любой произвольной клавиатуре. Большая проблема пароль с юникод-символами, если вы хотите ввести его на смартфоне. Большая проблема с кириллицей, если вы хотите войти с компа в турции в отпуске, потеряв, к примеру, телефон.
— пароль слишком короткий;
— хеш пароля находится в списке наиболее распространённых паролей;
— пароль выглядит как набранный с инвертированным капс-локом.
Эти предупреждения должны быть заметны, но не должны запрещать создать такой пароль. Обсуждать можно только то, что касается списка самых распространённых паролей, скажем тысячи самых популярных. Ну и короткие (меньше 6 знаков).
Пароль следует хешировать с только что сгенерированной солью. Хранить соль нужно рядом с хешем. Также рядом можно указать название алгоритма хеширования. Прямо в одной строке. Это не снизит безопасность, зато избавит вас от проблем связанных с переходом на новые алгортимы хеширования.
как вы сделали на основании регулярки, что пароли хранятся в открытом виде?
DevMan, я выводов не делал, я просто сказал, что это признак.
Часто встречаются люди, которые накладывают на ввод пользователя очень странные требования потому что не умеют правильно экранировать строки. В случае пароля это еще и признак хранения пароля не в виде хеша.
Однажды я видел в продакшне даже хранение «зашифрованных», в base64(!), ага, паролей. И нет, там не хеши были в base64? а именно что пароли. На мой непрошенный аудит и WTF горе-разработчики мне заявили, что пароли, же зашифрованные, глазами текст паролей не виден, значит всё хорошо.
А чем у вас обусловлены такие странные требования к паролю? Просто интересно. Видимо я ошибся, да и признаки эти не стопроцентные. Поделитесь в общих чертах куда так ограничивают пароли.
чем у вас обусловлены такие странные требования к паролю?
не у меня, а у автора вопроса.
DevMan, о, простите. Я перепутал вас с топикстартером. Мельком глянул.
Ок. Для вас я перефразирую вопрос: чем бы, по-вашему, могли быть вероятно обусловлены такие требования к составу пароля.
Итак, что бы вы сочли вероятной причиной таких требований? Просто интересно. Это всего лишь невинные гипотезы и оценочные суждения. Тут нет правых и ошибающихся.
Сергей Паньков, у меня вообще нет привычки гадать. поэтому вопрос нужно адресовать автору.
а вообще: использование различных раскладок (или одной, но отличной от латиницы) приносит больше неудобств, чем профита.
DevMan, о, тогда вы, очевидно ещё больше чем я раздражаетесь от постановки большинства вопросов на этом ресурсе.
а вообще: использование различных раскладок (или одной, но отличной от латиницы) приносит больше неудобств, чем профита.
Проблемы проблемами, но это проблемы пользователя, а не ресурса.
Если вдруг это проблемы ресурса, значит что-то там в архитектуре не так: или с экранированием беда, или пароли не хешированы, или хеш-алгоритм кустарный, или у проджект-менеджера устаревшие взгляды на безопасность. В конце концов при нормально построенном процессе пароль несложно и сменить.
Сергей Паньков, проблема как раз для юзера – когда нужно пользоваться устройством, где внезапно нет национальной раскладки.
избегать подобного – такое же простое правило как избегать национальных символов и пробелов в путях.
но вывод, что запрет кириллицы признак хранения пароля в открытом виде, так и остался мной не понятым.
требование к паролю: наличие маленьких букв, больших и цифр, ну и длина минимум 8 символов, вполне логичное требование
НЕТ! Ну в смысле если это делать тупо обязательными условиями.
Смотрите: скажем я везде делаю очень длинные пароли по методу XKCD, за счет длины и вариативности их энтропии хватает, чтобы не баловаться регистром, цифрами и спец-символами. Ваш ресурс заставит пользователя запоминать ещё и какие именно буквы он сделал заглавными, чтобы удовлетворить дебильное обязательное требование. Я не против требования к уровню энтропии пароля. Я против тупых требований, которые мешают жить.
чтобы усложнить получение пароля путем банального перебора
Можно ввести квоту на число попыток ввода неправильного пароля. Эту квоту нужно вводить с умом, например за счет прогрессивного роста таймаута, после которого возможна следующая серия попыток. Легко оценить среднее время подбора пароля брутфорсом с учетом прогрессивных таймаутов и достаточно держать это время на уровне нерентабельности подбора. Разница между действиями пользователя и целесообразно написанного брутфорса не может быть четкой. Если ваши меры борьбы с брутфорсом тупы и однозначны, то злоумышленнику легко под них подстроиться и держаться за один шаг до блокировки.
Парадоксально, но требования к формату пароля зачастую лишь упрощают его брутфорс.
проблема как раз для юзера – когда нужно пользоваться устройством, где внезапно нет национальной раскладки.
избегать подобного – такое же простое правило как избегать национальных символов и пробелов в путях
Это ваше личное правило. У меня есть знакомая бабушка,которая активно пользуется соц-сетями. Ей вообще никогда не нужна латиница, она не техно-гик и никогда не заходит в свои соц-сети со смартфона или другого компьютера в Турции. У неё всегда по умолчанию кириллица и есть пантосвитчер, чтобы не приходилось перенабирать одним пальцем сообщение при ошибке в раскладке. Она вообще не понимает различий между «О, «O» и «0». А вы со своими пережитками проблем зари компьютеризации в голове сочиняете ей дикие (для нее) требования к паролю.
но вывод, что запрет кириллицы признак хранения пароля в открытом виде, так и остался мной не понятым.
Я повторно апеллирую к вашей логике и внимательности. Повторно обращаю внимание, что выводов не делал, лишь отметил признак свидетельствующий в пользу одной из вероятных причин.
Мой ход рассуждений таков: те дилетанты, которые хранят пароли в открытом виде, с большой долей вероятности собирают SQL-запросы методом конкатенации строк и, весьма вероятно, вообще не умеют правильно их экранировать. Чтобы залётная кавычка, пробел или килобайтный текст в поле не поломали им сервер, они выкатывают тупые требования в том числе и к паролям.
А может быть эти грамотные ребята не умеют нормально работать с кодировками и под виндой, а то и где угодно у них постоянно возникают «загадочные» проблемы с конвертацией не ascii символов для сохранения в файл. Такие дятлы могут неправильно настроить систему логирования и в придачу писать пароль в логи тоже в открытом виде. Даже если они потом посолят и захешируют пароль, в дебаг-логах он вполне может осесть и утечь. Сколько раз такое было? Как по-вашему текут пароли на разных сайтах?
Зачем вообще может кому-то прийти в голову запретить пробелы в пароле? А зачем запрещать минусы и подчеркивания?
Я могу придумать и другие причины: про контроллеры IoT я упоминал, но допустим у них секьюрное приложение с собственной программной экранной клавиатурой, где есть только такие символы. Но как вы оцениваете, что более вероятно? Задавали бы ребята из команды разработчиков такого приложения такой тупой и нубский вопрос по поводу тривиального регекспа? А вот «специалистов» не хеширующих пароли (ага, временно, до релиза, хотя бы) я встречал лично, на серьёзных щах утверждавших мне, что это не проблема. Вот так я делаю предположения. Читайте внимательнее.
Почему часто запрещен юникод в паролях?
Мне кажется было-бы очень удобно использовать юникод. Начиная с кириллицы и заканчивая смайликами. Запоминать вроде легко, перебирать сложно.
Так в чем проблема?
Т.е. делать процедуру аутентификации зависимой от того устройства и программы через которое ты логинишься (в частности от степени поддержки ею юникода и возможности ввести нужные символы)?
Версий Unicode много.
Потому что ascii прост и однобайтов. А юникод может быть с bom / без bom, в одной из трех разных вариаций канонизации и так далее.
Намного более глупый запрет: ограничение длины пароля 15-20 символами.
Беда начинается уже там, что глиф ‘ä’ можно записать и как \u00e4 но и как \u0061\u0308 и ещё несколькими способами.
Беда начинается уже там, что глиф ‘ä’ можно записать и как \u00e4 но и как \u0061\u0308 и ещё несколькими способами.
Для сравнения так и так положено нормализовывать.
Зачем нужен юникод если в действительно важных местах надо использовать ключи, а в остальных можно просто pwgen 20 1?
Для сравнения так и так положено нормализовывать.
Но в базу-то должен будет уйти хэш.
Ну и я вот думаю. Пароль из Emoji — это было бы круто 😁 и легко запомнить
Вот есть у тебя пароль легкий и удобный для запоминания «английскими буквами глядя на русские». И надо тебе его ввести с убогой стандартной клавиатуры телефона, например.
А с юникодом задница будет еще глубже.
А ключи это супер-надежно, да?
с убогой стандартной клавиатуры телефона
Для сравнения так и так положено нормализовывать.
В какую форму? Их несколько.
Т.е. делать процедуру аутентификации зависимой от того устройства и программы через которое ты логинишься
ни в чём, я разрешаю, в том, где я приложил руку, ограничивается только минимальная длинна.
Я бы вообще разрешал только base64 или даже base16. Потому что юникод неправильно задизайнен (написали выше) и это уже не исправить.
Запрещают в основном те сайты, которые работают не на utf8 например.
2) Один и тот же символ может быть представлен кучей способов (в том числе в зависимости от того, с помощью чего он был введён).
Но в базу-то должен будет уйти хэш.
Значит надо перед хэшированием нормализовать. Как в своё время TCP/IP стек от MS все пароли приводил к верхнему регистру. Да, пароль легче подбирать. Зато предотвращает разночтения.
Главное, чтобы единообразно. Сайт unicode.org рекомендует для внутреннего представления NFD или NFKD. NFKD длиннее, значит по хешу сложнее восстановить.
Главное, чтобы единообразно. Сайт unicode.org рекомендует для внутреннего представления NFD или NFKD. NFKD длиннее, значит по хешу сложнее восстановить.
Ну вот поэтому никто и не заморачивается 🙂
Потому что нужно заниматься нормализацией и прочим джанком. А так загнал буфер в криптофункцию и ок.
Вот да, зашел чтобы оставить этот комментарий. Но я видел ограничение еще круче: 12 символов, из которых разрешены только маленькие буквы и цифры.
NFC или NFD, как тебе удобнее.
Это будет проблема сервиса, когда пользователь не сможет ввести пароль и тупо уйдёт.
Все удобство ХРЮНИКОДА и всяких знаков пунктуации в паролях хорошо понимаешь после того, как приходится набирать такой пароль на телефоне. Теперь только латиница и цифры.
Вот прям железно запрещать пользователю выстрелить себе в ногу, конечно, не надо. Но хоть немного оградить от такой возможности стоит.
Вот банально сдохнет у меня комп (например соседи сверху затопят, или коты кусок штукатурки на него уронят, или я буду на каком-нибудь Бали верхом на шлюхе), и мне вдруг срочняк-срочняк понадобится зайти на условно панель управления условнохостинга чтобы оплатить, или еще чего. А уменя, как привел в пример @Im_not_a_robot, под рукой только телефон. Все, приплыли.
Это будет проблема сервиса, когда пользователь не сможет ввести пароль и тупо уйдёт.
знаешь соотношение пользователей, жаловашихся в саппорт на неверный пароль (и мои подозрения, что из-за того что перепутали заглавную и цифру) и сколько на уникод? у нас это 100500 к 0. никто не жаловался, что не мог ввести пароль из-за того, что он не может ввести уникодный символ, который он выбрал.
Вот прям железно запрещать пользователю выстрелить себе в ногу, конечно, не надо. Но хоть немного оградить от такой возможности стоит.
Более интересны другие цифры. Например:
Соотношение количества пользователей, использующих юникод в паролях, ко всем пользователям в целом.
Соотношение количества пользователей, знающих, что юникод в паролях разрешён, к количеству пользователей, знающих слово «юникод».
Соотношение количества пользователей, жаловавшихся в саппорт, к количеству пользователей, у которых возникли проблемы.
Соотношение количества пользователей, использующих юникод в паролях, ко всем пользователям в целом.
не в курсе, не знаю паролей пользователей
Соотношение количества пользователей, знающих, что юникод в паролях разрешён, к количеству пользователей, знающих слово «юникод».
из-за п1 не могу сказать
п2 не связан напрямую с п1
ограничения накладывает только способ ввода этого самого пароля.
введите первую, вторую и пятую букву вашего пароля
это где такой маразм?
Всё может, только вот зависит от способа ввода.
если клиент поддерживает юникод, то серверу должно быть по барабану.
Знать бы где его нет. Lloyds, FirstDirect, Halifax, Barclays, TescoBank, у Amexов наверное только логин и пароль нормальные.
а они про брутфорс не слышали?
впрочем, в банках редкостный заповедник странных технологий. все эти коды из трёх цифр.
Юникод — он не униформен. Для одного и того же глифа могут быть несколько предствалений на байтовом уровне. Т.е. в зависимости от, у тебя могут быть разные представления одного и тогоже символа. Ergo и «пароли» у тебя будут разные, хоть и выглядят одинаково.
это ты мне рассказываешь? я какбэ 20 с гаком лет программирую. я в курсе. и про все особенности тоже.
сервер всё равно не хранит пароли (ну, в нормальных реализациях). он хранит хэш от некой производной пароля и логина. плюс к этому обычно добавляют соль. и вычисление хэша происходит на стороне клиента, как правило.
если у тебя клиент юникодовый и ты можешь её повторить
Вот верность этого утверждения вызывает у меня сомнения.
В остальном не надо мне тоже рассказывать прописные истины. Речь не о них.
Вот верность этого утверждения вызывает у меня сомнения.
TL;DR: эквивалентные символы уникода совсем не эквивалентны на байтовом уровне. И в зависимости от разных нормализация могут быть совсем разные. Поэтому это таки больше интрепретация, а не только просто последовательность байт.
От восьми до двенадцати, обязательно цифра и буква в верхнем регистре. Онлайн-банкинг
Просто шикарно, лол.
Но я видел ограничение еще круче: 12 символов, из которых разрешены только маленькие буквы и цифры.
А ровно 8 цифр не хочешь? Да, один банк правда еще совсем недавно так делал.