Domanda:
Invio di password a qualcuno da remoto
user36976
2014-05-22 17:06:50 UTC
view on stackexchange narkive permalink

Essendo una persona che di solito lavora con persone in altri paesi, è sempre stato un problema inviare reciprocamente le informazioni di accesso.

Per i dettagli di accesso allo sviluppo come database di debug ecc.Sicuramente posso inviarli tramite e-mail di testo in chiaro o qualcosa del genere, ma quando si tratta di informazioni di produzione effettive come le chiavi SSH come puoi inviarle in modo sicuro a qualcuno di fronte a il contatto con il viso non è possibile.

Hai pensato di utilizzare GPG?
Puoi usare LastPass per condividere le password in modo sicuro con gli altri
Ho riscontrato questo problema esatto e ho deciso di creare una crittografia RSA una tantum utilizzando Javascript. Le domande frequenti spiegano perché è sicuro (ad es. La tua password non viene mai inviata al server) Puoi provarla qui: http://tanin.nanakorn.com/labs/secureMessage
Dodici risposte:
#1
+45
paj28
2014-05-22 18:50:36 UTC
view on stackexchange narkive permalink

Di solito utilizzo gli SMS. Sebbene non sia perfettamente sicuro, è più sicuro dell'email e generalmente adeguato. Ha il vantaggio principale di non richiedere alcuna configurazione, come lo scambio di chiavi PGP.

Puoi renderlo più sicuro inviando metà della password tramite e-mail e metà tramite SMS. In alternativa (come suggerito da Michael Kropat) inviare un file con la password crittografata simmetricamente tramite e-mail e inviare tramite SMS la password di decrittografia.

Per le chiavi SSH, è necessario trasferire solo la chiave pubblica. Se concedi a un utente l'accesso a un server, dovrebbe inviarti la sua chiave pubblica, invece di inviargli una chiave privata. Devi ancora confermare che la chiave ricevuta è autentica, ma non devi mantenerla riservata.

