¿Se incluye un GUID secreto en una URL de seguridad a través de la oscuridad?

Intentaré responder la pregunta en sí misma sin darte una lección sobre qué usar y qué no usar.

Teniendo en cuenta tus suposiciones (que son suposiciones bastante osadas, OMI)

• se utiliza SSL.
• No se registra en ninguna parte.
• Los GUID no son fácilmente predecibles.
• La contraseña es segura.

Entonces no, esto no es seguridad por oscuridad. Esto es seguridad por, bueno ... seguridad. Su seguridad depende de la incapacidad del atacante para adivinar / conocer la contraseña y no de la incapacidad del atacante para adivinar / saber cómo funciona su sistema. Su contraseña es, de alguna manera, su clave. Siempre que su seguridad dependa de su clave, estará bien.

Ahora, me temo que está intentando algo como almacenar directorios en su servidor con esos GUID y contraseñas y luego vincular a los recursos dentro de esos directorios. En ese caso, absolutamente no! No lo hagas Las contraseñas no deben tratarse de esa manera.

Seguridad a través de la oscuridad significa violar principio de Kerckhoffs , que se puede resumir de esta manera: asuma que toda inteligencia es pública y mantenga la aleatoriedad en privado.

Esto significa que su seguridad no debe verse afectada al hacer público su protocolo. Por otro lado, mantener una contraseña privada es el punto central de una contraseña.

Debería poder cuantificar cuánto conocimiento falta el atacante. Eso es imposible con un protocolo, no se puede medir qué tan difícil es para el atacante resolverlo. Eso es eminentemente posible para una contraseña: es la entropía que se empleó para generarla.

Un esquema cuya seguridad depende del secreto de una contraseña nunca es secreto por oscuridad. La generación de la contraseña puede ser de seguridad por oscuridad (si se elige que la contraseña sea inteligente en lugar de aleatoria), pero el uso de la contraseña no lo es.

La elección entre sus dos propuestas depende únicamente de lo que el cliente y el servidor harán con la URL. Tenga en cuenta que por cliente y servidor, me refiero a todo a cada lado de la conexión SSL; Si tiene un front-end de servidor que decodifica la solicitud HTTPS y la reenvía a un back-end, ambos forman parte del servidor.

La inclusión de un secreto dentro de una URL fuera del campo de contraseña (y algunas veces incluso en el campo de contraseña) suele ser mala porque la URL puede terminar en muchos registros, tanto en el lado del cliente (historial del navegador) como en el lado del servidor. Si la solicitud proviene de su aplicación y no a través de un navegador, ese es un lado seguro. Debe observar detenidamente el lado del servidor, tanto en la forma en que está ahora como en la forma en que puede evolucionar en el futuro. ¿Hay algún registro? ¿Qué información incluyen? ¿Cómo se protegen los registros? ¿Dónde están respaldados?

Con respecto al uso de GUID: mientras que algunas API de Windows proporcionan GUIDs "algo aleatorios pero en realidad predecibles", hay pocas razones para usarlos. Se adhieren a los UUID aleatorios (versión 4), utilizando un buen generador de números aleatorios con entropía adecuada. Si no tiene una función de biblioteca adecuada, genere 128 bits aleatorios, y si necesita UUID compatibles con RFC, aplique la máscara uuid[6] = (uuid[6] & 0x0f) | 0x40; uuid[8] = (uuid[8] & 0x3f ) | 0x80; .

Veamos si podemos desglosar esto:

