Хранение, получение и проверка пароля (SecureString) в SQL Server

НИКОГДА не храните пароль - даже не зашифрованный ...

Просто сохраните хэш пароля (который предотвращает получение пароля, пока хеширование выполняется безопасным способом), а для проверки вы хешируете введенный пользователем пароль таким же образом и сравниваете результаты ...

Для этого существуют стандарты:

• http://en.wikipedia.org/wiki/PBKDF2
• http://www.ietf.org/rfc/rfc2898.txt
• http://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes.aspx

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

Вы можете сохранить результат либо как VARBINARY напрямую, либо как VARCHAR после Base64- или HEX-кодирования байтов ... вам нужно будет сохранить соль вместе с ней (что не представляет опасности для безопасности, если каждый пароль имеет свой собственный криптографический безопасная сгенерированная случайная соль).

На моем предыдущем концерте мы сохранили пароль в виде хешированного / зашифрованного / соленого значения (в то время с использованием MD5) как VARBINARY(32). Чтобы позже сравнить пароль, вместо того, чтобы пытаться его расшифровать, мы сравнили бы зашифрованное + солёное значение, которое мы сохранили, с зашифрованным + солёным значением пытаемого пароля. Если они совпали, они вошли, если они не совпали, они не вошли.

Хеширование выполнялось на среднем уровне (как для первоначального сохранения пароля, так и для последующего сравнения), но на примере на основе SQL Server (чтобы остановить ворчание @Yahia, это не означает, что вы укажете наиболее безопасный способ возможно, я просто иллюстрирую методологию на очень легком примере. MD5 недостаточно силен для вас? Вы можете использовать другой, более сложный алгоритм вместе с более продвинутыми методами соления, особенно если вы выполняете хеширование на уровне приложения ):

CREATE TABLE dbo.Users
(
    UserID INT IDENTITY(1,1) PRIMARY KEY,
    Username NVARCHAR(255) NOT NULL UNIQUE,
    PasswordHash VARBINARY(32) NOT NULL
);

CREATE PROCEDURE dbo.User_Create
    @Username NVARCHAR(255),
    @Password NVARCHAR(16)
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @salt NVARCHAR(16) = '$w0rdf1$h';

    INSERT dbo.Users(Username, Password)
        SELECT @Username, 
          CONVERT(VARBINARY(32), HASHBYTES('MD5', @Password + @Salt));
END
GO

CREATE PROCEDURE dbo.User_Authenticate
    @Username NVARCHAR(255),
    @Password NVARCHAR(16)
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @salt NVARCHAR(16) = '$w0rdf1$h';

    IF EXISTS 
    (
      SELECT 1 FROM dbo.Users
        WHERE Username = @Username AND 
        PasswordHash = CONVERT(VARBINARY(32), HASHBYTES('MD5', @Password + @salt))
    )
    BEGIN
        PRINT 'Please, come on in!';
    END
    ELSE
    BEGIN
        PRINT 'You can keep knocking but you cannot come in.';
    END
END
GO