Длина уникальных пользовательских идентификаторов (созданных в диапазоне [0..N]) должна быть достаточно большой в целях безопасности

Question

Человек при успешной регистрации (вводит адрес электронной почты, создает пароль) получает сгенерированный (так что трудно угадать предыдущий или следующий) уникальный идентификатор - большое число от 0 до N .Итак, после успешной регистрации у нас есть 3 вещи для каждого пользователя: уникальный адрес электронной почты, хэш пароля и сгенерированный и уникальный идентификатор (целое число от 0 до N ).Электронная почта, хэш пароля и идентификатор хранятся в БД.

Вопрос в следующем: насколько большим должно быть N , чтобы вероятность угадать действительный идентификатор не превышала угадывание пароля (для любого данного адреса электронной почты).(Пароль может содержать только заглавные и строчные буквы, цифры, 8+ символов, если это важно.) Итак, все, что мне нужно, это иметь идентификаторы, которые слишком сложно угадать.

Предположим, больше не должно бытьчем 10 000 зарегистрированных пользователей (в зависимости от этого числа N зависит).По крайней мере, сколько цифр должно содержать число N (0 .. N - диапазон для того, чтобы эти длинные числа были уникальными) в наше время?

Мой алгоритм хорошдостаточно, справедливо, плохо или очень плохо?Если я отправляю этот вопрос не в ту ветку, пожалуйста, сообщите мне об этом в следующий раз, когда я буду в порядке.

PS Этот идентификатор из базы данных применяется к переменной SESSION, когда пользователь успешно входит в систему.Все SQL-запросы, которые извлекают персональные данные для пользователя, сравнивают этот идентификатор с этой переменной SESSION (поэтому мы теперь чьи данные извлекаем):

"SELECT ... FROM ... WHERE id='".$_SESSION['id']."'"

Спасибо.

Answer 1

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

Answer 2

Чтобы число не было легче угадать, чем пароль, в случае, если параноидальный пользователь - или программа - выбирает пароль, генерируя его случайным образом, из числа всех возможных паролей, вам нужно указать быть минимальным (количество возможных паролей, количество возможных хэшей паролей). Если вы используете номер без ссылки на имя пользователя, вам также необходимо, чтобы он был уникальным с высокой вероятностью - см. http://en.wikipedia.org/wiki/Birthday_attack.

На практике известно, что компьютерные системы используют 128-битные или даже 64-битные числа в качестве предположительно не поддающихся проверке токенов. Еще один способ взглянуть на это - рассмотреть, сколько предположений в секунду может сделать злоумышленник, и подумать, сколько времени им потребуется, чтобы угадать 64-битное или 128-битное число с любой вероятностью, заставляющей вас чувствовать угрозу (Более длинные ключи, используемые с RSA, необходимы, потому что есть лучшие способы угадать закрытый ключ RSA, чем угадывать числа один за другим).

Answer 3

Вместо цифры вы можете использовать строку, что-то вроде UUID должно быть довольно сложно угадать.

>>> import uuid
>>> str(uuid.uuid4()).replace('-', '')
'71dca6b8e3fb41708f93372171f53b9f'
>>>

Answer 4

Почему он вообще должен быть определенного размера?Почему бы вам не использовать автоматически увеличивающийся уникальный идентификатор и не использовать его?Вероятно, первичный ключ.Любая база данных SQL должна иметь возможность управлять этим в значительной степени автоматически, если вы правильно настроите таблицу.