Perché la crittografia è dannosa per le password?

-1

Usiamo PGP per quasi tutto ed è così irrealizzabile per la bruteforce che è considerato sicuro. Questo è il principio guida oltre a CryptoLocker. Ma per cose come e-mail, SSH e HTTPS, è ancora considerato sicuro anche se il costo computazionale della crittografia dovrebbe essere basso, poiché si tratta di attività comuni che devono accadere milioni di volte al giorno. Ora se una password crittografata con crittografia strong è in chiaro, l'aggressore non può farci nulla. Ma una password hash è vulnerabile - può essere bruta. Quindi esiste una politica di password che può rendere sicura la crittografia di una password con crittografia strong? Un utente può utilizzare le sue chiavi PGP per crittografare la password prima di inviarla al server? Che dire della crittografia end-to-end?

    
posta user101387 16.02.2016 - 02:59
fonte

3 risposte

13

Password con hash corretto

  • L'app Web memorizza il valore di hash e iterazione (PBKDF2 / BCrypt / SCrypt, crypto random salt, alte iterazioni / fattore di lavoro).

  • Per accedere, l'utente inserisce la password

    • l'app web recupera il conteggio di sale e iterazioni e il risultato hash

    • gli hash delle app Web hanno immesso la password con il numero di sale e di iterazione, confronta i risultati. Se uguale, va bene.

    • un utente malintenzionato offline con una copia del database può ottenere MEGLIO solo quelle password che l'utente malintenzionato suppone

    • Detto attaccante offline non guadagna NESSUN VANTAGGIO se ruba anche il codice eseguibile dell'app Web

    • L'offensivo offline non guadagna NESSUN VANTAGGIO se ruba anche il codice sorgente dell'app Web

    • Detto attaccante offline guadagna MINIMAL ADVANTAGE se ruba tutti gli altri dati a cui l'app web può accedere, dal momento che sarà in grado di utilizzare nomi, dati dei membri della famiglia, indirizzi, ecc. per aiutare a indovinare le password per le persone chi usa quelli per costruire le loro password.

Password correttamente crittografate

  • L'app Web memorizza l'IV e il risultato PW crittografato in DB, e inserisce in qualche altro archivio di chiavi (AES / Camellia / Aria).

  • Per accedere, l'utente inserisce la password

    • l'app web recupera IV e chiave e PW crittografato

    • l'app web decrittografa PW crittografato con IV e chiave, confronta i risultati. Se uguale, va bene.

    • un utente malintenzionato offline con una copia del database di IV e PW crittografati può ottenere MEGLIO solo quelle password che l'utente malintenzionato indovina la chiave per

    • Detto attaccante offline guadagna POSSIBILE IL 100% DI TUTTE LE PASSWORD DECRITE se rubano anche il codice eseguibile dell'app Web, se è lì che le chiavi erano

    • Detto attaccante offline guadagna POSSIBILE IL 100% DI TUTTE LE PASSWORD DECRITE se rubano anche il codice sorgente dell'app Web, se è lì che le chiavi erano

    • Detto attaccante offline guadagna GARANTITO AL 100% DI TUTTE LE PASSWORD DECRITE se rubano tutti gli altri dati a cui l'app web può accedere, poiché l'app web doveva avere accesso alle chiavi

Altri punti importanti:

  • Crittografia significa che chiunque abbia accesso a chiavi, IV e password crittografate può silenziosamente e senza traccia impersonare qualsiasi utente, lì o dall'esterno, che è generalmente considerato orribilmente cattivo.

  • Hashing rende le più forti password crittografiche casuali, più di 30 caratteri virtualmente immuni dal fatto di essere indovinate, perché sono criptate casuali con un enorme spazio per le chiavi.

    • D'altro canto, la crittografia rende tutte le password ugualmente deboli, indipendentemente da quanto sia strong la vera password, perché tutto ciò che serve è IV e chiave, e si ottiene anche la password più strong per provare altri siti o vendere.
  • Se avevi già intenzione di archiviare le chiavi di crittografia separatamente dalle password crittografate, puoi ottenere risultati superiori in ogni categoria memorizzando i sali unici per utente, crittograficamente casuali separatamente dalle password effettive con hash.

risposta data 16.02.2016 - 04:41
fonte
4

Il problema principale con la crittografia delle password non è che la crittografia può essere interrotta, ma che qualcuno con la chiave di decodifica può capire quale sia la password.

Immagina questo scenario avvio un servizio web di qualche tipo e crittografo le password con crittografia AES a 256 bit e per il gusto di un argomento supponiamo che sia implementato perfettamente, non ci siano difetti o attacchi ai canali laterali, l'unico il modo per recuperare la password è con la chiave.

Quindi vieni e iscriviti al mio servizio e inserisci il tuo indirizzo email e imposta la password.

Ora vado fuori di testa o forse è un impiegato che ha / ha avuto accesso legittimo alla chiave, o forse un hacker che ha scaricato il database ha rubato la chiave. Qualunque cosa sia, il punto è che in qualche modo la chiave viene fuori.

Ora chiunque abbia la chiave può vedere che la tua e-mail è [email protected] e la password che hai usato è "0pen 5esame" quindi ora vado su facebook, twitter, instagram e così via provando quella e-mail e password < sup> [1] .

Ora, se immaginiamo la stessa situazione ma con PBKDF2 invece di AES, non ci sono più chiavi da perdere e, anche se può essere forzato brutalmente, ci vorranno giorni o settimane per rompere solo alcune password deboli. Non c'è modo di decodificare tutte le password contemporaneamente.

[1] si potrebbe sostenere che l'utente non deve riutilizzare le password attraverso i siti, ma questo è il mondo in cui viviamo e la maggior parte delle persone ha solo una password che usa ovunque.

    
risposta data 16.02.2016 - 03:29
fonte
0

Oltre alle buone risposte qui, voglio anche dire che la tua affermazione "Ma una password hash è vulnerabile - può essere bruta-forza" è anche abbastanza sbagliata.

Bruteforce, o meglio usare le tabelle arcobaleno, è utile solo per le password deboli. Se generi una password strong casuale con sufficiente entropia, il suo hash probabilmente non comparirà in nessuna tabella arcobaleno (né potrà essere bruto in qualsiasi momento pratico).

Gli algoritmi meno recenti (MD5, SHA1) possono avere punti deboli per la collisione, ma poiché è un vettore difeso attivamente nella progettazione, è improbabile che ti dia un vantaggio troppo significativo nella bruteforcing di un hash specifico (solo in arcobaleno generazione di tabelle davvero).

    
risposta data 16.02.2016 - 18:17
fonte