Dovresti memorizzarlo in un unico campo. Non cercare di dividerlo in parti.

So che questo potrebbe sembrare un po 'poco intuitivo per le persone che provengono dallo sfondo di un database, dove il modus operandi è normalizzare i dati e l'uso di stringhe serializzate è considerato un brutto trucco. Ma da una pratica di sicurezza, questo ha perfettamente senso.

Perché? Perché l'unità più piccola su cui il singolo sviluppatore deve operare è quella stringa completa. Questo è ciò che l'app deve passare alla libreria hash per verificare se una password fornita è corretta o meno. Dal punto di vista degli sviluppatori, la libreria hash può essere una scatola nera e lei non deve preoccuparsi di cosa significano effettivamente quelle parti fastidiose.

Questa è una buona cosa, perché la maggior parte degli sviluppatori sono esseri umani imperfetti (lo so , perché lo sono anch'io). Se lasci che raccolgano quella corda e poi provi a rimetterla insieme, probabilmente rovineranno le cose, come dare a tutti gli utenti lo stesso sale o niente sale.

Anche memorizzare solo i parametri nel codice è una cattiva idea. Man mano che i processori diventano più veloci, potresti voler aumentare il fattore costo in futuro. Durante la fase di migrazione, password diverse avranno fattori di costo diversi. Quindi avrai bisogno di informazioni a livello di password su quale fattore di costo è stato utilizzato per l'hashing.

Quello che ti manca è che gli hash funzionano sui dati originali, meno la stringa originale. Quando si desidera convalidare una stringa rispetto a un hash, si prende la stringa fornita, più i dati hash originali (costo, salt, ecc.) E si genera un nuovo hash. Se il nuovo hash corrisponde a quello vecchio, la stringa viene quindi convalidata (in altre parole, la stringa non viene mai decrittografata , viene modificata ).

Avere il sale non aiuta la forza bruta. Il sale è una parte essenziale di un hashish allo stesso modo in cui i bicchieri fanno parte di una serratura. Se elimini uno dei due, nessuno può usarlo.

Separare lo spazio di archiviazione è inutile. Nella maggior parte dei casi dovrai riassemblare l'hash completato per convalidarlo. Ecco perché tutti i componenti sono memorizzati in una comoda stringa per impostazione predefinita.

Sì, puoi memorizzarlo in un singolo campo e molti database / applicazioni memorizzano l'hash salt + in un singolo campo / file ecc.

Il più famoso è Linux (che non è un DB), che memorizza l'hash nel file / etc / shadow utilizzando il formato:

"$ id $ salt $ hashed", il formato stampabile di un hash della password prodotto da crypt (C) , dove "$ id" è l'algoritmo utilizzato. (Su GNU / Linux, "$ 1 $" sta per MD5, "$ 2a $" è Blowfish, "$ 2y $" è Blowfish (corretta gestione dei caratteri a 8 bit), "$ 5 $" è SHA-256 e "$ 6 $ "è SHA-512, [4] altri Unix possono avere valori diversi, come NetBSD.

(fonte: https://en.wikipedia.org/wiki/Passwd)

Il sale non deve essere segreto (o almeno non più segreto dell'hash). Il suo scopo principale è rendere gli attacchi di forza bruta molto più difficili poiché l'attaccante deve usare un sale diverso per ogni singolo utente.

Ma la tua domanda è più sfumata, perché non stai solo chiedendo sali ma anche parametri. Cose come l'algoritmo di hashing, il conteggio delle iterazioni e il sale. In qualsiasi caso, non memorizzarlo nel codice, appartengono ancora al DB.

Immagina di avere un gruppo di utenti e di aver utilizzato SHA1 come algoritmo di hashing. Quindi il campo del tuo database lo farebbe essere qualcosa come SHA1:SALT:HASH”.

Se volessi aggiornare il tuo database a BCRYPT, come faresti?

Typi normalmente distribuiresti un po 'di codice in modo che quando un utente accede, verifichi la password e, se valida, riesci ad eseguire nuovamente l'hash della password con un algoritmo più recente. Ora il campo per l'utente ha questo aspetto: BCRYPT:SALT:HASH”.

Ma allora alcuni utenti sarebbero su SHA1 e altri su BCRYPT, e poiché questo è a livello utente, hai bisogno dei parametri che dicono al tuo codice quali sono gli utenti che devono essere nel database.

In breve, memorizzare i parametri e l'hash in un singolo campo va bene, ma suddividerli per qualsiasi motivo (efficienza, codice più semplice, ecc.) Va bene anche. Ciò che non va bene è memorizzare questo nel codice :)

Troy Hunt ha recentemente pubblicato un podcast in cui suggerisce che invece di migrare a BCRYPT nel modo sopra, è più efficace prendere semplicemente tutti gli hash SHA1 attualmente presenti il DB e l'hashing utilizzando BCRYPT.

Efficacemente BCRYPT(SHA1(clear_password))

Quando un utente accede a voi

  BCRYPT (SHA1 (clear_password)) == <db_field>  

In questo modo, tutti sulla piattaforma vengono aggiornati contemporaneamente e non hai un database con più hash formati per le password. Molto pulito e molto carino.

Penso che questa idea abbia perfettamente senso, ma anche se tutti migrano contemporaneamente, non è istantanea. A meno che tu non sia disposto ad accettare un po 'di inattività sull'app (mentre esegui nuovamente l'hash di tutte le password), ci sarà ancora un piccolo intervallo di tempo in cui alcuni utenti sono su BCRYPT e altri su SHA1, quindi il tuo DB dovrebbe ancora memorizzare parametri dell'algoritmo di hashing e il tuo codice verrebbe eseguito in base ad esso.

Dal punto di vista della sicurezza, non importa se il salt e la password con hash sono memorizzati in un singolo campo o in campi separati, anche se per semplicità preferirei un unico campo. L'unico motivo per separarli è se il codice dell'applicazione deve passare separatamente il salt e la password alla funzione di convalida. Se il codice dell'applicazione richiede solo una singola stringa combinata, puoi anche memorizzarlo in questo modo.

Ad esempio, l'appartenenza ad ASP.NET precedente divide l'hash della password e il sale in due campi DB e il La più recente identità ASP.NET ha l'hash e il sale in un unico campo DB e, a loro volta, le nuove funzioni sono state modificate per gestire la singola stringa come input e output.

È accettabile memorizzarlo in un campo in un database SQL (varchar (99) in questo caso)

No. La dimensione dei dati potrebbe cambiare in qualche momento. Deve essere utilizzato un campo varchar (MAX) a meno che le specifiche non stabiliscano che la dimensione sarà sempre esattamente 99 e non ci saranno variazioni mai . Lascia che il database si occupi dei requisiti di archiviazione.

Per sapere se è più o meno sicuro, dobbiamo capire lo scopo di un sale.

Un sale ha pochi scopi (a cui posso pensare)

1. Prevenire gli attacchi del dizionario

Un attacco del dizionario è quando una parola logica viene utilizzata come parte di una password. L'archetipo è la parola password o anche P @ ssW0rd . Le persone sono imperfette ed è più facile per loro ricordare le parole quindi stringhe casuali di lettere e numeri. Un attacco del dizionario si basa su questo per abbreviare il percorso intrapreso da un attacco di forza bruta. Ovviamente se aggiungiamo un pezzo casuale di cose ad esso, allora rende questo tipo di attacco impossibile o inutile e li rimette a forzare il tutto.

Se un utente malintenzionato conosce il salt utilizzato, dovrebbe modificare tutti i file del dizionario per ciascuna password, e questo presuppone che sappia come il salt viene aggiunto alla password originale. Un grande vantaggio di un elenco di dizionari è che tu prenda 1000 password e 1 milione di parole del dizionario. Quindi le scorri cercando di ottenere alcune corrispondenze su password più deboli. Quindi, dover modificare 1 milione di parole 1000 volte non è molto pratico.

2. Prevenire attacchi Hash o Rainbow table.

A La tabella arcobaleno è dove gli hash vengono pre-calcolati e archiviati in una sorta di database. Ad esempio, potresti prendere MD5 e iniziare a fare l'hashing di cose casuali e salvarle. Quindi, quando vuoi decifrare una password, devi solo cercare nella tabella arcobaleno.

Se un attaccante ha il sale, deve ricompilare la tabella arcobaleno per ogni sale utilizzato. Il vantaggio di questo attacco è che i dati vengono compilati in anticipo e riutilizzati più e più volte. Questo li riporta alla forzatura bruta della password. Salando e salando tutte le password in modo diverso, ciò significa sostanzialmente che devi ricalcolare la tabella arcobaleno per ogni sale. Questo è il motivo per cui è importante utilizzare sali diversi per ciascuna password.

Estivo

Nessuna di queste ragioni fa affidamento sul fatto che il sale sia segreto. Ovviamente sono tutti meno forti se un attaccante conosce il sale. Ma le informazioni aggiuntive che ottengono li aiuteranno sempre. Quindi non direi di pubblicizzarlo, ma c'è un detto sulla sicurezza basata sull'oscurità ....

Disclaimer Non sono affatto un esperto di crittografia, ma questi sono alcuni dei principali motivi che mi vengono in mente quando penso ai sali.

Spero che questo aiuti.

Il sale viene utilizzato solo per bloccare gli attacchi alle tabelle arcobaleno, quindi il tuo sale potrebbe essere memorizzato con la password con hash come avviene sul sistema GNU / Linux più recente in cui il sale è memorizzato in / etc / shadow.