TL; DR Sì, se fatto correttamente, il sistema che hai progettato dovrebbe fornire un piccolo vantaggio in termini di sicurezza, ma probabilmente non è l'opzione migliore.
La versione espansa:
Quando progettiamo la sicurezza in un sistema, per prima cosa sviluppiamo un modello di minaccia, e quindi scopriamo in che modo il nostro sistema attenuerà quelle specifiche minacce. Quindi, la domanda per te è: "Qual è la minaccia che stai cercando di proteggere dal sistema, e questo design mitiga ragionevolmente quella minaccia?" dove "ragionevolmente" significa efficacemente riduce la minaccia ad un livello accettabile di rischio senza aggiungere costi o complessità eccessivi.
Quindi, mi sembra che la minaccia specifica che stai cercando di proteggere sia un utente malintenzionato che scarica gli hash delle password e i sali dal database dell'applicazione web.
Se vogliamo stabilire che un utente malintenzionato abbia la possibilità di eseguire query nel database nel contesto dell'applicazione, ciò rappresenta un problema valido. Tuttavia, in generale, suggerirei che non in realtà lo stabiliscono. Ciò porta l'hacker a poter accedere a un'ampia gamma di dati potenzialmente privilegiati e l'aggiunta di complessità al sistema per proteggere questo target (hash e sali) senza aggiungere complessità per proteggere gli altri dati privilegiati non ha senso ... A meno che questi dati non siano significativamente più preziosi di altri dati nel database. Al contrario, vorremmo in genere che il nostro modello di minaccia enumeri la minaccia più generica di un utente malintenzionato che accede illegittimamente al database e che lo protegge nel suo complesso.
Tuttavia, andiamo avanti e aggiungiamo questo al nostro modello di minaccia come una minaccia valida che necessita di attenuazione, dal momento che il meccanismo di attenuazione è ciò di cui avevi davvero una domanda in primo luogo.
Quindi, si sta spostando la verifica della password su un sistema separato e il fatto che il sistema esponga solo un'API che fornisce una password oracle un modo valido per difendersi da questa minaccia? Sì. È. L'isolamento dei dati sensibili in sistemi specializzati per scopi specifici è un modello standard per la sicurezza delle informazioni, come il modo in cui memorizziamo le chiavi segrete nei moduli di sicurezza hardware. In questo caso, tuttavia, sono molti i costi e la complessità da aggiungere per una minaccia piuttosto ristretta, quindi non so che lo raccomando di solito, ma sicuramente ha alcuni (piccoli) potenziali vantaggi di sicurezza.
Tuttavia, questo non è l'unico meccanismo che hai a disposizione per ridurre questa minaccia. A seconda del tuo motore di database, potresti essere in grado di utilizzare qualcosa come stored procedure per verificare le password e, al minimo, negare l'accesso dell'applicazione agli hash delle password, quindi non possono essere scaricati e i sali possono essere recuperati individualmente. Potenzialmente potresti persino avere il database calcolare la verifica per te e non permettere all'applicazione l'accesso a hash o sali, ottenendo in modo efficace gli stessi identici obiettivi che hai disposto, senza la complessità di un sistema aggiuntivo.
Oppure, potresti seguire la strada estremamente popolare della federazione di identità e autenticazione e eliminare completamente gli hash delle password e i sali. In un'impostazione aziendale è possibile disporre di un provider di federazione che consente di delegare l'autenticazione e gestire invece qualcosa come un token SAML e, nel mondo Web, è possibile utilizzare OAUTH e consentire alle aziende come Google e Facebook di preoccuparsi della gestione delle credenziali e autenticazione, e non è necessario avere password, eliminando completamente questa particolare minaccia.