вот библиотека и несколько примеров http://www.c-sharpcorner.com/UploadFile/malcolmcrowe/SnmpLib11232005011613AM/SnmpLib.aspx
Он не должен генерировать дубликаты.
import random
chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
def gen():
return ''.join([random.choice(chars) for x in range(32)])
test = [gen() for i in range(100000)]
print len(test), len(set(test)) # 100000 100000
Вероятность дублирования значительна с chars = "ab"; 126 дубликатов за 1000000 итераций. Его нет в 62.
Тем не менее, это не лучший способ создания файлов cookie, потому что файлы cookie сеанса должны быть непредсказуемыми, чтобы избежать атак, связанных с кражей файлов cookie сеанса других людей. Mersenne Twister не предназначен для генерации безопасных случайных чисел. Вот что я делаю:
import os, hashlib
def gen():
return hashlib.sha1(os.urandom(512)).hexdigest()
test = [gen() for i in range(100000)]
print len(test), len(set(test))
... который должен быть очень безопасным (то есть, трудно взять строку файлов cookie сеанса и угадать из них другие существующие файлы cookie сеанса).
Я не знаю, как создаются ваши процессы FCGI, но возможно ли, что он использует fork () после запуска интерпретатора Python (и случайный модуль был импортирован чем-то) , следовательно, эффективное заполнение random._inst
двух процессов из одного и того же источника?
Может быть, внести некоторую отладку, чтобы убедиться, что он правильно загружается из urandom и не возвращается к менее строгому времени - на основе семян?
этот комментарий: человек! Тогда это меня озадачило; если RNG всегда имеет другое состояние при запуске, я не могу понять, как вы могли бы получить коллизии. Странно. Я полагаю, что для расследования конкретных случаев, которые приводят к столкновениям, пришлось бы добавить много журналов состояний, что звучит как большая работа по просмотру журналов. Может быть (1a) сервер FCGI обычно не
Мне пришлось стереть свой исходный ответ, в котором говорилось, что генератор не засевается из / dev / urandom
, поскольку его источник (для Python 3 .x) ясно говорит, что это так:
def seed(self, a=None):
"""Initialize internal state from hashable object.
None or no argument seeds from current time or from an operating
system specific randomness source if available.
If a is not None or an int or long, hash(a) is used instead.
"""
if a is None:
try:
a = int(_hexlify(_urandom(16)), 16)
except NotImplementedError:
import time
a = int(time.time() * 256) # use fractional seconds
super().seed(a)
self.gauss_next = None
Поэтому я смиренно принимаю, что в мире есть тайны, которые я, возможно, не смогу разгадать.
Чтобы избежать проблемы, вы можете использовать последовательность файлов cookie, которые гарантированно будут отличаться (например, вы можете использовать набор). Каждый раз, когда вы даете кому-то файл cookie, вы берете его из последовательности и добавляете к нему еще один. Другой вариант - сгенерировать UUID и использовать его в качестве файла cookie.
Другой способ избежать проблемы может заключаться в хранении закрытого ключа и использовании контрольной суммы закрытого ключа (например, MD5) со значением счетчика, присоединенным к Это. Тогда вероятность столкновения будет очень низкой. Для большей безопасности добавьте к контрольной сумме еще несколько переменных, таких как текущее время, IP-адрес пользователя, ...
Существуют библиотеки для создания файлов cookie. Любая реализация WSGI, вероятно, содержит генератор файлов cookie.
Если вас интересует только то, насколько случайны ваши строки, вы можете сгенерировать файл, скажем, с одним миллионом файлов cookie и выполнить проверку случайности в этом файле. Однако это не то, что я бы рекомендовал.
Это определенно не обычный сценарий коллизии:
Может ли это быть проблемой параллелизма?
random.Random
для каждого потока threading.local ()
) os.urandom ()
- не систему time - поэтому вы должны получить разные потоки для каждого потока.