Stavo pensando al modo di creare un login più sicuro: questa era un’idea che mi era venuta già un po’ di tempo fa ma poi ho rinunciato a compierla perché mi ero incasinato, così sono tornato al classico cookie con id e password.

Questo tipo di login però è un po’ rischioso: intanto l’hash della password (o l’hash dell’hash, come preferite 😉 ) rimane salvato in un computer e non è mai una bella cosa; inoltre rende più possibili i tentativi di attacco, per esempio tramite forza bruta: una volta scoperta la funzione dell’hash (soprattutto in assenza di un salt), si può saltare il form di login e provare direttamente con i vari cookie.

Il sistema a cui invece ho pensato si basa sempre su un cookie, ma che racchiude un id del login (generato magari con la funzione uniqid) e un codice di sicurezza diverso dalla password.

Di svantaggio ha il fatto che se a un utente viene “rubato” il cookie può fare tranquillamente il login, ma ciò avveniva anche con l’altro metodo.

Il secondo svantaggio è che il cookie che dura per la sessione viene fatto sparire dal browser, mentre applicando quest’idea bisognerebbe pensare a un tot di tempo di validità per il login breve.

Tuttavia, qualora ciò accadesse, con il mio metodo si può creare una pagina per l’utente che consente di chiudere altri login aperti (sperando non venga usata come arma a doppio taglio).

Un altro vantaggio che questo sistema offre è che il bruteforce diventa molto più difficile: bisogna trovare un id di login valido e dopo bisogna trovare anche il codice di sicurezza; inoltre, a meno che non si conosca un codice di login di un utente, non si può avere un bersaglio preciso.

Inoltre è sempre possibile sapere per l’applicazione se il login dell’utente è a breve durata o a lunga durata (utile se magari si vuole che al cambio password l’utente non debba rifare il login).

Un’altra possibilità da non trascurare con questo sistema è quella del login in altri siti, nello stile dei grandi social network (sito A): lo sviluppatore dell’applicazione (sito B) che vuole richiedere il login deve farsi dare una chiave, quindi esegue un redirect al sito A (per verificare i cookie) che poi lo reindirizza al sito B con un parametro GET con cui indica una chiave di login (opportunamente criptata).

Tutto ciò però costa almeno una tabella in più nel database e qualche query in più.