Ho cercato argomenti correlati, ma ho trovato altri esistenti answers non essere soddisfacenti, perché richiedono l'installazione di strumenti speciali.
Questo è un caso d'uso molto comune. Ad esempio, voglio condividere credenziali di accesso sensibili con altri membri del mio team in modo da poter amministrare i server.
Il testo normale deve essere crittografato e quindi sia la password che il testo cifrato devono essere trasferiti alla parte amichevole tramite il canale non sicuro che è Internet.
Il fermo? Non voglio dover guidare il mio collega (o faticare con me stesso a dover passare) a installare PGP o generare una coppia di chiavi RSA 2048bit e ospitare un server SFTP o qualcosa del genere.
Ciò significa che l'unica opzione rimasta è il browser web.
Ecco la mia soluzione finora. Considera onetimesecret.com come servizio generalizzato accessibile dal Web che fa effettivamente ciò che promette di fare. La mia domanda è, può essere ulteriormente migliorata?
- Alice esegue
cat /dev/urandom | base64, acquisisce parte del flusso, abbastanza a lungo da essere una buona password e non troppo lunga per il passaggio successivo - Alice invia questa stringa a Bob tramite link
- Alice attende Bob per segnalare che la stringa è stata recuperata con successo. Se ci fidiamo di
onetimesecret.com, ciò significa che solo Alice e Bob sono in possesso della stringa. Se Bob segnala che il collegamento è morto e ha avuto accesso, Alice getta via e genera una nuova password. - Alice crittografa in chiaro con la password che Bob ha ricevuto con successo. Ad esempio, crittografia AES utilizzando un archivio 7z o RAR.
- Alice invia a Bob un altro link link con i contenuti. C'è un po 'di difetto qui, che è che il servizio
onetimesecret.comeffettivo non sembra supportare gli allegati di file. Una soluzione alternativa potrebbe essere quella di Base64: codificare il carico utile crittografato e inviarlo. Oppure, meno desiderabilmente, Alice può semplicemente inviarlo tramite e-mail: in questo caso, un avversario può ottenere una copia del file crittografato ma dovrebbe comunque decrittografarlo. Il passaggio 1 si occupa di rendere questo sufficientemente difficile.
Il collegamento più debole in questo è probabilmente il passaggio 3. Credo che la terminologia corretta qui sia "Autenticazione".
Le opzioni dell'avversario sono, per quanto ne so,
- essere
onetimesecret.como avere accesso interno ad esso (noi handwave questo e dire che va bene, sono sicuro) - interrompi TLS o HTTPS. (abbiamo anche questo handwave e dire che va bene, il nostro sistema operativo è patchato, il nostro browser è patchato)
- impersona Bob finché Alice non compie il passaggio 5. (Alice chiede a Bob di restare al telefono per verificare il passaggio 3)
E potrei affermare l'ovvio qui, ma solo per chiarire, la necessità di tutti questi 5 passaggi è di aggiungere una sorta di passo "manuale" di handshake in modo indipendente, nel tentativo di prevenire la perdita di dati - questo significa che abbiamo fidarsi del% web service di onetimesecret.com per distruggere effettivamente i messaggi che gli inviamo e che promettono di essere consegnati una sola volta.
Il terzo elemento nella seconda lista è quello relativo alla parte di autenticazione della nostra stretta di mano personalizzata. L'autenticazione sicura tradizionale / standard non è possibile senza il coinvolgimento di ulteriori passaggi per generare chiavi sicure. Sto cercando di ottimizzare le cose al punto in cui diventano pratiche. Il che significa non richiedere agli utenti di generare chiavi.