Фильтр preg_replace для Паролей
VIM Эмулятор. Этот плагин обеспечивает почти полную эмуляцию vi / vim / gvim при редактировании файлов в IDEA. Поддерживаются следующие функции:
- Клавиши управления движением
- Удаление / изменение
- Команды режима вставки
- Метки
- Регистры
- VIM отменить / повторить
- Команды визуального режима
- Некоторые команды Ex
- Некоторые: установить опции
- Полные регулярные выражения VIM для поиска и поиск / замена
- Макросы
- Диаграммы
- История командной строки
- История поиска
- Списки переходов
- Помощь VIM
некоторые комментарии об этом плагине от http://plugins.jetbrains.net/plugin/?id=164
Я не вижу когда-либо возвращаясь к любому другому Ide из-за этого плагина .. Лучший из обоих миров ... Потрясающе !. это то, чего мне не хватало во всех IDE.
6 ответов
Как говорили другие, не ограничивайте набор символов, разрешенных в паролях. Просто потому, что на вашей клавиатуре нет ä, å или ö, это не причина мешать тем из нас, у кого они есть (или все равно умеют их набирать), от использования этих букв. Вы все равно собираетесь хранить пароль в виде криптографического хэша (или, по крайней мере, в виде зашифрованной строки), не так ли? Если так, то это не так. Не имеет значения, может ли ваша база данных успешно / безопасно хранить фактические символы в пароле в любом случае, только символы, выводимые вашим криптоалгоритмом. (А если нет, то хранение паролей в виде открытого текста представляет собой гораздо большую проблему, чем то, какие символы пароли могут содержать или не содержать - не делайте этого!)
Ваше очевидное намерение обеспечить соблюдение вашего набора символов ограничения, молча удаляя символы, которые вам не нравятся, вместо того, чтобы говорить пользователю: «Попробуйте еще раз и на этот раз используйте только эти символы: a, e, i, o, u». делает ваш предложенный метод поистине ужасным, так как это означает, что если я попытаюсь использовать, скажем, пароль fäîry (не очень безопасный, но должен выдерживать легкие атаки по словарю), мой фактический пароль, мне неизвестный , будет fry (если ваш пароль представляет собой трехбуквенное слово, прямо из словаря и широко используется, вы можете даже не беспокоиться). Ой!
Personally, I've always found it highly disturbing when a web site or service tried to force me to use passwords that follow a certain (usually downright stupid) limitation.
Isn't it the whole point of passwords that they are not too easily guessable? Why would you want them to be less complex than your users want them to be? I can't imagine a technical limitation that would require the use of "ASCII only" for passwords.
Let your users use any password they like, hash them and store them as Base64 strings. These are ASCII only.
Here you go:
^[ -~]+$
assuming you don't want empty passwords; otherwise it's:
^[ -~]*$
to allow empty ones.
I'm not sure why you're asking about preg_replace - I'd be wary of manipulating the passwords that people type. Better to enforce the rule that you only accept printable ASCII, and tell the user if they break that rule (or, as others have said, to not have any rules, but I assume you have reasons for them).
If you're thinking of quietly removing the characters that don't match, and someone comes along with a password of Úéåæ, then you'll be storing an empty password for them without their knowledge.
Не фильтруйте пароли пользователей. Это во многом противоречит сути. Подробнее об этом я писал здесь: http://www.evanfosmark.com/2009/06/why-do-so-many-websites-fail-with-password-restrictions/
/[\p{Cc}]/ to get control characters (I think this covers 0-31)
I agree with Richie. Use preg_match instead of preg_replace.
Я не согласен с тем, что нет причин отклонять символы, отличные от ascii, хотя вам решать, перевешивают ли плюсы минусы.
Если вы разрешаете символы, отличные от ascii, то вы фактически обязуетесь правильно интернационализировать эту часть своего веб-приложения. Для многих приложений интернационализация является второстепенной задачей. Для веб-приложений это очень нетривиальный вопрос.
Если вы явно не управляете кодировкой символов при переходе между символами и байтами, то вы в основном полагаетесь на какие бы то ни было значения по умолчанию для вашего развертывания. Если ваша конфигурация когда-либо изменится (например, при переходе с Windows на Linux или переключении на другой веб-сервер), то ваши настройки по умолчанию имеют хороший шанс измениться из-под вас, а затем символы, отличные от ascii, будут сериализованы в другую последовательность байтов. Так что внезапно хэши людей, использующих их в своих паролях, не будут соответствовать тому, что находится в базе данных, и их учетные записи будут заблокированы.
Я, конечно, согласен с тем, что это совершенно неприемлемо. просто отфильтруйте эти символы; вы должны либо принять, либо отклонить пароль.