2011-11-22 23 views
11

Alcuni sistemi di password (soprattutto bancari) richiedono l'inserimento di tre (specificate) lettere dalla password per l'accesso. Ciò dovrebbe sconfiggere i keylogger e, eventualmente, gli attacchi di riproduzione wire-sniff (per sessioni non crittografate).Sistemi di password che richiedono lettere individuali: cosa memorizzano?

Chiaramente, non è possibile che un tale schema possa funzionare utilizzando l'hashing della password ordinaria, poiché è necessario conoscere l'intera password per calcolare l'hash.

Che cosa solitamente tali sistemi memorizzano sul lato server per fare in modo che funzioni?

Memorizzano la password in testo semplice o forse un hash separato di ogni lettera o cosa?

+4

Non necessariamente - è stata fornita una risposta su ITSecurity.SE: http://security.stackexchange.com/questions/4830/how-do-some-sites-eg-online-banks-only-ask-for-specific -caratteri-da-a-pa. Vedi anche http://www.smartarchitects.co.uk/news/9/15/Partial-Passwords---How.html – Piskvor

+0

Forse sono solo io, ma non ho mai visto una banca chiedermi tre lettere. Solo per un [TAN] (http://en.wikipedia.org/wiki/Transaction_authentication_number). – PiTheNumber

+0

@PiTheNumber: Non è * solo * tu, ma alcune banche lo fanno (fatto?) Questo; Ho vissuto questo in prima persona. Si noti che questo è un sistema che è stato messo in atto prima dell'adozione diffusa di telefoni cellulari (che ha permesso l'uso di TAN), e non sono sicuro che sia ancora in uso in quella particolare banca. – Piskvor

risposta

15

Come si nota correttamente, gli schemi di hashing delle password standard non funzioneranno se l'autenticazione viene eseguita utilizzando solo una sottostringa della password. Ci sono un certo numero di modi in cui un tale sistema potrebbe essere implementato:

Conservare la password in pianura:

  • semplice e facile da implementare.
  • Insicuro se il database è compromesso.
  • Potrebbe non essere conforme alle normative che richiedono l'hashing o l'archiviazione crittografata delle password (ma l'utilizzo della crittografia di database di basso livello potrebbe aggirare tale problema).

Conservare la password criptata, decriptare per controllare:

  • Non più sicuro di riporlo in pianura se la chiave di crittografia è anche compromessa.
  • Può soddisfare i regolamenti che vietano l'archiviazione delle password in chiaro.
  • Potrebbe essere reso più sicuro utilizzando uno hardware security module dedicato o un server di autenticazione separato, che memorizzerebbe la chiave e fornirà un'interfaccia black-box per la verifica della sottostringa e della crittografia.

hash Negozio di tutti (o molti) sufficientemente possibili stringhe:

  • ha bisogno di molto più spazio di archiviazione rispetto ad altre soluzioni.
  • La password può essere ripristinata abbastanza facilmente con la forza bruta se il database è compromesso, poiché ogni sottostringa può essere attaccata separatamente.

Uso k-out-of-n threshold secret sharing:

  • ha bisogno di meno spazio rispetto memorizzazione di più hash, ma più di memorizzare la password in tinta unita o con crittografia reversibile.
  • Non è necessario decrittografare la password per la verifica della sottostringa.
  • Ancora suscettibile di attacco a forza bruta se il database è compromesso: chiunque riesca a indovinare le lettere k della password può recuperare il resto.(In effetti, con alcune implementazioni, k -1 lettere potrebbero essere sufficienti.)

In ultima analisi, tutti questi sistemi soffrono di debolezza contro gli attacchi di forza bruta se il database è compromessa. La ragione fondamentale per questo è che non c'è molta entropia in una sottostringa di tre lettere di una password tipica (o, in realtà, anche di una particolarmente forte), quindi non ci vorranno molte ipotesi per incrinarsi.

Quale di questi è il migliore? È difficile da dire. Se io avessi per scegliere uno di questi schemi, probabilmente utilizzerei lo spazio di archiviazione crittografato usando una forte crittografia simmetrica (come AES), con un server separato o HSM per gestire la crittografia e la verifica. In questo modo, almeno, un utente malintenzionato che compromette un server front-end non sarebbe in grado di copiare semplicemente il database e attaccarlo offline (anche se potrebbe ancora montare un attacco di forza bruta sull'HSM se non implementasse una limitazione della velocità effettiva)).

Tuttavia, direi che l'intera idea di usare solo una parte della password per l'autenticazione è profondamente sbagliata: in realtà non consegnare i benefici di sicurezza che si suppone di, tranne in alcuni scenari di attacco particolarmente vincolate (quali come intercettatore che può solo osservare un evento di autenticazione e non può continuare a provare finché non ottengono la stessa sfida), ma indebolisce sostanzialmente la sicurezza riducendo la quantità di informazioni necessarie per un'autenticazione corretta. Esistono soluzioni molto migliori, come ad esempio TANs, per i problemi di sicurezza che si suppone che l'autenticazione della password parziale indirizzi.

Problemi correlati