Continuamos hoy con otros dos métodos de autenticación en Apache. El primero que vamos a ver recupera los problemas de gestión de usuarios y contraseñas pero soluciona el problema de la transferencia de contraseñas en claro sin necesidad de usar SSL. Consiste en usar la autenticación mediante digest. El procedimiento, como veréis, es muy similar al visto el otro día con la autenticación básica pero cambiando algunas de las directivas y usando la utilidad htdigest en lugar de htpassword para crear el fichero de contraseñas. El módulo de autenticación necesario suele venir con Apache pero no habilitado por defecto. Para activarlo usamos la utilidad a2enmod y, a continuación reiniciamos el servidor Apache:
$ sudo a2enmod auth_digest
$sudo /etc/init.d/apache2 restart
Luego incluimos una sección como esta en el fichero de configuración de nuestro Virtual Host:
<Directory "/var/www/miweb/privado">
Order deny,allow
AuthType Digest
AuthName "dominio"
AuthUserFile "/etc/claves/digest.txt"
<Limit GET POST>
Require valid-user
</Limit>
</Directory>
Como vemos, es muy similar a la configuración necesaria en la autenticación básica. Sólo dos notas: el fichero donde se dejan las contraseñas se indicaba con la directiva AuthDigestFile hasta la versión 2.2 de apache. Ahora, como veis en el ejemplo, es AuthUserFile. Y dos: la directiva AuthName que en la autenticación básica se usaba para mostrar un mensaje en la ventana que pide el usuario y contraseña, ahora se usa también para identificar un nombre de dominio (realm) que debe de coincidir con el que aparezca después en el fichero de contraseñas. Dicho esto, vamos a generar dicho fichero con la utilidad htdigest:
# htdigest -c /etc/claves/digest.txt dominio josemaria
Adding password for josemaria in realm dominio.
New password:
Re-type new password:
Al igual que ocurría con htpassword, la opción -c (create) sólo debemos de usarla al crear el fichero con el primer usuario. Luego añadiremos los restantes usuarios prescindiendo de ella. A continuación vemos el fichero que se genera después de añadir un segundo usuario:
josemaria:dominio:8d6af4e11e38ee8b51bb775895e11e0f
gemma:dominio:dbd98f4294e2a49f62a486ec070b9b8c
El último método que vamos a ver usa una base de datos de mySQL como repositorio de contraseñas. Esto nos permitirá preparar de forma fácil unas páginas para gestionarlas por personal no experto o, incluso, permitir al propio usuario final que haga cambios por si mismo, crear algún método de recuperación automático por email, etc. Esto, combinado con un cifrado SSL, nos proporciona un método cómodo, flexible y suficientemente seguro para la mayoría de los casos. Lo primero que debemos de hacer es instalar el módulo que nos proporciona este modelo de autenticación, activarlo y reiniciar nuestro apache:
$ sudo apt-get install libapache2-mod-auth-mysql
$sudo a2enmod auth_mysql
$sudo /etc/init.d/apache2 restart
A continuación necesitamos crear una base de datos adecuada en el servidor mysql. Los únicos campos imprescindibles son los dos correspondientes al usuario y contraseña, tal y como se muestran en la siguiente imagen. El resto, a nuestro gusto y dependiendo de si planeamos hacer alguna página para gestionarlos y las funcionalidades que queremos que tenga (nombre completo, dirección de email, etc.)
Necesitaremos, además, un usuario de mySQL con acceso a estas tablas para que Apache pueda usarlo. Con concederle privilegios de lectura (SELECT) nos basta:
Añadimos un par de registros a nuestra base de datos para hacer pruebas:
Y, por último, editamos la sección correspondiente en la configuración de nuestro Virtual Host y pedimos a apache que haga un reload de la misma:
<Directory "/var/www/miweb/privado">
AuthType Basic
AuthName "Zona Privada"
AuthBasicAuthoritative Off
AuthUserFile /dev/null
AuthMYSQL on
AuthMySQL_Authoritative on
AuthMySQL_DB httpdauthmysql
Auth_MySQL_Host localhost
Auth_MySQL_User apacheauth
Auth_MySQL_Password 4pache3Sql
AuthMySQL_Password_Table usuarios
AuthMySQL_Username_Field login
AuthMySQL_Password_Field pwd
AuthMySQL_Empty_Passwords off
AuthMySQL_Encryption_Types Plaintext
Require valid-user
</Directory>
El significado de los campos a personalizar para nuestra configuración es fácilmente distinguible:
- AuthMySQL_DB y Auth_MySQL_Host determinan los nombres de la base de datos y el servidor donde esta reside, que usaremos para la autenticación de usuarios.
- Auth_MySQL_User y Auth_MySQL_Password son los datos del usuario que apache usará para leer de la base de datos anterior.
- AuthMySQL_Password_Table, AuthMySQL_Username_Field y AuthMySQL_Password_Field describen, respectivamente, la tabla donde se guardan las credenciales de los usuarios con permiso de acceso y los campos que usaremos para almacenar sus usuarios y contraseñas.
El campo Auth_MySQL_Encryption_Types, por último, nos permite definir la forma en que la contraseña se guarda en nuestra base de datos y admite múltiples formas. Tal y como está en el ejemplo anterior, indicamos que la contraseña se guardará en texto plano. Si queremos hacerlo un poco más serio y no guardar la contraseña así podríamos, por ejemplo, almacenar un hash de la misma. Existen diversos métodos para esto, pero lo más sencillo es variar el valor de este campo por lo siguiente:
AuthMySQL_Encryption_Types Crypt
Esto nos permitirá usar las mismas firmas generadas por la utilidad htpasswd que vimos aquí o, en general, las creadas a partir de la llamada a la función crypt(). Copiamos el hash al campo pwd de la base de datos antes generada, volvemos a hacer un reload a nuestro apache y listo.
La principal ventaja de este método es su sencillez. Sus inconvenientes: lo incómodo de delegar la generación de nuevos usuarios en alguien que no sea un administrador de sistemas o de hacer un front-end para que sea el propio usuario quien cambie su contraseña. Y, por supuesto, que dichas contraseñas viajan en claro a través de la red. Si queremos evitar esto último podemos crear 
No recuerdo (y tal vez no haya precedentes) la última vez que un servicio de Internet ha creado en torno suyo un ecosistema tan diverso de aplicaciones y servicios como está ocurriendo con 
Pero que el uso de twitter corre también el riesgo de convertirse en un verdadero coñazo es algo más que evidente. Por un lado empiezan a proliferar bots y herramientas que permiten la automatización de seguimientos y respuestas automáticas (
Desgraciadamente al otro lado, el que nos permitiría controlar de alguna forma esta actividad, sigue habiendo pocas cosas interesantes. Pero haberlas, haylas. Una de ellas nos la proporciona 
Un cluster de 400 ordenadores para auditar la seguridad de una clave WPA en 10 minutos por 34$ (17$ si sólo queremos usar la mitad) mediante un ataque por fuerza bruta, la única posibilidad factible por el momento contra este sistema. Todo lo que necesitas, aparte de pagarles, es el ESSID de la red que quieres auditar, una captura de tráfico lo suficientemente grande (unos 10 Mbytes, indican en 
Hacía ya tiempo que había empezado a recibirlos, pero este es de lo mejorcito y me han llegado más de 10 copias en las últimas 12 horas así que debe de haber campaña. Cuidadín...
Bitdefender es un antivirus dentro de lo que podríamos considerar “gama media” según 
En cuanto a la integración con el escritorio, el botón de “Hide” minimiza el programa en el “System Tray” y, aunque la integración no es perfecta en KDE 4.x, funciona de forma correcta tanto en este como en Gnome. Los idiomas disponibles son sólo cuatro: inglés, frances, portugues y rumano. Un detalle muy vistoso es que tiene una opción para colocar un “widget” sobre el escritorio (file drop zone, lo llaman en la configuración) sobre el cual podemos arrastrar archivos o carpetas para ser analizados y que funciona perfectamente en ambos escritorios. Por último, es posible añadir extensiones para integrarlo con nautilus en Gnome o con konqueror (pero sólo en KDE 3.x) aunque estas han de ser compiladas manualmente por el usuario. No tiene opciones de integración con ningún cliente de correo electrónico.
