Conservare, recuperare e password validate (SecureString) in SQL Server

Question

Ho una finestra di login che ottiene il nome utente e la password da parte dell'utente e vorrei sapere il modo migliore per gestire la password. Il nome utente è solo una casella di testo normale, ma la password è un PasswordBox. Passo il nome utente direttamente al ViewModel, ma solo impostare una proprietà SecureString sul ViewModel una volta il pulsante Login viene cliccato utilizza codice sottostante. Dopo che la password è impostata SecureString voglio Convalida.

sto scrivendo il Loginbox ora, ma non ho il modello pienamente funzionato ancora. Come devo conservare la password in SQL Server? Ho appena scrivere il contenuto della SecureString per SQL e quindi provare a confrontarlo quando l'utente tenta di login?

Answer 1

Non si dovrebbe mai memorizzare una password - nemmeno criptato ...

Basta memorizzare un hash della password (che impedisce la pasword venga mai recuperati fino a quando l'hashing è implementato in modo sicuro) e per la convalida si hash l'utente password fornita allo stesso modo e confronta i risultati ...

Ci sono norme di farlo:

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

Il sopra marchi standard, è difficile utilizzare tabelle arcobaleno ecc perché rende il calcolo molto costoso in quanto utilizza diversi giri oltre ad un sale ... hashing quindi è per esempio 1000 volte più lento (con 1000 giri), ma questo è esattamente quello che vuoi - l'attaccante avrà bisogno di fare lo stesso calcolo e quindi avrà bisogno di 1000 volte la potenza o il tempo precessione per raggiungere l'obiettivo con la forza bruta ...

È possibile memorizzare il risultato sia come VARBINARY direttamente o come VARCHAR dopo Base64- o HEX-codificare i byte ... è necessario memorizzare il sale con esso (che non è rischio per la sicurezza finché ogni parola prende il propria distinta secure crittografica generata sale casuale).

Answer 2

Al mio concerto precedente abbiamo memorizzato la password come un crittografata / salato valore hash / (utilizzando MD5 al momento) come VARBINARY(32). Per confrontare la password in seguito, piuttosto che cercare di decifrare la password, avremmo confrontato il valore salata crittografato + che abbiamo memorizzato al valore salata cifrato + della password viene tentata. Se abbinati, hanno ottenuto in, se non corrisponde, non hanno ottenuto in.

Il lavoro di hashing è stato fatto nel livello intermedio (sia per salvare la password inizialmente e per il confronto più tardi), ma un esempio basato su SQL Server ( alla fermata @ mugugni di Yahia, questo non è destinato a dire la modo più sicuro possibile, sto solo illustrando la metodologia con un esempio molto leggero. MD5 non è forte abbastanza per voi? È possibile utilizzare un algoritmo diverso e più complesso insieme a tecniche di salagione più avanzate, soprattutto se si esegue l'hashing del livello applicazione ):

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

Una procedura per creare un utente (senza gestione degli errori o dupe prevenzione, solo pseudo).

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

Ora un procedimento per autenticare un utente.

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

In realtà si sarebbe probabilmente eseguire l'hashing all'interno dell'applicazione, e passare i valori di hash come VARBINARY (32) - questo lo rende molto più difficile "Sniff" la password effettiva chiaro il testo da dovunque. E forse non sarebbe conservare il sale in testo in chiaro con il codice di entrambi, ma recuperarlo da altrove.

Questo è sicuramente più sicuro di memorizzare la password in chiaro, ma rimuove la capacità di mai recuperare la password. Win-win, a mio parere.