È prassi consolidata che le password in chiaro non vengano mai memorizzate, ma, al loro posto, venga memorizzata la loro "firma" (one way hash) ricavata tramite una funzione di digest, tipo MD5 o SHA1.
La logica sottostante è che è computazionalmente veloce ricavare dalla password in chiaro la firma, ma computazionalmente "impossibile" il verso opposto, poiché l'inversione dell'algoritmo di firma è "matematicamente complicatissima" e quindi estremamente laboriosa e lunga da compiersi nonché (last but not least) con perdita di informazione.
Ciò che viene confrontata è quindi la firma della password scelta dall'utente (salvata, lo ripeto, su database) e la firma di quella digitata. Se queste coincidono, ciò vuol dire con elevatissima probabilità (certezza, salvo collisioni) che anche le password in chiaro coincidono, dato che la lunghezza della firma finale è in genere grande.
È inteso che, con questo sistema, se un utente smarrisce la password, ad egli ne dovrà essere inviata una nuova: quella vecchia è persa per sempre.
Come è inteso che, se la password è debole, può essere possibile (e lo è!) che con un attacco di brute force si riesca ad ottenere la password in chiaro, a partire dalla sua firma, appunto per "tentativi ed errori", "scavalcando" in toto il problema dell'inversione dell'algoritmo.
Prime vulnerabilità e debolezze
Esaminiamo alcuni punti riguardo il codice di autenticazione ed inizializzazione/propagazione della sessione poco sopra riportato.
- Nome utente e password sono inviati (in chiaro) via form Web (in POST).
- Lato server, è verificata la corrispondenza di nome utente e MD5(password_spedita), ovvero viene verificato se la coppia nome utente e hash password corrispondono a quanto è su database per almeno un utente.
- Viene quindi creata una sessione.
- Per ogni nuova pagina viene fatto il controllo sulla sessione stessa.
Rispettivamente, seguono alcune debolezze dello schema adottato.
- Specie in LAN (no, diciamo, esclusivamente in rete locale: lo sniffing via Internet è davvero improbabile), qualsiasi dato inviamo in chiaro in rete è passibile di intercettazione (sniffing appunto). Per tale motivazione è meglio usare HTTPS, protocollo sicuro che cifra i dati in transito, rendendoli incomprensibili a terzi anche se intercettati.
- Come già accennato precedentemente nella guida, è preferibile usare un'autenticazione del tipo MD5(MD5(password)) oppure qualche altro celeberrimo algoritmo di firma, quale lo SHA1 (più sicuro, non fosse altro perché la lunghezza in caratteri del suo hash è maggiore, quindi si ha minor possibilità di "doppioni", cioè collisioni detto in gergo corretto).
- L'attenzione qui si sposta sull'inviolabilità di questi file su server.
- Esistono alcune tecniche per "usufruire" del SID di utenti autenticati. Cosa che noi dovremo evitare. Si potrebbe pensare di controllare taluni parametri legati al client, in modo da esser più sicuri di bloccare ogni tentativo di hackeraggio anche in caso di furto dei dati di sessione. Tuttavia non esiste parametro "sicuro": l'indirizzo IP è facilmente camuffabile ("spoofabile") e nelle organizzazioni in genere è unico per tutti gli utenti (IP del gateway / router). Di più, in taluni casi, i provider (americani) modificano l'indirizzo IP degli utenti connessi anche durante una singola connessione. Il controllo dell'IP quindi può dare falsi positivi e falsi negativi. Un'altra informazione (forse altrettanto inutile…) può essere l'identità del browser. Non si dice, però, che l'unione fa la forza?