Ripensando al funzionamento dei token, di cui abbiamo parlato poco tempo fa a proposito della Banca Popolare di Vicenza, mi è venuto qualche dubbio sul loro effettivo livello di sicurezza. Mi spiego meglio.
La maggior parte delle banche utilizza token event-based anziché time-based, cioè in cui la password “monouso” generata non dipende da data e ora in cui viene richiesta, ma dall’accadere di un evento, e cioè il fatto che venga richiesta. Tradotto in parole molto semplici, il token contiene una tabella con un elenco di password (che per capirci meglio, immaginiamo che siano una serie di numeri consecutivi anziché casuali):
- 000001
- 000002
- 000003
- 000004
- 000005
- …
Ogni volta che gli viene richiesto di generare una password, il token “va avanti di una riga” e mostra la successiva password nell’elenco.
Anche il server della banca ha la stessa tabella di password in memoria, e verifica che la password digitata via browser dal cliente sia presente nella tabella. Ma non pretende che sia la password successiva. Cioè se prima avete inserito la password n°2, poi considera accettabile utilizzare per l’accesso anche la password n°4, senza dover utilizzare la 3. Il che è corretto, perché potrebbe essere che la password n°3 l’avete fatta generare al token ma poi avete cambiato idea e avete rinunciato ad accedere al sito della banca, oppure banalmente il tastino per la generazione si è premuto mentre lo avevate in tasca senza che ve ne accorgeste (di solito, quando viene utilizzato un codice tutti quelli precedenti vengono “invalidati”, nel senso che se uso la password n° 5, le password 1,2,3 e 4 non permettono più di accedere al sistema, a prescindere dal fatto che siano effettivamente state utilizzate o meno). Se la banca vi obbligasse ad usare tutti i codici successivi, in un caso come questo rischiereste di non riuscire più ad accedere al vostro conto.
Questo funzionamento però implica che perché il mio codice sia valido non deve essere una specifica riga della tabella, ma semplicemente deve essere presente nella tabella. E quindi (ipotizzando la generazione di password a sei cifre) se “tiro ad indovinare” la probabilità non è una su un milione, ma una su un milione moltiplicato il numero di righe della tabella. Se la tabella ha mille righe, mille codici memorizzati, la probabilità che tirando ad indovinare trovi un numero (una password) che è tra quelli della tabella, è di una su mille.
Certo, non si tratta di un buco di sicurezza tremendo, l’accesso con il token rimane più sicuro che senza, ma credo evidenzi il fatto che il token non è la panacea a tutti i mali e a tutti i pericoli della sicurezza, e l’utente dovrebbe comunque non perdere tutte quelle buone abitudine di attenzione e “prudenza informatica” di cui abbiamo più volte parlato.
Banche e Risparmio [http://www.banknoise.com]
Ciao,
la risposta è semplice ed è alla portata di chiunque abbia programmato sotto DOS :D
Utilizzando un algoritmo pseudo-casuale puoi generare sequenze che utilizzano tutti i numeri di sei cifre.
Ti servono solo 2 cose: l’algoritmo ed un numero di inizializzazione (ad es il codice cliente); la potenza di calcolo e la memoria necessaria entrano benissimo (oggi) in un portachiavi.
Ecco che per ogni cliente hai una sequenza univoca di 1M di numeri.
Prendiamo ad esempio un trader scatenato: diciamo che fa 100 operazioni al giorno, per 260 giorni all’anno di apertura del mercato: una sequenza gli dura 38,5 anni… direi che ci possiamo stare ;)
Ciao,
la risposta è semplice ed è alla portata di chiunque abbia programmato sotto DOS :D
Utilizzando un algoritmo pseudo-casuale puoi generare sequenze che utilizzano tutti i numeri di sei cifre.
Ti servono solo 2 cose: l’algoritmo ed un numero di inizializzazione (ad es il codice cliente); la potenza di calcolo e la memoria necessaria entrano benissimo (oggi) in un portachiavi.
Ecco che per ogni cliente hai una sequenza univoca di 1M di numeri.
Prendiamo ad esempio un trader scatenato: diciamo che fa 100 operazioni al giorno, per 260 giorni all’anno di apertura del mercato: una sequenza gli dura 38,5 anni… direi che ci possiamo stare ;)
Cia Anonimo, penso che il punto sollevato da Mark75 non e’ questo. Lui dice che il sistema invalida automaticamente tutte le chiavi vecchie, ma di quelle nuove ne accetta piu’ di una. Questo metodo e’ simile a quello utilizzato dai telecomandi degli antifurti per auto con “rolling-code” e penso che il numero di codici successivi a quello utilizzato ritenuti validi sia limitato e, quindi, la probabilita’ di individuarlo con uno casuale e’ fortemente abbattuta.
Cia Anonimo, penso che il punto sollevato da Mark75 non e’ questo. Lui dice che il sistema invalida automaticamente tutte le chiavi vecchie, ma di quelle nuove ne accetta piu’ di una. Questo metodo e’ simile a quello utilizzato dai telecomandi degli antifurti per auto con “rolling-code” e penso che il numero di codici successivi a quello utilizzato ritenuti validi sia limitato e, quindi, la probabilita’ di individuarlo con uno casuale e’ fortemente abbattuta.
Non è che la banca accetta qualsiasi numero successivo. Per esempio il token event-based di iwbank accetta solo i 10 codici successivi all’ultimo utilizzato e non tutta la tabella. in questo modo indovinare uno dei prossimi dieci in tre tentativi (dopo di che ti viene bloccato l’accesso) non è cosa fattibile.
Non è che la banca accetta qualsiasi numero successivo. Per esempio il token event-based di iwbank accetta solo i 10 codici successivi all’ultimo utilizzato e non tutta la tabella. in questo modo indovinare uno dei prossimi dieci in tre tentativi (dopo di che ti viene bloccato l’accesso) non è cosa fattibile.
Se accetta solo un insieme limitato di codici dopo l’ultimo inserito, allora effettivamente le probabilità tornano ad essere “migliori”.
Immaginavo ci fosse un limite ma non avevo avuto conferma. Comunque a me 10 codici sembrano pochi, dato che non è impossibile che uno giocherelli con il token e generi 10 codici inutili (basta finisca in mano ad un bambino…). Del resto evidentemente è un “trade-off” tra sicurezza e rischio di trovarsi l’accesso bloccato.
Se accetta solo un insieme limitato di codici dopo l’ultimo inserito, allora effettivamente le probabilità tornano ad essere “migliori”.
Immaginavo ci fosse un limite ma non avevo avuto conferma. Comunque a me 10 codici sembrano pochi, dato che non è impossibile che uno giocherelli con il token e generi 10 codici inutili (basta finisca in mano ad un bambino…). Del resto evidentemente è un “trade-off” tra sicurezza e rischio di trovarsi l’accesso bloccato.
Il token che ho io per generare il codice deve essere premuto di continuo per 5 secondi. insomma non è che semplicemente giocherellandoci escono fuori i codici. Ci deve essere l’intenzionalità di generarli.
Il token che ho io per generare il codice deve essere premuto di continuo per 5 secondi. insomma non è che semplicemente giocherellandoci escono fuori i codici. Ci deve essere l’intenzionalità di generarli.
Sì, in effetti non è che partano “codici a caso”.
Bene, direi che quindi il problema della sicurezza del token la possiamo bollare “eccesso di preoccupazione” :)
Sì, in effetti non è che partano “codici a caso”.
Bene, direi che quindi il problema della sicurezza del token la possiamo bollare “eccesso di preoccupazione” :)
Ciao,
oltre al fattore sicurezza io considererei anche il fattore comodità. Io lo trovo un po’ scomodo a meno di portarlo sempre con se
Ciao,
oltre al fattore sicurezza io considererei anche il fattore comodità. Io lo trovo un po’ scomodo a meno di portarlo sempre con se
Hai perfettamente ragione. Il token è molto scomodo. Io l’ho attaccato al portachiavi (e di qui era nato tutto il dubbio per codici generati involontariamente, tenendolo in tasca…), però non è il massimo.
Detto proprio fuori dai denti, a me il token mi sa un po’ di moda e di marketing: il terzetto username+password di accesso+ password dispositiva è già sufficientemente sicuro per molti. Anche se va detto che c’è in giro anche gente pigra e distratta che si scrive le password o non le aggiorna (pensate a quelli che hanno lasciato in IWBank la password dispositiva di default), per cui capisco che il token è anche un modo delle banche di “pararsi il culo”: basta un paio di clienti che si trovano accessi al conto non autorizzati, magari perché si sono scritti le password su un foglio e lo hanno lasciato in giro, e la banca si ritrova con una pubblicità negativa enorme…
Hai perfettamente ragione. Il token è molto scomodo. Io l’ho attaccato al portachiavi (e di qui era nato tutto il dubbio per codici generati involontariamente, tenendolo in tasca…), però non è il massimo.
Detto proprio fuori dai denti, a me il token mi sa un po’ di moda e di marketing: il terzetto username+password di accesso+ password dispositiva è già sufficientemente sicuro per molti. Anche se va detto che c’è in giro anche gente pigra e distratta che si scrive le password o non le aggiorna (pensate a quelli che hanno lasciato in IWBank la password dispositiva di default), per cui capisco che il token è anche un modo delle banche di “pararsi il culo”: basta un paio di clienti che si trovano accessi al conto non autorizzati, magari perché si sono scritti le password su un foglio e lo hanno lasciato in giro, e la banca si ritrova con una pubblicità negativa enorme…
Beh, però se uno non vuole portarsi dietro il token un metodo c’è e l’ho già sperimentato, si creano un pò di codici e si scrivono su un foglietto, ovviamente in sequenza di generazione, il tutto funziona anche dopo vari giorni, se però si inserisce un codice successivo tutti i precedenti vengono invalidati come è giusto che sia. Trovo la cosa molto comoda, ovviamente non bisogna lasciare in giro il foglietto con i codici e tantomeno il token. In pratica si crea una tabella di password usa e getta da utilizzare in sequenza, e se proprio si volesse basta utilizzare l’ultima per invalidare tutte le altre… Saluti Carlo
Beh, però se uno non vuole portarsi dietro il token un metodo c’è e l’ho già sperimentato, si creano un pò di codici e si scrivono su un foglietto, ovviamente in sequenza di generazione, il tutto funziona anche dopo vari giorni, se però si inserisce un codice successivo tutti i precedenti vengono invalidati come è giusto che sia. Trovo la cosa molto comoda, ovviamente non bisogna lasciare in giro il foglietto con i codici e tantomeno il token. In pratica si crea una tabella di password usa e getta da utilizzare in sequenza, e se proprio si volesse basta utilizzare l’ultima per invalidare tutte le altre… Saluti Carlo
Awesome article, I’m a large believer in commenting on blogs and forums to assist the website creators know that they have developed something valuable.
Smart read, smart points, a number of that I have learned along the approach also (humility, grace, layoff the controversial stuff).
Invece di ringraziare la banca che da il token e pure gratis la gente si permette di obiettare. Ma stiamo scherzando.! Io una banca senza token nemmeno la considero, chiederei solo la visualizzazione del c/c, senza operativita’. C’e’ gente che considera noioso il token, pero’ perde tempo con smartphone, sistema android,ecc. quello non e’ noioso no.! Eppure e’ stata diffusa la notizia che gli hachers gia’ hanno fatto danno cogli sms , impedendo l’sms alert. Scommento che non hanno neppure un antivirus adeguato , che il buon kaspersky ha approntato per la telefonia mobile. Io uso solo il pc per la banca, ne ho tre tutte col token e sono strafelice, uso la suite di kaspersky per difendere il pc. Ho la tastierina antikeylogger, le banche mi avvertono quando movimento denaro in uscita. E cancello ogni email o altri messaggi che siano sospetti e ne arrivano a valanghe. Cosi’ si fa per proteggere il proprio denaro, siamo seri!
Salve, in realtà il token per esempio di iwbank accetta pochi codici oltre quello progressivo successivo. Tu tale token infatti schiacciando a caso la generazione del codice senza un uso sul sito della banca avviene un disalineamento dal quiale si esce solo loggando sul conto usando altri codici defiiti pin2 già forniti a suo tempo dalla banca e mai usati se non in eventi di questo genere.