Best practice per la distribuzione delle password

17

Sto per creare un nuovo account sul mio server Linux per un utente che vive in un altro stato negli Stati Uniti.

Non riesco a pensare a un buon modo per ottenere da questo utente la loro password. Ci deve essere un meccanismo standard per questo, giusto?

    
posta mlissner 24.03.2012 - 06:12
fonte

11 risposte

8

La distribuzione delle chiavi è un argomento su cui è abbastanza un sacco di articoli sono stati scritti e probabilmente lo faranno. Fondamentalmente, è necessario un qualche tipo di canale sicuro per ottenere l'invio della chiave, ma quel canale sicuro non è ancora lì, motivo per cui la chiave è necessaria in primo luogo.

Il potente aggressore

Per questa risposta, inizia con l'immaginare un attaccante molto potente, ad es. un attaccante Dolev-Yao che può ascoltare, intercettare e sintetizzare qualsiasi messaggio sulla rete. Ovviamente, questi aggressori hanno molto più potere di quanto comunemente ragionevole, ma è anche il punto di partenza nella ricerca di sicurezza comune. In seguito abbasseremo il barier.

Dato il nostro potentissimo attacker, abbiamo effettivamente bisogno di un trust bootstrap. Ad esempio, se si dispone di una sorta di schema di crittografia e-mail in atto, che potrebbe essere utilizzato. Pensa a PGP o S / MIME. Ciò lascia ancora un problema di fiducia, ma nel primo caso può essere delegato a una decisione informata in base alla loro rete di fiducia o nel secondo caso alla decisione dell'autorità di certificazione (probabilmente solo in base al controllo dell'e-mail). In altre parole, la fiducia è contenuta in una delle strutture esistenti e possiamo basare la nostra decisione su ipotesi su quelle che sono normalmente considerate terze parti fidate.

Se intendi utilizzare la crittografia a chiave pubblica, ad es. Chiavi SSH. Si accende il problema. Ora, non è necessaria la riservatezza della chiave, ma l'utente deve essere in grado di mantenere l'integrità quando si invia la chiave pubblica. Nell'esempio di crittografia della posta elettronica, è necessario assicurarsi che il messaggio con la chiave pubblica da utilizzare per il server sia firmato dal dipendente (anziché crittografato correttamente per lui e solo da lui letto).

Pertanto, quando la riservatezza è il tuo problema, crittografati utilizzando un trust bootstrap, come fornito da strumenti di crittografia e-mail (o simili), e quando l'integrità è la tua causa, lascia che i tuoi dipendenti firmi utilizzando la fiducia bootstrap.

L'autore dell'attacco potente su un solo canale

Più realisticamente, l'attaccante ha potere solo su uno o più canali non sicuri. In altre parole, si presuppone l'esistenza di un canale protetto sul lato del canale principale. Questo canale può essere utilizzato per inviare informazioni aggiuntive necessarie per comprendere il messaggio principale o per verificare il messaggio principale. Ad esempio, si cripta la password con un'altra password e la si invia tramite e-mail. Sul lato, si invia un SMS con la password necessaria per decrittografare la password. In questo modo, due canali devono essere compromessi. Si noti che questa potrebbe essere una combinazione qualsiasi (posta, telefono, SMS, e-mail, fax, ecc.) Purché siano scollegati abbastanza da essere sicuri. Quindi, uno smartphone che gestisce sia gli SMS in entrata che le e-mail non è abbastanza buono!

L'approccio a due canali potrebbe essere riprodotto in modo simile nella situazione di integrità, ad es. inviare la chiave pubblica su due canali separati. In ogni caso, è necessario verificare questi risultati l'uno contro l'altro.

Note conclusive

Esistono numerosi altri metodi, ma mi aspetto che ciò generi un onere troppo alto per non avere troppa sicurezza in più, visto che hai ancora a che fare con gli umani.

Inoltre, le cose che richiedono direttamente una modifica della password al primo accesso sarebbero aggiunte intelligenti.

Infine, noterai che queste sono tutte questioni di fiducia, che sono fondamentali per molti sistemi crittografici e altri metodi di sicurezza. Dovresti trovare il giusto equilibrio tra paranoia ed essere ingenui, ad es. il sistema di certificati usati da SSL e S / MIME non è certamente fantastico, ma è comunemente trovato abbastanza buono per l'online banking, quindi quando non si comunica ai missili nucleari, probabilmente andrà bene. Assicurati di fare anche un ragionevole controllo.

    
risposta data 27.03.2012 - 09:48
fonte
11

Parla con loro in una conversazione a due vie il più vicino possibile in tempo reale (di persona / telefono / messaggio istantaneo / conservazione della posta elettronica) e dai loro una password iniziale che deve essere ripristinata al primo accesso.

Questo in genere viene eseguito con il comando chage su linux / unix:

