Sempre que se deseña unha aplicación que necesite identificación de usuarios suscítase a dúbida de se utilizar un sistema de autenticación externo (Facebook, Google , OpenId, ...) ou un sistema de autenticación propio. Cando se utiliza un sistema de autenticación propio, exponse o problema da seguridade á hora de gardar os contrasinais dos usuarios na nosa base de datos.

Aparentemente é un problema menor, xa que, á fin e ó cabo, o contrasinal dun usuario para o noso foro ou blog non parece unha información crítica. E isto sería así se non fose porque se sabe que moitos usuarios reutilizan os seus contrasinais en diferentes sitios. Se o unimos a que a conta de email é tamén un dato que se adoita pedir, calquera atacante que consiga roubar os contrasinais dun pequeno foro ou blog acabará cos contrasinais das contas de email, facebook, ... de moitos dos seus usuarios.

Ademais das medidas para evitar os ataques por forza bruta (pedir contrasinais cun número mínimo de carácteres, que conteñan maiúsculas, minúsculas, carácteres especiais e números, bloquear repetidos intentos de acceso errado, ...) e outros, hai que ter en conta a posibilidade de que se comprometa a nosa base de datos ou un backup da mesma.

Protexendo os contrasinais

Nunca debemos gardar os contrasinais dos usuarios sen cifrar. Isto é un erro máis común do que poida parecer xa que os clientes adoitan pedir como requisito o que se poida "recordar" o contrasinal ós usuarios (enviar por correo o contrasinal actual, non un novo).

Os contrasinais sempre han de gardarse na base de datos "cifrados" dalgún modo, de forma que o atacante non poida coñecelos. Se é requisito indispensable o que os contrasinais poidan ser "recordadas", deberán cifrarse cun algoritmo de "dobre sentido" para que poidan ser descifrados pola aplicación. Pero este sistema é moi pouco recomendable xa que o atacante poderá tamén descifralos. O mellor é cifrar os contrasinais cun algoritmo de "un só sentido" de forma que non se poidan descifrar.

Encriptando os contrasinais

En realidade, aínda que seguiremos chamándolle "encriptado" por comodidade, o que se adoita facer é pasar os contrasinais por unha función resumen como función resumen como MD5, SHA, ..., gardar na base de datos o "resumen" xerado e descartar o contrasinal.

$hash = sha1($password);
unset($password);
// Se $password == 'apple'
// $hash == 'd0be2dc421be4fcd0172e5afceea3970e2f3d940'

Máis adiante, para comprobar se un usuario puxo ben o seu contrasinal, o que faremos será encriptar o que o usuario nos envía e comparar o resultado do cifrado co que temos na nosa base de datos.

// $db_hash será o que temos gardado na base de datos
if ($db_hash === sha1($password))
{
	// Contrasinal correcto
}

Así, aínda que se comprometa a nosa base de datos, o atacante non poderá coñecer os contrasinais dos usuarios de forma fácil. O único que lle queda para poder descifralos é un ataque por forza bruta ou por táboas rainbow (táboas con cadeas de carácteres e o resultado de cifralas con algunhas funcións de resumo).

Elexir un algoritmo de cifrado

As funcións de resumo máis coñecidas e utilizadas son MD5 e SHA-1, pero dado que MD5 e SHA-1 foron comprometidas, actualmente estanse impondo novas funcións como son SHA-2 e Bcrypt.

Á hora de escoller unha delas para a nosa aplicación, deberemos ter en conta ademais da dispoñibilidade que teñamos, a velocidade de execución da función. Neste caso, ó contrario que na maioría dos casos en computación, a que máis nos interesa é a máis lenta (Bcrypt). A razón é que nós só imos cifrar un contrasinal ó identificarse un usuario. Non importa que este proceso leve 0.001 segundos ou 0.3 segundos. Con todo, para un atacante, esta diferenza fai que xerar táboas rainbow poida tardar dunhas horas a varios anos.

Engadindo sementes

Outra forma de porllo difícil ó atacante é engadir unha semente ó contrasinal antes de pasalo pola función resumen. Desta forma, aínda ten máis complicado utilizar as táboas rainbow, ó facer a cadea do contrasinal máis longa e máis improbable que estea na táboa rainbow.

Para porllo aínda peor, o mellor é que a semente sexa única para cada contrasinal, de forma que non poida facerse unha táboa rainbow coa túa semente incorporada, senón que tería que facerse unha táboa para cada contrasinal.

A forma de facelo sería así:

$salt = md5(uniqid(rand(), true)); // Ou ata mellor se tivese maiúsculas, minúsculas, carácteres especiais...
$hash = hash('sha512', $salt.$password); // Pode porse diante ou detrás, é igual
unset($password);
// Gardar en base de datos o $hash e $salt

Logo, cando queiramos autenticar un usuario:

// $db_salt será a semente que teremos en base de datos
// $db_hash será o resumo que temos gardado na base de datos
if ($db_hash === hash('sha512', $db_salt.$password))
{
	// Contrasinal correcto
}

Con este método, aínda que dous usuarios teñan o mesmo contrasinal, será imposible sabelo xa que o seu resumo será distinto.