• Añadir la macro _CRTDBG_MAP_ALLOC del preprocesador, ya sea definiéndola en algún archivo del proyecto o en las opciones de compilación del proyecto.
• Incluir en el siguiente orden stdlib.h y crtdbg.h en los archivos dónde se busquen las fugas de memoria. El archivo crtdgb.h sustituye las funciones malloc y free por unas propias que registran la memoria reservada y liberada.
• Añadir la función _CrtDumpMemoryLeaks () al final del programa en el que se buscan las fugas de memoria. Esta función muestra por la salida de depuración las fugas de memoria detectadas.

Todo esto sólo funcionará cuando el proyecto se compile con la macro _DEBUG definida, es decir, en lo que debería ser para todos la versión de depuración del programa.

La macro _CRTDBG_MAP_ALLOC sirve para que la función _CrtDumpMemoryLeaks () muestre información sobre el archivo y la línea en la que se produjo la fuga de memoria.

Un pequeño ejemplo de cómo quedaría todo:

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

int
main (int argc, char *argv[])
{
    /* Código del programa */

    _CrtDumpMemoryLeaks ();

    return 0;
}

Si este programa tuviera alguna fuga de memoria, al compilarlo en modo depuración y ejecutar el depurador de Visual Studio, se obtendría en la salida de éste un listado con las fugas de memoria del programa.

Para más información, leed el artículo Enabling Memory Leak Detection de la MSDN.

Esto, que en principio puede parecer un gran avance porque evita problemas de seguridad en los programas (uno de los motivos por los que en Java no se pueden manejar punteros), al final se demuestra que es un nido de bugs. Porque 212 no son -44. Y esto puede ser un auténtico problema en algo tan visible como una fecha.

El mes de marzo es un mes muy especial. Su mes anterior es de longitud variable (28 ó 29 días) y el siguiente es de 30, siendo el propio marzo de 31. Ved el siguiente código:

Calendar cal = new GregorianCalendar();
cal.set (Calendar.DAY_OF_MONTH, 30);
cal.set (Calendar.MONTH, 2);
System.out.println (cal.getTime ());
System.out.println (cal.getActualMaximum (Calendar.DAY_OF_MONTH));
cal.set (Calendar.MONTH, cal.get(Calendar.MONTH) -1);
System.out.println (cal.getActualMaximum (Calendar.DAY_OF_MONTH));

Esencialmente, lo que hace es ponernos en 30 de marzo de este año y sacar por pantalla los siguientes datos:

• Fecha actual
• Número de días del mes de marzo
• Número de días del mes de… ¿febrero?

Java, en su excelsa sabiduría, ha decidido que en este caso que 2-1=2. Porque al restar uno al mes nos quedamos en 30 de febrero o, lo que es lo mismo, 2 de marzo. Esta chorrada (obviamente en un código más complejo) nos tuvo en el trabajo una mañana entretenidos porque el número de días de los meses siempre eran 30 ó 31, incluído un inexistente febrero.

En parte fue una suerte que estuviéramos a 30 de marzo y no en 2 de abril, en cuyo caso nos daríamos cuenta del problema casi un año después de sacar el proyecto a producción. A veces Java es realmente odioso con su “deja que la JVM piense por ti“.

;Archivo INI

[sección]
clave1=valor1
clave2=valor2

En estos casos lo mejor es no reinventar la rueda, así que hice un par de búsquedas por internet, pero lo que encontré no me gustó, así que ni corto ni perezoso realicé mi propio cutre-parser que funcionaba bien para lo que quería, archivos INI creados a mano, pero no para todos los casos que podría tener un archivo INI.

Así que gracias a un poco de tiempo libre me he puesto las pilas un poco y he ido modificando aquel cutre-parser hasta algo más decente, aunque todavía le quiero dar un par de vueltas para dejarlo bien. De todos modos, el código que hay ahora mismo funciona bastante bien, así que he creado un repositorio para mini en github (por cierto, git mola mil), así no tenéis excusa para probarlo.

En mi opinión hay bastantes charlas con temas muy interesantes, por ejemplo: seguridad en servidores, BOINC, OpenGL, Python, Ruby, … Así que si os interesa algún tema de estos, pasaos por allí, la entrada es gratuita y no hace falta ningún tipo de registro.

