Hash de una sesión de huellas dactilares realmente necesario?

Se me ocurren dos casos en los que sería útil:

1. Cuando los datos de la sesión se almacenan en el lado del cliente. (Como en una galleta. Por lo tanto, se me impediría llevar mi cookie a otra computadora, y se me impediría crear mis propios contenidos de cookies. (Ok, así que este no es un escenario muy probable...)
2. Cuando los datos de la sesión se almacenan en algún recurso compartido del lado del servidor (es decir, /tmp) y son vulnerables al espionaje. En este caso, si el espía es capaz de ver el contenido de la sesión, todavía no podrán falsificar una conexión a esa sesión porque no saben qué datos entraron en la huella digital.

En complemento a la respuesta de @Kai Sellgren (+1) que contiene algunos buenos consejos sobre cómo asegurar el almacenamiento de su sesión, agregaría algunas ideas que pueden explicar el hash & salt en algunas aplicaciones específicas.

No estoy hablando de aplicaciones que están utilizando la cookie como almacenamiento de sesión, todavía vemos esto, por ejemplo, en la solución de comercio electrónico Prestashop, con cifrado del contenido de la cookie (¿por qué demonios decidieron almacenar la sesión en la cookie?). Entiendo que hablar acerca del almacenamiento de sesiones del lado del servidor.

El punto clave es seguridad en capas y defensa en profundidad :

Los compromisos nunca son cosas booleanas, tu no estás 'completamente comprometido' o 'completamente seguro'. Una de las historias reales que me gusta de eso es la explicación del gusano de MySpace , muestra un ataque real y cómo los pasos defensivos deben romperse. Siempre hay un muro nuevo. Solo un ejemplo, comparto la misma IP que mi jefe cuando estoy en la oficina, y tal vez la misma navegador, esto podría romper una seguridad basada solo en IP + user-agent.

Así que en el hash & salt de session stamping claramente estamos actuando después de que algunas paredes hayan caído. Y kai nos muestra algunas de estas paredes. Cuando habla de asegurar el almacenamiento de la sesión, agregaría 2 cosas:

• es una muy buena idea alterar el session.save_path y el open_basedir de cada aplicación PHP (y obtener un Virtualhost separado para cada una). Rara vez se hace.
• si su aplicación está instalada en una ruta (como / myapp), añadir un prefix_path en la cookie de sesión (y arreglarlo para cualquier otra aplicación en el mismo servidor)

Ahora imaginemos un compromiso realista. Tienes varias maneras de comprometer la sesión en el lado del servidor:

• La aplicación se está ejecutando en un sitio web con algunas otras aplicaciones que se ejecutan en otras rutas (o en otros dominios en el mismo servidor). Y al menos en de estas aplicaciones es bastante inseguro. En el peor de los casos, el código del lado del servidor podría inyectarse en esta aplicación, pero algunos de los muros de seguridad (como open_basedir u otras técnicas de chroot) pueden evitar que este código inyectado afecte a su aplicación (o datos) por separado.
• Algunas de las bibliotecas javascript vienen con algunos subdirectorios de prueba que contienen scripts altamente inseguros, con no solo una buena divulgación de la sesión, sino tal vez alguna fijación o predicción de la sesión disponible.
• La aplicación es compartida, y hablando de softs similares a Wordpress se puede imaginar que algunas plataformas comparten mucho de diferentes instalaciones, con diferentes módulos y tal vez algún código personalizado. En este tipo de plataformas encontrarás ajustes para permitir alterar la sal para cada consumidor, hay una razón para eso. Uno de los sitios web podría afectar la seguridad de los demás y la separación limpia puede ser más difícil de hacer si las aplicaciones quieren administrar los sitios web todo en uno.

Su aplicación objetivo puede ser afectada por el entorno, si el almacenamiento de la sesión se puede compartir con algunos scripts de otros aplicación, o desde un script en su propia aplicación que ni siquiera notó (como estos ejemplos f*** en las bibliotecas de javascript, ¿por qué no suspendió la ejecución de php en directorios de archivos estáticos?)

A partir de este primer paso de compromiso el atacante podría potencialmente (y en aumento de gravedad):

• lea los sellos de sesión y tal vez encuentre qué información debe falsificar para obtener el mismo sello{[18]]}
• construir una nueva sesión que contenga un sello de sesión válido para su configuración y, a continuación, utilice este nuevo identificador de sesión en su aplicación. Su aplicación encontrará el archivo de sesión y lo aceptará.
• altere una de sus sesiones válidas para modificar el sello de la misma manera

Un simple hash del sello haría su vida más difícil, pero solo sería una pared para romper, la sal hacer esta pared realmente más difícil de romper.

Un punto importante es, de su pregunta, si un chico puede alterar algo en el almacenamiento de sesiones ¿ya estoy de mal humor?. Bueno, tal vez no del todo. Si es lo único que el chroot/separación/securización de aplicaciones le permite hacer esta sal será una pesadilla para él.

