Chiave primaria come sale?

Non vedo problemi immediati con questo approccio. Soprattutto se si utilizza un sale per sito Web in aggiunta a un sale per utente. In modo che il tuo sale combinato sia abbastanza complesso. La funzione principale di un salt in hashing della password sta impedendo le tabelle arcobaleno. E non hai bisogno di un sale molto casuale per questo.

Ancora non lo farei in questo modo, dal momento che l'utilizzo di un sale casuale è una pratica standard. E inventare la tua cripto è di solito una cattiva idea, perché è facile sbagliare. Quindi seguirò semplicemente la pratica standard a meno che non ci sia una buona ragione per non farlo.

IMO è più importante usare una funzione KeyDerivation con iterazioni sufficienti per rallentare gli attacchi a forza bruta piuttosto che preoccuparsi della casualità del sale. Avere un po 'di sale è essenziale, ma solo una delle cose di cui hai bisogno.

Salt dovrebbe sempre contenere i bit random generati da un metodo sound crittografico. La chiave primaria è tutto tranne che casuale; non farlo!

EDIT: quello che sto ottenendo qui è che la tua chiave primaria da sola non conterrà abbastanza entropia. È possibile generare una tabella arcobaleno separata per ogni valore di sale. Il tuo sale deve contenere abbastanza bit di entropia in modo che non sia possibile generare abbastanza tabelle per consentire a un utente malintenzionato di precompilare gli hash.

Is it okay to use the primary key as the salt in a Users table?

È possibile essere accettabile, in alcune rare occasioni, ma anche in questo caso è improbabile che possa offrire vantaggi reali. Fondamentalmente, non farlo.

Le situazioni in cui potrebbe essere corretto sono dove la chiave primaria è a) un valore grande, e b) un valore casuale. Un esempio un po 'forzato di questo potrebbe essere un UUID Tipo 4 utilizzato come chiave primaria.

L'unico vantaggio che otterresti da questo è il risparmio di pochi byte per utente. Questo è completamente trascurabile, nessun motore di database attuale noterebbe questo risparmio, anche se hai milioni di utenti.

Tuttavia, ci sono grossi inconvenienti nell'usare la chiave primaria come una soluzione salina, nelle aree delle esigenze di sviluppo del software e della sicurezza:

Nello sviluppo del software:

• I buoni team di sviluppo useranno un OR / M e i buoni OR / M amano davvero avere il controllo esclusivo della chiave primaria. Questo apre buone ottimizzazioni delle prestazioni. Un esempio è l'algoritmo NHibernate Hi / Lo , che consente a NHibernate di "scrivere pigro" al database, velocizzando le cose.

• Buoni database amano avere anche il controllo esclusivo della chiave primaria. E spesso strutturano il loro file di dati dalla chiave primaria , con conseguenti maggiori guadagni in termini di prestazioni con la chiave primaria corretta.

• Molti database come la chiave primaria sono piccoli, fx un numero intero a 32 bit, perché la chiave primaria è spesso inclusa negli indici conservati nella RAM.

In sicurezza:

• Non hai detto quello che in realtà usi come chiave primaria (). Tuttavia, il caso più comune sarebbe un valore a incremento automatico a 32 o 64 bit (il primo utente ha la chiave "0", la seconda chiave utente "1" e così via). Non è abbastanza buono per una password salt.

Is it okay to use the primary key as the salt in a Users table?

Sicuramente non OK . Utilizza un salt random per ogni utente. Utilizza blowfish (lo standard) o qualcosa di equivalente.

Oltre ad accettare salt salt, blowfish è adaptive , il che significa che puoi farlo più a lungo da calcolare man mano che le CPU diventano più veloci.

Modifica: scusa, ho sbagliato: ho pensato alla "chiave primaria" come a una specie di chiave privata del server (ad esempio in un contesto HTTPS), non nel significato del database SQL. Tuttavia, la chiave primaria del database è ancora univoco in quel database , ma se il software viene utilizzato in diverse installazioni server distinte, molto probabilmente si avranno gli stessi valori della "chiave primaria" in tutti loro. Quindi è ancora da preferire un sale (lungo) casuale, per quanto riguarda la sicurezza (la casualità garantisce l'unicità con alta probabilità, se il sale è abbastanza grande, ad esempio 16 byte o più).

Risposta originale:

D'altra parte, il sale non deve essere segreto (altrimenti sarebbe chiamato "chiave"). È ipotizzabile avere uno schema di hashing delle password che dipende da una chiave (in pratica, un MAC ) ma ciò comporta una minaccia diversa modello, in particolare con la gestione delle chiavi, che è noto per essere un problema difficile. Utilizza un salt casuale per password, memorizzato lungo la password con hash, senza alcuna chiave, e sarai più felice.

Non consiglierei di usare la chiave primaria come sale. Quella pratica è fragile.

I buoni progetti dovrebbero essere robusti e in manutenzione. I sistemi non sono statici; spesso dobbiamo mantenerli nel tempo, aggiungere nuove funzionalità, correggere bug, migliorare le prestazioni, ecc.

L'uso della chiave primaria come sale è una cattiva pratica perché rende la sicurezza dipendente da qualcosa che è fuori dal nostro controllo. Non c'è alcuna garanzia che una chiave primaria sia imprevedibile e abbia sufficiente entropia per un sale; i requisiti per un sale (unicità tra i siti, imprevedibile) sono diversi e un superset dei requisiti per una chiave primaria (unicità all'interno di un singolo database). L'uso di una chiave primaria per uno scopo per il quale non è stato progettato sembra imprudente.

Anche se si utilizza la chiave primaria in quanto sale sembra essere sicuro quando inizialmente implementato, sarebbe facile per lui diventare silenziosamente insicuro a un certo punto in futuro, come viene mantenuto il software. Supponiamo che il database o l'applicazione cambino il modo in cui sceglie le chiavi primarie. Ciò potrebbe non influire sulla correttezza del database e potrebbe sembrare una modifica innocua per alcuni progettisti di database o sviluppatori software, ma potrebbe ridurre leggermente la sicurezza della salatura della password.

Per essere chiari, non la considero una violazione egregia. Se l'ho visto in un'applicazione esistente, non saltavo su e giù per aggiustarlo ora, ora, ora. Ma se stai scrivendo una nuova applicazione, sembra una cattiva pratica e non la consiglierei. È troppo intelligente per metà.