O-KEY chiave accesso banca i codici generati sono creati da un algoritmo ben preciso. Lo stesso che viene controllato dal sito in fase di login. Con 6 numeri variabili, avresti una possibilità infinitesimale di azzeccare un codice creato da un algoritmo (che, tra l'altro, è blindato). Chiavetta O-Key L'algoritmo è uguale per tutte le chiavette, quello che cambia è il "seme" con cui viene inizializzato l'algoritmo e che è diverso per ogni chiavetta (potrebbe essere ad esempio un codice collegato al serial number del dispositivo). Sulla base del tuo codice (che la banca conosce) il sistema è in grado di sapere quale numero ti viene generato dal token in un dato momento e quindi verificarlo. La chiavetta genera un codice ogni x secondi, infatti se premi più volte il tasto vedrai che per un po' ricompare lo stesso per poi cambiare... Questo numero è utilizzabile (comunque solo 1 volta -> OneTimePassword) all'interno di una finestra temporale (16 secondi circa o poco più dopodiché scade ed è necessario rigenerarne uno più attuale). In sostanza quindi, un'altra chiavetta genera un codice che sarà con probabilità altissima diverso da quello generato nello stesso istante dalla tua. Formula matematica Formula matematica? Cos(x) dove X aumenta di 1 ad ogni chiamata. Facile, no? Ovvio, se prima sei entrato con 99984, io banca che so che la formula e' il coseno so che la tua chiavetta si trovava a cos(1), e mi aspetto che i prossimi siano 99939 o 99862(*) ovvero cos(2) o cos(3), se te n'esci con 17364 che potrebbe essere cos(100) o penso che ti sei messo a giocare col tastino del token o che stai scazzando dei numeri. Tutti gli altri numeri che poi non sono proprio generabili con la formula in questione, ovviamente li scarto gia' in partenza. (*) in questo esempio assumo che la banca abbia "tolleranza 2" da aggiungere poi la crittografia !!! il token usa lo standard oath per creare la chiave. se vuoi capire come funziona puoi trovare l'algoritmo qua: http://www.openauthentication.org/resources.asp algoritmo del TOKEN non e' riproducibile? tramite reverse engineering tutto è riproducibile, se qualcuno con le adatte capacità ci si mettesse d'impegno riuscirebbe benissimo a scoprire su che tipo di algoritmo lavora il token e riprodurlo tramite un key-generator... considera, però, che resta comunque un controllo in più rispetto rispetto ai soli userid e password. In questo caso( improbabilissimo...) sarebbe cmq responsabile la banca per aver usato un algoritmo che poi è stato craccato...... Ma l'algoritmo varia da chiave a chiave ? O cmq la "fonte" è un algoritmo con piccole modifiche per ogni chiave? Nel senso se un "malitenzionato" ha una okey, riesce a riprodurre solo tale okey o anche altre okey? Se il caso è il secondo... lo trovo molto triste... nel senso: a quel punto trovavo + sicuri i "gratta e vinci" P.S: considerate che inoltre ora il codice segreto è molto + corto... mi pare 5 numeri. mentre prima mi pare fosse una cosa come 16 o 26 caratteri alfanumerici Di solito in crittografia non è mai l'algoritmo ad essere segreto, ma la chiave (in questo caso il codice associato al token del cliente). La forza di un algoritmo sta anche e soprattutto nella difficoltà nel risalire alla chiave originaria conoscendo l'algoritmo e il risultato (funzione del tempo e del codice di inizializzazione) il token usa lo standard oath per creare la chiave. se vuoi capire come funziona puoi trovare l'algoritmo qua: http://www.openauthentication.org/ Partendo dal presupposto che attualmente è difficile implementare sistemi biometrici per l'accesso tramite internet, e quindi la terza categoria viene automaticamente esclusa, la massima sicurezza si ha quando si combinano le altre due (SYK e SYH). Per fare un esempio, basti pensare al bancomat: se per prelevare fosse sufficiente andare in banca con la tesserina, senza dover conoscere il codice, oppure bastasse conoscere il codice senza dover avere la tessera, è evidente che sarebbe molto più facile che qualcuno "non autorizzato" prelevasse dei soldi. Il token quindi genera un codice che, poiché viene generato volta per volta, e non può essere riutilizzato, permette ai sistemi di sicurezza della banca di riconoscere che effettivamente chi sta tentando di accedere è in possesso di quello specifico token. Qui entra in gioco una differenza tra due tipi di token: • Quelli "time-based" genera un codice che dipende dalla data e dall'ora, pertanto, il sistema di sicurezza della banca può determinare che chi sta effettuando l'accesso è in possesso in quel momento del token. Il rovescio della medaglia è che per fare ciò il token e server devono utilizzare un algoritmo che generi un codice basato sull'ora. Quindi è teoricamente possibile che, con un adeguato numero di "osservazioni" un terzo possa riuscire a replicare l'algoritmo e a generare il codice senza il token. Soprattutto però crea difficoltà di sincronia, dato che questa va mantenuta tra l'orologio interno del token e quello del server, rendendo necessari ri-allineamenti per poter effettuare l'accesso. • Quelli "event-based" generano un codice che dipende "da un evento", che realtà più comune e più semplice il numero di volte che viene richiesto di generare un codice. Tradotto, vuol dire che il token ha in memoria un elenco di codici, che vengono restituiti in successione man mano che l'utente richiede un codice da utilizzare. Il server ha in memoria la stessa tabella, anche se non "pretende" che tutti i codici vengano utilizzati, ma semplicemente quando viene utilizzato un codice, tutti quelli che lo precedono nella tabella non possono più essere utilizzati. Si tratta di un sistema più semplice che ha il vantaggio di non richiedere potenza di calcolo al token così come di generare codici che non hanno una correlazione tra loro. Lo svantaggio è che non dà la garanzia al 100% che chi inserisce il codice sia in possesso del token in quel momento. In teoria potrebbe essere qualcuno che ha avuto modo di entrare in contatto con il token precedentemente, e generare un codice rimasto valido in quanto il legittimo proprietario non ha effettuato ulteriori accessi al sistema di banking. In ogni caso, non vi è una categoria di token migliore "in assoluto" dell'altra, e si può dire che contribuiscono in modo significativo alla sicurezza. Non bisogna fare però l'errore di affidarsi solamente al token: è sempre opportuno prestare una certa attenzione alle password che si utilizzano, cercando sì di utilizzare password mnemoniche ma di non essere banali utilizzando password facilmente identificabili o intuibili. Inoltre, è consigliabile cambiare periodicamente la i codici segreti di utilizzo dei servizi di banca online (password e password dispositiva) almeno ogni 6 mesi o un anno, o quando si ha il minimo sospetto che non siano più segreti. La chiavetta non genera un numero a caso ma genera un numero preso a caso tra una x quantità di quelli che le sono stati assegnati in fase di assemblaggio. Parimenti sul server Sanpaolo Intesa c'e un database che ha associato al tuo conto quel set di numeri che corrispondono a quella chiavetta che ti hanno dato, man mano che tu usi i codici sul sito il database provvede ad autenticarti e a disabilitarli pertanto solo i codici che la tua chaivetta può visualizzare sono quelli che il database riconosce come validi per quello che tu non puoi usare la chiavetta di un altro e un altro non può usare la tua e i codici una volta usati non sono più riusabili. La chiavetta genera al volo un numero partendo da un codice univoco insito nella chiavetta e dall'ora corrente (quantizzata ai 10 secondi. Si, la chiavetta contiene un orologio.). Infatti il codice deve essere utilizzato entro 16 secondi dalla generazione, poi diviene inutilizzabile. Conoscendo l'ora corrente e il codice della chiavetta il server puo' controllare il numero generato. Il codice non e' casuale, ma e' una funzione del numero della chiavetta, data e ora. Il server sa qual e' il numero della tua chiavetta, data e ora e fa lo stesso calcolo, cosi' vede se il numero che gli hai dato e' giusto. Se uno conoscesse la funzione, potrebbe calcolarla per qualunque chiavetta, ma si spera che questa funzione sia segreta :-) Perche' se tu esci e rientri non accetta piu' il codice? Perche' qualcuno potrebbe spiarti (con una telecamera, o via computer), vedere il tuo codice ed usarlo su un altro computer. Quindi il computer centrale, quando riceve un codice, lo segna come usato. ...e oltretutto scade, trascorso poco più di un minuto. Se provi a segnarti il codice e ad utilizzarlo 5 minuti dopo non te lo accetta più perchè è funzione anche del tempo in cui è stato generato. Peccato non esista un programmino con lo stesso algoritmo, da caricare sul PC, in modo da non avere un altro aggeggio da portarsi dietro. Di certo una volta usata la chiave il sistema centrale non la accetta più. Poi ho visto varie implementazioni sia con algoritmi dedicati (per cui i numeri non sono poi così casuali) sia con tabelle precaricate. In questo casi i numeri possono davvero essere "casuali" ma sono già caricati sia nella chiavetta che nel server. In caso di disallineamento il server sa che indietro non si torna e quindi verifica se la tua chiave è presente qualche record più avanti. Marco / iw2nzm FUNZIONAMENTO E CARATTERISTICHE Le password sono elaborate dal token stesso tramite un algoritmo a chiave simmetrica (3-DES â " Triple Data Encryption Standard) che cifra uno o piu' di uno dei seguenti elementi: · un valore numerico (ad esempio un contatore numerico sequenziale); · il tempo, ovvero lâ ™istante temporale calcolato da un orologio interno al token; · un challenge, ovvero un valore fornito da unâ ™applicazione esterna. · La validazione dellâ ™utente è a carico di un Authentication Server, sincronizzato con lâ ™orologio del token, e su cui è eventualmente memorizzabile il valore di challenge. L'Authentication Server è in grado di rielaborare, tramite la stessa chiave simmetrica dell'utente, la medesima password. Soluzioni per l’autenticazione ! # $% " # " & ' # $% & ! # ' # ( *+ + ) ) # + $ ) ) " + # # Authentication Server One Time Password - AS OTP , / ' ) ./ + ## # # )0 + $% # ./ " # 0 $ # # # $ FUNZIONAMENTO E CARATTERISTICHE 2./ " ' # $ " . # 1 # " ( • Validare l’identità di un utente in rapporto alle credenziali fornite (valore della password temporanea e riferimento al token che l’ha generato). • Amministrare un token tramite le funzioni di: importazione, ovvero di caricamento massivo, nell’anagrafica del cliente dei valori associati ai token (numero seriale, chiave di cifratura del token, ecc.); • risincronizzazione dell’orologio del server con quello del token; • verifica del funzionamento del token (attivo, non attivo, bloccato, ecc.) e dell’associazione corretta all’utente a cui è stato assegnato; • registrazione degli eventi (logging). * ' " / ' # 2. /% * 2 ) 2 .3 + $ REQUISITI MINIMI DI SISTEMA 2 #( ' ) 4555 , 7)* 8 9 :,8 * !;: * 82 2 # 45562 # + % 7 + TOKEN One Time Password (OTP) */.< ./ " # ' # # # $% = = /.< ' # ./ = ## ( # ' *$ FUNZIONAMENTO E CARATTERISTICHE % ' 0 @ 2 + A # ) A # # A # # # A %# " "# # # = # ) 6:> 2? / > ( + B 0 B $ 2 # $% = 0 2 # " ' $% " 0 # # $ # # /.< ./ ( A ' # # B A # # # 0 $ + A A # 0 ) ) 0 # B + B B A A & B # # #1 # # ) * $ + $ REQUISITI MINIMI DI SISTEMA " # ' # # $% = 2 # $ TrustAccess / % • " ' $ ( # ' ( * >1 ' B • • # B B • $ * / : $ " / # # # : $* # # -# $ Descrizione / " # $% $> / # ) ( $ + # ' " $ %# # *) ' +# # %# ' ./ ) 0 ./ + / + ./ ) . # $ * " / % # $ "# # / #$ # * - # ' $ " +% ' # $ ' # # / Requisiti minimi A2 . # (2, 2 A (2, 2 D A; D ;(E4F; @ A A2 . # (% 7 A; D ;(CH; @ A 4$ C 6FC Target *# - $* !; ) : 0 2 2 G$ 7 + # " # # I $ " # # % # # $ : # 2 # $ * #
© Copyright 2024 ExpyDoc
