Хешид против чистого случайного хэша в обфускации идентификатора
Я пытаюсь запутать идентификаторы в моем приложении Rails, просто потому, что это выглядит немного постыдно, когда вы развертываете приложение, чтобы иметь пользователей с ID: 1,2,3... и также не в курсе, чтобы не угадать размер веб-приложения и его темп роста..
1-й выпуск:
Хешид может быть декодирован, что не относится к реальному хешу (основанному на сильном алгоритме, таком как, например, Bcrypt). Все же хэши - это очень длинные строки, которые сделают мой путь безобразным.
Это компромисс, но я думаю, что я счастлив с хэшами.
Тем не менее, есть ли общие знания о том, как легко декодировать хэш? И это зависит от размера хеша?
2-й выпуск:
одна из моих моделей в конечном итоге достигнет около 1 миллиона записей.
Затем при использовании буквенно-цифровых прописных и строчных букв я получаю 62 возможности для каждой хэш-цифры:
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890".size = 62
Тогда 4 цифры дают: 62^4 = 14 776 336 возможностей
Хотя приведенный ниже хеш-код попросил зашифровать номер 90000 вернул 5-значный хеш (?!)
var hashids = new Hashids("whatever salt", 4, "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890");
var id = hashids.encode(90000);
Возвращенный хешид: PpBAR
Таким образом, хэшид немного пожирает возможности, а затем остается много неиспользованных хешей.
Тогда моя идея заключалась в том, чтобы обработать по-другому: сгенерировать 4 числа от 0 до 62 и извлечь связанную цифру из этой цепочки: "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890"
Хотя один недостаток: столкновения. Затем я должен проверить в таблице, если этот хэш уже был задан => много времени.
Учитывая мой верхний предел в 1 000 000 и хэш из четырех цифр, можно получить 14 776 336 возможностей. Когда модель достигнет верхнего предела, будет 1 / 14 шанс создать новый хэш и выполнить поиск в новой базе данных.
Что кажется мне приемлемым...
Ах, одна вещь: хеш будет храниться в независимом столбце, поэтому нет необходимости иметь возможность декодирования, что хорошо, потому что случайный метод не позволяет это...
Поэтому я хотел бы узнать ваше мнение по этому вопросу: кажется ли это приемлемым? Поиск может занять больше времени, чем генерация уникального хеша с помощью хеш-кода (а для некоторых из них, вероятно, намного дольше, если необходимо выполнить новый поиск)... но в целом я могу иметь более короткие уникальные идентификаторы, чем с хеш-кодами? (И это не может быть декодировано поверх этого..)
РЕДАКТИРОВАТЬ
моя база данных - Postgresql и запросы к базе данных выполняются в Ruby (затем преобразуются в SQL)