Как предотвратить коллизии при генерации ключей активации регистрации?

Question

Я работаю над системой регистрации большого проекта.

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

Вопрос (я знаю, что это звучит абстрактно, но мне просто интересно), как избежать дублирования генерации проходов? Я имею в виду, есть ли шанс, что в будущем генератор сможет создать ключ активации, который уже существует в таблице БД? Стоит ли проверять дублирование после генерации ключа?

Answer 1

Я бы рекомендовал использовать пакет Text_Password от PEAR. Не пытайтесь изобретать это колесо.

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

Не используйте хеш-дайджест в качестве сгенерированного пароля. Ваши пользователи не хотят вводить шестнадцатеричную строку длиной 32 символа (или более). У меня был опыт кодирования пакета ключей активации безопасного программного обеспечения в 2001 году с использованием хешей PKI и MD5. Но никто не использовал бы его, потому что ключи были слишком длинными.

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

См. Также мои ответы на несколько других вопросов, связанных с паролем:

• Как создать случайный пароль или временный URL для сброса пароля в Zend Framework?
• PHP и MySQL сравнивают пароль
• Какой тип данных использовать для поля хешированного пароля и какой длины?
• Насколько большим должен быть мой пароль?

Answer 2

Попробуйте uniqid().

Answer 3

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

IЯ бы не стал использовать мой собственный алгоритм для этого.uniqid() или md5(), как уже упоминалось, являются гарантированными решениями.

Answer 4

Используйте GUID в качестве регистрационного ключа, поскольку он всегда уникален и генерируется системой

Answer 5

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

$key = md5(time());