1. Estás usando SSL, lo cual es bueno. SSL encripta todos los datos que envía, incluida la URL. Sin embargo, SSL solo protege los datos mientras está en tránsito. Lo que significa que tanto el servidor como el cliente finalizan los datos pueden ser legibles.
2. Si tiene un token de seguridad (nombre de usuario / contraseña, clave generada aleatoriamente o lo que sea) y lo transmite de forma segura (es decir, SSL, consulte el punto 1), entonces, para alguien que intente interceptar los datos, no hará ninguna diferencia. El bloque de datos cifrados se almacena. No pueden verlo.
3. Debe comprender completamente cómo el servidor maneja los datos (ahora descifrados) que recibe. Como se mencionó en las otras respuestas, un servidor http típico registrará las URL que recibe. Esto y cualquier otra cosa que el servidor haga con la URL se convierte en una fuente de posibles fugas de datos.
4. También debe comprender completamente cómo funciona el cliente (y las bibliotecas de sistema operativo que utiliza) para asegurarse de que no pierda su token de seguridad (sin importar dónde lo almacene en sus datos). Si el cliente es un navegador o no es en gran medida irrelevante para su pregunta
5. Realmente no puedes confiar en el cliente. Si el cliente conoce el token de seguridad, suponga que el usuario también lo sabe. En general, esto no es un problema con un nombre de usuario y una contraseña normales, pero si está usando una clave compartida entre varios usuarios, no puede revocar fácilmente el acceso.

En resumen, necesita saber dónde (y en qué estado) están los datos en todo momento. Tanto en tránsito como en reposo. Si entiende que puede decidir qué riesgos desea preocuparse o puede necesitar una mitigación adicional.

Su premisa básica de pasar un token de seguridad en la URL a través de HTTPS no es la seguridad a través de la oscuridad. Sin embargo, puede que aún no sea una gran idea, y probablemente haya mejores formas de hacer lo que usted quiere hacer.

Según uno de tus comentarios, parece que estás creando una URL tal que saber la URL de una parte de los datos no hace que la url de otras partes de los datos sea estimable (cualquier clave aleatoria de larga duración funcionaría). Dependiendo de cuáles sean sus objetivos generales, esto puede ser adecuado (he trabajado con un software que hace esto), pero no consideraría esto como una contraseña.

El anterior formato <user>:<password>@<host> está en desuso y no es compatible con todos los navegadores principales , así que no lo use. Sin embargo, los navegadores que lo admiten convierten un URI HTTP de este tipo en una solicitud con autenticación básica HTTP .

Por lo tanto, su pregunta debería ser más bien sobre la autenticación básica HTTP y los parámetros URI a través de HTTPS. Y la principal desventaja de este último es que la URL solicitada puede aparecer en varias ubicaciones, es decir, los archivos de registro del servidor web, el historial del navegador, la referencia HTTP, etc., lo que puede resultar en una divulgación de las credenciales utilizadas. Así que, una vez más, no hagas eso.

En su lugar, use HTTP Basic o Digest Authentication, o algún otro esquema de autenticación comprobado.

El esquema de URL de nombre de usuario / contraseña tiene la posibilidad de cifrar esos valores para la transmisión, mientras que la solicitud de obtención normal no lo hace. Sin embargo, muestra el esquema HTTPS allí, así que no veo ningún problema.

Una falla es que un usuario querría marcar una de sus URL, que podría quedar desprotegida y, por lo tanto, ser tomada por alguien. El primer esquema permite un marcador sin el combo de nombre de usuario / contraseña. Sólo un pensamiento.

Su segundo esquema parece similar a enviar credenciales de inicio de sesión en un formulario utilizando GET en lugar de POST. Nadie realmente lo hace. ¿Es menos seguro? Tal vez, pero no hay razones concretas por las que eso sea así. La gente simplemente prefiere POST porque está más "oculta" en la transacción HTTP.

Un pensamiento final, es bueno seguir las prácticas estándar. La seguridad por oscuridad es excelente contra un ataque amplio, pero un ataque enfocado será brindado. Las mejores prácticas tienen la posibilidad de protegerlo contra factores externos no relacionados con el protocolo HTTP, como la ingeniería social, para capturar nombres de usuario y contraseñas. Centrarse en la seguridad no debería ser demasiado estrecho.