правило установки пароля для случайного веб-сайта

, надеюсь, вы не хранить пароли в вашей базе данных. Вы должны хранить хеш только пароля .

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

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

Даже если вы делают ограничить персонажей, почему вы считаете белым пространством незаконным персонажем? Многие пользователи создают «проходные фразы» для обеспечения их паролей.

Почему вы хотите незаконные персонажи? До тех пор, пока он не сломает никаких частей вашей системы (которая не должна), нет никакой реальной причины отклонить его.

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

То же самое относится и к ограничению символов, которые могут быть использованы. Зачем вообще его ограничивать?

Несмотря на то, что ваш сайт является случайным, хранение паролей в текстовом виде является плохой практикой. Как минимум, конкатенуйте некоторую соль (например, имя пользователя плюс некоторую постоянную строку для вашего сайта) и храните ее SHA-1 хэш. Поскольку пользователи склонны использовать одни и те же пароли на нескольких сайтах, это обеспечивает хорошую защиту от перекрестного взлома, если пароли вашего сайта будут взломаны.

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

{ lines[NR] = $0; }
END {
    for (line_no=1; line_no<=NR; ++line_no) {
        print lines[line_no];
    }
}

Вы можете свернуть его в одну строку, если хотите:

cat file | awk '{lines[NR]=$0;} END {for(i=1;i<=NR;++i) print lines[i];}' > file

Со всем этим я бы все еще рекомендовал использовать временный файл для вывода, а затем перезаписать исходный файл вместе с ним.

Аппаратное обеспечение

или

Аппаратное обеспечение + ОС

или

Аппаратное обеспечение + ОС + Apache

или

Аппаратное обеспечение + ОС + Apache + PHP

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

Как выйти из бизнеса паролей и использовать Open ID, как SO использует?

Большинство сайтов требуют более 6+ символов или не имеют минимального предела. Пока 6 не очень безопасен, это, вероятно, не имеет значения слишком много, так как это случайный веб-сайт. Вероятно, вы должны разрешить пароли до 6 символов, чтобы пользователи счастливее, если они хотят более короткие пароли.

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

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

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

Если вы не банк, вы не должны применять сложность пароля любого вида. Если пользователь хочет букве «A» как его пароль, пусть он пойдет на это. Когда он обнаруживает, что некоторая злонамеренная сущность сокращается URL-адреса в его имени (или все, что делает ваш сайт), он может справиться с ним и, возможно, выучить хороший урок.

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