работа с хешированными паролями в рубине
В зависимости от того, на какой системе вы его запускаете, ничего не произойдет, произойдет сбой программы, будет повреждена память или появятся другие интересные эффекты.
2 ответа
Лучший способ сделать это - сохранить соль для каждого пользователя, и она создается на основе времени в тот момент, когда они это сделали.
Это правда, что как только человек получает доступ к вашей базе данных, он может видеть соль для пользователей, но если это произошло, вам нужно беспокоиться о более серьезных вещах.
Вы проверяете свой пароль пользователя, беря его очистите ввод текста и зашифруйте его с помощью соли, а затем сравните crypted_passwords, если они совпадают, они аутентифицированы. Я не верю, что хранение соли - проблема, так как она вам понадобится. Если вас беспокоят атаки с использованием SQL-инъекций, вам лучше защитить свое приложение от них, чем не хранить необходимую информацию, в этом случае соль каждого пользователя.
Theoretically the salt serves two main purposes. The first is to prevent duplicate passwords to end up with the same hash value on the database. The second is to increase the length of the password, thus also increasing the difficulty of an attacker guessing a password.
But there is the problem of storing the salt, if you insert it on the database the second purpose is somewhat defeated in case someone grabs that data, ideally it should be stored on a different location, but this is only necessary if your application is very sensitive!
If the code of your application is not public, I'd say a possible way to circumvent this issue is to generate the salt based on a static value of each user, like the creation date or username, because if someone reads the database it is unclear whether or not you use salt...