security - ¿Está usando una seguridad GUID aunque oscura?
security-by-obscurity (12)
Al principio estaba listo para dar un sí no calificado, pero me hizo pensar si eso significaba que TODA autenticación basada en contraseña es seguridad por oscuridad. En el sentido más estricto, supongo que lo es, en cierto modo.
Sin embargo, suponiendo que tiene usuarios que inician sesión con contraseñas y no está publicando ese GUID en ninguna parte, creo que los riesgos se ven compensados por las contraseñas menos seguras que tienen los usuarios, o incluso por la contraseña de sysadmin.
Si hubiera dicho que la URL de una página de administrador que no estaba protegida incluía un GUID codificado, la respuesta sería un sí definitivo.
Si usa un GUID como contraseña para una aplicación pública como un medio para obtener acceso a un servicio, ¿esta seguridad es oscura?
Creo que la respuesta obvia es sí, pero el nivel de seguridad me parece muy alto, ya que las posibilidades de adivinar un GUID son muy, muy bajas, ¿correcto?
Actualizar
El GUID se almacenará en un dispositivo, cuando esté enchufado, se enviará a través del GUID a través de una conexión SSL.
¿Tal vez podría generar un GUID, luego hacer una incrustación de AES de 128 bits en el GUID y almacenar ese valor en el dispositivo?
Claro que es seguridad por oscuridad. Pero es esto malo? Cualquier contraseña "fuerte" es seguridad por oscuridad. Usted cuenta con que el sistema de autenticación es seguro, pero al final si su contraseña es fácil de adivinar, no importa cuán bueno sea el sistema de autenticación. Entonces, crea una contraseña "fuerte" y "oscura" para que sea difícil de adivinar.
En realidad, usar un GUID como contraseña no es una buena idea (en comparación con encontrar una contraseña verdaderamente aleatoria de longitud equivalente). Aunque parece largo, en realidad solo son 16 bytes, que generalmente incluyen la dirección MAC del usuario, la fecha / hora y un elemento aleatorio pequeño. Si un pirata informático puede determinar la dirección MAC de los usuarios, es relativamente fácil adivinar los GUID posibles que generaría.
Es mejor que usar "contraseña" como contraseña, al menos.
No creo que un GUID se considere una contraseña segura, y hay muchos generadores de contraseñas fuertes que podrías usar tan fácilmente como Guid.NewGuid ().
Es solo seguridad a través de la oscuridad en la medida en que eso es lo que son las contraseñas. Probablemente el problema principal con el uso de un GUID como contraseña es que solo se usan letras y números. Sin embargo, un GUID es bastante largo en comparación con la mayoría de las contraseñas. No hay contraseña segura para una búsqueda exhaustiva; eso es bastante obvio. Simplemente porque un GUID puede o no tener alguna base en algún tipo de sello de tiempo o tal vez una dirección MAC es algo irrelevante.
La diferencia en la probabilidad de adivinarlo y otra cosa es bastante mínima. Algunos GUID pueden ser "más fáciles" (leer: más rápido) para romperlos que otros. Más tiempo es mejor. Sin embargo, una mayor diversidad en el alfabeto también es mejor. Pero, de nuevo, la búsqueda exhaustiva revela todo.
Estoy de acuerdo con la mayoría de las otras personas en que es mejor que una contraseña débil, pero sería preferible usar algo más sólido como un intercambio de certificados que esté destinado a este tipo de autenticación (si el dispositivo lo admite).
También me aseguraré de que realice algún tipo de autenticación mutua (es decir, haga que el dispositivo verifique el certificado SSL de los servidores para asegurarse de que sea el que espera). Sería lo suficientemente fácil de mí para agarrar el dispositivo, conectarlo a mi sistema, leer el GUID y volver a reproducirlo en el sistema de destino.
GUID es para prevenir colisiones accidentales, no intencionales. En otras palabras, es poco probable que adivine un GUID, pero no es necesariamente difícil averiguar si realmente lo desea.
Realmente depende de lo que quieras hacer. Usar un GUID como contraseña no es en sí mismo seguridad por oscuridad (pero cuidado con el hecho de que un GUID contiene muchos bits imaginables del total de 128: hay una marca de tiempo, algunos incluyen la dirección MAC de la máquina que la generó, etc.) pero el verdadero problema es cómo va a almacenar y comunicar esa contraseña al servidor.
Si la contraseña se almacena en un script del lado del servidor que nunca se muestra al usuario final, no hay mucho riesgo. Si la contraseña está incrustada en alguna aplicación que el usuario descarga en su propia máquina, deberá ocultarla en la aplicación, y no hay manera de hacerlo de forma segura. Al ejecutar un depurador, un usuario siempre podrá acceder a la contraseña.
Si uno puede observar el GUID que se envía (por ejemplo, a través de HTTP Auth), entonces es irrelevante qué tan adivinable es.
Algunos sitios, como Flickr, emplean una clave API y una clave secreta. La clave secreta se usa para crear una firma a través del hash MD5. El servidor calcula la misma firma usando la clave secreta y realiza la autenticación de esa manera. El secreto nunca necesita pasar por la red.
En mi opinion, la respuesta es no.
Si configura una contraseña para que sea un GUID recién creado, entonces es una contraseña bastante segura: más de 8 charcters, contiene números, letras y caracteres especiales, etc.
Por supuesto, en un GUID se conoce la posición de ''{'' , ''}'' y ''-'' , así como el hecho de que todas las letras están en mayúsculas. Así que mientras nadie sepa que usa un GUID, la contraseña es más difícil de descifrar. Una vez que el atacante sabe que está buscando un GUID, se reduce el esfuerzo necesario para un ataque de fuerza bruta. Desde ese punto de vista, es seguridad por oscuridad .
Aún así, considere este GUID: {91626979-FB5C-439A-BBA3-7715ED647504} Si supone que el atacante conoce la posición de los caracteres especiales, su problema se reduce a la búsqueda de la cadena 91626979FB5C439ABBA37715ED647504 . Brute forzando una contraseña de 32 caracteres? Solo sucederá durante su vida, si alguien inventa una computadora cuántica funcional.
Esto es seguridad al usar una contraseña muy, muy larga , no por oscuridad .
EDITAR: Después de leer la respuesta de Denis Hennessy, tengo que revisar la respuesta. Si el GUID realmente contiene esta información (específicamente la dirección MAC) en una forma descifrable, un atacante puede reducir considerablemente el espacio de claves. En ese caso, definitivamente sería seguridad por oscuridad , léase: bastante inseguro .
Y, por supuesto, MusiGenesis tiene razón: hay muchas herramientas que generan contraseñas (pseudo) aleatorias. Mi recomendación es seguir con uno de esos.
En general, introduce vulnerabilidades de seguridad si incrusta la clave en su dispositivo o si transmite la clave durante la autenticación. No importa si la clave es un GUID o una contraseña, ya que la única diferencia criptográfica es su longitud y aleatoriedad. En cualquier caso, un atacante puede escanear la memoria de su producto o espiar el proceso de autenticación.
Puede mitigar esto de varias maneras, cada una de las cuales, en última instancia, se reduce a aumentar la oscuridad (o nivel de protección) de la clave:
Encripta la clave antes de almacenarla. Por supuesto, ahora necesita almacenar esa clave de cifrado, pero ha introducido un nivel de indirección.
Calcule la clave, en lugar de almacenarla. Ahora un atacante debe realizar una ingeniería inversa de su algoritmo , en lugar de simplemente buscar una clave.
Transmita un hash de la clave durante la autenticación, en lugar de la clave en sí, como otros han sugerido, o use autenticación de desafío-respuesta . Ambos métodos evitan que la clave se transmita en texto sin formato. SSL también lo logrará, pero depende del usuario para mantener una implementación adecuada; has perdido el control sobre la seguridad .
Como siempre, cada vez que se dirige a la seguridad, debe considerar varias compensaciones. ¿Cuál es la probabilidad de un ataque? ¿Cuál es el riesgo si un ataque tiene éxito? ¿Cuál es el costo de la seguridad en términos de desarrollo, soporte y usabilidad?
Una buena solución suele ser un compromiso que aborde cada uno de estos factores satisfactoriamente. ¡Buena suerte!
Recomiendo no usar un GUID como contraseña (excepto tal vez como una inicial que se cambiará más adelante). Cualquier contraseña que deba escribirse para ser recordada es intrínsecamente insegura. Será anotado.
Editar: "inherentemente" es inexacto. ver conversación en comentarios