¿Deben revelarse las contraseñas en un mensaje de error?

Esta pregunta está cargada, pero estoy completamente de acuerdo con la respuesta: no, las contraseñas no deben revelarse en los mensajes de error. Las contraseñas nunca deben escribirse en ningún lugar sin el consentimiento explícito del usuario. Considere los siguientes roles y cómo podrían acceder a la contraseña incorrecta que el usuario acaba de escribir:

• El usuario. Ese es el único papel que debería poder saber lo que acaba de escribir. Bien.
• Alguien surfea por los hombros. La mayoría de los formularios de entrada de contraseña ocultan la contraseña en **** ; mostrando una contraseña en pantalla derrota esta protección. Esto es irrelevante si la contraseña no se muestra en un entorno de producción (pero hay más información sobre esto más adelante).
• Un administrador del sistema donde estaba la contraseña. Un administrador malintencionado generalmente puede obtener la contraseña insertando un código de registro subrepticio, sin embargo, este es un ataque activo, con riesgo de ser detectado. Incluso si la contraseña solo se muestra en las configuraciones de desarrollo, significa que el código está ahí y se puede reactivar con un cambio de apariencia inocente de muchas variables de configuración a la vez. Es una práctica común ocultar las contraseñas de los administradores: no están registradas por ningún software público general que no haya visto en la web y que haya visto nunca; los administradores de sistemas y el personal de soporte de TI suelen desviar la vista cuando un usuario escribe una contraseña en su presencia.
• Un desarrollador de la aplicación a quien se le ha realizado un informe de error. Ese rol nunca debería tener acceso a las contraseñas. No es bueno incluir las contraseñas en las trazas de error, incluso si solo se muestran a quienes tienen el mayor uso de las trazas.
• Un atacante roba una copia de seguridad de las trazas de error, o puede ver una traza de retroceso en una configuración incorrecta (como la configuración accidental de display_errors=on ).

El valor de la contraseña incorrecta como un activo depende de lo que es. Si es un error tipográfico en la contraseña correcta, la contraseña incorrecta es prácticamente tan valiosa como la contraseña correcta. Si la contraseña es una contraseña para otro sitio (oops, escribí la contraseña de mi sitio de producción en el formulario de inicio de sesión del usuario en el entorno de prueba), es prácticamente tan valiosa como una credencial para ese sitio. Revelar la contraseña incorrecta tiene un alto riesgo de revelar un activo de alto valor.

La respuesta del desarrollador es profundamente insatisfactoria:

  

Sí, ejecutar el servidor de producción con display_errors = encender e imprimir backtraces con argumento es un riesgo de seguridad. Por eso nunca debes hacerlo.

Primero, existe una fuerte preocupación de seguridad incluso en un entorno de desarrollo, incluso si los registros solo se muestran a quienes los verían legítimamente.

Segundo, todo "es un riesgo de seguridad", pero algunos riesgos son peores que otros. Los backtraces pueden revelar información confidencial que pueden ser activos en sí mismos o que pueden convertirse en un solo paso es una ruta de ataque. No es tan malo como entregar contraseñas en bandeja de plata.

Zeroth y ante todo, esta respuesta muestra una visión muy limitada de la seguridad: "si usa mi software correctamente, no tendrá ningún riesgo directo". Incluso si eso fuera cierto (no lo es), la seguridad es una preocupación integral. Es difícil asegurar que todos los componentes de un sistema más grande se utilicen exactamente como el autor de ese componente. Por lo tanto, los componentes deben ser robustos, esto también se conoce como "defensa en profundidad". Una regla como "nunca registrar contraseñas" es más simple que "no mostrar los trazos anteriores a aquellos (¿quién?) Que no deberían verlos, y desactivarlos de todos modos (y si los necesita, demasiado mal)".

Puede ser difícil reconocer qué es una contraseña y qué no lo es. Se puede argumentar que ocultar las contraseñas crea la expectativa de que las contraseñas siempre estarán ocultas, lo cual es malo si no lo están. Creo que la tasa de éxito es más que suficiente para justificar el mejor esfuerzo aquí.

