¿Puedo ocultar qué cuenta de mi base de datos es la cuenta de administrador, por lo que un atacante no sabrá qué hash descifrar primero?

Yo diría que esto es un poco demasiado problemático teniendo en cuenta lo que se obtiene al hacerlo. Creo que cuando el atacante tiene acceso a la base de datos, tiene problemas mucho mayores. Ofuscar el estado de administrador de un usuario solo le costará al atacante un tiempo adicional, pero una APT (Amenaza Persistente Avanzada) probablemente no será disuadida por este hecho.

La seguridad a través de la ofuscación tiene, en el mejor de los casos, una eficacia limitada: para determinar si es adecuada, debe comprender qué amenazas desea contrarrestar. Si un actor de amenazas puede leer su base de datos directamente, ¿qué beneficio tiene ocultar un detalle almacenado en particular?

Si hay hay beneficio en la ofuscación (asegúrese de que realmente puede demostrar esto), entonces emplee el tipo de ofuscación que aborda esa amenaza (valores cifrados, fuentes de datos fuera de línea, hash, etc.) ).

Estoy de acuerdo con Black Magic en que probablemente no valga la pena hacerlo, pero si quisieras, podrías usar una función de derivación de claves para crear una clave de cifrado basada en la contraseña y usarla para cifrar el contenido de la columna Estado.

Potencialmente, el estado debería mantenerse en la memoria para cualquier sesión abierta de usuarios, por lo que aún podrían ser vulnerables al atacante.

Esto significaría que tendría las mismas restricciones que su atacante, asumiendo que no conoce las contraseñas de sus usuarios. No podría leer el estado de la base de datos, y si quisiera cambiar el estado de un usuario, tendría que cambiar su contraseña al mismo tiempo.

Muchos sistemas modernos realmente separan el inicio de sesión del usuario (cómo se autentican) de sus "perfiles" (permisos que tienen), implementados como dos o más sistemas discretos. Su servidor de inicio de sesión podría tener un GUID, un nombre de usuario con hash y una contraseña con hash; en un inicio de sesión exitoso, transfiera la sesión al servidor de aplicaciones. Mientras su servidor de aplicaciones no se vea comprometido, la base de datos de inicio de sesión es inútil incluso si se vuelca.

Como paso adicional, también puede cifrar los datos del usuario con una clave del servidor de inicio de sesión (almacenado como parte de la sesión), lo que también hace que el servidor de aplicaciones sea más seguro. Dos sistemas son típicamente más difíciles de vencer que uno. Sin embargo, si no está dispuesto a configurar dos servidores (o clústeres), y todo esto parece demasiado trabajo, entonces probablemente esté mejor con su diseño actual. El simple hecho de saber a qué cuentas dirigirse no facilita el trabajo; si el atacante puede descifrar uno, puede descifrarlos a todos con computación paralela.

La sugerencia de PlasmaHH fue: "anteponer una letra a la contraseña cuando se escribe" hash (en realidad, varias letras, era una "identificación de grupo") y hacer que el mecanismo de autenticación pruebe todas las combinaciones ".

Aunque es algo seguro por la oscuridad, y necesita estar emparejado con buenas prácticas como:

• un factor de trabajo fuerte en bcrypt
• administradores que tienen una contraseña segura
• formas de evitar que el atacante tenga una copia de la base de datos en primer lugar

Es una buena manera de reducir la velocidad de un atacante lo suficiente para que la contraseña se cambie antes de que se encuentre.

El descifrar una contraseña no trivial (suponiendo que haya utilizado un factor de trabajo sólido) puede demorar entre algunos días y algunos meses, por lo que es factible, pero si no saben qué cuenta vale la pena piratear, tiene que hacerlo. hackear cada cuenta.

Entonces, a menos que tengan suerte o que hayas nombrado a una cuenta de administrador "admin", tendrán que probar varias cuentas, lo que hará que sus costos sean al menos un orden de magnitud más grandes, haciendo que el atacante espere más, compre más poder , o rendirse.

En conclusión, no es inútil, ya que es un elemento disuasivo barato que no molesta al usuario.

Tenga en cuenta que si tiene indicios de que alguien sea un administrador, como una publicación de otra persona editada por ellos (si solo los administradores pueden hacer eso), enmascarar su estado en la db es inútil.

Como han mencionado otros, esto tiene problemas como evitar que usted haga un administrador de usuario sin cambiar o al menos pedirle su contraseña.

Si está disponible, solicitar la autenticación de 2 factores para los administradores probablemente sería una mejor manera de proteger las cuentas de administrador.

Sí, puedes. Solo agrega el estado de administrador como parte de la contraseña.

gusta: HereIsMe! 65371 = admin HereIsMe! 65370 = regular

Luego, al iniciar sesión, intente primero primero y luego admin, como esto:

if (sha512($password . "0") eq $hash) {
blabla user functions
} else {
if (sha512($password . "1") eq $hash) {
blabla admin functions
}
else
{
show incorrect password message
}
}

IMPORTANTE: asegúrate de asegurarte de que alguien no pueda editar su último carácter con su propia contraseña. Por ejemplo, asegúrese de que el formulario de registro, el formulario de contraseña olvidada y el formulario de cambio de contraseña, siempre agregue un 0 o 1 al final de la contraseña, dependiendo de su estado real. Almacene el estado en una sesión del lado del servidor, preferiblemente cifrada usando una cookie de sesión del lado del cliente.

Esto hace prácticamente imposible deducir el estado de administrador sin descifrar con éxito la contraseña.

Si su base de datos lo admite, configure un servidor de autenticación LDAP o similar, y entonces las credenciales no se almacenarán localmente.

Hay varias sugerencias técnicas interesantes aquí, pero es necesario mencionar que incluso si las implementa perfectamente, este enfoque no le proporcionará nada en caso de una intrusión por las siguientes razones:

• Si alguien tiene acceso a la base de datos (a pesar de la inyección de sql o algo así), es un hecho que pueden hacer lo que quieran en su servidor con los permisos de cualquier usuario con el que se esté ejecutando su servicio de base de datos, ya que la mayoría de los sistemas de administración de bases de datos Proporcionar funcionalidad para manipular archivos y ejecutar procesos en su host. Eso significa que el intruso puede modificar sus páginas web o el procesamiento del lado del servidor para capturar contraseñas de texto simple durante el inicio de sesión y obtener rápidamente contraseñas no cifradas para sus usuarios activos. Supongo que su cuenta de administrador es un usuario activo.
• Si alguien obtiene acceso a sus hashes de contraseña, es probable que no vayan a marcar cuáles deberían intentar descifrar primero. Simplemente ejecutarán un cracker a granel para procesarlos todos a la vez y en cada paso comprobarán todos los hashes en la tabla que están procesando.
• Incluso si mantuviera su hash de contraseña de administrador en una tabla separada o fuera de la base de datos por completo, el compromiso de las cuentas con menos privilegios probablemente llevará a una escalada de privilegios siempre y cuando la intrusión no haya sido detectada, ya que el intruso podrá hacerse pasar por la suplantación los usuarios de confianza pueden acceder a más información (mediante el uso de una cuenta de moderador para hablar con el administrador y lanzar el robo de cookies o alguna otra actividad maliciosa, por ejemplo).
• Si su sitio tiene alguna capacidad social, es muy probable que ya exponga otras formas de identificar usuarios administrativos.

Si el atacante obtuvo acceso a la base de datos, puede crear su propio hash bcrypt y reemplazar el de la base de datos. No hay necesidad de romper el hash.