sudo chage -d 0 the_new_user

Verifica in seguito che hanno ottenuto il nuovo account utilizzando un metodo indipendente (ad esempio, se li hai richiamati in precedenza, invia loro un'email), quindi nel caso in cui tu sia stato socialmente ingegnerizzato in qualche modo (ad esempio, il cellulare è stato rubato o l'email è stata intercettata ) c'è stato un controllo indipendente in seguito. Inoltre, non fornire loro le autorizzazioni root o altre autorizzazioni elevate finché non le hai verificate.

EDIT: la password iniziale dovrebbe essere qualcosa di casuale; per esempio. 12 caratteri casuali generati da un computer.

EDIT2: Mitigare contro gli intercettatori è semplice se ci si può fidare delle persone ad entrambe le estremità. Se è possibile identificare con sicurezza la persona all'altra estremità di un telefono / videoconferenza / ecc, fornire loro una password iniziale valida (che devono quindi reimpostare), verificare che siano presenti e quindi elevare i privilegi. Se si tratta di un'app Web, questa password iniziale potrebbe essere un token in un collegamento inviato tramite email (che funziona una volta, scade automaticamente dopo un breve periodo). Se si tratta di un account di lavoro, è sufficiente lasciare che l'app Web invii e-mail di password da / al tuo dominio locale (che hai configurato per utilizzare SSL). Anche se un intercettatore intercettato, avrebbe dovuto battere la persona inizialmente per usarlo (e quindi l'utente legittimo avrebbe problemi che potrebbero far scappare gli intercettatori).

Il problema spinoso è quello di stabilire la fiducia che una terza parte remota dovrebbe avere accesso all'account. Questo inizia con la verifica del motivo per cui hai fornito questo account a questo utente? Sono un noto collega / conoscente che ha bisogno di accedere a qualcosa di nuovo? Oppure il tuo capo ti ha detto di darti una email dicendo di dare accesso a [email protected] al server X? Potresti essere socialmente ingegnerizzato (qualcuno che finge di essere il capo del telefono / email rubate dai boss)? Questo non è un compito semplice; tuttavia, il controllo delle istruzioni di persona o tramite videoconferenza o telefono riduce i rischi che il comando sia gestito socialmente. Garantito che il tuo capo possa essere progettato socialmente - forse la nuova persona non dovrebbe essere attendibile.

    
risposta data 24.03.2012 - 06:57
fonte
7

Potrebbe essere utile o meno, ma potresti anche considerare di consentire l'autenticazione solo tramite chiavi SSH:

link

Devi ancora verificare che la chiave pubblica che stai accettando provenga dall'utente che pensi sia (cioè, che non sei socialmente ingegnerizzato, come sottolineato sopra), ma è più sicuro posta elettronica attorno a una chiave pubblica piuttosto che una password. (Dico questo perché le chiavi pubbliche sono destinate a essere distribuite, mentre le password non lo sono. Ci sono meno danni nel lasciare una chiave pubblica seduta su un server di posta / client di posta "per sempre" rispetto a una password.)

    
risposta data 24.03.2012 - 15:41
fonte
4

Per mantenerlo pratico, prendi accordi tramite posta ordinaria o messenger. Quindi invia un messaggio di testo dal tuo cellulare (SMS) contenente solo la password. Chiedere al destinatario di confermare tramite mail o messenger. Come dice dr jimbob, e se possibile, fa scadere la password, quindi è necessario cambiarla con il primo accesso.

    
risposta data 24.03.2012 - 09:11
fonte
2

Ecco alcune soluzioni rapide e semplici che non ho ancora visto menzionate:

link

link

Modifica:

Si sta richiedendo il "metodo ufficiale corretto" per farlo e i metodi ben consolidati sono quelli di utilizzare la crittografia a chiave pubblica o una terza parte attendibile (come Kerberos) per consentire a entrambe le parti di fidarsi l'una dell'altra. Entrambi hanno equivalenti nel mondo reale come una sorta di deposito di garanzia o un notaio pubblico, ma se tecnica o non tecnica, l'implementazione spesso non è pratica.

L'unica altra alternativa è stabilire in anticipo un segreto precondiviso che entrambe le estremità possano utilizzare per autenticarsi a vicenda. È come se una spia presentasse una frase e l'altra spia la completasse correttamente in modo che entrambe le parti sappiano che l'altra parte è autentica. Dal punto di vista tecnico, ciò viene solitamente ottenuto utilizzando una funzione di derivazione della chiave con un vettore di inizializzazione precondiviso. Ovviamente questo metodo richiede la possibilità di pre-condividere in modo sicuro un segreto.