Enlace original: Jornadas técnicas (Marzo 2010) del GUL-UC3M

En principio pensaba que el evento sería una especie de curso sobre cómo desarrollar una aplicación de Android, pero estaba equivocado, todo consistió en un poco de marketing de Android y luego las novedades de la nueva versión (la 2.1) de Android, para acabar con una ronda de preguntas de la gente.

En general, el evento no me gustó demasiado por no ser realmente técnico, pero que regalasen Nexus One hizo que valiese la pena. Y sí, en poco tiempo espero hablar por aquí de programación en Android.

En algunos paradigmas de programación (como la programación orientada a objetos) se nos dice que desde fuera de una clase sólo necesitamos saber qué se hace, no el cómo. Si la clase se encarga de interaccionar con una base de datos no necesita saber cuál es la base de datos ya que de eso se encargaría el driver (lo cual sería cierto si el estándar SQL fuera más… estándar… pero eso es otro tema). Y al resto de clases del proyecto no les importa tampoco cómo realiza esa interacción, sino que sólo deben preocuparse de que tal método devuelve los datos de la tabla cual.

¿Cómo se hace esto? Definiendo muy bien la visibilidad de la clase. Esto es, qué métodos se van a llamar desde el resto de clases (métodos públicos), cuáles están restringidos a clases “amigas” (del mismo paquete o que hereden de la nuestra, son los métodos protegidos) y cuáles no son accesibles en absoluto fuera de nuestra clase (métodos privados).

Por definición, es recomendable que todas las variables sean definidas como privadas, de forma que la única manera de manipularlas sea a través de los métodos públicos definidos por la clase y que sean éstos los que se encarguen de hacer todas las comprobaciones que sean necesarias.

Imaginemos la siguiente clase muy básica:

public class Persona {

  private String nombre;
  private int edad;

  public Persona () {
    inicializar ();
  }

  public void setNombre (String nombre2) {
    nombre = nombre2;
  }

  public void setEdad (int edad2) {
    if (edad2 > 0) {
      edad = edad2;
    }
  }

  public boolean validaVariables () {
    return edad > 0 && ! "".equals(nombre);
  }

  private void inicializar () {
    nombre = "";
    edad = 0;
  }
}

En este caso, lo que vemos desde fuera es que para la clase Persona podemos asignar una variable nombre y una variable edad. Podría haber más, pero no nos interesan puesto que no podemos interaccionar con ellas.

Además disponemos de una función para validar que los datos son correctos, pero nunca sabremos desde otra clase que existe un método inicializar.

1. Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.
2. La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.
3. La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.
4. La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.
5. Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.
6. Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.
7. Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.
8. Exigimos que el Gobierno garantice por ley la neutralidad de la red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.
9. Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
10. En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Este manifiesto es obra de muchas manos, y propiedad de todos. Si te gusta, cópialo, pásalo, publícalo en tu blog o haz lo que quieras con él.

Aunque llego con dos días de retraso, como se suele decir más vale tarde que nunca. Por cierto, para hoy (4 de Diciembre) hay convocada una manifestación concentración en diferentes ciudades de España, en Madrid será frente al ministerio de cultura a las ocho de la tarde.

Los modelos

Al basarse django en el MVC, divide la aplicación en dos partes la vista (que ya se pudo ver en el anterior post) y el modelo. El modelo define los datos que utilizará la aplicación, como podrían ser los datos de un usuario (nombre, apellidos, dirección, …).

En el caso de django, los modelos serán clases de python que heredarán la clase Model y que utilizarán unos tipos de datos especiales para definir sus atributos. Más tarde, django, gracias a su ORM, transformará estas clases en tablas de la base de datos del proyecto.

Creando un modelo

Los modelos se definen en el archivo «models.py» de la aplicación de django que los vaya a utilizar. Cada modelo será una clase de python que heredará la clase django.db.models.Model, los atributos de las clases de cada modelo deberán ser instancias de unas clases que ofrece django para poder traducir estos atributos en campos de las tablas de la base de datos. Por ejemplo, para crear el modelo de un usuario:

# models.py
# -*- coding: utf-8 -*-

from django.db import models

class Usuario (models.Model):
    """Datos del usuario utilizados en la aplicación."""

    nombre = models.CharField (max_length=40)
    apellidos = models.CharField (max_length=60)
    email = models.EmailField (unique=True)

    def __unicode__ (self):
        return '%s %s (%s)' % (self.nombre, self.apellidos, self.email)