Y el segundo punto importante es: ¿debo hacer este nivel de seguridad en profundidad en cada aplicación web?. La respuesta es no. La sobreingeniería es algo malo y puede reducir la seguridad de su aplicación por el simple hecho de que se hizo más difícil de entender y maitin. No necesita complejizar su aplicación si:

• tienes un nivel bastante bueno de separación de almacenamiento de sesiones
• usted está solo en su servidor, solo una aplicación, y no cualquier tipo de manejo multisitio
• el nivel de seguridad de su aplicación es tan débil que una simple inyección de código está disponible en la aplicación, por lo que no se necesita una fijación de sesión para un atacante: -)

Puedo imaginar que el punto de hash esa información de huella digital es el espacio de almacenamiento, ya que el hash resultante tiene una longitud fija.

Pero usar también una sal no tiene mucho sentido para mí. Porque, como ya ha dicho, ya que los datos se almacenan en la ubicación de almacenamiento de datos de la sesión, ya tendría un problema más grande que la fijación/secuestro de la sesión si alguien pudiera obtener esos datos.

Puede encontrar una solución plausible aquí: http://shiflett.org/articles/the-truth-about-sessions

La toma de huellas digitales combate el secuestro de sesiones. El atacante no solo necesita su session_id, también necesita cualquier encabezado HTTP sensible. Añade otra barrera para el atacante, aunque una que se puede superar fácilmente.

El hash está ahí para uniformar los datos. La sal está ahí para oscurecer el proceso de hash, por lo que un atacante no puede generar una huella digital válida para su propio combinación de encabezados HTTP.

Si un hacker está en su sistema de archivos, tiene problemas más grandes: D

Muchas personas que no entienden mucho sobre seguridad combinan consejos flotando en Internet con la esperanza de que lo que terminen sea "lo suficientemente bueno". Atar el ID de sesión a la U-A rompe las actualizaciones del navegador (que Chrome hace con bastante frecuencia) y atar a la dirección IP rompe la movilidad (cualquier persona con un ordenador portátil que utiliza Wi-Fi), y muchos ISP no tienen asignaciones contiguas. Cualquier persona que pueda oler las cookies también puede oler la U-A, y probablemente tendrá acceso a la misma dirección IP porque consiguieron la cookie de Wi-Fi inseguro detrás de un NAT.

Lo que probablemente quiere hacer es cambiar el ID de sesión en un intento de inicio de sesión, que es una forma confiable de evitar ataques de "fijación de sesión" (donde el atacante hace que la víctima cargue http://example.com/?SESSIONID=foo e.g. through an <img>, waits for you to log in, and now knows the victim session ID). Hay pocas razones para preservar una sesión a través de un inicio de sesión, y puede copiar los pocos cosas que necesitan ser preservadas (por ejemplo, un carrito de compras) a través.

Si un hacker puede llegar a ti sistema de archivos para ver el archivo de sesión contenido, ¿no es usted ya regado en ese punto?

Si está utilizando PHP como CGI (como en el caso de nginx), entonces creo que no. Si establece permisos correctamente, sus archivos de sesión deben tener permisos de lectura / escritura para el usuario PHP, mientras que sus archivos PHP solo deben tener permisos de lectura. Por lo tanto, si pasa la sal del servidor web a PHP, entonces el usuario de PHP no puede obtener acceso a ella (no puede crear ninguna nuevo / cambiar archivos PHP existentes que pueden ser ejecutados por su servidor web y no puede acceder al servidor web ya que se ejecuta en otro usuario), por lo que realmente no puede hackear(cambiar) las cookies (solo eliminarlas) porque no puede obtener salt. Por supuesto, también tendrá que pasar la configuración de la base de datos desde el servidor web.

Realmente nunca lo intenté, así que por favor corrígeme si me equivoco.

¿Es realmente necesaria la sal y el hash en algo como esto [huella dactilar del cliente http]?

El hash podría ser útil para reducir el número de bytes consumidos por la huella digital dentro de los datos de la sesión. Así que mientras la huella dactilar hash sea de un tamaño más pequeño que la huella dactilar en sí, esto puede tener sentido en términos de reducción de espacio. El precio es el consumo de recursos del sistema para generar el hash.

, ¿realmente tiene sentido? Usted tendría que benchmark esto para decirlo.

¿Cómo puede ser útil una sal entonces? Debo admitir que no veo razón para una sal. Solo tendría sentido hacer más difícil adivinar la huella digital de un hash. Pero como no veo ningún beneficio de seguridad en el hash de la huella digital (se mantiene solo en el lado del servidor y ya es considerablemente seguro), salting no está agregando nada.

En caso de que el almacén de sesiones en sí no se considere seguro (si eso es para el argumento), la sesión completa debería ser cifrado, no solo la huella digital.

Así que particularmente para la huella digital, no veo mucho uso en el hachís y la salazón.