¿Se ve comprometida la privacidad al compartir URL con hash SHA-1?

Es mejor pero no perfecto.

Aunque (actualmente) es imposible obtener la URL para un hash determinado, por supuesto, cada URL tiene el mismo hash.

Por lo tanto, no es posible ver todas las URL que un usuario navega, pero es muy probable que obtenga la mayoría de ellas.

Si bien no es posible ver el usuario A visita HASH1 y concluye que HASH1 significa fancyDomainBelongingToUserA-NoOneElseVisits.com , por ejemplo, es posible simplemente calcular el hash para CheatOnMyWife.fancytld y luego ver qué usuarios visitan ese sitio.

No consideraría que eso proteja la privacidad de los usuarios.

También los usuarios coincidentes que visitan muchos de dominios similares pueden ser bastante reveladores.

Creo que es bueno que quieras proteger la privacidad de un usuario, pero lo que estás creando parece oponerse a proteger la privacidad, por lo que no creo que sea posible hacerlo con una configuración simple (por ejemplo, la URL de envío del cliente, en cualquier forma, directamente a su servicio backend).

Como han señalado otros, el hashing usando sha1 es un buen primer paso, pero solo logra privacidad contra humanos que arriesgan un vistazo rápido a la base de datos. No le brinda mucha privacidad contra los algoritmos diseñados para analizar el contenido de la base de datos.

También está filtrando más que la URL visitada: el usuario también le dice a qué hora estuvo en línea y miró la URL dada si realiza una comprobación en tiempo real.

Algunos otros han sugerido soluciones para mitigar los problemas de privacidad. Si bien todos son mejores que no hacer nada, no resuelven el problema. Por ejemplo, la solución de Google de solo enviar 32 bits del hash se ve bien, pero que aún solo asigna todas las direcciones URL existentes a una tabla hash con 4 mil millones de ranuras. Algunas de estas ranuras pueden contener un gran número de entradas, pero dado que no todas las direcciones URL tienen la misma probabilidad de ser visitadas (por ejemplo, es mucho más probable que se visiten las direcciones URL de Facebook que la página de inicio de alguna escuela primaria) y las direcciones URL de un solo dominio lo más probable es que haya un hash bastante equitativo en los 4 mil millones de ranuras disponibles, aún así será bastante fácil de adivinar, dado un conjunto de urls completas que contienen el mismo prefijo de 32 bits, que realmente se visitó (especialmente para google, que tiene un pagerank datos sobre una gran cantidad de urls por ahí ...)

Un ataque de este tipo involucra a alguien que está construyendo una tabla arcoiris de URL en las que está interesado. Podrías hacerlo más difícil por

1. Usar una función de hash de contraseña en lugar de sha1, que toma mucho tiempo para calcular el hash, pero esto significará que el complemento de su navegador parece no responder.
2. Salan tus hashes. Obviamente, no puede dar a cada usuario su propia sal, o todos los hashes para la misma URL proporcionada por diferentes usuarios serán únicos, lo que probablemente hará que su aplicación sea inútil. Pero cuanto mayor sea la base de usuarios, menos usuarios necesitarán los mismos valores de sal. Aún no protege la privacidad del usuario, pero hace que sea más difícil calcular las tablas arco iris para averiguar exactamente qué URL se visitaron, y si alguien lo hace por la sal de un usuario específico, solo la privacidad de todos los demás usuarios que comparten su sal. está comprometido.

Sin embargo, esto todavía no ayuda en absoluto en los casos en que un atacante no está interesado en el conjunto completo de URL con hash, pero solo quiere responder preguntas muy específicas (por ejemplo, qué usuarios visitaron las URL que pertenecen a los dominios en ¿Una "lista negra" dada?) Dado que tales consultas solo involucrarán una lista corta (tal vez unas pocas docenas hasta unos cientos de miles de URL, dependiendo del tamaño de la lista negra), es trivial hacer hash de cada una de ellas en una cantidad corta de tiempo, no importa qué contramedidas utilice para disminuir la velocidad.

Es peor que eso, porque muchos sitios web solo tienen algunos puntos de entrada comunes, el más probable es que solo sea el dominio seguido de una ruta vacía. Otras rutas comúnmente visitadas son las páginas de inicio de sesión, las páginas de perfil, etc., por lo que el número de urls que necesita hacer hash para determinar si alguien ha visitado un dominio específico es muy pequeño. Si un atacante hace eso, perderá a los usuarios que usaron un enlace profundo en un sitio web, pero capturará a la mayoría de ellos.

Y se pone aún peor: si un atacante logra encontrar una url completa de un hash que proporcionó un usuario, podría obtener fácilmente todas las urls para una gran parte de la sesión de navegación de ese usuario. ¿Cómo? Bueno, ya que tiene una URL, puede anularla con su propia araña personalizada, mirar todos los enlaces del documento, marcarlos y buscarlos en su base de datos. Luego él hace lo mismo con esos enlaces, y así sucesivamente.

Así que puedes hacer algunas cosas para hacerlo más difícil, pero no creo que haya una manera de evitar que el usuario confíe básicamente en ti con su historial de navegación. Las únicas formas de solucionar lo que puedo ver implicarían construir un sistema distribuido que no esté completamente bajo su control y usarlo para recopilar direcciones URL, por ejemplo, un tipo de red de mezcladores. Otro lugar podría ser que los clientes descarguen una gran parte del contenido de su base de datos, ocultando así las URL que realmente les interesaban y brindando contenido nuevo para su base de datos solo en paquetes grandes, que al menos ocultaría el componente de tiempo de la navegación del usuario. .

