Burdjia

Etiqueta Seguridad, 3 entrada(s)

Feed Rss, Atom

Cómo hacer un sistema CAPTCHA propio

Mis dos webs tienen sendos formularios con los cuales cualquiera puede enviarme un mensaje.  El funcionamiento es muy sencillo:  cuando el servidor recibe el mensaje, comprueba que contiene todos los datos y que hay un correo correctamente indicado, y acto seguido me envía un mensaje con todo.  Pero claro, fue poner en marcha estos formularios y empecé a recibir SPAM.  Bueno, inicialmente recibí varios intentos de juankeo (estoy seguro de haber escrito algo sobre dar las gracias a los piratas turcos por poner a prueba la web, pero ahora no lo encuentro), el SPAM tardó un poquito en llegar, pero llegó.

La solución de añadir un CAPTCHA la barajé desde el principio, pero no me apetecía tener que meter una biblioteca de terceros ya que podía complicar las cosas.  No uso un framework al uso ni ninguna biblioteca extra, así que tendría que instalarlo y configurarlo y hacer pruebas y… paso.

Pero hace cosa de un mes hice un trámite para la TSS y me encontré con un sistema a priori muy simple pero ingenioso.  La página te presenta una lista de palabras y tienes que escribir en un campo aquella que pertenece a una categoría concreta.  Esto me recordó, también, a la pregunta de seguridad de la wiki de Free Pascal, la cual pregunta por el resultado de ejecutar una instrucción Pascal.  Así que me decidí, finalmente, a programarlo.

Cómo funciona

Primero, tenemos una tabla con dos campos:  Palabras y Categorías.  Cada palabra tiene una única categoría y no debe haber ambigüedades, lo cual limita un poco el número de palabras pero facilita las cosas luego.

Cuando se genera el formulario, se selecciona una palabra de forma aleatoriamente, que será la respuesta.  Luego se seleccionan otras tres que pertenezcan a una categoría distinta a la seleccionada.  A continuación creo un código hash combinando la palabra de respuesta con la fecha POSIX para tenerla con referencia y almaceno la palabra de respuesta junto con el hash y la fecha.  Finalmente se genera el formulario mostrando todas las palabras, desordenadas, y la pregunta, con el hash en un campo oculto.

Cuando se recibe el formulario, se eliminan del almacén todas las respuestas viejas para que no se acumulen y se comprueba si la respuesta enviada es correcta.  Si no lo es, se genera otro hash diferente.

Podéis probarlo vosotros mismos.

El resultado

Sé que el sistema no es perfecto, y seguramente que algún bot sería capaz de romperlo con facilidad, sin embargo desde que está activo he dejado de recibir SPAM.  ¿Por cuánto tiempo?  Pues no lo sé.

De todas formas me parece bastante absurdo que me envíen SPAM cuando es más que evidente que tiene un retorno del 0%.  Incluso cuando lo recibía, no lo leía, porque era fácilmente identificable: en el asunto se limitaban a poner una cadena de caracteres aleatoria.

En conclusión, ha sido muy fácil quitarse esta molestia de encima, así que si tienes este problema de SPAM no quites el formulario, símplemente añade un CAPTCHA, aunque sea simple como el mío, y asunto arreglado.

Etiquetas: Seguridad

Categorías: Artículos, Mantenimiento web, Programación, Web

Mejorando la sal en la protección de datos

Aunque el tema que voy a tratar es técnico, no hace falta saber mucho.  De hecho creo que incluso alguien que no sepa (todavía) cómo se maneja el tema de las claves de acceso y su protección puede entenderlo.  Aun así, para que todos estemos al mismo nivel, deberíais echar un vistazo al artículo Entendiendo las Funciones Hash y Cómo Mantener las Contraseñas Seguras, que explica perfectamente el tema y no precisa ningún conocimiento previo.  No hace falta que lo leas si controlas el tema.

Vale, ¿estamos todos?  Pues al turrón.

