ASP.NET che memorizza la password criptata e salata

Question

ASP.NET che memorizza la password criptata e salata

#1 da (4 voti)
#2 da (1 voti)

2

Ho una domanda su come memorizzare password crittografate nel tuo database per proteggerle. Ho una classe che crittografa la password passata e restituisce una stringa. Questa stringa ha anche 3 parti, tutte separate da due punti. La prima parte è l'iterazione, la seconda parte è il sale e la terza parte è la password crittografata. Es: "1000: {salt}: {password crittografata}".

La mia domanda è come suppongo di archiviare questo? A partire da ora, sto memorizzando l'intera stringa nel mio database sotto la colonna della password. Poi quando vado a controllare le password per un login, recupero quel record, e ho un metodo nella mia classe che lo analizza e verifica che le due password corrispondano. È un grande "no no?" Ho letto dove alcune persone memorizzano il sale nella propria colonna e poi lo abbassano quando verifica un login. Tuttavia, questa classe che sto usando per la crittografia restituirà una stringa come ho mostrato sopra. Quindi è venuto con un metodo che posso semplicemente passare l'intera stringa al suo interno e lo analizzerò e verificherò le password come login.

Credo che quello che sto chiedendo sia, devo ricostruire la mia classe per separare la stringa ("{iteration}: {salt}: {password crittografata}"), o sta memorizzando l'intera stringa nel database OK?

security asp.net hashing

posta James 11.01.2016 - 04:32

fonte

2 risposte

1

Durante lo sviluppo di un'applicazione stavo usando una libreria di crittografia che aveva lo stesso formato {iterations}:{salt}:{PasswordHash} . Aveva 2 metodi principali public string GetPasswordHash (string PlainTextPassword) e public bool VerifyPassword(string formatedPaswordHash, string PlainTextPassword) . Poiché GetPasswordHash è ritornato e VerifyPassword previsto una stringa nel formato {iterations}:{salt}:{PasswordHash} è così che l'ho memorizzata nel database. Era quindi un semplice recupero dell'hash dal DB, passare al metodo di verifica e non avere alcun codice aggiuntivo da gestire.

Avrei potuto suddividerlo in 3 colonne (Iterations, Salt, PasswordHash) ma dovrei solo combinarle di nuovo per verificare l'aggiunta di un passaggio che potrebbe introdurre un bug. Dal momento che non avrei mai aggiornato manualmente nessuna delle parti, non ho visto alcun beneficio memorizzarle separate, specialmente quando un utente malintenzionato potrebbe rompere le parti o rimetterle insieme più facilmente che potessero, se avessero accesso a un altro bug.

In generale, in entrambi i casi si può difendere, ma io tendo sempre ad andare mantenendo le cose semplici. Se la libreria sputa una stringa da un metodo e si aspetta che una stringa nello stesso formato venga passata in un altro metodo, perché preoccuparsi di cambiare il formato per la memorizzazione se non si intende aggiornare manualmente una delle singole parti.

L'unico grande no no di crittografia consiste nel non eseguire il rollout di GetPasswordHash e VerifyPassword . Finché sono forti, il modo in cui memorizzi le cose nel database diventa un problema secondario.

risposta data 11.01.2016 - 18:05

fonte

Leggi altre domande sui tag security asp.net hashing

I pacchetti udp possono essere incollati I numeri di porta UDP e TCP dovrebbero essere rappresentati come brevi o interi?

score 4 · Accepted Answer

Quello che fai è come la maggior parte lo sta facendo, ed è perfettamente soddisfacente.

La cosa che la gente dice di non fare la tua sicurezza è che non dovresti inventare il tuo modo di usare la password. Utilizza sempre un algoritmo di hashing della password all'avanguardia.

Quindi memorizza la password con hash che include il singolo salt e il numero di iterazioni (che ti consente di aumentare il numero di iterazioni in un secondo momento se necessario) nel database.