Come conservare i semi OTP in modo sicuro sul server di convalida

16

"Tutti" sa quando si memorizzano le password in un database, questo dovrebbe essere fatto in modo sicuro, ad esempio utilizzando Sali e un algoritmo di hashing appropriato.

La maggior parte delle soluzioni OTP (One Time Password) si basano su un valore seme casuale a lungo segreto. In qualche modo questo deve essere memorizzato anche sul server di validazione per poter verificare il valore OTP inviato.

In un certo modo questi semi hanno lo stesso ruolo delle password fornite dall'utente e devono essere archiviati in modo altrettanto sicuro. Salatura e amp; l'hashing non funzionerà qui in quanto ciò interromperà l'algoritmo OTP.
La maggior parte dei token OTP piccoli sono fisicamente protetti essendo più o meno a prova di manomissione, ma questo non si applica al server.

In che modo i semi possono essere immagazzinati in modo appropriato?

E se esiste una soluzione per l'archiviazione dei semi senza hashing, perché non applicare lo stesso metodo alle password normali?

    
posta Jeff 16.11.2012 - 15:52
fonte

3 risposte

7

In parole povere, il meglio che puoi fare è indurire il server per renderlo più resistente al compromesso possibile.

Idealmente, si memorizzerebbe il seme in un modulo di sicurezza hardware (HSM, noto anche come criptoprocessore). Assicurati che il seme non lasci mai l'HSM, cioè esegua tutti i calcoli crittografici nell'HSM. Questo offre una migliore protezione, anche se è certamente più costoso.

Tuttavia, come correttamente sottolineato, non è possibile memorizzare il seme in formato hash. Il seme deve essere memorizzato in chiaro, quindi se quel server viene compromesso , si sono in grande //www.theregister.co.uk/2011/03/24/rsa_securid_news_blackout/">trouble. Ciò significa che è assolutamente importante proteggere quel server nello stesso modo in cui lo si può fare.

I semi OTP sono diversi dalle password. Le persone tendono ad usare la stessa password su più siti; questo non succede con i semi di OTP. Le password di hashing vengono utilizzate in parte per proteggere le password degli utenti, in modo che se il database del sito X viene violato, gli account degli utenti di X su altri siti non vengono compromessi. Quella minaccia semplicemente non si applica ai semi OTP.

Inoltre, con le password, puoi poter password hash. Se puoi, potresti anche farlo, poiché aiuta a mitigare alcuni rischi. (E le password sono così ampiamente utilizzate e usate dagli sviluppatori che non sono esperti di sicurezza, è quasi scontato che molti siti che usano password incontreranno una violazione della sicurezza a un certo punto.) Dal momento che non si possono avere semi OTP di hash, questo la mitigazione semplicemente non è disponibile per i semi di OTP - quindi dovrai usare altri metodi per proteggere i tuoi semi di OTP. Fortunatamente, solo i siti con molta sicurezza dovrebbero memorizzare i propri semi di OTP, quindi se uno è ottimista, si potrebbe sperare che siano in una posizione migliore per applicare altre difese.

Comunque, dal momento che i semi di OTP hanno caratteristiche diverse dalle password, non dovresti assumere che ogni mitigazione per le password si trasferirà necessariamente anche ai semi di OTP.

    
risposta data 16.11.2012 - 22:04
fonte
9

È possibile crittografare il seme OTP utilizzando una chiave simmetrica derivata dalla password dell'utente. Tuttavia, ciò richiede che l'utente inserisca la password prima di immettere l'OTP, altrimenti il server non può decodificare il seme OTP.

In alternativa, potresti avere un server altamente sicuro che riceve il seme OTP crittografato e restituisce un OTP attualmente valido. La chiave simmetrica per le sementi è memorizzata su questo server. HSM potrebbe aiutarti anche qui.

    
risposta data 21.11.2012 - 11:03
fonte
-2

Diciamo che hai un intervallo di tempo TOTP di "T". Ad esempio, il tuo OTP scade dopo il tempo T. Ciò che si può fare è (per tutti gli utenti uno per uno) che se l'utente non ha richiesto un tempo T OTP prima dell'ora corrente, è possibile modificare il seme. Dato che l'utente non ha richiesto un otp nella nostra finestra temporale, possiamo essere sicuri che non ci sia OTP che deve ancora essere autenticato dal nostro server. Quindi, nel caso in cui l'attaccante ottenga il seme, il seme sarebbe cambiato.

    
risposta data 29.11.2018 - 23:48
fonte

Leggi altre domande sui tag