Certamente esistono metodi meno che ideali che funzionerebbero abbastanza bene per la maggior parte delle situazioni. Ad esempio, l'utilizzo di uno dei servizi come pwpush.com elencato sopra può consentire di crittografare e limitare l'esposizione del segreto. L'invio del link a un indirizzo email autentificherà l'utente. Stai praticamente facendo la stessa cosa della prima situazione ma stai utilizzando il provider di posta elettronica come autorità fiduciaria per autenticare l'utente. Ovviamente, l'email non è un metodo molto sicuro ma è solo un esempio. Esistono numerosi canali che forniscono alcune misure di autenticazione (ad esempio il possesso fisico di un telefono cellulare chiamato).

Indipendentemente dal metodo utilizzato, è sempre necessario coinvolgere una terza parte attendibile o un'informazione condivisa.

    
risposta data 30.03.2012 - 07:52
fonte
2

C'è una soluzione migliore. Non distribuire le password. Invece, distribuire le chiavi pubbliche SSH. Chiedi all'altra persona di inviarti la chiave pubblica SSH. Quindi, aggiungi la loro chiave pubblica SSH a un file ~/.ssh/authorized_keys nella home directory del loro nuovo account. Ciò consentirà loro di accedere all'account.

Puoi ragionevolmente farti mandare per e-mail la chiave pubblica SSH. La chiave pubblica non è segreta, quindi non devi preoccuparti di chi lo ruba. (Devi assicurarti di ottenere la chiave pubblica SSH appropriata dalla persona giusta, ma nella pratica ordinaria, è spesso sufficiente contattare la persona e chiedergli di inviarti tramite email la chiave pubblica SSH. Se sei paranoico o hai un installazione ad alta sicurezza, puoi chiamarli e chiedere loro di leggere l'hash della loro chiave pubblica.)

Oltre a semplificare il problema di comunicazione, questo ha anche il vantaggio di evitare password, che hanno problemi noti: tendono ad essere suscettibili alle intercettazioni, all'ingegneria sociale e all'attacco di dizionari.

    
risposta data 03.04.2012 - 10:09
fonte
1

Qui farò l'ingenuo.

Supponiamo che tu non voglia utilizzare alcun protocollo basato sullo scambio di chiavi Diffie-Hellman Ti suggerisco questa tecnica molto empirica:

crea l'account e imposta la password su randomShortString

chiama l'utente:

AMMINISTRATORE: Ciao utente A, questa è la tua password: randomShortString effettua il login adesso e poi digita "passwd" e imposta una nuova password diversa.

UTENTE A: Ciao amministratore, grazie ho effettuato l'accesso .... e sì, ora ho cambiato la mia password.

AMMINISMO : su utente A, password ... accesso fallito. "Ok, grazie utente A"

Direi che se è solo per un utente questo funzionerà ...

    
risposta data 29.03.2012 - 14:21
fonte
1

Se conosci solo la persona come una voce su un telefono in un altro stato, nessuna quantità di verifica secondaria ti fornirà alcuna garanzia aggiuntiva di tale identità. Telefonarli fornisce un circuito fuori banda, l'autenticazione tramite la voce e dare loro una password temporanea è la norma del settore.

Se spingi questa domanda abbastanza lontano, entri in un concetto molto astratto di "Identità". Che cos'è un nome? Perché ha un significato? Che valore ha il governo che ha un record che collega quel nome a quella faccia? Perché è importante per la tua interazione? Ti fidi dell'ID del governo, o ti fidi davvero della persona che hai incontrato a quella convention, indipendentemente da quello che ti dicono che il loro nome è?

    
risposta data 29.03.2012 - 14:52
fonte
0

Se questa persona è decentemente esperta di tecnologia, GPG (PGP) è un modo ideale e semplice per realizzare questo:

  1. Il tuo interlocutore creerebbe una propria chiave
  2. Ti invierebbero una copia della loro chiave pubblica
  3. Quindi crittografate un file di testo in chiaro con la password, usando quella chiave pubblica
  4. In seguito, puoi inviarlo via e-mail, inviarlo o persino pubblicarlo su un sito pubblico: i dati sono perfettamente sicuri, presupponendo che abbiano mantenuto la chiave privata al sicuro.

link

    
risposta data 28.03.2012 - 01:19
fonte
0

Infrastruttura PKI (aziendale o di terze parti), certificati S / MIME personali, scambio con chiavi pubbliche (e-mail, posta ordinaria), verifica dell'autore tramite impronte digitali (voce), crittografia S / MIME posta per il trasferimento finale dei dati.

Modo Unbreakable (in termini di tempo, ora misurabile)

    
risposta data 29.03.2012 - 07:16
fonte
0

Odio dirlo, ma se non riesci a darlo a loro per telefono basta attaccare con un vecchio apparecchio fax della scuola. Verifica che stiano aspettando la trasmissione e invialo, quindi conferma di averlo ricevuto direttamente.

    
risposta data 30.03.2012 - 01:50
fonte

Leggi altre domande sui tag