viernes, 19 de agosto de 2011

Moodle, Drupal, SHA512 y John The Ripper.

A ver si no me lío mucho y voy al grano.

Problema:

"Sincronizar" usuario de una plataforma Moodle 1.9.x y un Drupal 7. Los usuarios deben poder acceder al Drupal7 con la misma cuenta que Moodle. No he visto módulo SSO para Drupal 7 así que decide cocinarme yo el tema. El problema es que no sabía que en Drupal 7 no "hashea" el password con MD5 sino que lo hace con SHA512.

Marrón:

Las pruebas las hice con Drupal 6, hace un tiempo, y le he comentado por anticipado al cliente "eso con un script lo soluciono en una mañana". Mal. Muy mal. Pero bueno, el proyecto está en marcha y lo único que falta es solucionar este pequeño inconveniente.

Descripción del marrón:

  • "El" Moodle y "el" Drupal se ejecutan en distintas máquinas. No es problema, por lo menos yo no veo inconveniente, a priori.
  • Tengo funcionando un script en PHP que exporta los usuarios a un fichero CSV en la máquina Moodle. Sin problema.
  • La máquina Moodle envía por scp el fichero a la máquina Drupal. Sin problema.
  • En la máquina Drupal ejecuto un script lee los registros del CSV y los inserta en la tabla users de Drupal. Aquí está el marrón.
Como indicaba, Drupal no usa md5 sino sha512, por lo tanto si intentas logearte en el sistema no podrás acceder.

Posible solución:

La mejor solución, o la más adecuada en este caso, a mi modo de ver, sería instalar OpenLDAP y se acabarían los problemas, pero no es posible.

La posible solución(no válida a efectos de LOPD, privacidad y demás, pero bueno, al final lo que cuenta es solucionar el problema( ¿?¿?¿? ) ) sería.

A) Averiguar el password del usuario.
B) Insertar/actualizar el campo password de la tabla users de Drupal.


Para el punto B, Drush es la solución, máxime cuando vamos a usar PHP y bash(shell_exec vía PHP). No voy perder el tiempo en este punto, ya que en este post viene bien explicado.

Para el punto A) voy a utilizar el fichero listado_users_passwords.txt generado en la máquina que corre Moodle, cuyo contenido(es un ejemplo, así que no os molestéis en hacer el gamberro que he modificado los datos ^_^).
user,12c41121e857a474b1ce23e24166019, guillermopuertas@microsoft.com

Preparo el fichero para que John The Ripper pueda leerlo e intentar que me indique el password del usuario y poder pasarlo como parámetro a Drush para actualizar el password.

Ahora viene el verdadero motivo por el cual escribí este post: aplicaciones multihilo.

Instalar John en un sistema basado en Debian GNU/Linux no tiene ciencia. Aptitude o apt-get install john y problema resulto. Luego bastaría con:

john -format=raw-MD5 listado_users_passwords.txt

Y en cinco minutos tema resuelto. Esto está muy bien si sólo tienes un usuario, pero cuando son 429, necesitas sí o sí agilizar el proceso. La verdad es que todavía no tengo muy claro el concepto de multihilo a nivel de programación, pero lo que sí he observado es que muchas aplicaciones compiladas para distribuciónes Linux NO tiene soporte multicore, por lo tanto tu dual o quad core por el que has pagado XXX€ y del que tanto farda con tus compis, se queda en un cutre core la mitad del tiempo de proceso. John The Ripper no es una excepción. En el proceso anterior, abrí htop y pude comprobar a ojímetro como uno de los cores del procesador/(Intel(R) Core(TM)2 Duo CPU E7200 @ 2.53GHz) del PC del trabajo estaba más ocioso que Paquirrín en agosto.

Decidí investigar,leer y comprender el por qué. John The Ripper, por lo menos en la versión para Ubuntu/Debian GNU/Linux , sólo va a usar 1 core de tu máquina.En el wiki de Openwall encontré un artículo muy interesante acerca de "Parallel and distributed processing with John the Ripper", que por supuesto recomiendo leer. Seguí navegando y no recuerdo en qué web, leí algo acerca de la versión Jumbo de John The Ripper. En la práctica es un patch que permite usar varios cores. Lo mejor de todo no es esto. Lo más interesante es que me he enterado de que hay una "Community-enhanced version" Jumbo Powered. Genial. La descargo, la compilo y a probar. Juzguen ustedes mismos.

Comando: john -format=raw-MD5 listado_users_passwords.txt
Versión John: Version: 1.7.3.1-1
Paquete: deb
SSOO: Ubuntu 10.10 x86
Kernel: 2.6.35-30-generic-pae
Resultado John:
Loaded 1 password hash (Raw MD5 [raw-md5])
3169Y (user)
guesses: 1 time: 0:00:05:25 (3) c/s: 4876K trying: 314d* - 318bh

Comando: john -format=raw-MD5 listado_users_passwords.txt
Versión John: Version: 1.7.8-jumbo-5
Paquete: src(tar.gz)
SSOO: Ubuntu 10.10 x86
Kernel: 2.6.35-30-generic-pae
Resultado John:
Using raw-md5 mode, by linking to md5_gen(0) functions
Loaded 1 password hash (Raw MD5 [gen])
3169Y (user)
guesses: 1 time: 0:00:02:32 DONE (Fri Aug 19 13:06:13 2011) c/s: 10374K trying: 314d* - 3132E

No sé si al final consiguiré mi propósito, seguro que aplicaré KISS y solucionaré de otro modo el problema.

Nota: sí, he elimando el fichero .john de mi $home.


1 comentario:

Amhairghin dijo...

Si señor, hackeo de contraseñas. xD

Yo intentaría pasar el Moodle a SHA, porque, aunque MD5 mola, ya sabemos que tiene ciertas inconsistencias.

Saludotes.