La "soluzione comune" che hai citato ha un difetto evidente e evidente: non può usare il sale. Se il tuo hash ha un sale (dovrebbe), allora devi recuperare il sale prima di eseguire l'operazione di hash. E se stai recuperando il sale, dovresti solo recuperare il risultato dell'hash allo stesso tempo. In effetti, i due sono in genere memorizzati nella stessa stringa.

Idealmente, dovresti recuperare l'hash dal database ed eseguire il calcolo su di esso nella tua applicazione. Il fatto di non voler preoccuparsi delle vostre applicazioni che supportano le vostre funzioni hash è strano. Le applicazioni in genere portano, non in ritardo, i database nell'adozione della tecnologia.

La soluzione per inserire la routine di verifica password in una stored procedure è un po 'folle dal punto di vista della scalabilità; l'hashing della password, se eseguito correttamente, è estremamente intenso per il processore e la memoria. Scaricare quel tipo di carico sul database è ridicolo.

Le stored procedure spingono il calcolo dal server web al server di database, così come le query SQL complesse. Mentre questo è OK in teoria, in pratica il tuo database tende ad essere la parte meno scalabile dell'intera operazione. I server Web tendono ad essere (dovrebbe essere se si fanno le cose per bene) completamente privi di stato, quindi l'esecuzione di dieci server Web non richiede più lavoro rispetto all'esecuzione di due. I database non sono così semplici e la scalabilità del database è una delle proposte più difficili e costose affrontate dalla maggior parte dei siti Web di piccole dimensioni. Questo è immensamente più difficile se si utilizza qualsiasi tipo di logica di business lato database. Se si desidera che la cosa sia scalabile, il server delle applicazioni deve contenere la logica e nessuno stato e il database deve contenere stato e nessuna logica.

Supponendo che la procedura memorizzata usi qualcosa come bcrypt con un sale sicuro e molti round, non vedo alcun problema con ciò che stai implementando. In pratica tratta il database come provider di identità in un identità federata in cui le applicazioni sono applicazioni PHP.

Detto questo, non vedo alcun motivo per cui lo faresti. PHP ha funzioni integrate per la gestione delle password. Questi sono ben testati e, nel caso in cui un problema venga scoperto, verranno tempestivamente corretti. È improbabile che ciò si verifichi per la procedura memorizzata personalizzata. Quando si tratta di sicurezza, è (quasi) sempre meglio andare con la strada più percorsa. Quindi segui i primitivi di PHP e sii sicuro di aver capito bene.

La procedura memorizzata sta eseguendo la salatura e più cicli di hashing sicuro? Se non si implementa questo diritto, ciò potrebbe influire sulle prestazioni del DB e sulla sicurezza. C'è un sacco di librerie là fuori in quasi tutti i linguaggi web per gestire l'autenticazione sicura.

Utilizzare una stored procedure è una buona idea quando si autentica l'utente o si interagisce con qualsiasi tabella di account. In questo modo anche uno SQLi non ha potuto modificare la tabella oltre l'utilizzo delle funzioni che hai creato.

MODIFICA: sembra che qualcuno abbia fatto questo in overflow dello stack link