È sicuro rivelare la password crittografata AES?

5

Per favore correggimi se qualcuna delle mie affermazioni è errata.

Probabilmente è più utile non mostrare alcun suggerimento della password.

Tuttavia, le password crittografate AES di per sé non possono essere utilizzate per decrittografare la password o trovare la chiave; attacco con testo in chiaro non funziona con AES. Ciò significa che rivelare la password crittografata non fa davvero male a nessuno.

Quindi, è sicuro rivelare le password crittografate AES nelle applicazioni web?

    
posta Harry Cho 15.04.2016 - 01:41
fonte

2 risposte

9

Risposta principale

In sintesi, hai perfettamente ragione con la tua prima ipotesi:

It is probably more good practice to not show any hint of the password.

Tuttavia ci sono alcuni problemi con il resto della tua domanda:

  • Non vuoi crittografare le password.

    Di solito, questo è, almeno.

    schroeder chiede giustamente nei commenti

    Side question: why are passwords encrypted and not hashed?

    Il fatto è che se crittografate le password invece di eseguirne l'hashing, potete sempre decrittografarle e usarle. Di solito, la chiave per la decrittografia deve essere da qualche parte nell'applicazione affinché i dati siano di qualsiasi utilità.

    Quindi, se qualcuno ha rubato i dati della tua applicazione - che non è così raro (e il solito motivo per cui le credenziali appaiono su haveibeenpwned ) - che qualcuno ha tutte le password in chiaro.

    Quindi, di solito vuoi usare le password hash - ci sono Q & ben ricevuto come qui su come funziona.

  • Non vuoi usare AES semplice

    Se si utilizza semplicemente AES, la stessa password viene crittografata sullo stesso testo cifrato.

    Se qualcuno ha accesso a tutti i testi cifrati, è probabile che l'analisi statistica dia via il testo in chiaro di almeno un testo cifrato e tutti gli account con quella password vengono automaticamente violati.

    Un esempio: se sai che la password più utilizzata è cucumber , vai avanti e cerca il testo cifrato più spesso visualizzato - il testo normale è probabilmente cucumber .

    Inoltre, questo limita le password dei tuoi utenti alle dimensioni del blocco. Questo potrebbe non essere quello che vuoi tu (o i tuoi utenti).

  • Vuoi dare meno informazioni possibili.

    Anche pubblicamente elencare gli hash delle password degli utenti sarebbe una pessima idea, dato che - di nuovo - schroeder ha già inserito i commenti:

    Another question: what do you mean by "safe"? It is possible to brute-force the decryption of an encrypted string.

  • La crittografia delle password è fondamentalmente un reato di testo normale, in base alle Domande frequenti sui criminali di testo normale

    1. But the site says they store my password securely using [something]!

      Your password is yours. It is the means by which you identify yourself to a site. If a site can tell what your password is after you gave it to them, anyone can know what your password is (hackers, disgruntled employees, people stumbling onto it by accident, etc.).

Nota a margine

Mentre AES con una ragionevole modalità operativa non è vulnerabile agli attacchi di testo in chiaro noti (penso che quello che avevi in mente era "Conosco la mia password, posso estrapolare la chiave e conoscere tutte le password"), usando la semplice AES, come detto prima, aumenta le possibilità che un attaccante vinca in un CPA modello.

Che è sostanzialmente quello che hai, dato che un utente può cambiare la sua password.

    
risposta data 15.04.2016 - 09:52
fonte
-2

No, non lo è.

Mentre è lo scopo stesso della crittografia, per proteggere i dati all'interno della crittografia (a condizione che la chiave sia sicura!), esiste una vulnerabilità molto chiara, che le password, in particolare, sono abbastanza vulnerabili a:

Una data stringa di input, crittografata con AES, darà sempre lo stesso risultato.

Ciò significa che, se due utenti hanno le stesse password e una è compromessa, anche l'altra viene automaticamente compromessa.

Ad esempio, diciamo che ho impostato la mia password con la password più comune: "password". Ottengo la stringa crittografata AES. Quindi lo cambio in "123456", e ottenere questa stringa crittografata. Passo a poco a poco il mio modo attraverso le prime 10.000 password, generando 10.000 stringhe crittografate (e le loro password non criptate). Non ho idea di quale chiave è stata utilizzata.

Ora, vado a un altro utente casuale. C'è una possibilità del 90% di poter cercare la loro password crittografata con AES nella mia tabella arcobaleno, a quel punto posso vedere esattamente quale sia la loro password.

Gli hash delle password sono anche vulnerabili a questo. Questo è il motivo per cui sale & normalmente vengono utilizzati i peperoni.

Inoltre, per le password più lunghe, se il primo blocco (16-32 caratteri) dell'ingresso corrisponde, anche il primo blocco dell'output corrisponderà. Quindi, se la password è "Il mio nome di accesso è AMADANON Inc." e la password di qualcun altro è "Il mio nome di accesso è Harry Cho" e la mia password è compromessa, sono noti anche i primi 16 caratteri della tua password.

Sebbene questi problemi possano essere risolti, c'è anche un problema più grande: se qualcuno riceve la chiave AES, tutte le password sono in chiaro. Le chiavi AES sono, abbastanza inevitabilmente, archiviate abbastanza vicine alle password crittografate (sulla stessa macchina). dovresti accettare che, se il malware accede a un server con la chiave AES e le password crittografate AES, vengono compromessi.

L'unica ragione per archiviare una password crittografata AES, è sul lato client, se non si ha il controllo del lato server. NON farlo MAI sul server - usa un buon hash standard, da una libreria standard, con sale e pepe.

Se stai scrivendo sia il client che il server, NON utilizzare affatto le password. A questo punto, non si sta autenticando un utente, ma una macchina. Per autenticare una macchina, le password sono lo strumento sbagliato. Invece, usa la chiave pubblica crypto - TLS per esempio, con l'autenticazione del client - di nuovo, ci sono già delle librerie scritte per te. Se si desidera autenticare anche l'utente, inserire una password sulla chiave privata. La chiave crittografica pubblica ha i vantaggi che il segreto non viaggia mai attraverso la rete e il server non sa cosa sia; si dimostra di averlo senza darlo al server.

    
risposta data 15.04.2016 - 05:57
fonte

Leggi altre domande sui tag