Una breve explicación sobre el ejemplo anterior:

• Los atributos nombre y apellidos serán dos campos de texto con una longitud máxima de 40 y de 60 caracteres respectivamente en la base de datos.
• El atributo email será un campo de texto cuyo valor deberá ser único y que además sólo aceptará direcciones de correo electrónico bien formadas.
• El método __unicode__ es el equivalente a __str__ en python, es decir, se usará cuando se quiera mostrar una instancia de la clase como una cadena de caracteres.

Para conocer los tipos existentes para los atributos de los modelos, siempre se puede consultar la lista de los tipos de los modelos de django.

Una vez se tengan los modelos creados, se deberán sincronizar con la base de datos utilizada.

Configurando la base de datos

Configurar la base de datos a utilizar en django es muy sencillo, sólo hay que editar el archivo «settings.py» del proyecto. Concretamente las siguientes variables:

• DATABASE_ENGINE indica el gestor de base de datos utilizado, actualmente django sólo dispone de los siguientes módulos: postgresql_psycopg2, postgresql, mysql, sqlite3 u oracle.
• DATABASE_NAME indica el nombre de la base de datos, menos en el caso de sqlite3 que indica la ruta al archivo de la base de datos.
• DATABASE_USER indica el usuario con acceso a la base de datos anterior.
• DATABASE_PASSWORD indica la contraseña del usuario anterior.
• DATABASE_HOST indica la dirección del servidor de la base de datos, se debe dejar vacío para la máquina local.
• DATABASE_PORT indica el puerto del servidor de la base de datos, se debe dejar vacío para usar el puerto predeterminado.

Aviso: El usuario, la contraseña, la dirección y el puerto del servidor no se usan con sqlite3, ya que no son necesarios.

Una vez configurada la base de datos y creados los modelos necesarios, se podrá sincronizar los modelos de las aplicaciones del proyecto con la base de datos, sólo hay que ejecutar:

$ python manage.py syncdb

Nota: Hay que recordar que las aplicaciones del proyecto aparecen en la variable INSTALLED_APPS del archivo «settings.py», yo recomendaría (para estos ejemplos) quitar o comentar las que vienen de manera predeterminada.

Trabajando con la base de datos

Esta es una de las mejores cosas que tiene django, y es que para acceder (ya sea para consultar, insertar, actualizar o borrar una entrada) a la base de datos, gracias al ORM sólo se usan las clases definidas como modelos.

Para probar todo lo que se va a explicar sin tener que crearse vistas (que todavía no se han explicado en profundidad) siempre se puede ejecutar la consola de django:

$ python manage.py shell

Insertar, actualizar y borrar entradas

Tomando como ejemplo la clase Usuario anterior, se podría realizar:

from proyecto.aplicación.models import Usuario

# Insertar un nuevo usuario
usuario = Usuario (nombre='Pepe', apellidos='Garcia',
                   email='pepe@garcia.es')
usuario.save ()

# Actualizar los datos del usuario
usuario.nombre = 'Jose'
usuario.save ()

# Borrar el usuario
usuario.delete ()

Como se puede ver es tan sencillo como trabajar con cualquier clase de python.

Los «QuerySets»

Los «QuerySets» son conjuntos de objetos de la base de datos, es decir, los resultados de una consulta a la base de datos en forma de objetos de python.

Las clases de los modelos disponen de una instancia del gestor de objetos de la base de datos Clase.objects, en esta instancia se definen los diferentes métodos para realizar las consultas sobre la base de datos, que devolverán un «QuerySet» que contendrá los resultados.

De este modo, tomando el ejemplo de la clase Usuario:

from proyecto.aplicación.models import Usuario

# Insertar varios usuarios
usuario = Usuario (nombre='Pepe', apellidos='Garcia',
                   email='pepe@garcia.es')
usuario.save ()

usuario = Usuario (nombre='Maruja', apellidos='Perez',
                   email='maruja@perez.es')
usuario.save ()

usuario = Usuario (nombre='Pedro', apellidos='Garcia',
                   email='pedro@garcia.es')
usuario.save ()

# Conseguir todas las entradas de la base de datos
todos_los_usuarios = Usuario.objects.all ()
print 'Todos los usuarios %s' % todos_los_usuarios

