Блог

Мне нужно хранить пароли в моей базе данных SQL. Слишком высокая безопасность на данный момент не требуется, но вместо использования хэша MD5 с начальным значением я планирую использовать SHA1 seed для хранения своих паролей.

Использование было бы просто для входа пользователя на веб-сайт. Поэтому, когда пользователь входит в систему, мой код C # объединяет соль пароль, хэширует его, а затем сравнивает с тем, что хранится в базе данных.

Мой вопрос в том, что в SQL Server я должен хранить SHA1 как есть (40 символов) или после преобразования их в Base64 (28 символов)?

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

Хэш SHA-1 — это 160-битное значение; решения для хеширования будут выдавать 20 байт выходных данных, включая непечатаемые символы. Большинство реализаций преобразуют это в читаемый формат перед сохранением, либо в шестнадцатеричный (40 байт), либо в base64 (~ 28 символов).

Нет причин преобразовывать шестнадцатеричную строку в base64 перед сохранением, поэтому, если ваши строки уже в шестнадцатеричном формате, просто оставьте их такими.

Ответ Криса Хилда объясняет некоторые детали, но он не дает конкретного ответа на ваш вопрос.

Весь смысл хэширования пароля в первую очередь заключается в том, чтобы сделать его бесспорным, неузнаваемым и нечитаемым. Тогда нет причин конвертировать его обратно в base64, чтобы снова сделать его читаемым. Причина, по которой многие реализации делают это, в основном, из-за наборов символов и кодировок. При использовании простых наборов символов на основе ASCII реализации могут незначительно отличаться в зависимости от баз данных и языков программирования, что может привести к потере или модификации данных при сохранении и извлечении и, следовательно, поэтому специальный (необычный) символ в 1 наборе символов может не существовать в другом наборе символов.