La cuestión es que, tras darle vueltas y como uno es rarito, he decidido hacer mi propio gestor de contenidos.  Que sí, que los hay muy buenos, que lo sé, que los conozco, pero es que cuatro megas (por poner el ejemplo de CodeIgniter, y que ni siquiera es un gestor de contenidos completo) para lo que necesito me parece demasiado.  Evidentemente mi gestor de contenidos ha de ser, también, mínimamente seguro.  Mi idea es confiar en el servidor todo lo que se pueda, pero el tema del acceso y las contraseñas tengo que manejarlo yo.  Buscando información encontré el artículo anteriormente mencionado (a partir de ahora lo llamaré "El Artículo").  Leyéndolo me di cuenta de que ya hacía algo bien, aunque fuera un poco por casualidad.  Esta no es la primera vez que me veo en el brete de almacenar claves de acceso.  Desde hace años uso un sistema consistente en codificar la clave junto con otro dato del usuario, normalmente su dirección de correo, usando bien MD5, bien SHA1, según me diera.  La razón era que si había dos usuarios que tuvieran la misma clave, en la base de datos no aparecieran con el mismo hash, y sin saberlo estaba añadiendo sal a la ensalada.  Bien por mi.  Cuando supe lo que era la sal, me di cuenta de la tremenda serendipia del caso, pero no me puse a analizarlo en profundidad.  Cuando me puse a trabajar en Ágora 2.0 (que publicaré, lo prometo) y en el gestor de contenidos, decidí que era buen momento para machacar el tema.  Y lo hice, ¡vaya si lo hice!  Hasta el punto de encontrar el que, posiblemente, sea el mejor método hasta la fecha para elegir la sal a usar.  Si El Artículo propone un método que con un buen ordenador necesitaría siete años (7) para crear la tabla rainbow, mi sistema necesitaría al menos catorce (14).  Y todo ello manteniéndolo KISS.  No está mal, ¿verdad?

La cuestión es sencilla.  Para poder usar la sal, hay que saber cuál es esa sal.  Es obvio, lo sé, pero es importante tenerlo en cuenta.  Tenemos dos opciones para saber qué sal usar:  calcularla o almacenarla.  En el caso de El Artículo tenemos que almacenarla, ya que obtenemos esa sal de forma aleatoria, usando mt_rand.  Si hacemos esto y un cracker nos roba la base de datos, tardará siete años por usuario (o menos, si va comprobando los resultados según los va calculando) en obtener su premio.  Sin embargo, si esa sal no está almacenada en la base de datos sino que tiene que calcularla, tardará un poco más.  ¿Qué tal si tarda en calcular esa sal tanto como en calcular el propio hash?  Pues que se duplica el tiempo.  ¿Y cómo hacerlo?  Pues haciendo que la sal sea, precisamente, un hash.  Pero, ¿cómo hacer que el piratón tarde lo mismo en calcular la sal, esto son siete años en nuestro caso?  Pues haciendo que la sal se calcule a partir de la propia clave de acceso.  Al no conocer la clave, deberá calcular una sal por cada posible clave y usar dicha sal para calcular el hash de la propia clave.  Es decir: calcular dos hash por clave.  Asunto resuelto.  ¿No?  ¿Os habéis perdido?  No problemo.  A ver qué os parece esto:


    public function ObtieneHash ($Nombre, $Clave)
    {
    # Generamos la sal.
      $Sal = substr (sha1 ($Nombre.$Clave), 0, 22);
      $Sal = substr (crypt ($Sal, '$2y$10$'.$Sal), 29, 22);
    # Obtenemos la codificación de la contraseña.
      return substr (crypt ($Clave, '$2y$10$'.$Sal), 29, 32);
    }

¿Está más claro?  Primero obtenemos una sal inicial a través de unir el nombre y la clave (para evitar que usuarios diferentes con la misma clave tengan la misma sal y devuelvan el mismo hash).  Luego re-procesamos la sal con un coste de 10 (es decir, que hace 1024 iteraciones), y finalmente usamos esta sal para calcular el hash de la clave, de nuevo con un coste de 10.  Además la función devuelve sólo el hash y no la sal, como hace crypt, ya que no necesitamos almacenarla.  Cuando el usuario intenta acceder, usamos la clave que nos dé de la misma forma.  La tabla rainbow, por tanto, necesitará el doble de tiempo para generarse, multiplicando el tiempo por el número de usuarios, ya que al incluir el nombre en la sal, la misma clave dará sales diferentes a diferentes usuarios.

