30 apr 2013

Inserire la password

"pippobaudo" era quella di un mio vicino di scrivania molti anni fa. Dieci caratteri: niente male; forse un po' vulnerabile ad attacchi dictionary-based, anche se la debolezza maggiore credo fosse il fatto che la declamava ad alta voce ogni mattina quando faceva login.
Oggi, "pippobaudo" non sarebbe una password accettabile su Fineco, ma per la ragione sbagliata: è troppo lunga. Fineco richiede che le password siano lunghe al massimo 8 caratteri.
Ieri Ars Technica ha pubblicato un post che segnala come la cattiva abitudine di imporre limiti alla robustezza delle password sia molto diffusa. Chi richiede una lunghezza massima, chi non accetta determinati caratteri, chi non accetta le parolacce, eccetera.
E' vero che il problema principale delle password non è la loro resistenza agli attacchi brute-force ma piuttosto la tendenza delle persone a comunicarle al primo che passa, e che servizi "delicati" come ad esempio l'home banking dovrebbero piuttosto attrezzarsi per il passaggio all'autenticazione a due fattori (che non è la panacea di tutti i mali ma è un passo in avanti). Non si capisce però perché imporre dei limiti a chi vuole utilizzare password più robuste.
Una possibile ragione, che emerge dall'articolo e nonostante mi faccia venire i brividi a pensarci mi pare la più probabile, è che le password siano immagazzinate in chiaro e non sotto forma di hash per risparmiare spazio su disco e tempo di accesso. La cosa è delirante ma non mi sorprenderebbe se fosse realmente così.
Un esempio, per cercare di chiarire:
La Banca A conserva la mia password in chiaro nel loro database. La mia password è "pippobaudo": 10 bytes occupati su disco. Quando io accedo al sito, inserisco la password, il sistema cerca la mia username e confronta la password presente nel database con quella che ho immesso e se sono uguali mi fa entrare: molto celere.
La Banca B, invece, conserva la mia password (che è sempre "pippobaudo") sotto forma di hash digest. Una funzione di hash è una funzione one-way che, dato un input qualunque, restituisce un valore di lunghezza fissa. "One-way" vuol dire che dato il valore di output, è praticamente impossibile risalire all'input. Ad esempio, la funzione di hash MD5 (da tempo ormai superata da altre che forniscono maggiore robustezza) fornisce un output di 16 bytes, solitamente rappresentato sotto forma di 32 cifre esadecimali, come ad esempio "3719bec537b6f764cdc2e34f7f21056b". Trentadue caratteri ASCII scritti su disco: il 320% in più rispetto alla Banca A. Quando io accedo al sito, inserisco la password, il sistema ne calcola l'hash e lo confronta con quello conservato nel database associato alla mia username, e se sono uguali mi lascia accedere: più calcoli richiesti, più dati trasferiti, moltiplicati per migliaia di accessi al giorno.
Se la Banca A introducesse un limite massimo di lunghezza, ad esempio a 8 caratteri, avrebbe bisogno, per conservare ad esempio le sole password di 100.000 clienti, circa 800KB di spazio al massimo; per Banca B, invece, lo spazio necessario per gli stessi dati sarebbe di circa 3,2MB; introdurre un limite alla lunghezza delle password non farebbe diminuire tale numero, visto che l'hash produce un output di lunghezza fissa.

Apparentemente, le differenze in richieste di storage e CPU potrebbero deporre a favore della conservazione in chiaro delle password, ma in realtà non è così: spazio disco e CPU sono ormai risorse estremamente economiche, e approvvigionarsi opportunamente non è certo un problema finanziario; in secondo luogo, e più importante, in caso un intruso riuscisse ad accedere al database della banca, egli avrebbe a disposizione immediatamente tutte le password in chiaro, mentre se queste fossero conservate  sotto forma di hash digest sarebbero inutilizzabili.

4 commenti:

Meg ha detto...

comunque "pippobau" rimane una bella pw

Anonimo ha detto...

Scusami, ma l'ipotesi del mantenere le password in chiaro per risparmiare spazio è un tantinello ridicola.
Prova a considerare lo spazio occupato dai dati anagrafici, dal profilo che l'azienda ha del cliente, dallo stato patrimoniale completo, da tutte le transazioni, e conservati per anni e anni.

32 bytes anziché 10 non fa testo.

Anonimo ha detto...

Invece, c'è un motivo, sbagliato quanto ti pare, ma pratico, per tenere "semplici" le cose: pochi utenti sono Power User.
Non tutti gli utenti sono utenti assennati e lungimiranti.
Che succede se hai una password di 20 caratteri invece di una da 8 e non sei più tanto giovane e/o sei disorientato dalla tecnologia?
La dimentichi, o la scrivi su un post-it, ci scrivi sopra PASSWORD DELLA BANCA, e la metti in bella mostra sotto il piano di vetro della scrivania (true story: l'ha fatto mio padre).

ilgioa ha detto...

Un altra opinione molto diffusa ma a mio parere errata è che non sia una buona idea scriversi le password su un post-it. E' una cattiva idea scriversi il pin del bancomat E CONSERVARLO INSIEME AL BANCOMAT STESSO; ma non vedo che problema ci sia nello scriversi la password dell'home banking su un post-it conservato con cura IN CASA PROPRIA. Il rischio che una password debole venga compromessa attraverso un attacco brute force è molto più elevato di qualcuno che si introduca in casa vostra per leggervi i post-it.