TL; DR Sí, si se hace correctamente, el sistema que ha diseñado debería proporcionar una pequeña ganancia de seguridad, pero probablemente no sea la mejor opción.
La versión expandida:
Cuando diseñamos la seguridad en un sistema, primero desarrollamos un modelo de amenaza y luego descubrimos cómo nuestro sistema mitigará esas amenazas específicas. Entonces, la pregunta para usted es: "¿De qué amenaza está tratando de proteger el sistema, y este diseño mitiga razonablemente esa amenaza?" donde "razonablemente" significa reducir efectivamente la amenaza a un nivel aceptable de riesgo sin agregar un costo o complejidad excesivos.
Por lo tanto, me parece que la amenaza específica contra la que está tratando de protegerse es que un atacante descarte hashes y sales de contraseña de la base de datos de la aplicación web.
Si queremos estipular que un atacante tiene la capacidad de consultar la base de datos en el contexto de la aplicación, esta es una preocupación válida. Sin embargo, en general, sugiero que no de hecho lo estipulemos. Eso hace que el atacante pueda acceder a una amplia variedad de datos potencialmente privilegiados, y agregar complejidad al sistema para proteger este objetivo (hashes y sales) sin agregar complejidad para proteger los otros datos privilegiados no tiene sentido ... A menos que estos datos sean significativamente más valiosos que cualquier otro dato en la base de datos. En cambio, generalmente queremos que nuestro modelo de amenaza enumere la amenaza más genérica de un atacante que acceda ilegítimamente a la base de datos y la proteja contra ella en su totalidad.
Sin embargo, avancemos y agreguemos esto a nuestro modelo de amenaza como una amenaza válida que necesita mitigación, ya que su mecanismo de mitigación es de lo que realmente tenía una pregunta.
Entonces, ¿mover la verificación de contraseña a un sistema separado, y tener ese sistema solo para exponer una API que proporciona una contraseña de Oracle es una forma válida de defenderse contra esta amenaza? Sí. Es. El aislamiento de datos confidenciales en sistemas reforzados para fines especiales es un patrón estándar en seguridad de la información, como la forma en que almacenamos claves secretas en módulos de seguridad de hardware. Sin embargo, en este caso, es mucho más costoso y complejo agregar una amenaza bastante estrecha, por lo que no sé si generalmente lo recomendaría, pero sin duda tiene algunas ventajas de seguridad potenciales (pequeñas).
Sin embargo, este no es el único mecanismo que tiene disponible para reducir esta amenaza. Dependiendo de su motor de base de datos, puede usar algo como procedimientos almacenados para verificar las contraseñas, y al menos denegar el acceso de la aplicación a los hashes de contraseñas, por lo que no se pueden volcar, y las sales solo se pueden recuperar individualmente. Potencialmente, incluso podría hacer que la base de datos calcule la verificación por usted, y no permita que la aplicación acceda a hashes o sales, logrando efectivamente los mismos objetivos que usted estableció, sin la complejidad de un sistema adicional.
O, podría ir por la popular ruta de la federación de identidad y autenticación, y eliminar el almacenamiento de hashes y sales de contraseña. En un entorno empresarial, puede tener un proveedor de federación que puede permitirle delegar la autenticación y, en cambio, tratar con algo como un token SAML, y en el mundo web, puede usar OAUTH y dejar que compañías como Google y Facebook se preocupen por la administración de credenciales y autenticación, y no necesita tener contraseñas, eliminando esta amenaza en particular por completo.