Realmente desconozco si esto ya era conocido, pero lo cierto es que no lo he encontrado en ningún otro sitio.  De todas formas, podéis usarlo si lo deseáis;  y también podéis ponerlo a prueba, y si encontráis algún problema no dudéis en hacérmelo saber.

Etiquetas: Seguridad

Categorías: Artículos, Programación, Web

KITT y las descargas de Internet

Me gusta el nuevo Coche Fantástico. Bueno, siendo sinceros me gusta más el viejo Pontiac Firebird que el nuevo Mustang. ¿Y quién no prefiere un estilizado deportivo frente a un ladrillo pintado de negro, eh?


Que se atreva alguien a decirme que el mustang es más bonito.

Lo de la serie es distinto. Por mucho que la nostalgia tire de mi, he de reconocer que la nueva serie es estupenda. He leído y oído a mucha gente quejarse porque no les gusta la nueva voz. Por mi parte la nueva personalidad de KITT me gusta más, ya que es más real, más robot, con menos humanidad, lo que hace que se sugieran multitud de escenas divertidas. Lo cierto es que los guionistas se lo están currando en este aspecto. Y este es uno de los detalles que los guionistas, aun teniendo en cuenta las fantasmadas típicas de una serie de ficción como esta, están siendo bastante creíbles. Y ojo, que digo creíble, no realista, lo cual es diferente como me explicó mi profesor de interpretación de la Escuela Municipal de Teatro.

Sin embargo esta credibilidad a veces salta por los aires, y es lo que pasó hace unos pocos capítulos. A mi me rechinó enormemente, puesto que soy informático, pero cualquiera que sepa cómo funciona Internet se habrá dado cuenta.

Resulta que la empresa propietaria de KITT está siendo desmantelada, por razones que se arrastran desde el primer capítulo por lo que no contaré aquí. El propio KITT es desconectado, pero antes de que lo hagan, el coche hace una copia de seguridad de sí mismo y la sube a Internet, a un servidor y dominio que él mismo ha creado, con la esperanza de que Michael Knight Jr. (sí: se llama igual que su predecesor ochentero) y sus colegas puedan recuperarlo. Es difícil pero entra dentro de lo posible, especialmente dentro de la premisa de la serie, por lo que nos lo podemos creer sin más. Los problemas aparecen cuando se descargan la copia de seguridad.

Resulta que en la descarga falta uno de los paquetes en los que se divide la copia de seguridad. ¿La razón? Que un chaval se lo ha descargado con su consola de videojuegos así que ya no está disponible. No, no he omitido nada. Al parecer, según los guionistas del nuevo Coche Fantástico, cuando te descargas un archivo de Internet este deja de existir, dado que te lo has descargado. A ver, por si alguien no lo sabe, los archivos que hay disponibles en Internet se encuentran en el disco duro de un ordenador conectado a la red. Cuando alguien se lo descarga lo que hace es conectar con ese ordenador, este lee el archivo (igual que nuestro ordenador lee los archivos de nuestro ordenador cuando lo marcamos con el cursor del ratón) y envía a nuestro ordenador la información leída, pero evidentemente el archivo sigue estando en el disco duro del otro ordenador, al igual que los archivos que hay en el nuestro no desaparecen cada vez que los cargamos con el editor de textos, de fotos o lo que sea. ¡Menuda papeleta si no fuera así!

Pero la cosa no termina aquí. Resulta que para poder recuperar dicho paquete hay que ir a casa del chaval que se lo ha descargado, lo cual es lógico, y acceder a su videoconsola, lo cual es evidente. Lo que ya escapa a mi compresión es que para obtener el archivo tiene que jugar a un juego y encontrar una esfera dentro del mismo, así, sin anestesia ni nada. A ver, lo único que tienen que hacer es poner una tarjeta de memoria al aparato y copiar el archivo desde el disco a la tarjeta utilizando el menú del mismo, lo cual no sólo entra dentro de lo creíble sino dentro de lo posible, ya que estos aparatos lo permiten para poder copiar cosas como las puntuaciones conseguidas en los juegos, o fotografías y vídeos. Pues no: tienen que jugar un juego... Incluso la película TRON tenía más lógica, sinceramente.

En fin, nadie es perfecto.

Etiquetas: Seguridad

Categorías: Artículos, Web