# Conseguir los usuarios que se apelliden Garcia
garcias = Usuario.objects.filter (apellidos='Garcia')
print 'La familia Garcia %s' % garcias

# La familia Garcia ordenada por nombre
print 'La familia Garcia ordenada por nombre %s' % garcias.order_by ('name')

Como siempre esto no es más que una mota de polvo de lo que en realidad se puede hacer, para profundizar lo mejor es consultar la documentación de django sobre los «QuerySets».

1. Visión general

Casi todas las aplicaciones web modernas necesitan, de un modo u otro, cifrar las contraseñas de sus usuarios. Se podría decir que, desde el momento en que la aplicación tiene usuarios, y los usuarios se identifican usando una contraseña, esas contraseñas se deben guardar usando algún tipo de cifrado.

Hay muchas razones básicas para esto: las bases de datos pueden estar comprometidas, y por tanto también las comunicaciones. Pero la razón más importante es que se tiene que pensar que las contraseñas de los usuarios son datos personales. Sus contraseñas son sus claves para su privacidad, por tanto son personales, y nadie tiene el derecho de conocerlas. Y se debe cumplir esto si se quiere ganar la confianza de los usuarios.

2. El algoritmo

Ahora que se quieren cifrar las contraseñas, se debe saber cómo. Aquí entra la primera regla:

I. Cifrar las contraseñas usando técnicas de un sentido, es decir, funciones resumen (o hash).

Esto se debe a que, excepto para algunos escenarios específicos, no hay ninguna razón para que una contraseña sea descifrada. Si se cifran las contraseñas usando cifrados basados en claves (una técnica de dos sentidos) y un atacante consigue saber la clave de cifrado, se revelarán todas las contraseñas. Si no se tiene una clave para el cifrado, el riesgo desaparece, y el atacante tendrá que confiar en el uso de técnicas de fuerza bruta o similares.

Pero, ¿qué ocurre si un usuario pierde su contraseña? ¿No podrá recuperarla? La respuesta es NO. No sólo no se puede recuperar, si no que ni siquiera existe una manera de leer/conocer/ver las contraseñas de los usuarios, no importa si se es el administrador del sistema. Si un usuario pierde su contraseña, sólo se podrá reiniciarla a un nuevo valor y enviárselo por algún canal seguro al usuario, y pidiéndole que la cambie lo más pronto que pueda.

Ahora que está claro que las funciones resumen son necesarias en las contraseñas, ¿cuál algoritmo se debería usar? Hay bastantes, y dependen de las necesidades de cada uno. Los más usados son:

• Algoritmo MD5.
• Familia SHA: SHA-1 y la variantes de SHA-2 (SHA-224, SHA-256, SHA-384 y SHA-512)

En la mayoría de los casos, MD5 o SHA-1 serán elecciones adecuadas para los resúmenes de contraseñas, aunque aplicar estos algoritmos no será suficiente, como se verá a continuación.

Cuando se dice que se deberían usar funciones resumen para los cifrados de las contraseñas, y dado que estas funciones resumen son técnicas de un sentido, la siguiente pregunta es: «Si no se pueden descifrar las contraseñas, ¿cómo se comprueba que un usuario tiene una contraseña correcta?»

Hay una respuesta muy simple a esta cuestión, que será la segunda regla:

II. La entrada y las contraseñas guardadas se comparan usando los resultados de las funciones resumen, no usando cadenas sin cifrar.

Lo que significa que, una vez los usuarios han introducido sus contraseñas en la identificación, se realizará la función resumen sobre la contraseña introducida con el mismo algoritmo que se ha usado con las contraseñas guardadas, y se compararán ambos resultados. Como estas funciones garantizan que dos entradas iguales obtienen el mismo resultado (lo que no es cierto en el sentido contrario), si los resultados coinciden se considerará que la contraseña introducida por el usuario es correcta.

3. Mejorando la seguridad de los resúmenes

Todos los algoritmos de funciones resumen mencionados anteriormente comparten una característica: son públicos. Son algoritmos muy conocidos y ampliamente implementados, por lo que cualquiera puede usarlos.

Si cualquiera puede usar el mismo algoritmo que la aplicación, y por alguna razón los atacantes pueden ver la base de datos de los resúmenes de las contraseñas, ¿cómo se puede estar seguro que los atacantes no serán capaces de conseguir alguna contraseña de los usuarios probando todas las posibilidades hasta que encuentren algún resumen que coincida con uno de los guardados?

