Hoy nos centraremos en la autenticación.
Fíjate: el no repudio de un documento se puede asegurar si estamos seguros de con quién estamos hablando y tenemos un medio de probar qué es lo que dice.
Es decir, no repudio = autenticidad + integridad
Man in the middle y impersonation son muy similares, y la defensa contra ambos es la misma:
- man in the middle: Malloy se pone en medio de una comunicación entre Alice y Bob, que piensan que están hablando entre sí cuando en realidad los dos hablar con Malloy
- impersonation: Alice habla con Malloy pensando que está hablando con Bob. Puede que Bob ni sepa que hay una conversación en marcha.
La diferencia es que en el caso de man in the middle malloy tiene algo más de ventaja: si Alice pregunta algo que solo puede responder Bob, Malloy podría preguntárselo a Bob y entonces le responde a Alice.
Diffie Hellman no ofrece autenticación: vamos a acabar hablando de forma segura, sí, pero con Malloy: Alice habla con Malloy y Bob también habla con Malloy, sin saber que Malloy existe. Malloy puede limitarse a descifrar los mensajes que le envía Alice con la clave que comparte con Alice, leerlos y cifrarlos con la clave que comparte con Bob para enviarlos modificados o sin modificar.
Hay muchas formas de guardar nuestra identidad en internet:
- Más informal: mi nombre de usuario, mi dirección de correo electrónico...
- Más formal: certificados, DNI electrónico...
En el caso de webs o empresas, la identidad puede ser simplemente que cuando el usuario se conecta a bancosantander.com, que el servidor que le responda sea propiedad del Banco Santander
Image 
Estos son los factores clásico de la autenticación
El hackeo de 2022 a Activision se produjo así:
- Activision usaba un un sistema 2FA que enviaba número de confirmación por SMS
- Los atacantes inundaron a whatsapp a los trabajadores "somos el servicio técnico, necesitamos su número de confirmación para atender una incidencia"
- Un trabajador acabó harto de las inundaciones y envió su número de confirmación
Pregunta: ¿el orden en que se prueba cada factor importa? Es decir: ¿es lo mismo?:
- preguntar por una clave y depués por algo que tenemos
- preguntar por algo que tenemos y después por una clave
Depende del sistema, y especialmente de lo difícil que sea atacar cada paso. Interesa preguntar primero lo que sea más difícil atacar.
En el 2FA de Gmail preguntan primero por contraseña y después confirmación en el móvil. Eso es porque Gmail bloquea la cuenta si detecta muchos intentos de pruebas de contraseña: Gmail considera que "adivinar una contraseña" es más difícil que "robar un móvil".
Aunque los CAPTCHA son ejemplos sencillos de desafío-respuesta, vamos a centrarnos en protocolos criptográficos
Como parte de otros protocolos, se suele implementar un sistemas challenge-response para probar que alguien tiene la clave privada que se corresponde con una clave pública
Fíjate:
- Cuando hablamos con alguien, nos envía su certificado con su clave pública. Con los mecanismos del tema de PKI sabemos que esa es, sin ninguna duda, la clave pública de Bob
- ¿Pero realmente estamos hablando con Bob? En realidad solo estamos hablando con alguien que TIENE la clave pública de Bob, igual que nosotros la tenemos ahora.
- Aunque sepamos que esa es sin duda la clave pública de Bob, aún es necesario asegurarse de que estamos hablando realmente con Bob. Le desafiamos a que firme algo con la clave privada que dice tener.
Diagrama editable: https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNqNUctqwzAQ_JVFp5Y6l6bQYmjATQyBhgbqqy9raR0L9HBlKRBCvqq3XvNjlWOnNBBKddJqZ3ZmtHvGrSCWso4-AhlOC4kbh7o0EE-mJKfJbHb3YqsUlvlqtR4asY7Pk1M_hbnCLUF7_KpijX3zkn6GWd26QBVClAKFwC951MH69ZrwvEGlyGzouWRP0_vH5qGZ7kp2zcp7kd38QG7_YYMUCOq4rB0K-9vCm_UEdktu4CcnJwtZ15ImS1JKo4EWHQJy6wS6MU2WF3_wo3YwMSuXx08Dg2r8B2t6HkuYJqdRiriPfT-lZL4hTSVL41VQjUH5PvchQkMr0FMupLeOpTWqjhKGwdtiZzhLfYx4Bo07HVGHb7IApH4
Es un Diffie-Hellman tradicional, pero los mensajes van firmados con las claves privadas de cada parte
De esta forma, si tenemos y confiamos en la clave pública de la otra parte (ver tema PKI), entonces sabemos que no se ha puesto nadie en medio de las comunicaciones
Esta es la versión de D-H implementada en SSL/TLS
La BBDD podría cifrar las contraseñas, pero eso es una solución parcial: si alguien es capaz de robar la base de datos, es muy posible que también sea capaz de robar la contraseña de cifrado.
Aún así, guardar las contraseñas cifradas es sin duda mejor que guardarla en claro. Simplemente, hay soluciones mejores que no requieren una contraseña de cifrado, como veremos a continuación
Que el adminitrador de la BBDD conozca la contraseña es un problema: ¿realmente podemos confiar en él? No sería la primera vez que el ladrón está dentro de casa, y que sea el administrador de sistemas
Diagrama editable: https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp9jzsLwjAUhf9KuKst7hkKljo5KIhblmtyq4EmqXkgUvrfTWtLN890Oee7rwGkUwQcAr0SWUmNxodHIyzLOnRaUllVu9rdObuFhF47tmcXDOHtvPpROZyZumn-QDnNVDlPOp-2zsmc92z2KijAkDeoVT5wmDIB8UmGBPBcKmoxdVGAsGNGU68w0lHp6DzwFrtABWCK7vqxEnj0iVZoeXKhxi_lzVGW
Nota: Alice podría enviar o bien su contraseña, o bien su hash. Es normal que Alice envíe a Bob (una página web) la contraseña, pero Bob calcula inmediatamente el hash: Alice se fía de Bob, pero Bob no se fía de la base de datos
Diagrama editable: https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNp1kLsOwjAMRX8l8gSiFXuHSlRlYgCpYstiGpdGahPIQwhV_XfSl8oAHu89tq_dQakFQQKWnp5USbnEu8GWKxbq0MiS4jTdZfqWsKv1aKRme3ZBa1_aiIkK5shkeb5CsxW04MVjP4cCG8eBCWqYn7j_EyJWo603y6rtj4Hn03d7PKZd1aUggpZMi1KEM7vB4-BqaonDkElQhX6IxVUfUP8Q6OgopNMGkgobSxGgd7p4qxISZzwt0PyqSew_ELlmNQ
Diagrama editable: https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNptkE8LwjAMxb9KyUlxw3sPA8c8eVAY3nqJa-YK26r9g8jYd7edmyiYY94vLy8ZoNKSgIOlu6e-okLh1WAnehZq16qK0izb5PrC2dl6NEqzLTuhtQ9t5JsK4sTkRfGBZiW0gpRO4wJKbJ0AJqll_gf7Y5CwBm2ziiOcL_vWf2yPh2-TdIocu5BAR6ZDJcN1Q2QEuIY6EhCzSKrRxziiHwPqbxId7aVy2gCvsbWUAHqny2dfAXfG0wLNH5qp8QUjTmYe
- Entrada:
- `password`
- `cost`, 10 ó 12 es usual son valores usuales
- `salt`, que se se escoge automáticamente. La *salt* es otro nombre para el *nonce*
- Derivación de clave, que es el proceso lento de Blowfish, se hace $2^{cost}$ veces.
- Cifra con la clave derivada la cadena estándar *OrpheanBeholderScryDoubt* 64 veces.
Fijaos que ejecutar bcrypt sobre la misma contraseña "sesamo", da resultados diferentes. De esta forma se puede guardar las contraseñas repetidas sin que ndie pueda saber que son repetidas
Observa: El token está cifrado con una clave **que solo conoce Bob**
En esta transparencia se muestra el caso de que el usuario utilice nombre/contraseña para autenticarse, pero funciona exactamente igual si usa un servicio no-password como el de Google:
1. El usuario entre en la web manolita.com, que utiliza Google como autenticación
2. Google confirma la identifidad de usuario en el móvil y avisa a manolita.com
3. manolita.com envía al usuario un token de autenticación
Diagrama editable: https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNptkU1OwzAQha8ymlUrHCG2liiiDasuilSx82aIJ8QisYN_hFDVU3EELobzU1SkeDnzvffs5xNWTjNKDPyR2FZcGnrz1CkL-Ty2puJis7nZulcJLyGRNw5u4ZlC-HReT1Rejsy2LP-geZNHeVWMcoVHaqNC0NxC-octGAhoKDSrQSIvcesF18P-2qMYbywhune2cA87U3vSbjXHiTtonKf10ut6jqYyP99WTOpr2xGYPA_7h6VAz6FPHCIpiwI79h0ZnWs9DbDC2HDHCocSNNeUhh6UPWc09ZoiP2kTnUdZUxtYIKXojl-2Qhl94gs0f800PP8Cu0KNqw
Diagrama editable: https://mermaid-js.github.io/mermaid-live-editor/edit/#pako:eNpdkEFOAzEMRa9ieQViKsQ2EkUFuuoCJMQuG5N4mIiZZHAcEKp6Ko7AxQhNixBeWf7v-8veokue0WDm18LR8W2gZ6HJRqi1GoPjxXJ5tio6ZJY3FgOPuZCEBOdwTzm_J_EH-JepjsXeakDTC0e4hJvQC_l0Upq5u4AhCZ3-i7lOTwZm1uDC12fsmrsxVarEHmg77zZXf5VjoHCeC2clG7HDiWWi4Ot92x_Yog48sUVTW889lVEt2riraJk9Ka990CRoehozd0hF08NHdGhUCh-hw4_acPcNO9hsng
En el ejemplo un sistema de pagos por tokens: queremos poder comprar desde una APP o una web, pero no nos interesa darle a la web nuestra tarjeta de crédito o nuestra contraseña de Paypal
Podemos usar tokens, que se validan y caducan en cada paso, y así no hace falta decirle nuestra tarjeta de crédito a nadie
Kerberos se utiliza, por ejemplo, en redes Windows corporaivas: un usuario de dominio se autentica en el DC y obtiene un token que luego puede utilizar en cualquier ordenador de la empresa
CUIDADO: en los ciberataques actuales, los atacantes buscan por todos los medios hacerse con estos tokens
Si fuerzas "reglas para las contraseñas"...
- Baja la entropía de las contraseñas: los atacantes ya no tienen que probar contraseñas que no contengan números
- No evitas que los usuarios acaben usando contraseñas sencillas que cumplan las reglas: S3samo!
- No evitas "trucos" como "Sesamo2022" "Sesamo2023"