Quali sono le carenze del seguente schema di autenticazione delle transazioni bancarie?

Question

Quali sono le carenze del seguente schema di autenticazione delle transazioni bancarie?

#1 da (6 voti)
#2 da (1 voti)

6

Qui in Germania, l'autenticazione delle transazioni nel banking online (oltre la password di accesso di base che è ed è sempre stata necessaria) si è evoluta da un elenco di password monouso distribuite in anticipo su carta (quindi -called "TAN" codici o numeri di autenticazione della transazione) per l'uso di password monouso inviate su richiesta a un telefono cellulare o dispositivo simile, in un messaggio che contiene anche i dettagli del trasferimento per autenticare il messaggio. Mi sono chiesto se sia possibile raggiungere un simile livello di sicurezza usando ancora il vecchio metodo di distribuzione di un elenco cartaceo in anticipo, e in effetti è venuto fuori con uno schema che mi sembra praticabile. Dato che sono consapevole della qualità generale dei sistemi di sicurezza ideati dai dilettanti (e sono un dilettante) sarei interessato a sentire commenti sulle carenze del mio schema da parte dei lettori di questo sito.

L'idea di base dello schema è che un elenco cartaceo di voci numerate venga distribuito in anticipo al cliente dalla banca. Invece di contenere semplici password, l'elenco dovrebbe contenere semplici attività numeriche, come ad esempio:

Immettere la somma della figura uno e la cifra quattro del numero di conto, seguito dal numero otto, seguito da sessanta meno la cifra tre del codice di ordinamento bancario.
Immettere la figura 3 del numero di conto, seguito dalla figura due e dalla figura sette del codice di ordinamento bancario, seguito dalla figura due e dalla figura uno dell'importo da trasferire (ignorando i centesimi).
...

Quando il cliente deve autenticare una transazione, verrà assegnato il numero di una delle attività e gli verrà chiesto di inserire la soluzione, utilizzando i dettagli della transazione. Mi sembra che questo schema soddisfi i requisiti che la generazione di una password deve essere avviata dalla banca al momento della transazione, che è legata alla transazione, che non è banale tornare indietro dalla password al metodo utilizzato per generare e che coinvolge un secondo canale di comunicazione separato. Inoltre, mi auguro che sia gestibile per i clienti (eccetto per il fatto che potrebbe essere necessario un pezzo di carta di grandi dimensioni per contenere i compiti!), E in effetti li incoraggerei a controllare i dettagli della transazione.

Mi rendo conto che ci dovrebbero essere requisiti per i compiti per mantenerli utilizzabili ma comunque sicuri, e che dovrebbero essere espressi e parametrizzabili in un modo che i computer della banca possono gestire (anche se potrebbero essere introdotti nuovi tipi in ogni momento). Oltre a questo, sarei interessato a sentire quali sono i principali fori presenti in questo schema che mi sono sfuggito.

authentication

posta michaeljt 21.03.2012 - 11:02

fonte

2 risposte

Leggi altre domande sui tag authentication

È possibile utilizzare le funzioni hash con la modalità CTR o OFB? Protezione di un'architettura multi-tenant

score 6 · Answer 1

Alcuni pensieri senza un particolare ordine.

Richiede buone capacità matematiche, di lettura e di ragionamento; benché Sarebbe bello se tutti potessero svolgere questi compiti che non possiamo (né dovremmo) aspettarci che tutti quelli con un conto bancario saranno in grado di farlo. Questo risulterà in falsi accessi non riusciti, utilizzo ridotto e maggiori chiamate di supporto.
Richiede la standardizzazione su come scrivere le domande. Idealmente queste domande dovrebbero essere in grado di essere algoritmicamente generato, non scritto da un umano, e verifabilmente corretto e privo di ambiguità.
Lo schema richiede la possibilità di leggere la lingua in cui sono scritte le domande. Uno schema che ha solo una scheda token o un elenco di passcode non ha questa limitazione. I conti bancari sono per lo più numeri che sono interlinguistici.
Data la standardizzazione richiesta sopra, ora dobbiamo essere in grado di verificarlo non è infatti banale lavorare all'indietro da password a algoritmo di generazione. Non è chiaro dalla tua descrizione che questo è verosimilmente vero.
Il numero risultante deve essere sufficientemente lungo da fornire sufficiente entropia e abbastanza breve da fare il passo di calcolo fattibile. Per esempio. un numero di 10 cifre potrebbe avere entropia sufficiente a seconda dello schema di calcolo e del resto della sicurezza; ma 10 cifre potrebbero essere troppo lunghe per aspettarsi che qualcuno segua tutto il tuo passi.
Quale problema stai cercando di risolvere nel caso in cui ritieni che gli schemi attuali siano insufficienti?

score 1 · Answer 2

Questo ha due difetti, uno dei quali è probabilmente devastante (secondo me).

L'usabilità fa schifo. Una parte significativa dei clienti avrà difficoltà a utilizzare questo. Il tasso di errore sta andando verso l'alto. Alcuni clienti non saranno contenti della banca e questo non va bene per gli affari. Altri chiameranno la linea di supporto telefonico per chiedere aiuto, e questo è terribile per gli affari: ho sentito stime che suggeriscono che costa $ 20-40 per chiamata all'help desk. Pertanto, se l'introduzione della proposta aumenta le chiamate all'help desk del 10%, si tratta di un costo enorme per il tuo schema, che lo rende morto nell'acqua. Penso che questo sia un ostacolo.
Non ha alcun chiaro vantaggio in termini di sicurezza rispetto agli schemi alternativi, come l'invio di dettagli della transazione e un codice di conferma al cellulare del cliente.