La respuesta es que no se puede. Pero se puede hacer que todo eso sea una tarea enorme y con un gran tiempo de realización, de modo que no resulte útil, a menos que puedan esperar toda la eternidad. Para lograr esto, se van a explicar dos conceptos: «salt» y el contador de iteración.

3.1. «Salt»

«Salt» es una secuencia de bytes que se añaden a la contraseña antes de conseguir su resumen. Esto hace que estos resúmenes sean diferentes a los que deberían ser usando sólo la contraseña, y como resultado se consigue protección contra los ataques de diccionario. Se pueden seguir dos estrategias para usar «salt»:

• Usar un «salt» fijo, una secuencia de bytes que se utilizarán para resumir cualquier contraseña. Se puede guardar oculto el «salt» y considerarlo un valor añadido de seguridad, pero esto puede hacer que el sistema se vuelva más vulnerable a ataques de cumpleaños y, en general, a ataques dirigidos contra la base de datos de contraseñas.
• Usar un «salt» variable, que normalmente es una opción segura (especialmente si es aleatorio). Este se genera independientemente para cada contraseña a resumir, y permite que cada contraseña guardada esté desacoplada de las demás, creando una gran protección general y un alta seguridad contra ataques dirigidos contra la base de datos de contraseñas.

En la práctica, un «salt» aleatorio (o variable) es la mejor idea porque, aunque al generarse aleatoriamente tendrá que guardarse junto al resumen de la contraseña (por lo que cualquiera podrá recuperarlo) y esto hará que sea trivial para un atacante conocerlo, permitirá que cada contraseña de usuario sea independiente del resto, por lo que tendrán que atacarse una por una.

Se tiene que pensar que, si se usa un «salt» fijo y el atacante consigue saberlo, la seguridad de toda la base de datos de contraseñas será nula. Y hay muchos métodos para que el atacante pueda conocer este «salt», como aplicar fuerza bruta en sus contraseñas o en contraseñas que tenga de algún usuario válido. En un escenario de un «salt» fijo, una contraseña débil podría hacer que el sistema de contraseñas fuera débil.

Sin embargo, si se quiere mantener una parte del «salt» en secreto, se puede usar una técnica que mezcle las otras dos, usando un «salt» compuesto de una parte fija y otra aleatoria, guardando los bytes aleatorios junto al resumen de la contraseña.

El tamaño mínimo de un «salt» es de 8 bytes. Si se usa una opción mixta, al menos 8 bytes deberían ser aleatorios.

Así, se puede definir la tercera regla:

III. Se debe usar un «salt» que contenga al menos 8 bytes aleatorios, y añadir esos bytes junto al resumen de la contraseña.

3.2. El contador de iteración

El contador de iteración es el número de veces que la función hash que realiza el resumen se aplica a sus propios resultados.

Esto significa que, una vez se ha seleccionado un «salt» y concatenado con la contraseña, se deberá aplicar la función hash (por ejemplo, MD5), conseguir el resultado, y pasarlo de nuevo como entrada a la misma función, y hacer lo mismo las veces que indique el contador de iteración.

El número mínimo recomendado de iteraciones es 1.000, y esto proporcionará una buena seguridad extra. Hay que pensar que, cuando se crea un único resumen de una contraseña para un nuevo usuario, la diferencia entre aplicar la función hash una vez o 1.000 veces no será un problema, tal vez doscientos milisegundos, pero los atacantes deberán tener que generar una enorme cantidad de intentos de resumen mediante fuerza bruta y, para un atacante, la diferencia entre aplicar la función hash una vez y aplicarla mil veces para cada intento será un gran problema computacional.

Así, se obtiene la cuarta regla:

IV. Iterar la función hash al menos 1.000 veces.

4. Secuencia de traducción de caracteres a secuencia de bytes

Antes de poder guardar correctamente los resúmenes de las contraseñas, hay algo que se debería tener en cuenta, que es la diferencia entre cadenas de caracteres y secuencias de bytes: dos cadenas de caracteres se pueden representar con diferentes secuencias de bytes dependiendo de la codificación empleada (ISO-8859-1, UTF-8, …)

