Archiviazione dati asimmetrica + Memorizzazione password No-Hash?

0

Modifica: rimosso una parte della domanda originale; Lo analizzerò in un altro post.

Sto seguendo @ Polynomial's answer per memorizzare le informazioni in un database. Ecco i miei requisiti:

  • Solo l'utente può vedere le loro informazioni. Il server vede solo i dati codificati.
  • Consente di modificare facilmente la password
  • OK con "hai perso la tua password, hai perso i tuoi dati"
  • Se possibile, non memorizza un hash della password utente
  • Utilizza solo un server e il suo spazio di archiviazione

Ecco cosa ho finora:

Tabella DB USER_DATA contiene ([chiave XORed] [casuale IV] [dati segreti crittografati] [userID])

Inserimento dati

1. User enters (secret data) into a form.
2. User enters (user password)
3. Generate a strong (random key).
4. Encrypt (secret data) using (random key) and (random IV), as (encrypted secret data).
5. XOR hash of (random key) with hash of (user password) as (XORed key).
6. In the database, store in a new row: (XORed key),(random IV),(encrypted secret data), (userID)

Recupera dati

1. Ask user for (user password).
2. Query database for (XORed key),(random IV),(encrypted secret data).
3. XOR hash (user password) with (XORed key) to retrieve the initial (random key)
4. Use (random key), (random IV) to decrypt (encrypted secret data).
5. Display decrypted data on screen.

Vorrei chiedere un riscontro sul sistema sopra, per quanto riguarda la (1) sicurezza e (2) l'efficienza. Vorrei anche avere le tue opinioni sul seguente sistema:

L'autenticazione

Il modo semplice sarebbe quello di memorizzare un hash della password, autenticarsi contro di esso e creare una sessione per consentire la navigazione nei record. Ogni record viene decifrato e quindi visualizzato all'utente. Tuttavia, poiché la password è utilizzata per decrittografare tutte le informazioni dell'utente, sto cercando di evitare di memorizzare il suo hash: Sono curioso di sapere se è possibile anche con un solo server coinvolto . Ecco un sistema a cui ho pensato, ma spezzarlo avrebbe richiesto esattamente lo stesso sforzo di forzare un hash:

Accesso utente iniziale

1. Ask user for (user password)
1. Create a strong (random key)
2. XOR (user password) with (random key) into (XORed key).
   Store this value in the database.
3. Create a (random hash).  Store in database.
4. Encrypt (random hash) with (random key) and (random IV)
   as (Encrypted random hash).  Store in database.

Quindi ora abbiamo nel database:     Tabella USER_AUTH ([chiave XORed] [hash casuale] [hash casuale crittografato] [casuale IV])

Negli accessi successivi, la password che l'utente fornisce è XORed con (chiave XORed) per recuperare (chiave casuale). (chiave casuale) viene quindi utilizzato per decrittografare (hash casuale crittografato). Se il valore decodificato è uguale a (hash casuale), la password è corretta.

    
posta David_Springfield 08.05.2014 - 03:40
fonte

2 risposte

1

Quello che probabilmente vorrai fare è usare un algoritmo Key Wrap , ma non è assolutamente necessario. Mi sembra ragionevole che tu possa fare quanto segue per la crittografia:

  1. Calcola un codice utente dalla password dell'utente, usando qualcosa di strong come PBKDF2.
  2. Genera una chiave dati casuale .
  3. Cripta la chiave dati con il tasto utente , questa verrà memorizzata come chiave avvolta .
  4. Genera un HMAC attraverso il tasto avvolto digitato dal tasto utente . Questo sarà memorizzato per l'autenticazione. (Devi ancora selezionare la riga con un altro meccanismo.)
  5. Cifra i dati usando il tasto dati .
  6. Memorizza il sale PBKDF2, la chiave avvolta , hmac, IV e crittografati.

Decodifica:

  1. Seleziona la riga pertinente dal DB.
  2. Usando il sale, ricalcola il codice utente dalla password.
  3. Verifica l'HMAC sulla chiave incartata utilizzando il tasto utente . Questo è il passo di autenticazione.
  4. Utilizza il tasto utente per decrittografare la chiave avvolta , rivelando la chiave dati .
  5. Decrittografare i dati usando IV e chiave dati .
risposta data 09.05.2014 - 06:07
fonte
0

Vedo due difetti con questo sistema:

1) Non menzioni alcun modo per associare le righe nel database con un dato utente (ad esempio il passaggio 2 nel processo "recupera dati").

2) Ogni chiave casuale è XORd con lo stesso valore (la password dell'utente). Poiché si può presumere che le chiavi casuali siano distribuite in modo uniforme, un utente malintenzionato in grado di determinare che più file di database appartengono allo stesso utente può recuperare la password dell'utente tramite analisi statistiche banali. Più dati memorizza l'utente, più facile e più accurata è questa analisi.

    
risposta data 08.05.2014 - 08:39
fonte