NUNCA devolvería las credenciales por ningún motivo durante una excepción, depende del desarrollador hacer algo como una impresión de var_dump para verificar lo que están pasando, cualquier otra cosa puede filtrar datos que no deberían ser.

Por supuesto, es una buena práctica nunca mostrar mensajes de excepción a los usuarios, y en otras circunstancias puede usarse fácilmente para explotar aún más el sitio, pero esto es demasiado fácil y no veo una razón clara por la que lo aprobaría. tipo de detalle de vuelta.

Los errores de MySQL son mucho mejores (usuario @ dirección, contraseña sí / no), informativos pero no demasiados datos (aunque podría argumentarse que no quiero que las personas conozcan las direcciones internas o mi mecanismo de autenticación). / p>

PHP también es conocido por no tomar tu mano en absoluto, y lanzarte a los tiburones cuando haces algo mal (porque está mal documentado), por lo que parece estar a la altura del curso.

La forma en que lo hace la DOP es absolutamente errónea, y no hay excusa para ello.

Los mensajes de error, incluso en un sistema configurado correctamente, terminan en todo tipo de lugares: registros de errores, mensajes de error orientados al usuario, etc. Las personas cometen errores, y el riesgo de exponer las credenciales de la base de datos es demasiado alto , mientras que el beneficio (señalar una contraseña incorrecta) es marginal en el mejor de los casos. Cuando se produce un error de este tipo, el culpable puede ser algo así como un SQL no válido, una infracción de restricción, problemas de red o un servidor de base de datos corrupto. Incluso si la contraseña es incorrecta, no hay razón para mostrarla; simplemente lanzar con un mensaje en la línea de "credenciales de base de datos no válidas" o "acceso denegado a la base de datos" sería suficiente; Si sospechas que la contraseña no es la que quieres que sea, hay muchas formas de depurar esto específicamente. Incluso si no hubiera ningún riesgo, incluir la contraseña en el mensaje de error sería innecesario.

Si navegas por el repositorio de errores de PHP, estoy seguro de que encontrarás mucha discusión sobre este problema y otros similares. Para abreviar: el problema se discutió hasta la muerte y los desarrolladores responsables no parecen estar de acuerdo en que el comportamiento actual sea problemático, por lo que es muy improbable que se modifique pronto.

Esto significa que tendrás que encontrar una solución por ti mismo. Una última solución que funciona es configurar un controlador de excepciones global que solo str_replace s la contraseña real con una serie de asteriscos. Alternativamente, podría obligar a la DOP a no lanzar, pero luego pierde la comodidad del manejo de errores basado en excepciones, y todavía tiene que desinfectar los mensajes de error de la DOP (solo que ahora tiene que quitarlos tediosamente de las DOP y de las declaraciones de DOP).

Simplemente oculte la contraseña usando str_replace ().

// Connect using PDO
try 
{   
    $this->dbh = new PDO('mysql:host='.DB_HOST.';dbname='.DB_NAME , DB_USER , DB_PASS); 
    $this->dbh->setAttribute(PDO::ATTR_ERRMODE , PDO::ERRMODE_EXCEPTION);           
}
catch(PDOException $e)
{
    echo str_replace(DB_PASS, ' *** LOOK @CONFIG FOR YOUR SECRET PASSWORD! *** ' , $e);
}

Normalmente, cuando se activa una excepción, significa que ocurrió un error indefinido. Y lo que sigue es el por qué y el de la excepción. Los desarrolladores de PHP Core tienen todo el derecho de mostrar las contraseñas en función del tipo de error que provocó la excepción.

Y, por supuesto, la visualización de contraseñas por cualquier motivo es insegura. Es tarea de los desarrolladores de producción ocultar las contraseñas y, finalmente, ocultar los mensajes de error.

Cuando desarrollas una aplicación para que otros la utilicen, debes ser lo más explícito posible. Por esa razón, casi todas las aplicaciones están configuradas para opciones predeterminadas mínimas y eficientes, y es responsabilidad del usuario final asegurarse de que las configuraciones sean óptimas para su aplicación.