Esto afecta, ya que las contraseñas suelen ser cadenas de caracteres, pero las funciones hash trabajan a nivel de byte.

4.1. Problemas codificando la contraseña introducida

En el supuesto de que un nuevo usuario se identifique con una contraseña que no contiene caracteres ASCII, y que la aplicación de identificación, que se está ejecutándo en Windows 2000 en Europa Occidental, convierta la cadena de caracteres a bytes sin elegir una codificación específica para la operación, e incluso usando la que haya de forma predeterminada, en Windows suele ser ISO-8859-1. De modo que el resumen se realice sobre esa secuencia de bytes y quede almacenado.

Entonces, este usuario vuelve de nuevo y esta vez no visita la aplicación de identificación anterior, en vez de eso usa cualquier otra aplicación con la misma base de datos de contraseñas pero en Linux. El usuario introduce correctamente su contraseña y … ¡no coincide!

¿Por qué? Porque la mayoría de los sistemas Linux, usan UTF-8 como codificación predeterminada, y las contraseñas que ha introducido el usuario en ambos casos se han codificado en diferentes secuencias de bytes, afectando a la correcta concordancia de las contraseñas.

Cómo se puede resolver esto, pues utilizando una codificación fija para las codificaciones de las cadena de caracteres a secuencia de bytes. Así se enuncia la quinta regla:

V. Antes de resumir, realizar una codificación de cadena de caracteres a secuencia de bytes usando una codificación fija, preferiblemente UTF-8.

Si se usa Java, donde las cadenas de caracteres (clases String) se codifican independientemente (aunque usan de fondo UTF-16), no habrá que preocuparse de si la aplicación usa ISO-8859-1 o alguna otra codificación en lugar de UTF-8 para su interfaz de usuario, al igual que no será necesario que la codificación para los resúmenes de las contraseñas coincidan con las de la interfaz de usuario. Sólo será necesario que la codificación sea una fija, y UTF-8 proporciona un buen equilibrio entre tamaño y conjunto de caracteres.

4.2. Problemas codificando en el almacenamiento del resumen

Normalmente se quiere gestionar y almacenar el resumen de contraseñas como una cadena de caracteres, pero la función hash dará como resultado una secuencia de bytes que no necesariamente representará un carácter válido en alguna codificación. Por esto, la secuencia de bytes del resumen no se puede codificar en una cadena de caracteres, habiendo peligro de pérdidas de datos si se realizase.

Aquí es donde entra al rescate la codificación BASE64. Codificando la secuencia de bytes del resumen en BASE64, se asegura que la secuencia de bytes de salida representa una cadena de caracteres US-ASCII válida. Por lo que se podrá codificar una secuencia de bytes en BASE64 en una cadena de caracteres US-ASCII.

VI. Finalmente, se debe aplicar la codificación BASE64 y guardar el resumen como una cadena de caracteres US-ASCII.

5. Resumen de las reglas para el cifrado de contraseñas

La lista completa de reglas a aplicar:

1. Cifrar las contraseñas usando técnicas de un sentido, es decir, funciones resumen (o hash).
2. La entrada y las contraseñas guardadas se comparan usando los resultados de las funciones resumen, no usando cadenas sin cifrar.
3. Se debe usar un «salt» que contenga al menos 8 bytes aleatorios, y añadir esos bytes junto al resumen de la contraseña.
4. Iterar la función hash al menos 1.000 veces.
5. Antes de resumir, realizar una codificación de cadena de caracteres a secuencia de bytes usando una codificación fija, preferiblemente UTF-8.
6. Finalmente, se debe aplicar la codificación BASE64 y guardar el resumen como una cadena de caracteres US-ASCII.

6. Realizándolo en Java

La forma más sencilla de cifrar contraseñas en Java, mediante las técnicas explicadas es usar Jasypt.

Si no se puede usar jasypt, o si por alguna razón se quiere desarrollar alguna característica de cifrado propia, se necesitarán:

• La clase java.security.MessageDigest para crear resúmenes. Esta clase permite especificar el algoritmo que se va a usar.
• La clase java.security.SecureRandom para generar «salt» aleatorios de una manera segura, usando algoritmos como SHA1PRNG.
• El método java.lang.String.getBytes (String charsetName), para obtener una secuencia de bytes desde una cadena de caracteres, especificando una codificación fija (UTF-8).
• La clase org.apache.commons.codec.binary.Base64, parte de la biblioteca Apache Commons-Codec, para realizar codificaciones BASE64 en la salida de la función hash.

