È possibile firmare digitalmente le informazioni con una password?

Trasferito in un'altra domanda:

Any problemi con questo design di sicurezza per lo storage cloud? Il server non ha nemmeno bisogno di conoscere la password per registrare qualcuno in

L'hashing di più volte per rallentare la forzatura bruta è una cattiva idea, perché ogni volta che si hash si riduce l'entrophy e quindi si rendono più probabili le collisioni accidentali. Quando vuoi intenzionalmente rallentare il calcolo dell'hash, usa un algoritmo con una complessità regolabile, come bcrypt .

Quando vuoi assicurarti che un messaggio sia 1. da parte dell'utente che ti aspetti che provenga e 2. non sia stato manomesso, devi usare un firma crittografica . È possibile creare una firma crittografica creando un hash del messaggio e quindi crittografando tale hash con la chiave privata del mittente. Il ricevitore può quindi calcolare l'hash del messaggio che riceve, decodificare il presunto hash con la chiave pubblica del mittente e verificare che gli hash corrispondano. La sicurezza deriva dal fatto che è impossibile creare un hash corrispondente senza conoscere la chiave privata del mittente.

Ma come si ottiene la chiave pubblica del mittente? O lo hai ricevuto in anticipo su un canale più affidabile. Oppure si ottiene una terza parte affidabile per firmare crittograficamente la chiave pubblica dei mittenti con la propria chiave privata. Alcune affidabili "autorità di certificazione" su cui possono contare che hanno verificato correttamente l'identità del proprio partner di comunicazione. E congratulazioni, hai appena reinventato TLS.

"Ma per quanto riguarda la password"? Bene, ad un certo punto nel passato, il tuo server deve aver ricevuto la password. O l'hash della password. O l'hash dell'hash della password. La password è proprio come la chiave pubblica dell'utente. Come fai a sapere che questa prima volta che hai ricevuto questo non è stato manomesso? Non puoi Nessun sistema crittografico funziona senza aver verificato l'identità di uno dei partner di comunicazione ad un certo punto nel passato, direttamente o tramite una catena di certificati.

Se non vuoi che il server abbia la password né alcuna forma di hash, avrai bisogno di qualche forma alternativa di credenziali.

Potresti, ad esempio, creare la tua CA (che non deve essere considerata attendibile da nessun altro) e rilasciare i certificati di autenticazione del client degli utenti.

Tuttavia, se si è disposti a fornire al server l'hash della password, è possibile effettuare le seguenti operazioni:

• Consenti all'utente di scegliere una password complessa
• Consenti all'utente di ricavare due chiavi casuali a 256 bit da questa password utilizzando PBKDF2
• La prima chiave è ora una chiave privata della firma ECDSA. L'utente calcola la chiave pubblica e ti fornisce durante la registrazione. Questa chiave ora rappresenta l'utente. Qualsiasi richiesta API deve essere firmata con questa chiave.
• La seconda chiave è utilizzata per crittografare simmetricamente i file.

Ora, questo significherebbe che l'utente non può mai cambiare la sua password. Per questo motivo, ciò che di solito accade è il seguente:

• Consenti all'utente di scegliere una password complessa
• Consenti all'utente di ricavare due chiavi, pwkeyA e pwkeyB.
• L'utente genera qualcosa che può utilizzare per autenticarsi correttamente (ad esempio keypair o una chiave simmetrica di cui si riceve una copia). La chiave simmetrica o la chiave privata è authKey.
• L'utente genera una chiave di crittografia del file encKey.
• L'utente crittografa encKey e authKey sotto pwkeyA, risultando in un blob crittografato. Ora ti dà questo blob crittografato. Nota: ora puoi provare a rinforzare la password dell'utente derivando pwkeyA e cercando di decrittografare il blob.
• Se l'utente vuole accedere ai suoi dati, richiede il blob, lo decripta usando pwkeyA e si autenticherà usando authKey. Quindi scarica un file e lo decripta usando encKey.
• Se l'utente vuole cambiare la sua password, scarica il blob, lo decripta usando pwkeyA (derivato dalla vecchia password), lo crittografa usando pwkeyA (derivato dalla nuova password) e lo memorizza sul tuo server.
• Ora, non vuoi che qualcuno sia in grado di cancellare il blob dei tasti del tuo utente, vero? Probabilmente non vuoi che nessuno permetta di scaricare quel blob e di eseguire bruteforce offline su di esso. È qui che entra in gioco pwkeyB. Viene utilizzato come "password" per accedere alla "memoria chiavi" e scaricare / caricare il blob delle chiavi. Nota che pwkeyB è fondamentalmente un hash della password. Potresti migliorare ulteriormente la sicurezza usando pwkeyB come chiave ECDSA privata e facendo la cosa nel primo esempio.

Per il controllo dell'integrità dei file, l'utente potrebbe voler ricavare più chiavi dalla chiave di crittografia e usarne una per AES-CBC, l'altra per HMAC. O utilizzare una modalità di crittografia di autenticazione. Questo è irrilevante per il problema di gestione delle chiavi però.

NOTA: Sono un criptato di poltrone ... (anche noto come un matematico) quindi prendilo in considerazione. Tuttavia, ho testato a penna e "rotto" una buona parte della crittografia implementata male

Passaggio 1, proteggere adeguatamente il canale di comunicazione.

Assicurati che i tuoi certificati TLS / SSL implementino un segreto di inoltro perfetto. La buona notizia è che non è difficile da implementare , ma deve essere fatto sul server. Ciò impedisce agli avversari di essere in grado di catturare il traffico e in seguito di decrittografarlo dopo aver ottenuto la chiave TLS privata (legalmente o illegalmente).

In Moxie's (ha scritto SSLstrip) la recente critica di Lavabit , spiega alcuni problemi di sicurezza relativi all'email fornitori, che potrebbero essere rilevanti nella tua situazione.

A typical (unencrypted) email provider has three main adversaries:

1. The operator, who has access to the server.
2. An attacker who can get access to the server.
3. An attacker who can intercept the communication to the server.

Sono felice di vedere che stai eseguendo l'hashing della password, ma commentarla mi metterebbe fuori dalla mia profondità. Ho sentito molte persone più intelligenti a crypto di me a consigliare PBKDF2 .

Questa è solo una risposta parziale, ma la sicurezza del canale di comunicazione con perfetta segretezza in avanti è il lavoro 1.