Ci scusiamo per questa domanda probabilmente noobish. Finora, ho letto che il confronto / verifica delle password è implicitamente compreso nel livello dell'applicazione e non nel database. Ad esempio in PHP, si farebbe usando la funzione password_verify() e non tramite una query come
SELECT * WHERE username = foo AND password_hash = $2y$10$blahblah
Quale sarebbe una solida causa contro questo? O si tratta di un approccio perfettamente valido al confronto / verifica delle password?
La migliore pratica consiste nell'utilizzare gli hash salati per la password. Il confronto di due hash salati comporta la rimozione del sale dalla password memorizzata, l'accodamento alla password del testo libero e il rimontaggio e il confronto dell'eguaglianza. Per questo motivo, non è qualcosa che potrebbe facilmente far parte di un'istruzione SQL WHERE.
Anche se suppongo che questo possa essere implementato a livello di DB, la maggior parte delle implementazioni recupererà l'utente per ID e quindi confronterà gli hash nel livello dell'app.
Non vi è alcun motivo di sicurezza per cui non è possibile hash manualmente la password e confrontare utilizzando un'istruzione SQL. Ci sono motivi di non sicurezza per farlo, però.
SELECT hashed_password FROM users WHERE userid=?
Il recupero della password con hash dal database e il confronto nel codice richiede solo un singolo accesso al database.
SELECT salt FROM users WHERE userid=?
SELECT 1 FROM users WHERE userid=? AND hashed_password=?
Il confronto in SQL richiede due accessi: uno per ottenere il sale (tu sei usando i sali per utente, giusto?) e uno per eseguire il controllo. La penalità legata alle prestazioni potrebbe essere un problema (o potrebbe non esserlo).