También, se puede utilizar el código fuente para las clases org.jasypt.digest.StandardByteDigester y org.jasypt.digest.StandardStringDigester, disponible en el repositorio de jasypt.

7. Defensa frente a los típicos ataques

7.1. Ataques de fuerza bruta

Realizado sobre: Una única contraseña.

Descripción: El atacante intenta conseguir la contraseña del usuario generando todas las contraseñas posibles, resumiéndolas y probando si coinciden con el resumen de la contraseña del usuario.

Defensa: La iteración de la función hash un número de veces, como 1.000 (mínimo recomendado), el coste de la creación del resumen de la contraseña en el tiempo de identificación del usuario no es significante, pero el coste de un ataque de fuerza bruta por parte de un atacante que genera millones de resúmenes será muy grande. Hay que recordar que una de las mejores maneras de proteger los datos cifrados es haciendo que el coste de romper la seguridad sea más alto de lo que cuesta el esfuerzo.

7.2. Ataques de diccionario

Realizado sobre: Cada contraseña o una base de datos de contraseñas

Descripción: El atacante intenta conseguir la contraseña de un usuario comparando sus resúmenes contra un conjunto de resúmenes de contraseñas más probables, normalmente se generan desde una lista de palabras de un diccionario. Este ataque explota una debilidad actual de las aplicaciones, ya que muchos usuarios usan palabras del diccionario como contraseña.

Defensa: Añadiendo un «salt» aleatorio, la debilidad de las contraseñas basadas en diccionario se reduce, y la posibilidad de de que el resumen aparezca en un conjunto de resúmenes previamente creados por el atacante es mínima.

7.3. Ataques de cumpleaños

Realizado sobre: La base de datos de las contraseñas.

Descripción: Este ataque explota la paradoja del cumpleaños, la cual en resumen consiste en, teniendo un gran conjunto de resúmenes de contraseñas, las posibilidades de generar una contraseña cuyo resumen coincida con al menos uno de los resúmenes en el conjunto es mucho más alto que lo esperado. Y estas posibilidades aumentan bastante cuando el tamaño del conjunto (el número de usuarios) aumenta.

Defensa: Añadiendo un «salt» aleatorio las posibilidades de que un ataque de cumpleaños tenga éxito son mínimas, porque el atacante tendría que atacar cada contraseña por separado, y no el conjunto de contraseñas, para encontrar una coincidencia. Esto es porque se tendría que encontrar una contraseña que crease el mismo resumen que el del atacante usando el mismo «salt» que se usó para el resumen, y que es diferente para cada contraseña haciendo que el ataque pase a ser de fuerza bruta.

Espero que este pequeño manual os sea de utilidad, a mí me sirvió para mi PFC.

¿Qué es django?

Django es un entorno de desarrollo (lo que en inglés se denomina framework) para la creación rápida de aplicaciones web, basándose en el MVC (Modelo-Vista-Controlador).

Entre todas las posibilidades que ofrece están que permite trabajar con las bases de datos como si no existieran, la creación de URL bonitas sin tener que tocar nada del servidor web, el uso de plantillas en (X)HTML para la creación de las diferentes páginas, y muchas cosas más, todas ellas estupendas y supongo que todas ellas también las tendrán otros entornos similares que utilicen otros lenguajes de programación.

Iniciando un nuevo proyecto

Lo primero que se debe hacer en django es crear lo que se denomina un proyecto, éste a su vez contendrá aplicaciones que serán las que contengan el código utilizado en la aplicación web. Por poner un ejemplo: el proyecto sería un CMS y las aplicaciones las diferentes funcionalidades de dicho CMS.

Para ello se deberá ejecutar:

$ django-admin.py startproject nombre_del_proyecto

Esto creará un directorio, llamado «nombre_del_proyecto», con los archivos básicos de todo proyecto de django:

• __init__.py es el archivo de inicialización de cualquier paquete de python.
• manage.py permitirá la gestión del proyecto de django, como: crear las aplicaciones del proyecto, crear las bases de datos, ejecutar un servidor web para probar el proyecto, …
• settings.py contiene la configuración del proyecto, básicamente contiene un montón de variables que utilizará django para la configuración.
• urls.py contiene los patrones de las direcciones de las diferentes vistas del proyecto de django.

