Examen de SPI - I*38 - Septiembre 2007

!!!
  1. Has decidido montar una página web donde se puede "subir" y "descargar" música mp3, básicamente para tí y tus amigos/conocidos, a quienes no vas a cobrar nada para cumplir la ley. Dispones de mucho disco duro, pero de una capacidad de red limitada, y teniendo en cuenta la naturaleza del material, quieres controlar debidamente el acceso a la página. Reflexiona la particularidad de autenticar en una página como ésta, por su naturaleza. Propón diversos métodos de autenticación y explica sus ventajas e inconvenientes en este problema en concreto (no en general, abstente de divagaciones). %%% El problema aquí es que el material que hay en la página es apetecible y gratuito. Además tiene problemas legales, con lo que es necesario evitar que "los amigos de mis amigos son mis amigos", es decir que mis usuarios faciliten su acceso (no les cuesta nada ni les compromete) a otros conocidos suyos. Veamos diversos métodos: Nota: El criterio de corrección básico de la pregunta es que te des cuenta que user/pwd tal cual es inviable y que usar certificados puede no ser viable para tus amigos a fecha de hoy. %%%
  2. La directiva SSLVerifyClient de apache+mod_ssl, admite como valores none, optional, require y optional_noca. Explica las diferencias entre los tres últimos, sus aplicaciones, cual elegirías según las circunstancias, y en general todo lo que consideres significativo respecto a este tema, sin divagar. %%% El valor "optional" significa que el cliente puede presentar o no un certificado, pero si lo hace debe ser de una CA válida, es decir de una reconocida por apache. El valor "require" significa que debe presentar certificado y de una CA válida. El valor "optional_noca" es como "optional", pero la CA no tiene porqué ser válida. El valor "optional_noca" sólo lo emplearemos para pruebas, puesto que si la CA no es reconocida, la autenticación carece de valor, este valor no puede usarse en un entorno de producción. Respecto a los otros dos "optional" es más flexible que "require". Con éste último, si el cliente no presenta certificado, el servidor manda un error, con lo que el usuario recibe un mensaje informativo (en el caso de firefox ni eso) poco ilustrativo, pero la ventaja de "require" es que nos asegura que sólo se accede a los objetos protegidos si hay certificado. En cambio "optional" permite mostrar un mensaje de error más ilustrativo, pero si estamos en una página tipo php, requiere algo de programación para saber si se ha presentado o no el certificado, y en las páginas estáticas, imágenes, etc, hay que asegurarse de que se ha presentado el certificado mediante complejas directivas de apache. En general, la directiva "optional" tiene un interés añadido que es poder ofrecer al visitante distintos servicios si opta o no por autenticarse, pero claro, debe hacerse, como he comentado, por programación, puesto que el servidor concede el acceso siempre.

    Como esta pregunta parece "la difícil", veamos con un símil, que no lo es. Sea una discoteca en la que en la entrada caben varias opciones: no se paga ("none"), se paga siempre ("require"), se paga o no ("optional"), se paga si se quiere y los billetes pueden ser falsos ("optional_noca"). Si no se paga nunca, cualquiera puede entrar y disfrutar. Si se se paga siempre, sólo el que paga puede disfrutar, pero los que no pagan no pueden ni ver lo que hay. Si paga el que quiere, obviamente no pagará nadie, a no ser que se ofrezcan incentivos, como "el que paga tiene barra libre y acceso a zonas VIP". Así, el que no paga por lo menos ve algo, y el que quiere más, opta por pagar. La opción "se puede pagar o no y además con dinero falso" es absurda en la explotación real de la discoteca y podría tener interés en una simulación o en un entorno de pruebas para evitar usar dinero real. %%%

  3. Una página web pretende construir un directorio telefónico de móviles. Cualquiera puede registrase en el directorio, para lo que debe introducir su nombre, localidad, provincia y el número de teléfono. Al introducir estos datos, la página envía un SMS (esto cuesta dinero) al móvil, con un código único que el usuario debe introducir para validar el alta. Un mismo usuario puede dar de alta varios móviles. Discute todos los problemas/aspectos de seguridad que veas en este problema, teniendo en cuenta la posibilidad de autenticar o no la persona. %%% En primer lugar la página contendrá datos personales y deben estar declarados según la LOPD. En cuanto a consideraciones más técnicas, cabe considerar si pretendemos autenticar tb a la persona o no. Si lo pretendemos, no hay más remedio que usar certificados, en este caso tendríamos identificada a la persona, y debeíamos hacerle firmar un contrato electrónico comprometiéndose a respetar las normas, que incluirían un alta máxima de x móviles por persona. En caso de que no autentiquemos al usuario, corremos un grave riesgo: un usuario puede hacer un script que de de alta números aleatorios (o consecutivos) de móviles, y para cada número que hacierte, producirá un coste económico por el SMS. Por ello hay que evitar que se pueda ejecutar tal script, constrolando el número de altas por IP y hora, o mejor aún, usando un buen captcha que se asegure que se hace con intervención humana; o ambas precauciones a la vez. El usuario autenticado tb podría hacer ese script, pero de no tomar estas medias, al menos sabríamos a quien tenemos que llevar al juzgado por icumplimiento de contrato.
    En cualquier caso, debemos establecer un código de longitud suficiente para evitar ataques por fuerza bruto o simplemente restringir a unos pocos intentos en caso de usar un código corto (4 cigras aleatorias por ejemplo). También debería usarse HTTPS para garantizar la confidencialidad. %%%
  4. Explica claramente los pasos que da un lector de correo SMIME hasta considerar correcta la firma de un correo. %%%
    1. Separa y decodifica las dos partes MIME: la firma y el mensaje.
    2. Comprueba que dispone del certificado con cuya llave asociada se ha firmado el correo.
    3. Si no es así, y el certificado está presente en el pkcs#7, comprueba su validez:
      1. Comprueba que la firma es correcta según los mismos pasos que estamos explicando aquí.
      2. Si dispone de CRL, u OCSP, comprueba que no está revocado.
      3. Comprueba que la cadena de certificación hasta comprobar que la CA raíz emisora es de su confianza, y que la cadena de certificación no es excesivamente larga.
      4. Calcula el reumen del mensaje.
      5. Comprueba que es igual a lo que se obtiene de descifrar con la llave pública del certificado del emisor.
      6. Comprueba que la dirección de correo contenida en el certificado coincide con la del mensaje.
      %%%