fai memorizza la password "hash". Per essere precisi, memorizzi alcuni dati sul server:

• Un valore S (il "sale").
• Il "master secret" M (che non può essere veramente segreto, dal momento che il server lo memorizza "così com'è" da qualche parte nelle sue interiora).
• E (h (M || S), K) : crittografia dell'hash della concatenazione di M e S , utilizzando la chiave K che è derivato più o meno direttamente dalla password dell'utente.

Dato questi elementi di dati e una potenziale password P , è possibile fare alcuni calcoli che danno come risultato un risultato booleano: P è la password corretta, oppure no. È normale: il server deve essere in grado di verificare una password in entrata, usando ciò che il server "sa" solo. Ma se il server può farlo, può farlo anche un utente malintenzionato che ha ottenuto una copia dei dati del server. È inevitabile. Gli elementi di dati memorizzati non possono essere utilizzati direttamente per ricalcolare la password, solo per verificare una determinata password, quindi è a senso unico.

Questo è chiamato hashing password . Che ci sia un cosiddetto "master secret" e che una funzione di crittografia sia utilizzata internamente sono solo delle false piste; stai semplicemente creando una funzione di hashing della password personalizzata.

Lì può essere un valore nel "master secret" se in effetti riesci a mantenerlo "segreto". Il server deve saperlo per funzionare, quindi non è realmente nascosto, ma puoi organizzare che non sia memorizzato nel database , mantenendolo fuori dalla portata dei soliti attacchi di SQL injection. Tuttavia, non farà nulla contro un utente malintenzionato che ha ottenuto una shell di root sul server.

L'uso di un tale "segreto" in una funzione di hashing della password è chiamato "peppering" e il normale modo di farlo con crittografia è quello di rendere la funzione hashing della password a MAC con il" segreto "come chiave.

Vedi questa lunga risposta per un primer sulla password hashing, i suoi concetti, strumenti e terminologia.

Ho capito il tuo concetto come segue: -

Master Secret = "ReallyRandomAndSecureStringToUseAsASecret"

**User Registration**
dbPwd = Encrypt((hash(MasterSecret,Unique Salt),Key)
Store dbPwd

**User Login**
Take key as input.
Obtain MasterSecret and Unique Salt from DB.

dbHash = Decrypt(dbPwd,Key)

If, hash(MasterSecret + Unique Salt) == dbHash
    //Valid Login
else
    // Invalid Login

Punti da considerare: Se un server viene compromesso, verranno rivelati il Master Secret, Unique Salt e il dbPwd.

dbHash = Conosciuto da deviravtion di hash (MasterSecret, Unique Salt). dbPwd = Conosciuto da db.

Ora, un utente malintenzionato può entrare in modalità bruteforce Decrypt (dbPwd, Key) in cui la chiave viene variata utilizzando regole, un elenco di parole, ecc. Se viene rilevata la chiave utente, la decrittografia darà a dbHash la conferma.

Pertanto, anche se abbastanza innovativo, non credo che il tuo metodo fornirà un vantaggio in termini di sicurezza a meno che tu non speri che l'oscurità del meccanismo possa fermare l'aggressore.

tl; dr:

Contro:

Any system’s security is dependent largely on the knowledge and mindset of the person using it. - Mati Aharoni

1) Il tuo sistema richiede a un utente malintenzionato di risolvere una decrittazione simmetrica invece di calcolare un hash unidirezionale. In entrambi i casi, se la password dell'utente è debole, sarà interrotta.

2) Resistenza dell'algoritmo di crittografia simmetrica utilizzato.

Credo che gli hash a senso unico siano computazionalmente più difficili da risolvere rispetto a una crittografia simmetrica, tuttavia questo è un confronto tra gli algoritmi esatti usati.

Pro: Il tuo metodo sembra garantire che se la password dell'utente è strong, preverrà la collisione dell'hash. Hash collision è responsabile (in alcuni casi) per consentire l'accesso a un account anche attraverso la vera password sconosciuta. Si noti, tuttavia, che questo ha il prezzo di dbPwds di lunghezza variabile rispetto agli hash di lunghezza fissa. Questo dovrebbe essere considerato durante lo sviluppo. Rif. : link

Supponendo che un utente malintenzionato abbia accesso al segreto, al sale e al valore hash crittografato memorizzato nel database, è necessario preoccuparsi della potenza del proprio schema di crittografia simmetrica. La crittografia deve essere resistente agli attacchi di testo noti ( link ). Al momento è possibile utilizzare AES.

Se l'utente malintenzionato conosce l'algoritmo di crittografia / hashing che si sta utilizzando, che può ottenere dal codice sorgente, può utilizzare la forza bruta come al solito. Prima decifrare con la chiave che sta testando, quindi confrontare gli hash.

Si noti che questo modificherà la velocità di collisione di hashing.

Vorrei semplicemente aggiungere un po 'di pepe all'hash invece - sarebbe più prevedibile per te e altrettanto facile da sfruttare. Cerca di non adattarti a uno di quelli comuni, come quelli supportati da oclhashcat.