Le password monouso resistono agli attacchi bruteforce? Alternativa immunitaria?

Hai due domande diverse. Per rispondere alla tua prima domanda ...

Does a One-Time-Password like Google Authenticator or YubiKey protect against brute force attacks with unlimited computer power?

Quando parli di attacchi di forza bruta devi differenziare tra attacchi online e offline.

Quando si considerano gli attacchi brute force online, vi rimando alla sezione 7.3 della RFC 4226.

Truncating the HMAC-SHA-1 value to a shorter value makes a brute force attack possible. Therefore, the authentication server needs to detect and stop brute force attacks.

We RECOMMEND setting a throttling parameter T, which defines the maximum number of possible attempts for One-Time Password validation. The validation server manages individual counters per HOTP device in order to take note of any failed attempt. We RECOMMEND T not to be too large, particularly if the resynchronization method used on the server is window-based, and the window size is large. T SHOULD be set as low as possible, while still ensuring that usability is not significantly impacted.

Another option would be to implement a delay scheme to avoid a brute force attack. After each failed attempt A, the authentication server would wait for an increased T*A number of seconds, e.g., say T = 5, then after 1 attempt, the server waits for 5 seconds, at the second failed attempt, it waits for 5*2 = 10 seconds, etc.

The delay or lockout schemes MUST be across login sessions to prevent attacks based on multiple parallel guessing techniques.

Buone implementazioni di HOTP e TOTP, che sono gli algoritmi utilizzati in Google Authenticator dovrebbero limitare i tentativi di accesso, contrastando gli attacchi bruteforce online.

Quando si tratta di attacchi di forza bruta offline , l'attaccante deve indovinare il segreto condiviso usato.

RFC 4226 Sezione 4 ha questo da dire sul segreto.

R6 - The algorithm MUST use a strong shared secret. The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits.

Gli attacchi di forza bruta contro chiavi di tale lunghezza sono considerati impossibili .

Passa alla tua seconda domanda ...

If not, what algorithems are immune to bruteforce attacks against static data on a HHD or USB-Stick? Consider the data is stored on an USB-Storage and you loose the USB-Storage to the attacker who has unlimited computer power available to brute force the password.

Le unità ordinarie non crittografano il loro contenuto in alcun modo. Perdere l'unità significa rivelare tutti i dati su di esso. devi crittografare i dati sul disco se vuoi sperare che rimanga sicuro. Alcune unità hanno crittografia integrata mentre puoi usare software come TrueCrypt per crittografare gli altri.

Supponendo che la crittografia sia corretta (AES con una modalità operativa corretta e tutto il resto ...), si tratta della password da cui si ricava la chiave. In questa situazione, la crittografia è strong quanto la tua password. La scelta di una password lunga e casuale rende molto improbabile che un utente malintenzionato possa indovinarlo.

Ovviamente si presume che l'autore dell'attacco sia limitato a livello informatico che è ciò che dovrai affrontare nella realtà. Contro gli attaccanti con potenza di calcolo illimitata, avrai bisogno di una classe di algoritmi molto speciale, nota per essere information theoretic secure . Alcuni esempi di tali algoritmi sono One Time Pad e Shamir's Secret Sharing.

Nulla in questo mondo è invulnerabile a potenza del computer illimitata . Buono a sapersi che non esiste un tale sistema.

1. In uno scenario di attacco reale, l'attacco a un sistema protetto OTP dipende da quanti tentativi l'attaccante può effettuare nel tempo del token OTP (generalmente un minuto). Se utilizzi la limitazione della velocità sullo schema di autenticazione, impiegando un ritardo fisso in ogni sessione di autenticazione, sei abbastanza sicuro.

2. Non ci sono algorythm immune all'attacco offline. Ci sono quelli molto resistenti, che impiegano tempi molto lunghi per essere spezzati (miliardi di anni) ma nulla è indistruttibile. Se l'utente malintenzionato può forzare la tua password offline con una potenza di calcolo sufficiente, la sicurezza dipende dalla tua password. Qualsiasi dato criptato con un algoritmo molto sicuro e protetto da una chiave banale sarà facilmente decodificato.

Presumo nella mia risposta che l'OP parli di attacchi online, dal momento che non è proprio possibile utilizzare OTP per la crittografia o gli hard disk offline.

Per la prima domanda, dipende se usi OTP basati su eventi, eventi o basati su sfide. Parlerò del metodo standardizzato delle varianti di autenticazione OTP a 6 cifre (HOTP, TOTP, OCRA) ora:

