| Jonik-Mnimonik |
16-06-2008 07:05 826928 |
Цитата:
Цитата Amin
Лучше будет нарезать хеши в несколько таблиц, сгруппировав по сложности. Т.е., чтобы сперва просматривались таблицы с легкими (наиболее распространенными паролями), а если в них нету записей - только тогда переходить к таблицам со сложными паролями. Это здорово поможет поднять скорость.
56 миллиардов записей в одной таблице - это под нагрузкой ни одна БД не вынесет, будь она хоть на ассемблере написана.
А вообще MySQL для такой задачи отличный выбор. »
|
Я так и делаю. Я разбил таблицы на разные длинны паролей. То есть пароль с длиной 3 храниться в одной таблице, а пароль с длиной 4 в другой.
Цитата:
Цитата dmitryst
Jonik-Mnimonik, а зачем вам пароль из хэша? ИМХО, абсолютно ненужная трата ресурсов. У меня, например, в одной из программ используется такой метод - клиент присылает нешифрованый пароль, скрипт его принимает, шифрует, далее из базы запрашивется образец хэша, и с ним сравнивается свежезашифрованый. Таким образом, в базе у меня хранятся только хэши - никаких паролей в явном виде, правда, если пользователь его забудет, придется вводить новый. Зато количество записей соответствует количеству пользователей, не более. Для повышения безопасности я еще и блокирую учётку при трёхкратной ошибке набора пароля. Ну, как вариант, можно применить двусторонние алгоритмы, т.е. пароль можно получить из хэша и наоборот, хэш из пароля. Количество записей, опять же, по количеству пользователей. »
|
Дело в том, что задача поставилась именно восстановить пароль по значению хэш-функции. Это трудная задача. Вот мне и приходиться выщитывать все значения хэш-функций. а потом сравнивать, с тем по которому необходимо найти пароль. А в таблице храниться хэш-функция и соответствующий ему пароль. Если говорить про систему аутентификаци, то конечно я бы выбрал так как вы сказали.
зы Диплом, ни куда не деться. |
