Recupero della password decentralizzato

7

Esistono tecniche valide / consolidate per il recupero di password / chiave in situazioni senza un servizio centralizzato?

(Tutto va, ma preferirei soluzioni che distribuiscano le informazioni di recupero su più punti)

Ad esempio: posso immaginare un sistema in cui viene generata una chiave di ripristino, divisa usando condivisione segreta e distribuita ad esempio

  • alcune parti scaricate sul computer locale
  • alcune parti inviate via email a te stesso
  • alcune parti stampate e collocate in una cassetta di sicurezza
  • alcune parti fornite agli amici per salvaguardare

Questo è un escamione chiave essenzialmente distribuito: ci sono alcuni esempi di sistemi esistenti che usano uno schema come questo? Esistono schemi alternativi? Ci sono le migliori pratiche?

Chiarimento : Personalmente, mi fido a ricordare una password relativamente strong: questo sta progettando un sistema che altre persone potrebbero usare, e non tutti potrebbero essere sicuri di farlo.

    
posta cloudfeet 01.10.2014 - 17:56
fonte

4 risposte

2

Ho scritto alcuni commenti sotto la tua domanda iniziale, ma credo che combinando i miei commenti (che descrivono una soluzione) con tutte le risposte menzionate finora possa produrre qualcosa che puoi effettivamente usare (rispetto alla ricerca da solo).

Come menzionato nei commenti, la tecnologia split-key è il processo per creare X-number di sotto-chiavi. Lo stile di implementazione più comune è quello di richiedere TUTTE le sottochiavi X per ripristinare una chiave protetta.

Nell'esempio che discuto di seguito definirò le seguenti parole per garantire chiarezza:

chiave : una cripto-variabile statica (ovvero condivisa / simmetrica) o generata in base a una password o una passphrase.

password : un valore non crittografato o non crittografato che un essere umano normalmente memorizza (o, vergognosamente, scrive su un appiccicoso tenuto sotto la tastiera).

passphrase : per gli scopi di questo esempio, una passphrase è identica a una password.

sottochiave : una singola porzione di informazioni di ripristino di dimensioni uguali alla chiave protetta.

split-key : il concetto di rompere una chiave di ripristino in varie parti (aka, sub-key o chunks ).

caratteri del dizionario : il set di caratteri che un utente può immettere in un meccanismo di recupero (ad esempio, A-Za-z0-9).

Ora che abbiamo risolto il problema possiamo esaminare un metodo per implementare questa soluzione.

Assume that my password (as defined above) is IKnowThisIsBad.

I pass the password to the OpenSSL Linux bash command sha512sum and it outputs the hashed value: d3a48c640bbd58633138e2f88b2d3979e3d609df6cd22246dd73d35a77b6755fcf580be431a93c059bc7106ab8d37491d442339879947728d8da436a9c2c60c0