Basato sul tempo: sono sicuri contro la bruteforcing, dal momento che l'hacker ha solo 30 secondi per enumerare tutti i codici, a condizione che NON abbia alcuna finestra di sincronizzazione e che tu abbia i token TOTP impostati per cambiare codice ogni 30 secondi. Anche aggiungere un ritardo su 0,5 secondi per ogni tentativo di accesso (indipendentemente dal fatto che abbia successo o meno), che è fondamentalmente inosservabile per un utente normale, darà all'aggressore solo la possibilità di indovinare il codice con una propabilità di 1/16666, che è molto più difficile di indovinare un perno ATM con 3 tentativi, che ha una probabilità di successo di 1/3333. Dopo 30 secondi, il codice TOTP viene modificato, costringendo l'attaccante a ricominciare dall'inizio. Consiglierei comunque un captcha per evitare bruteforcing poiché l'utente malintenzionato potrebbe colpire per fortuna 1/16666.

Basato su eventi: NON sono sicuri contro la bruteforcing, poiché lo stesso codice statico viene utilizzato sempre, finché non viene presentato un codice corretto. L'unico modo per proteggere un accesso basato su eventi è bloccare l'account e richiedere 2 codici successivi per sbloccare o utilizzare un captcha. Un modo potrebbe essere quello di utilizzare entrambi. Il 2 sistema di codice successivo non sarebbe notabile all'utente finale, poiché l'utente tenterebbe di accedere al suo account bloccato, semplicemente ottenendo "Codice OTP non valido, riprova con il prossimo codice". (come gli utenti che hanno realmente digitato erroneamente la loro OTP), l'utente premerebbe di nuovo il pulsante per generare il codice successivo. Dopo aver inserito questo secondo codice, l'account sarebbe stato presentato con 2 codici HOTP successivi e sbloccato, senza che l'utente si accorgesse che l'account era bloccato e senza che un utente malintenzionato accorgesse di aver inserito l'HOTP corretto (poiché l'account sarebbe stato bloccato per primo prova, quindi l'utente malintenzionato dovrebbe inserire 2 codici successivi, ma l'autore dell'attacco non potrebbe mai scoprire quando ha inserito correttamente il primo codice). Richiedere 2 codici successivi ridurrebbe immediatamente l'attaccante a dover indovinare qualcosa fuori dalla possibilità di 1/1000000000000, che equivale a una password di 6 caratteri con A-Z a-z e 0-9. Inoltre, se l'autore dell'attacco inserisce correttamente il primo codice, ma il secondo non correttamente, dovrebbe ricominciare dall'inizio di tutti quei codici 1000000000000 poiché il primo codice è stato invalidato.

Basato sulla sfida: qui dipende dal design. Poiché la risposta è proporzionale alla sfida, è importante qui rendere le sfide unidirezionali e scadenti. Se si programma il proprio sistema di sfida per consentire una sola sfida valida per un account in una volta, assicurarsi che ogni sfida sia monouso (ad es. La sfida viene invalidata a ogni tentativo, indipendentemente dal corretto OTP specificato o meno), e assicurarsi che la sfida è scaduto quando non viene utilizzato per un certo periodo di tempo, quindi il sistema sarà fondamentalmente infinitamente sicuro contro la bruteforcing poiché ogni tentativo causerebbe al sistema di modificare il codice di accesso. Tuttavia, l'attaccante potrebbe colpire 1/1000000 di sfortuna semplicemente, come vincere un jolly su un numero esatto a 6 cifre del lotto, perché dovresti avere il captcha anche su questi accessi.

L'autenticatore di Google, se utilizzato con Google o Facebook, è un token TOTP, ad esempio OTP basato sul tempo, ma può anche essere caricato con profili HOTP (basati su eventi).

Quando parli di yubikey, usando la loro chiave interna da 44 caratteri o disattivando l'identificatore pubblico che fornisce una chiave di 32 caratteri, la lunghezza della chiave, anche se basata su eventi, rende praticamente impossibile forzare la forza a un sistema protetto da yubikey , dato che la bruteforcing di una risposta yubikey sarebbe equivale alla bruteforcing di una chiave AES a 128 bit (32 caratteri esadecimali). Quindi, indipendentemente dal fatto che tu applichi una forza maggiore alla risposta, o forza brutaforce la chiave di archiviazione interna yubikey, il tuo lavoro sarà duro come entrambi. Un utente malintenzionato vorrebbe potenziare la chiave interna, poiché otterrebbe un successo maggiore.

Sulla domanda 2, non capisco cosa intendi, dal momento che è tecnicamente impossibile utilizzare gli OTP se l'autenticatore Oracle non è completamente sicuro. Ciò significa che il processo o la voce che verifica le OTP devono essere attendibili e l'utilizzo di OTP in uno scenario offline significa semplicemente che l'autore dell'attacco potrebbe modificare il processo offline per consentire il riutilizzo di vecchie OTP e tentativi illimitati.

1. Sì. Supponendo che la bruteforcing offline abbia avuto successo e che abbiano scoperto la tua password, non possono ancora accedere al sistema senza il token di autenticazione monouso. Non avranno l'opportunità di implementare bruteforce il token di autenticazione una tantum.

2. N / A a causa del se non