[pyar] Auth entre servidor / cliente usando https y evitar robo de info en el medio ...

[Claudio Freire]

2011/1/17 Emiliano Dalla Verde Marcozzi <edvm en airtrack.com.ar>

> 2011/1/17 Daniel Moisset <dmoisset en machinalis.com>
>
> https esta bastante bien hecho, y no se te pueden meter transparentemente
>> al medio si haces las cosas bien. Es decir, armar un certificado de una CA,
>> firmar con ese el certificado que usas en el server, y poner la clave
>> publica de la CA en los clientes. Si no sabes quienes vas a ser los
>> clientes, podes pedir una firma de una CA conocida, pero te la van a cobrar.
>>
> Antes que nada, gracias por tu respuesta Daniel ... estoy leyendo sobre el
> protocolo https y voy a ver como es este maneje de que los clientes utilicen
> la cllave publica ...
>

En general, lo que tenés que hacer es que el server verifique el certificado
que se utilizó en la conexión https (que verifique que es un cliente
autorizado) y, asimismo, que el cliente verifique a su vez el certificado
del servidor, que es el servidor al que quiere realmente enviar el
user/pass.

Eso se hace con API de openssl o lo que uses, no de https. httplib no provee
ninguna verificación automática de la cadena de certificados otra que "acá
tenés el certificado que me mandaron del otro lado, verificalo si querés".

O sea que usar https sin validar (explícitamente) el certificado es como no
usar https. Ojo con eso.

Es posible que pylons sí provea algún mecanismo automático para esto.


>  Si no, estas reinventando la rueda de oido, cosa que en seguridad suele
>> ser mala idea :)
>>
>> En particular, el esquema que propones es la misma idea que SSL, y lo
>> estas haciendo sin firmas o sea que estas expuesto a exactamente el mismo
>> tipo de ataque de man in the middle que estabas queriendo evitar
>> inicialmente.
>>
> Aca entro en duda ... si estoy encriptando la info con openpgp, por mas que
> logren realizar un MITM, no podrian acceder a la data, correcto ? Por otro
> lado, cifrando con https como me aclaras arriba, y ademas encriptando la
> data que va por este canal seguro, es absurdo ? yo lo veo como un doble
> chaleco antibalas :P ...
>

El tema es que en criptografía todo es muy hostil. Cada paso que das lo
tenés que dar como si el piso fuera de caoba bajo un contrapiso de huevos
rajados - si pisás muy fuerte, se rompe. Si pisás torcido, se rompe. Si se
cae agua, se pudren los huevos. Si hay una grieta, el chiquito travieso de
al lado va a meter una aguja y va a romper todos los huevos, inyectar leche
y en pocos días tenés un holor a podrido que mata.

O sea... es en general mala idea reinventar la rueda en criptografía, por lo
difícil y engañoso que es. Lo que parece seguro suele no serlo, al punto que
SSL (y https) suele no ser seguro porque se implementa mal (sin validación
de certificados).

Aunque tu protocolo parezca seguro, tenés ataques como:

   1. Tu generación de claves no utiliza un buen random o no lo inicializa
   con suficiente entropía real, lo que hace que un atacante pueda adivinar la
   clave pub/priv que vas a usar.
   2. No agregaste suficiente entropía a cada paquete, lo que hace posible
   ataques diferenciales.
   3. No agregaste suficiente sal o no de la forma correcta (salting), y tu
   implementación es vulnerable a replay (interceptar un pedido sin
   desencriptarlo, y re-enviarlo para re-autenticar sin saber el user/pass)
   4. O, también por no usar suficiente salting, se pueden usar "tablas
   arcoiris" (rainbow tables) para relacionar pass cifrado con pass plano.
   5. O... ataques de canal secundario:
      1. timing attacks (medir el tiempo que tarda en cifrar, y usar ese
      conocimiento para derivar información de la clave privada)
      2. power attacks (medir el consumo de corriente y usar ese
      conocimiento para derivar información de la clave privada)
      3. Por ejemplo, un protocolo no tiene que reportar error
      prematuramente, y cada ejecución del protocolo (excepto latencias de red)
      debería tardar lo mismo exactamente y realizar las mismas operaciones. Es
      muy difícil lograr esto.

Podría seguir... pero ya se entiende. Es complejo. Si un profesional ya lo
hizo, más vale apoyarse en ese trabajo. Esto implica, apoyarse en SSL, y
hacerlo bien (validando certificados, evitando las vulnerabilidades
conocidas, etc).

Otro tema que tenés que ver es de no enviar el password y punto.

Hay muchos mecanismos de autenticación de "cero conocimiento". Es decir, que
no proveen información alguna sobre el password, sólo prueba de que el
cliente lo conoce. Son los llamados algoritmos de desafío-respuesta (
challenge-response<http://en.wikipedia.org/wiki/Zero-knowledge_password_proof>),
e incluso si no implementaras alguno de esos, podés implementar alguno
basado en passwords hasheados (y hay varios estándar, no usar un md5 o sha
plano porque eso también es vulnerable). Algo de información de esto hay en
la wikipedia ( http://en.wikipedia.org/wiki/Cryptographic_hash_function ),
pero no vi (a primera vista) ninguna mención a algún protocolo copado aún.

Ejemplos de protocolos de autenticación bien hechos tenés, por ejemplo, en
las últimas versiones (no las primeras) de OAuth por ejemplo. Aunque OAuth
está pensado para otras cosas (autenticación tripartita).
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20110117/3141eb48/attachment.html>