Respuesta corta
No puedes.
Si la contraseña se almacena en el artefacto que se envía al usuario final, debe ¡Considéralo comprometido! Incluso si el artefacto es un binario compilado, siempre hay formas (más o menos complicadas) de obtener la contraseña.
La única forma de proteger sus recursos es exponer solo una API limitada al usuario final. Cree una API programática (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) o solo exponga ciertas funcionalidades en su base de datos a través de SPROC (consulte a continuación).
Algunas cosas primero...
La pregunta aquí no debería ser cómo ocultar la contraseña, sino cómo proteger la base de datos. Recuerde que las contraseñas solas suelen ser una protección muy débil y no deben considerarse el único mecanismo de protección de la base de datos. ¿Está utilizando SSL? ¿No? Bueno, incluso si te las arreglas para ocultar la contraseña en el código de la aplicación, ¡todavía es fácil olfatearla en la red!
Tienes múltiples opciones. Todo con diversos grados de seguridad:
"Rol de la aplicación"
Cree un usuario de base de datos para la aplicación. Aplicar autorización para este rol. Una configuración muy común es permitir solo operaciones CRUD.
Ventajas
- muy fácil de configurar
- Evita
DROPconsultas (por ejemplo, en inyecciones de SQL?)
Contras
- Todos los que ven la contraseña tienen acceso a todos los datos de la base de datos. Incluso si esos datos normalmente están ocultos en la aplicación.
- Si la contraseña está comprometida, el usuario puede ejecutar
UPDATEyDELETEconsultas sin criterios (es decir, eliminar/actualizar una tabla completa a la vez).
Autenticación y autenticación atómica
Cree un usuario de base de datos por aplicación/usuario final. Esto le permite definir derechos de acceso atómico incluso por columna. Por ejemplo:el usuario X solo puede seleccionar las columnas far y baz de la tabla foo. Y nada más. Pero el usuario Y puede SELECT todo, pero sin actualizaciones, mientras que el usuario Z tiene acceso completo a CRUD (seleccionar, insertar, actualizar, eliminar).
Algunas bases de datos le permiten reutilizar las credenciales del nivel del sistema operativo. Esto hace que la autenticación para el usuario sea transparente (solo necesita iniciar sesión en la estación de trabajo, esa identidad luego se reenvía a la base de datos). Esto funciona más fácilmente en una pila completa de MS (OS =Windows, Auth =ActiveDirectory, DB =MSSQL) pero, que yo sepa, también es posible lograrlo en otras bases de datos.
Ventajas
- Bastante fácil de configurar.
- Esquema de autorización muy atómico
Contras
- Puede ser tedioso configurar todos los derechos de acceso en la base de datos.
- Usuarios con
UPDATEyDELETElos derechos aún pueden eliminar/actualizar accidentalmente (¿o intencionalmente?) sin criterios. Corre el riesgo de perder todos los datos de una tabla.
Procedimientos almacenados con autenticación atómica y autenticación
Escribe no Consultas SQL en su aplicación. Ejecutar todo a través de SPROC. A continuación, cree cuentas de base de datos para cada usuario y asigne privilegios a los SPROC solo .
Ventajas
- Mecanismo de protección más eficaz.
- Los SPROC pueden obligar a los usuarios a pasar criterios a cada consulta (incluyendo
DELETEyUPDATE)
Contras
- no estoy seguro si esto funciona con MySQL (mi conocimiento en esa área es inestable).
- Ciclo de desarrollo complejo:Todo lo que quieras hacer, primero debe definirse en un SPROC.
Reflexiones finales
Nunca debe permitir tareas administrativas de la base de datos a la aplicación. La mayoría de las veces, las únicas operaciones que necesita una aplicación son SELECT , INSERT , DELETE y UPDATE . Si sigue esta pauta, apenas hay riesgo de que los usuarios descubran la contraseña. Excepto los puntos mencionados anteriormente.
En cualquier caso, mantenga copias de seguridad. Supongo que desea proyectar su base de datos contra eliminaciones o actualizaciones accidentales. Pero los accidentes ocurren... tenlo en cuenta;)