+1 per questo. Uso anche gli sms per la trasmissione "sicura" della password, mentre invio altre informazioni tramite altri canali - e-mail o IRC. Qualcuno che intercetta il messaggio da solo non avrebbe abbastanza informazioni per scoprire a cosa serve una password. Questa è una sicurezza valida solo se la password è una tessera monouso e l'utente è costretto a cambiarla all'accesso, però.
Non vorrei solo dividere la password. Crittografa il testo della password con qualcosa di semplice come `openssl aes-256-cbc -out FILE`, invia loro il file crittografato via e-mail, quindi invia la password di decrittografia tramite SMS.
@MichaelKropat Bella idea; Ho modificato la risposta per includerla. Come per tutto, c'è un compromesso tra sicurezza e convenienza.
Gli SMS sono ancora migliori quando usi qualcosa come [TextSecure] (https://whispersystems.org/).
@GregHewgill - meglio ... forse, se TextSecure è effettivamente sicuro come afferma il suo sito web, ma questo ha il costo di richiedere al destinatario di avere quell'app installata.
Che ne dici di inviare la password tramite una normale telefonata? Se questo non è abbastanza buono, che ne dici di usare qualcosa come [Cellcrypt] (http://www.cellcrypt.com/)?
Se entrambi avete un iPhone, potete utilizzare gli SMS in modo sicuro con la crittografia end-to-end di iMessage.
Perché gli SMS dovrebbero essere più sicuri dell'email?
@Bergi - buona domanda, e forse degna di una domanda a sé stante. Tradizionalmente perché gli SMS avevano la crittografia del trasporto e operatori affidabili. Oggigiorno la posta elettronica tende ad avere anche queste proprietà, quindi la differenza è leggermente inferiore. In questo caso. il vantaggio principale è che gli SMS sono un canale separato, consentendo trucchi come dividere la password in due.
@paj28: Canali separati, sì; ma gli operatori affidabili vorrei mettere in discussione :-) Non dimenticare [Dishfire] (https://en.wikipedia.org/wiki/Dishfire) e Co.
@Bergi - se vuoi sconfiggere la sorveglianza della NSA, allora sì, avrai bisogno di più sicurezza di un semplice SMS!
+1 per la richiesta di una chiave pubblica SSH.Ottenere una chiave pubblica ha l'ulteriore vantaggio di poter condividere file contenenti dati segreti sul server.Assicurati solo di limitare l'accesso ai file su quel server in modo appropriato.
So che questo è vecchio, ma avevo l'impressione che le compagnie telefoniche registrassero tutti gli SMS, insieme alla NSA.
@jbo5112 - Corretto.Questo metodo non sarebbe adatto se si desidera impedire alla NSA di spiarti.Sfortunatamente, qualsiasi meccanismo più sicuro è anche molto più difficile da usare e per i dati commerciali tipici non vale la pena.
#2
+25
user47079
2014-05-22 19:11:31 UTC
view on stackexchange narkive permalink

Quando devo inviare qualcosa una sola volta, ho utilizzato One Time Secret. È un'app Web open source che ti consente di inserire informazioni che possono essere visualizzate solo una volta. Dopo che il destinatario ha aperto la pagina, le informazioni vengono eliminate e l'unica cosa rimasta nei registri della chat o nella posta elettronica è un collegamento non valido.

Non è solido come l'intero team che utilizza PGP, ma è molto più facile da configurare o spiegare. Sono stato in grado di usarlo per inviare informazioni di accesso a persone abbastanza non tecniche e lo trovano facile da usare.

Questa è un'ottima soluzione se non ti dispiace che qualcun altro ottenga la password.
@IstvanChung In teoria potresti non attivare una chiave / password prima che l'altra estremità segnali di aver letto / salvato con successo la chiave / password che era dietro il collegamento.
@IstvanChung Nessuno indovinerà un collegamento come https://onetimesecret.com/secret/oar70yed5i53vhwzaf8la64x1e1j3ye e anche se il destinatario non ha accesso al primo tentativo di visualizzarlo, allora sai che è stato compromesso e puoi reimpostare la password e provare ancora. Consente inoltre di proteggere con password le informazioni.
@Sumurai8 Ma perché preoccuparsi di un tale schema, quando esistono modi effettivamente sicuri per inviare informazioni?
@Keavon re: "Nessuno indovinerà un collegamento come ..." Non sono disposto a fidarmi della sicurezza di questo - tra le altre cose, questo significa che devo fidarmi dell'amministratore del server. ri: "Ti consente anche di proteggere con password le informazioni." Bene, se ho un mezzo sicuro per trasmettere la password con cui proteggo le informazioni, allora qual è il punto in primo luogo?
@IstvanChung puoi anche ospitare tu stesso un'istanza di questo servizio poiché hanno pubblicato la fonte.
Eseguo OTS in un ambiente aziendale. È ottimo. L'abbiamo reskinned e bloccato su una VM minima.
#3
+24
Fleche
2014-05-22 17:38:04 UTC
view on stackexchange narkive permalink

Come è stato già detto nel commento, questo è un classico caso d'uso per GPG / PGP. Tutti creano una chiave, le scambiate in modo arbitrario e poi verificate le impronte digitali per telefono, una chat video o qualsiasi altro canale con una ragionevole protezione contro la manomissione dei dati.

Potete anche firmarvi a vicenda 'chiavi per creare una piccola rete di fiducia. Ad esempio, se hai già verificato e firmato le chiavi dello sviluppatore A e dello sviluppatore B, A e B possono fidarsi l'uno dell'altro senza dover verificare nuovamente le chiavi.

Non è facile da usare poiché alcune delle persone con cui lavoro usano servizi come hotmail che non hanno la funzionalità GPG / PGP incorporata e devi usare un client di posta per farlo. Inoltre, alcune delle persone con cui lavoro non sono così esperti di tecnologia per sapere come utilizzare GPG / PGP (anche se è una buona soluzione per gli sviluppatori).
Usa il termine "chiave asimmetrica" ​​invece di GPG / PGP. Una connessione p2p SSH o una chat criptata o simili farebbero il lavoro
Non è solo una forma qualsiasi di crittografia asimmetrica. Come affermato sopra, una delle caratteristiche di GPG è che gli utenti possono firmare le chiavi e creare una rete di fiducia. Questo sicuramente aiuta nelle situazioni di squadra. Lo sviluppatore leader può verificare e firmare tutte le chiavi una volta, quindi tutti possono comunicare con tutti senza dover prima verificare personalmente le chiavi. Questo non è vero per tutti i protocolli.
@Nick Non è necessario avere GPG / PGP integrato nel tuo client di posta. Puoi eseguire la crittografia e la decrittografia utilizzando uno strumento autonomo, quindi inviare semplicemente il testo armato ASCII tramite posta.
@IstvanChung Lo so, ma per qualcuno che non sa nemmeno cosa sia PGP / GPG ... in nessun modo saranno in grado di capirlo.
Ho addestrato i clienti a utilizzare PGP / GPG; chiunque sia competente (abbastanza da potersi fidare di una password, a qualsiasi cosa) lo raccoglie abbastanza facilmente. Ma la parte che fa inciampare la maggior parte delle persone è che dimenticano la loro passphrase. Poi devo spiegare che non c'è modo di riaverlo e devono ricominciare da capo.
#4
+10
Simon Richter
2014-05-22 20:20:03 UTC
view on stackexchange narkive permalink

Per le chiavi SSH, faccio in modo che generino la chiave e mi inviino la chiave pubblica, quindi possiamo semplicemente confrontare le impronte digitali al telefono.

#5
+9
munkeyoto
2014-05-22 17:17:23 UTC
view on stackexchange narkive permalink

È possibile utilizzare il metodo lento di spedire loro (per posta) le chiavi su una chiave USB ma che nell'era odierna non è pratico. Quello che faccio in situazioni come questa è che ho un server web dedicato alle operazioni NOC che uso per memorizzare le chiavi in ​​una directory che creerò per chiunque abbia bisogno di inviare le chiavi. Blocca il server web con le regole mod_security e .htaccess per consentire SOLO all'individuo che desidero di vedere quella directory (tramite IP).

La mia struttura è qualcosa di simile alla seguente. Supponiamo di dover creare una chiave per diciamo un gruppo dev in Cina, creerò una directory basata sul checksum del loro nome / gruppo, ecc:

  [myoto @ mymachine ~] # mkdir `md5 -s devchina | awk '{print $ 4}' `[myoto @ mymachine ~] # cd` md5 -s devchina | awk '{print $ 4}' `[myoto @ mymachine ~ / 4b4dda9422c2de29f9a0364f1bd8494d] # cp / path / to / ssh_keys / what_I_want_2_copy.  

Questo assicura che nessuno possa imbattersi in una directory usando qualcosa di simile Nikto / Wikto, ecc. Le regole .htaccess e mod_security mi consentono di controllare chi accede a quella directory e posso ripulirlo dopo aver visto tramite i log, le chiavi sono state copiate.

Soprattutto se è solo per uso temporaneo, perché usare un hash? Basta creare un GUID (`mkdir -v $ (uuidgen)`), o prendere il numero di nanosecondi dal secondo in questo momento arbitrario (`mkdir -v $ (date +% N)`). Entrambe saranno piuttosto difficili da "inciampare" nel breve lasso di tempo in cui esistono se lo ripulisci in seguito.
@MichaelKjörling hai ragione, ma non scala bene se hai molte di queste cartelle in sospeso
#6
+8
Samuel Edwin Ward
2014-05-22 22:53:21 UTC
view on stackexchange narkive permalink

Probabilmente non è necessario inviare chiavi segrete ssh in giro.

L'individuo remoto dovrebbe generare una coppia di chiavi alla sua estremità, mantenere la chiave segreta e inviarti la chiave pubblica.

La chiave pubblica non è un segreto, quindi non è un problema inviarla in chiaro. Solo la chiave privata è segreta e non è necessario trasmetterla perché la possiedono già.

Quindi aggiungi la loro chiave pubblica all'elenco delle chiavi autorizzate.

l'unico problema che potresti avere è determinare che la chiave pubblica che hai ricevuto proviene davvero dalla persona a cui vuoi dare accesso.

Se hai altre informazioni segrete che devi condividere, beh, ora entrambi avere un accesso sicuro al server condiviso in modo da poterlo utilizzare.

#7
+6
Josh
2014-05-22 22:13:58 UTC
view on stackexchange narkive permalink

Se entrambi configurate un account con LastPass, questo servizio vi consente di condividere le vostre password (e altre informazioni protette) con altre parti.

Sì, se ti piace dare a chiunque gestisca LastPass tutte le tue informazioni.Il software di terze parti per questo non è una buona soluzione a meno che non ti fidi e conosci la persona che gestisce il sito Web, e anche in questo caso il database potrebbe essere violato
#8
+4
AJ Henderson
2014-05-22 18:37:09 UTC
view on stackexchange narkive permalink

Se ognuno di loro può configurare un account con un sito di condivisione file sicuro, puoi condividere i file con ciascuno di loro. Se vuoi farlo da solo, puoi configurare qualcosa come OwnCloud con crittografia abilitata e utilizzarlo come mezzo per lo scambio di file sicuro con più persone purché utilizzi SSL per l'istanza OwnCloud e puoi fare una distribuzione sicura delle credenziali fuori banda .

#9
+4
peterh - Reinstate Monica
2014-05-23 14:52:40 UTC
view on stackexchange narkive permalink

Il problema principale è che stiamo inviando le password normalmente a utenti semplici, che hanno problemi ad aprire una mail firmata con gpg.

Qual è il problema reale peggiorato da quel nostro lavoro / stipendio / progetto dipende dal loro giudizio, da quanto sono felici di collaborare con noi. Inoltre, la nostra prima priorità è rendere questa password il più semplice possibile per loro. Mi dispiace dirlo, ma in realtà è più importante ridurre la possibilità di un breakin dallo 0,1% allo 0,01% nel prossimo mese.

Normalmente faccio quanto segue:

  • Invio tutto (nome utente, informazioni di accesso aggiuntive) in una semplice e-mail non crittografata, tranne la password effettiva
  • Mi riferisco alla password effettiva come " Ti ho inviato questo SMS "
  • E mando un SMS contemporaneamente alla posta, solo con la semplice password, senza alcun commento.
#10
+3
Echsecutor
2014-05-23 14:14:11 UTC
view on stackexchange narkive permalink

Con PGP / GPG (e la maggior parte delle altre risposte suggerite) devi risolvere il problema di autenticazione per prevenire attacchi man in the middle. Gli SMS non dovrebbero essere considerati salvati, poiché la crittografia GSM è stata a lungo violata.

Userei OTR (non posso pubblicare più link, solo google).

Con alcuni client di chat, come pidgin. Puoi anche utilizzare alcuni canali non sicuri, come Facebook, chat di Google, ICQ, cosa mai, stabilire una connessione crittografata, autenticarti tramite build in SMP e quindi scambiare informazioni riservate.

Come si stabiliscono le chiavi OTR come affidabili?
@Michael: Come scritto sopra e spiegato in dettaglio nelle specifiche collegate, OTR supporta SMP (Socialist Millionaires 'Protocol) per l'autenticazione che è sicura per l'uomo. (Supponendo che tu e il tuo partner di comunicazione vi conosciate abbastanza bene da aver accidentalmente creato un `` segreto condiviso '', ovvero qualsiasi fatto mutualmente noto ma privato.) Vedere ad es. https://en.wikipedia.org/wiki/Socialist_millionaire
#11
+2
Matthew Peters
2014-05-22 19:02:47 UTC
view on stackexchange narkive permalink

Vorrei utilizzare una sorta di portale online sicuro da cui gli utenti remoti possono accedere / scaricare le informazioni sensibili. Per dare loro l'accesso al portale, consiglio l'autenticazione a due fattori con una password temporanea (sicura) che deve essere modificata quando la si utilizza una volta (ma l'autenticazione a due fattori garantisce che anche se l'e-mail con il passaggio temporaneo è compromessa, c'è è ancora un pin sms).

#12
+2
Anti-weakpasswords
2016-02-21 09:04:22 UTC
view on stackexchange narkive permalink

Innanzitutto, spero che tu abbia impostato le tue credenziali in modo che l'utente DEVE cambiarle durante il primo accesso, in modo che chi le ha impostate non possa più conoscerle.

Se un ufficio remoto ha un amministratore fidato, invia a quell'amministratore un set crittografato di chiavi / password monouso da condividere con altri utenti, quindi puoi semplicemente chiedere loro di utilizzare la password # 12 per il loro accesso iniziale.

A seconda del modello di minaccia (sei preoccupato per gli attori a livello di stato-nazione, cioè stai lavorando con un ufficio estero nel Paese 4, che potrebbe svolgere attività di spionaggio commerciale per conto dei tuoi concorrenti locali), questo è in realtà un caso classico in cui chiamare qualcuno in un la rete fissa è un'ottima soluzione.

Basta chiamare qualcuno su una linea fissa e comunicargli le credenziali di accesso iniziali per telefono funziona molto bene.

Oltre a ciò, GPG è sempre un modo classico di facendo questo, come molte persone hanno risposto. Ho esempi di utilizzo della chiave pubblica e di utilizzo simmetrico più sicuro rispetto a quello predefinito in questa risposta su Superuser.com.

A seconda dei requisiti normativi, OTR è un metodo per crittografare le comunicazioni, in particolare IM (vedere Pidgin come esempio) che consente anche l'autenticazione "segreto condiviso"; potresti condividere una password facile da digitare sul telefono mentre sei su IM per convalidare la sessione di messaggistica istantanea non ha un uomo nel mezzo, o utilizzare alcuni aspetti del lavoro che stanno facendo che sarebbe difficile per qualcun altro mantenere di.

Se disponi già di un modo per inviare email a cui ti fidi solo del destinatario e a cui possono accedere gli amministratori della tua rete / posta elettronica e puoi fidarti di alcuni altri prodotti / società, allora potresti utilizzare un " servizio di posta elettronica sicuro come Cisco Registered Envelope Service o un altro.

In particolare per chiavi SSH o password estremamente lunghe e difficili, puoi combinarle; è possibile crittografare, magari utilizzando la modalità simmetrica GPG (vedere il collegamento sopra), utilizzando una password sicura, quindi fornire quella password tramite il telefono o un altro metodo, in modo che possano decrittografare l'effettivo token di autenticazione / chiave SSH / certificato / ecc.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...