El gran problema contra el que habria que luchar no es este sino el SQL injection. En mi empresa tenemos expertos en este tipo de ataque precisamente por que se considera muy peligroso. Una vez tienes los datos el mal ya esta hecho por mucho que esten encriptados.

Ademas, el SQL injection no solo permite ver sino cambiar o borrar. Por eso creo que Pedro hace lo correcto al desactivar el foro. De hecho yo empezaria a pensar en substituir el sistema de foros por otro mas seguro.

De monento no está de más que por precaución cambiemos las contraseñas (especialmente si son débiles) como ha hecho pedro.

Voy a intentar explicaros con palabras sencillas cómo lo ha hecho. Lo primero ha sido conseguir el ‘hash’ (es decir la firma) de la contraseña a partir de la vulnerabilidad, en este caso para hacer que nos la dé el sistema se hace incluyendo en un campo de un formulario un parámetro especialmente construido para modificar los comandos que llegarán hasta la base de datos. Normalmente, tódo lo que llega desde el exterior a un servidor es filtrado y comprobado, pero a veces quedan agujeros.

Un ‘hash’ es un resumen generado a partir de algún contenido. Siempre un mismo contenido genera el mismo hash, pero a partir de un hash es muy difícil deducir el contenido. Primero porque el algoritmo usado busca eso, y segundo, porque cómo los hash tienen una longitud fija y funcionan sobre cualquier longitud de contenido, hay infinitos contenidos que equivalen a cada firma. Os pongo un ejemplo:

hash(HOLA)=d54eas, hash(pedro)=sy65s2, hash(En un lugar de la mancha)=sy65s2.

Siempre HOLA dará ese hash, y a partir de d54eas es muy difícil conseguir el contenido original. Además, hash de distintos mensejes pueden coincidir, en la jerga se le llama ‘colisión’.

La razón de almacenar los hash en lugar de las contraseñas es doble, por un lado, garantiza que ni siquiera alguien con acceso a la base de datos obtenga la contraseña, y por otro, ayuda a la seguridad en las comunicaciones, porque para comprobar la contraseña, yo no tengo que enviarla en claro, basta con que envie el hash y el servidor lo compare con el otro hash. Aunque hay una pequeña posibilida de colisión suele ser despreciable.

Hasta aquí, aunque hubiéramos tenido el hash no hubiéramos podido entrar, pero si la contraseña es débil, se puede intentar usar fuerza bruta, es decir, probar si el hash que tenemos corresponde a A, B, C…. AA, AB, AC… ZA, ZZ, AAA. Cuánto más sencilla sea la clave, antes daremos con ellas. En este caso, para hacerlo rápido, se ha recurrido a un diccionario de hashes, algo así cómo una guia telefónica inversa, dónde ya están introducidos todos los casos típicos (pocas letras, palabras de diccionarios…) de hash.

Espero haberme explicado.

Saludos

Me parece que la decision de cerrar el foro obedece antes al susto y disgusto que a la necesidad, ya que el simpatico intruso sugiere cual es la solucion respecto al problema que el aprovechó para descubrir tu contraseña de admistrador.

Sencillamente tienes que poner una contraseña mas fuerte.

GMail por ejemplo te testea la contraseña cuando abres una cuenta de email, e incluso se ofrece a generarte una.

Lo del SQL inyection es un problema de WordPress y a ese respecto solo los de WordPress pueden proveer solucion.