Respuesta corta.

Si bien declara que le preocupa la privacidad de su usuario final, no está claro de quién quiere "protegerlos" y por qué motivo.

• Si la funcionalidad principal de su aplicación es, esencialmente, agrupar datos de usuarios de un cliente, enviarlos a un servidor y entregar un resultado, entonces, como destinatario de esos datos, siempre sabrá lo que esos datos son.
• Si su objetivo es proteger los datos en transmisión del cliente al servidor de terceros indiscretos, entonces se puede diseñar un esquema de encriptación para proteger la transmisión. Pero ese es el mejor que puede hacer para proteger los datos del usuario.

Respuesta larga.

Primero dices esto:

  

Estoy trabajando en un pequeño proyecto paralelo que incluye un complemento de navegador   y un servicio de backend. El servicio es bastante simple: dale una URL y   comprobará si la URL existe en una base de datos. Si se encuentra la URL   También se devuelve información adicional.

Entonces dices esto:

  

El complemento del navegador reenvía cualquier URL que el usuario abra a la   Servicio y comprueba la respuesta. Ahora, compartiendo cada URL que estés   la navegación es, por supuesto, un grande no-no.

El problema con el esquema que describe y su preocupación por la privacidad es que el comportamiento inherente de sus aplicaciones es compartir información que tradicionalmente se considera privada. Entonces, al final del día, ¿qué nivel de “privacidad” pretende proteger para quién, de qué y por qué motivo?

Si alguien acepta usar su aplicación, ya que tiene un conocimiento básico y rudimentario de lo que hace la aplicación y la información que comparte, es probable que sepan que su servidor de fondo sabrá exactamente lo que navega. Oh, claro, puede configurar cualquier esquema de hashing elaborado y elaborado que pueda crear para "enmascarar" la URL, pero al final del día, su servidor backend conocerá los datos del usuario final. E incluso si está convencido de que esta información es de alguna manera desconocida para usted, todavía no detiene la percepción de que sabría qué es la información; y, honestamente, no puedo concebir un esquema en el que pueda proporcionar este servicio y no sepa en qué URL se navega.

Si le preocupa que los datos del usuario se filtren en transmisión a terceros potenciales de algún tipo, quizás pueda encontrar algún esquema de cifrado que pueda proteger los datos que se transmiten. Para mí, eso es factible.

Pero si su deseo general es recopilar datos privados de algún tipo para analizarlos y luego entregar un resultado final, el concepto general de usted y su sistema, de alguna manera no saber los detalles sobre esos datos es erróneo. Usted controla el backend de un proceso como este y tiene acceso completo a los datos, le guste o no.

Su propuesta para almacenar hashes (parciales) de las URL es una forma establecida de mitigar el impacto en la privacidad. Aunque eso dificulta la respuesta "¿En qué páginas ha estado?" obviamente es trivial si sabes qué páginas exactas estás buscando, ya que los hash son prácticamente únicos para cada URL.

Lo que describe es exactamente el problema que tenía el servicio Navegación segura de Google resolver. Chrome y otras aplicaciones utilizan este servicio para verificar las URL sospechosas en la lista de sitios web peligrosos de Google mientras navega, con el requisito de garantizar un cierto grado de privacidad.

Google describe su método en el Libro blanco de privacidad de Google Chrome :

  

Cuando la navegación segura está habilitada en Chrome, Chrome se pone en contacto con Google   servidores periódicamente para descargar la lista de navegación segura más reciente de   Sitios inseguros, incluyendo phishing, ingeniería social y malware   sitios, así como sitios que conducen a software no deseado. Lo mas   La copia reciente de esta lista se almacena localmente en su sistema. Cromo   comprueba la URL de cada sitio que visita o archiva contra el que descarga   esta lista local. Si navega a una URL que aparece en la lista,   Chrome envía una huella digital parcial de URL (los primeros 32 bits de un SHA-256   hash de la URL) a Google para verificar que la URL es de hecho   peligroso. Chrome también envía una huella dactilar parcial de URL cuando un sitio   solicita un permiso potencialmente peligroso, para que Google pueda   Te protege si el sitio es malicioso. Google no puede determinar el   URL real a partir de esta información.

(Enfatiza lo mío)

Tenga en cuenta que si algunos falsos positivos son aceptables para su servicio, puede almacenar solo una pequeña parte del hash con el beneficio de una búsqueda más rápida y negabilidad plausible .

Si bien todas las demás respuestas se centran en cómo transferir la url a su servicio backend "correctamente", la conclusión general parece ser que no es posible.

Me gustaría sugerir un enfoque diferente, que puede no ser posible en su caso de uso, pero creo que es un método valioso para al menos discutir.

En lugar de enviar la url al backend, ¿por qué no enviar la base de datos al complemento y hacer la búsqueda allí ?

Por supuesto, esto introduce todo tipo de problemas nuevos. La base de datos es probablemente muy grande, puede contener información que no desea en la máquina de sus usuarios, etc. Pero para aplicaciones simples / pequeñas, esta podría ser una solución válida.

No es mucho mejor para la privacidad del usuario. Por ejemplo, https://www.google.com/ tendría siempre el mismo hash, por lo que se sabría quién lo examinó.

Dependiendo de las necesidades de su proyecto, es posible que deba considerar otras opciones que le convienen, una de ellas sería no transmitir todas las URL cada vez, por ejemplo. También puedes consultar solo FQDN y no la URL completa, lo que sería mucho mejor para la privacidad.