Lo malo es que sólo con esto no se va a poder hacer nada más que cambiar unos cuantos valores de la configuración, para que un proyecto haga algo deberá tener al menos una aplicación que contendrá el código necesario.

Iniciando una nueva aplicación

Para crear una aplicación se debe usar el archivo «manage.py» del proyecto del siguiente modo:

$ python manage.py startapp nombre_de_la_aplicación

Esto creará un directorio, llamado «nombre_de_la_aplicación», con los archivos básicos de toda aplicación de django:

• __init__.py igual que antes, es el archivo de inicialización de cualquier paquete de python.
• models.py contendrá los modelos de la aplicación, estos modelos son clases de python que se traducirán en tablas en la base de datos.
• tests.py contendrá tests de la aplicación. Nota: Este archivo sólo se crea a partir de la versión 1.1 de django.
• views.py contendrá las vistas de la aplicación, estas vistas son funciones de python que realizarán las tareas necesarias para mostrar el resultado como una página web.

Para que esta aplicación esté disponible en el proyecto, hay que añadirla a la lista de aplicaciones del proyecto que está en el archivo «settings.py».

INSTALLED_APPS = (
    'hello_world.hello_app',
)

Nota: Cuando se crea un nuevo proyecto django crea una lista de aplicaciones predeterminada, que en este caso daría lo mismo borrarlas.

Creando un «hola mundo»

Lo primero será crear un proyecto («hello_world») y una aplicación («hello_app») para dicho proyecto, tal y como se ha mencionado antes. Una vez hecho, se deberá crear una vista para la página web.

Creando una vista

Para la creación de una vista, se debe editar el archivo «views.py» de la aplicación creada del siguiente modo:

# views.py
# -*- coding: utf-8 -*-
# Views used in hello world application.

from django.shortcuts import render_to_response

def hello (request):
    """Hello view function."""

    return render_to_response ('hello.htm',
                               { 'hello_msg' : '¡Hola mundo!' })

La función render_to_response usa una plantilla (que ahora se explicará) para crear la página web de la vista.

Creando una plantilla

Django dispone de un lenguaje propio para la creación de plantillas, básicamente son archivos HTML con unas etiquetas especiales, que se marcan con llaves dobles, que django se encargará de rellenar.

De este modo, crear una plantilla es tan sencillo como crear un archivo HTML en un directorio llamado «templates» dentro del directorio del proyecto o de la aplicación. En este caso valdría crear un archivo llamado «hello.htm» (es el que se usa en la función hello) en el directorio «templates» de la aplicación «hello_app».

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
    "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>{{ hello_msg }}</title>
</head>

<body>
    <p>{{ hello_msg }}</p>
</body>
</html>

Esta es una plantilla muy sencilla, el lenguaje de las plantillas de django permite realizar muchas más cosas, como herencia entre plantillas, definir bloques, bucles, …

Definiendo una dirección para la vista

Una vez creada la vista y su plantilla, habrá que definir una dirección para poder acceder a la vista. Como se mencionó al principio, para eso está el archivo «urls.py» del proyecto. Este archivo contiene una lista de direcciones a las que se les asignará unas vistas, de modo que cuando se abra esa dirección la vista asignada se encargue de crear su correspondiente página web.

En este caso, el archivo «urls.py» quedaría del siguiente modo:

# urls.py
# -*- coding: utf-8 -*-
# Django URL patterns for hello world project.

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    (r'', 'hello_world.hello_app.views.hello'),
)

Como se puede ver, lo único que se hace es añadir un patrón (una expresión regular) con una vista asociada. En este caso se trata de una dirección vacía (r''), la raíz del dominio, a la que se asocia la función hello que se definió en las vistas de la aplicación.

Probando la aplicación web

Una vez llegado a este punto, ya se puede probar la aplicación web, para ello no hace falta tener ningún servidor web instalado, ya que django dispone de uno para realizar pruebas. Para ejecutarlo, desde el directorio del proyecto:

$ python manage.py runserver

Y aquí concluye esta introducción básica, pero larga, próximamente más. Si os ha gustado y queréis ir aprendiendo por vuestra cuenta, siempre podéis leer la documentación oficial de django.