I use that hashed value (note: it is NOT salted at this point, I'm trying to keep it simple...) as my key. This is the key that we are going to protect and I use this key for all my relevant cryptographic purposes.

Let us assume we'll protect the recovery process by using 3 sub-keys (any number of sub-keys greater than 1 is valid, however).

We assume here that a user cannot remember such a sequence and thus cannot (in their head) store a sub-key. Nonetheless, to successfully (and properly) use split-key technology they must provide a chunk of appropriate length. We'll use our friend sha512sum again. In this example let us pretend that the user's passphrase for deriving their recovery chunk is My Secret Recovery Phrase. The output for that iteration produces: 196822a43878ff1c263fe16b6cb2d768b157cf1018ded64e6bab4d36822262ff7f61404ab21c2d279c6cfaa85112786044231917c484dcf3a81931d34fa86edd

Now we need a chunk that will be stored somewhere else. Using your example we'll say it's stored as text to an email. Back we go to our friend sha512sum to generate this sub-key value. We'll use the passphrase: Email Is Not Very Safe To Store Key Info!!, which yields the following value: a8a73e1c6ecd3f2ddff853901f3781fac5839d42cf360833e7148163beb2c05ad5288e6d3c30fd9e7a4bb854b7f507c70991f6c04c507c58028573b5f89ce6a7

At this point we have 2 out of the three recovery chunks or sub-keys generated. Regardless of how many sub-keys you make, the last one is treated special. If we had 10 sub-keys, then we could create the first 9 following the previous examples. If we had 30 then the first 29 could be created that way. But in any case, one value is generated special. To create the last recovery sub-key we must XOR all the know values up to this point together.

Let's look into this more closely.

The main reason we use XOR in cryptography is that it is recoverable (unlike OR and AND operations). When we XOR the previous three values (i.e., the key, the user recovery sub-key generated from the recovery passphrase, and the stored-in-email sub-key) we generate a 3rd sub-key that is automatically the same length as the other 3 inputs. This 3rd chunk can be assigned to your "download to local computer" recovery option. The result of this XOR operation (which can be thought of as: key ^ sub-key1 ^ sub-key2 -OR- key XOR sub-key1 XOR sub-key2) is: 426;94fc5?68'854eaff50ij?gcao?g'd7i2j;add=3af<3'71gehf0dm'26b7fa0511<7g1b'cjgc;g7'a65ibm5>340;l6'9?0d<k?'n40d7a352mm010gk=j8ecfc

I apologize for the weird formatting of that last output. It is necessary because the resultant sub-key value contained backtick (') characters that had to be specially escaped.

At this point we save that final value somewhere as specified by the "download to local computer" policy.

Grande. Quindi questo è un insieme di valori hash, ma come si ottiene la chiave in caso di perdita da qualsiasi sistema sottostante che lo utilizza? Ripristiniamo tutti i valori sub-key e li associamo a XOR. Questo riprodurrà il valore chiave originale

Per provare questo è il caso che ho scritto un piccolo blob Python che implementa questa operazione XOR per numeri arbitrari di stringhe XOR. Trovalo qui sotto.

#!/usr/bin/env python

#KEY:    d3a48c640bbd58633138e2f88b2d3979e3d609df6cd22246dd73d35a77b6755fcf580be431a93c059bc7106ab8d37491d442339879947728d8da436a9c2c60c0
#RECOV1: 196822a43878ff1c263fe16b6cb2d768b157cf1018ded64e6bab4d36822262ff7f61404ab21c2d279c6cfaa85112786044231917c484dcf3a81931d34fa86edd
#RECOV2: a8a73e1c6ecd3f2ddff853901f3781fac5839d42cf360833e7148163beb2c05ad5288e6d3c30fd9e7a4bb854b7f507c70991f6c04c507c58028573b5f89ce6a7

#    RECOV3 is generated by running this script with the above 3 command-line values generated by 'sha512sum'
#RECOV3: 426;94fc5?68'854eaff50ij?gcao?g'd7i2j;add=3af<3'71gehf0dm'26b7fa0511<7g1b'cjgc;g7'a65ibm5>340;l6'9?0d<k?'n40d7a352mm010gk=j8ecfc

#    Recovery of KEY is accomplished by running this script with RECOV1 RECOV2 and RECOV3 as parameters.

import sys, binascii, argparse;

parser      = None;
stringlist  = None;


def xor_strings(base, new):
    return "".join(chr(ord(b)^ord(n)) for b, n in zip(base, new));


def SetParseArgs():
    global parser, stringlist;

    parser = argparse.ArgumentParser(description="XOR a bunch of strings!");
    parser.add_argument("string", nargs="+");
    stringlist = parser.parse_args().string;


def main():
    global sys, stringlist;

    SetParseArgs();

    res = stringlist[0];
    for index in range(len(stringlist) - 1):
        #skip string #1
        hexstr = stringlist[index + 1];
        res = xor_strings(res, hexstr);

    print "XOR result string:\n%s" %(res);


if __name__ == "__main__":
    main();
else:
    print "This script cannot be imported";
    print "Please run as: %s <string_1> <string_2> [string_n]" %(sys.argv[0]);
    print "For best (and most logically-correct) results, ensure strings are the same length";

Questo script può essere utilizzato per creare i blocchi di ripristino, distribuirli come desideri, quindi utilizzare lo script con ALL dei chunk e recupererai il tuo tasto originale

Questo esempio dovrebbe chiarire in che modo il recupero di qualcosa di meno di ALL dei chunk è altrettanto inutile di non averne nessuno perché un utente malintenzionato dovrebbe ancora eseguire la bruta- forza ogni combinazione possibile nell'intero tasto spazio indirizzo

Spero che alcuni di voi lo trovino utile. Mi è piaciuto l'esercizio nel metterlo insieme e in realtà potrei usarlo io stesso ora che l'implementazione è a posto! : -)

Si prega di commentare qualsiasi errore di battitura che si osserva. Ho utilizzato valori letterali per tutti gli esempi sopra riportati, pertanto chiunque esegua i comandi / gli strumenti sopra descritti produrrà risultati identici. Ho scritto tutte le stringhe pre-sha512sum su singoli file di testo SENZA una nuova riga alla fine e le ho fornite come parametri per sha512sum per creare la chiave , sottochiave 1 e sottochiave 2.

Grazie e buon divertimento!

    
risposta data 22.12.2014 - 23:30
fonte
0

Non sono sicuro di aver capito correttamente ma ho visto sistemi che generano un token casuale sul client che viene poi inserito su un server remoto che convalida l'autenticità del token e genera a sua volta un secondo token, questo secondo il token viene immesso nuovamente sul client (o ovunque siano presenti le informazioni che si desidera ripristinare) che ora consente una reimpostazione della password se è valida.

Forse potrebbe aiutarti.

    
risposta data 05.12.2014 - 02:26
fonte
0

Penso che un gestore di password sia onestamente la soluzione migliore qui se è solo tu chi ha il controllo di queste password. È possibile memorizzare le password in un file di database delle password crittografato. Questo file può essere archiviato nel cloud, su una USB fornita a un amico e sul tuo computer locale / di lavoro.

Tutto ciò che devi mantenere o avere è una passphrase strong per il database e tenerlo per te e puoi avere più opzioni di recupero. Questo è altrettanto difficile, se non più difficile, da decifrare senza la conoscenza della chiave.

La suddivisione dei dettagli di recupero è inutilmente complicata se tutto ciò che si desidera è archiviare le password in modo sicuro e disporre di un percorso di backup per loro sicuro.

Condivisione segreta è utile quando è necessario che più parti si uniscano per accedere ai materiali sensibili. Un modo molto semplice e meno sicuro di fare questo sarebbe avere te e un amico memorizzare una password ciascuno. Quindi usi il tuo come primo componente della password completa e lei usa il suo come secondo. In questo modo, entrambi i componenti della chiave sono decentralizzati, ma possono riunirsi per accedere a qualcosa.

Generazione della passphrase Esistono modi davvero creativi e interessanti per ricordare facilmente passphrase super-sicuri, piuttosto che investire in qualche metodo decentralizzato che rischia di compromettere la sicurezza della loro password, dovrebbero passare 2-3 minuti per ottenere una password memorabile e sicura che possono usare in modo coerente con un gestore di password.

Alcuni metodi includono: Il metodo XKCD . Utilizzo di più parole in sequenza non correlate per creare la password. Penso che questo metodo abbia bisogno di un po 'più di confusione rispetto alle parole semplici perché se questo diventa il metodo più comune di quello che si può ricavare facilmente da un algoritmo di password cracking usando parole comunemente usate che lo rendono meno sorprendente.

Il metodo Passphrase / Password manager . Dove usi frasi memorabili per aiutarti a ricordare la tua password derivata. Questo può essere un buon metodo per password lunghe e forti.

Oppure, ottimo, un metodo che hai sviluppato che non è già stato menzionato e che crea una frase d'accesso strong, lunga, facile da ricordare / difficile da indovinare.

Ma sto ancora per dire che il recupero della password / chiave, ad es. mettere le tue password / chiavi in testo semplice da qualche altra parte per chiunque lo trovi è una cattiva idea. Amplia la tua rete di fiducia e riduce la tua sicurezza generale. Finché qualcuno non troverà un modo per irrompere nelle nostre menti, suggerirò che le nostre teste sono il posto più sicuro per qualsiasi chiave e lo saranno sempre.

Se hai qualche file crittografato super importante che vuoi trasmettere alla famiglia quando muori o qualcosa del genere. Dare loro la chiave su un usb e passare il file a un avvocato su un USB. Situazioni come questa sono tutte cose a cui posso davvero pensare quando questo potrebbe essere necessario. Anche così, ci sono alcune altre opzioni.

Spero che questo aiuti!

    
risposta data 05.12.2014 - 01:53
fonte
0

Le password e i tasti sono due elementi distinti. Ad esempio, quando assumiamo nuovi dipendenti e abbiamo bisogno di accedere a sistemi basati su Unix, distribuiamo le chiavi ssh per loro in modo che non ci sia alcuna password. Se / quando se ne vanno, revochiamo le chiavi. La necessità di gestire qualsiasi password che avrebbero è un punto controverso dal momento che potremmo reimpostare la password.

Dividere una password è uno spreco di larghezza di banda, considerando che esistono metodi più sicuri per fornire una nuova password: via telefono, via SMS, fax.

Esistono sistemi di gestione delle password open source per l'azienda come Team Pass che fanno un buon lavoro, ma devi ricordare, lo scopo di consentire a qualcuno di creare una password è per loro e solo loro di autenticare, non per un amministratore di avere un utente rivelare la propria password. La maggior parte se non tutti i sistemi operativi consentono password rigorose. Diventa una questione di educare gli utenti su come creare password complesse, altrimenti gli utenti fanno cose come postarlo su post-it pad, ecc.

Ora, nel separare una "chiave" e una password, Strongkey è un sistema di gestione delle chiavi aziendali. Immagina un'azienda in cui tutti hanno bisogno di creare una chiave GPG / PGP. Gestire quelli sarebbe un incubo quando le persone probabilmente dimenticheranno le loro passphrase, un utente viene licenziato / lascia, e ora nessuno può decifrare i suoi file. Il termine chiave e password non sono gli stessi anche se usati in modo intercambiabile.

    
risposta data 09.12.2014 - 18:17
fonte

Leggi altre domande sui tag