Ho un'idea per un'app che potrebbe essere utile (anche se non lo è, ho comunque imparato nel processo, che è ciò che conta).
Ci sono un sacco di applicazioni web pastebin crittografate disponibili (ad esempio defuse.ca/pastebin.htm) che eseguono la crittografia / decrittografia sul client utilizzando JavaScript. Quindi, la crittografia end-to-end viene raggiunta, A MENO CHE un utente abbia hackerato il server e modificato il codice JavaScript in modo che i futuri utenti che si connettono ottengano il codice JavaScript modificato che rimanda la password non crittografata all'hacker.
La mia idea è che l'utente debba interagire con un'app client autonoma anziché con un'app browser per rimuovere la vulnerabilità JavaScript.
- L'utente scarica l'app standalone del client. Durante il download / l'installazione viene fornita una certa sicurezza perché: un. L'app client è firmata digitalmente b. I download avvengono da un server https c. Gli hash SHA sono disponibili per i file scaricati d. Il codice sorgente per l'app client è disponibile
- L'utente avvia l'app e seleziona "new paste". Vede una grande casella di testo.
- Tipi di utenti / paste testo e clic "Invia". All'utente viene richiesta una password e la inserisce.
- L'app client CSPRNG genera sale S di 128 bit
- La funzione di derivazione lenta accetta password e S e deriva la chiave a 256 bit K e il vettore di inizializzazione a 128 bit IV.
- Esegui crittografia Aes (dimensione del blocco a 128 bit, chiave a 256 bit, modalità CBC, riempimento PKCS7) utilizzando testo in chiaro, K e IV per produrre Cyphertext C.
- Server delle app delle app client (chiamata di resto a https uri), passando S e C
- Il server memorizza S e C in una riga del database (S è chiave primaria).
- Server indica al client che i dati sono archiviati. Il client dice all'utente "dati salvati" e presenta S all'utente come identificatore di incolla univoco.
- L'utente prende nota di S (file di testo sul suo computer, e-mail a se stesso, ecc ... non deve essere tenuto segreto). La password deve essere tenuta segreta.
- Successivamente, l'utente avvia nuovamente l'app client.
- Sceglie "apri pasta esistente". Inserisce S e seleziona trova.
- L'app del client chiede al server di trovare una corrispondenza di corrispondenza S (chiamata di resto a https uri). Se lo fa, restituisce il testo crittografato.
- Se si trova incollare, l'app client richiede all'utente la password di decrittografia. Lo digita.
- La funzione di derivazione lenta accetta password e S e deriva la chiave a 256 bit K e il vettore di inizializzazione a 128 bit IV.
- Decodifica Aes eseguita (dimensione del blocco a 128 bit, chiave a 256 bit, modalità CBC, riempimento PKCS7) utilizzando testo in chiaro, K e IV per produrre plainText.
- L'app client mette il testo in chiaro nella casella. L'utente può modificarlo e ricodificarlo o chiuderlo e creare una nuova incolla (torna al passaggio 2).
Note:
- Diversi utenti potrebbero visualizzare la stessa pasta se: un. Sono d'accordo in anticipo su una password o la password viene comunicata dall'utente 1 all'utente 2 dopo aver fatto una copia, AND b. L'utente che fa la pasta condivide S con altri utenti (questo può essere condiviso in modo non sicuro).
Domande:
- Quali vulnerabilità di sicurezza ha questa installazione e come potrebbe essere migliorata?
- Mi manca qualcosa di vitale in termini di esperienza utente?
- Ri: Passaggio 17. Ho letto che non si dovrebbe mai usare lo stesso sale due volte. Sarebbe fastidioso che l'identificatore della pasta (S) cambi con ogni modifica / reencryption (se più utenti accedono alla stessa pasta, avrebbero bisogno di consigliare la nuova S ogni volta che viene effettuato un aggiornamento / reencryption), ma è inevitabile farlo se non voglio sacrificare la sicurezza?
Grazie in anticipo!