Yubikey con KeePass utilizzando challenge-response vs OATH-HOTP

a seconda di come il plugin lo fa internamente, questo può essere un modo abbastanza interessante di aggiungere sicurezza.

essenzialmente questa cosa fa un cattivo uso di HOTP, calcolando i prossimi molti OTP necessari e li forma insieme al passaggio principale per crittografare il database.

ma ovviamente quando hai un lookahead attivo (e dovresti davvero, soprattutto su un nano) genera alcune sequenze di tasti in più nel caso in cui tu abbia incrementato il contatore per caso.

L'idea alla base non è male, anche se ovviamente il keepass ha bisogno di memorizzare il seed (shared secret) nel database per consentire di ricodificarlo.

il plugin keechallenge funziona sulla stessa premessa: l'hashing di un segreto condiviso con qualche tipo di sfida (il contatore in HOTP), ma questo plugin è in realtà più sicuro da alcuni punti di vista.

1) fornisce un output a 160 bit di HMAC-SHA1 invece di "solo" di log2 (10 ^ (6 * x)) bit (x è il numero di OTP consecutivi che selezioni, 8 OTP consecutivi otterresti solo a 159 e mezzo bit di lunghezza)

Semplicemente dicendo, è necessario toccare MUCH less per lo stesso livello di sicurezza, e mentre il plugin OTP potrebbe probabilmente essere configurato per utilizzare una tonnellata di OTP per una sicurezza ancora maggiore, con modifiche il plugin Challenge-Response potrebbe anche eseguire più sfide lanciando il numero di bit attraverso il tetto, con ancora solo un ottavo dei tocchi necessari (e nessuna preoccupazione di intercettare male e non ottenere la sequenza corretta).

2) dal momento che la sfida è fornita dal database, non dobbiamo preoccuparci di toccare accidentalmente la chiave o lookaheads, il che significa che non abbiamo bisogno di abbassare la sicurezza consentendo l'accesso a più soluzioni di secondo fattore.

Semplicemente detto numero 2 significa che lo Yubi ha solo il Segreto e il DB ha quello che potrebbe essere chiamato lo "stato" della sfida, mentre in TOTP, lo Yubi ha sia lo stato sia il segreto necessari per decrittografare il DB e il lo stato cambia ogni volta che tocchi il tasto, il che significa che dovresti tenere conto di più stati.

anche se ovviamente il segreto condiviso deve ancora essere memorizzato in un modo o nell'altro all'interno del database (a meno che tu non cambi affatto la sfida, ma questo è spericolato).

Dovresti essere consapevole del fatto che qualsiasi meccanismo per implementare 2factor con KeePass non aggiunge fondamentalmente una vera sicurezza. Qualsiasi utente malintenzionato che riceve una sospensione del proprio database semplicemente non installerà il plug-in OTPKeyProv e non sarà obbligato a utilizzare il secondo fattore.

OTP 2-factor fornisce l'autenticazione, non la crittografia e funziona solo in scenari in cui l'utente malintenzionato non ha accesso diretto al vault della password prima dell'autenticazione, ad esempio con servizi online come LastPass. Con KeepPass, l'utente malintenzionato deve avere accesso al database durante l'autenticazione e, in quanto tale, può semplicemente scaricare il database e ignorare il pezzo di autenticazione.

Più semplicemente: l'uso di OtpKeyProv non aggiunge alcuna sicurezza alla tua chiave principale ed è principalmente teatro di sicurezza.

EDIT: Resto corretto su alcuni fronti - basato sulle risposte dell'autore del plugin, il plugin è progettato per aggiungere una chiave segreta aggiuntiva alla password principale e proteggerlo usando gli HOTP. Non è chiaro come ciò sia fatto, ma sembra plausibile. Tuttavia, si dovrebbe notare che questo non è un vero fattore 2, ed è più simile a un fattore e mezzo; il fattore principale (chiave di crittografia) viene rafforzato da una chiave più debole, anch'essa debolmente protetta. Quindi è una sicurezza aggiuntiva, ma non tanto quanto le vere offerte a 2 fattori nei sistemi di autenticazione.