Creazione di una chiave privata utilizzando l'intervento umano

6

In un sistema ipotetico, diciamo che un requisito di progettazione è che le persone che curiosano attorno al database di un'applicazione web (sysadmin è diventato canaglia o che cosa hai), non hanno accesso al testo semplice dei messaggi privati tra gli utenti . Una versione crittografata del testo viene invece memorizzata.

Il modo più semplice per farlo è utilizzare uno schema di crittografia a chiave pubblica / privata. Tuttavia è (davvero) inefficace memorizzare la chiave privata nel sistema, o nel browser degli utenti dato un aggressore dalla volontà decisa. Questo lascia l'intervento umano per la generazione.

A corto di usare un'applet java (o HTML5 / Javascript di fantasia), è difficile fornire un'istanza per un essere umano per fornire input casuali per generare la chiave privata, e c'è ancora il problema di archiviarla. C'è anche un problema che richiede agli umani di ricordare una password casuale di 16 caratteri usando caratteri alfanumerici e simboli sensibili al maiuscolo / minuscolo. Anche i dongle di chiavi private che le aziende tendono a utilizzare sono fuori questione.

Quindi la domanda è: Come faccio a prendere una password potenzialmente insicura e trasformarla in una chiave privata sicura? È persino possibile?

Le mie idee tendono a fluttuare verso ciò che non è realmente possibile fino a quando un utente non utilizza una passphrase decisamente sicura (16+ caratteri, maiuscole e minuscole con i numeri), a causa della facilità di forzare brute in questi giorni. Inoltre, un problema potrebbe essere la mancanza di una crittografia sufficientemente sicura che utilizza il proprio input per generare una chiave da utilizzare. Di nuovo, derivando dal problema con la memorizzazione della chiave utilizzata nella generazione.

Inoltre, supponiamo che vengano utilizzate tecniche appropriate in tutti gli altri punti del sistema (SSL, algos di crittografia aggiornati, ecc.)

    
posta Mike S 10.11.2011 - 14:56
fonte

1 risposta

3

Cercando di scrivere la resistenza della password agli attacchi di forza bruta come un'equazione: complessità * trasformazione costo = resistenza . Il limite limitato al costo di trasformazione è il tempo in cui si desidera lavorare per verificare (o generare una chiave da) una password ogni volta che è valida. Le password scadenti sono difficili da forzare se la funzione di derivazione impiega un anno per essere eseguita, ma è anche difficile utilizzarle come caso legittimo.

Il metodo "nuovo tradizionale" per generare una chiave da una password è eseguirlo tramite PBKDF2 . Bcrypt e scrypt sono due opzioni "più forti". Quando si sceglie il numero di iterazioni, punto di riferimento e manovella quella cosa in alto come ci si sente a proprio agio in base al carico previsto. Troppo basso ed è facile da decifrare. Troppo alto e ti negheresti di servirti fino alla morte con operazioni legittime. Il tornasole di base è "quanti tentativi di accesso devo essere in grado di gestire al secondo?" Ricorda che, a differenza dell'hash della password, non puoi aumentare le iterazioni in un secondo momento (a meno che non riesegui la crittografia di tutto - probabilmente non vuoi farlo).

Archivia un salt casuale con i tuoi dati crittografati (uno per ogni password / chiave utilizzata) e usa il corrispondente sale con la password. Ciò assicurerà che ciascuna password debba essere individualmente attaccata al posto dell'intero gruppo contemporaneamente.

    
risposta data 10.11.2011 - 15:30
fonte

Leggi altre domande sui tag