Alternativa all'invio della password tramite posta?

Kent

2019-04-03 17:04:19 UTC

view on stackexchange narkive permalink

Di solito utilizzo un gestore di password per archiviare e condividere le password. Esistono molti gestori di password che dispongono di questa funzionalità.

Una password viene condivisa da un account all'altro, con la notifica della condivisione inviata via email all'altra persona, che può scegliere di accettare, rifiutare, o semplicemente ignora la condivisione. La comunicazione della password è sicura, mentre la notifica della condivisione viaggia su canali meno sicuri come la posta elettronica, sfruttando così la forza di ogni metodo senza compromettere la sicurezza. Alcuni prodotti consentiranno la condivisione della password senza rivelare la password al destinatario. In tal caso diventa possibile revocare la password.

Consiglio vivamente di utilizzare un gestore di password per tutte le tue password. Alcuni commerciali sono LastPass, 1Password o Dashlane ma c'è anche la possibilità di ospitarne uno tu stesso se non vuoi fidarti di nessuno. Una rapida ricerca su Google di "password manager" dovrebbe metterti sulla strada giusta.

Benvenuto nel sito, Kent!L'aggiunta di contenuti a volte può essere complicata: cerchi di aiutare a utilizzare la tua esperienza, ma poi le persone si lamentano del fatto che suona come un annuncio.Grazie per aver mantenuto e aggiornato la tua risposta in base ai commenti!Spero che tu rimanga sul sito :)

Per completezza, vedo [Dashlane] (https://www.dashlane.com) ampiamente utilizzato anche per la condivisione dell'accesso con o senza divulgazione della password (con possibile revoca dell'accesso).

Sì, questa è la risposta "giusta".Nel mio datore di lavoro, utilizziamo una soluzione di gestione aziendale ospitata internamente con un front-end Web e, quando abbiamo bisogno di condividere le password, inviamo un'e-mail con un collegamento al segreto in questione.(Fondamentalmente - https: // [ourpasswordmanagentserver.ourdomain.com] /SecretView.aspx?secretid= [######])

Non puoi condividere una password senza rivelarla.Certo, puoi condividerlo senza mostrarlo, ma la persona con cui lo condividi può ancora vedere la password da qualche altra parte, sia sulla pagina che è stata riempita cambiando il campo della password in un campo di testo o sollevandola dalla reteaccede al browser una volta inviata la richiesta di accesso.Qualsiasi gestore di password che afferma il contrario non dovrebbe essere considerato attendibile.

Philipp

2019-04-03 16:13:57 UTC

view on stackexchange narkive permalink

Una pratica comune è inviare all'utente una password iniziale tramite posta elettronica che è valida solo per un tempo molto breve e deve essere modificata immediatamente durante il primo accesso.

Neanche questo è perfetto. Un utente malintenzionato con accesso in lettura alla posta elettronica dell'utente potrebbe intercettare la password iniziale prima dell'utente e utilizzarla per suo conto. L'utente se ne accorgerebbe non appena tenterà di utilizzare la password iniziale. Avrebbero notificato all'amministratore che la password è sbagliata, l'amministratore avrebbe indagato e avrebbe notato l'accesso illegittimo. Ma l'attaccante ha già avuto del tempo per accedere all'account, quindi potrebbe già esserci un danno. Ma è comunque meglio che inviare una password valida in modo permanente.

Richiede anche che il sistema lo supporti. Quindi non è una pratica universalmente applicabile.

Quando non ti fidi del tuo provider di posta elettronica per mantenere segrete le tue e-mail (stai utilizzando gmail, un servizio di posta finanziato dal data mining il contenuto della tua email e monetizzare i risultati), la crittografia delle email è un'opzione. C'è il buon vecchio PGP, il più moderno PEP, lo standard IETF S / MIME e alcune soluzioni proprietarie non standardizzate. Questo è il bello degli standard: ce ne sono così tanti tra cui scegliere! Ma hanno tutti una cosa in comune: semplicemente non prendono piede. Convinci i tuoi partner commerciali a crittografare la loro posta elettronica in uno schema che conosci può essere una noiosa battaglia in salita.

Uno "standard" a cui praticamente tutti hanno accesso è un file zip crittografato.Non la protezione più forte, ma molto meglio del testo normale.Invia la sua password su un canale diverso, testo, messaggio vocale, cognome di quell'ubriaco che conoscevamo al college.

Oppure invia una foto di un pezzo di carta di scarto con la password.Ovviamente se sei esplicitamente preso di mira, non importa, ma se sei preoccupato per il mining passivo, aggiungerà un ritardo sufficiente all'elaborazione in modo che la tua password limitata nel tempo scada prima che venga trapelata.

Potresti notare che OpenPGP è anche uno standard IETF ([RFC4880] (https://tools.ietf.org/html/rfc4880))

Potrebbe essere utile aggiungere che l'attivazione dell'autenticazione a due fattori / multifattore, quando disponibile, mitiga alcuni dei rischi dell'intercettazione di una password iniziale o reimpostata di recente.

Se il sistema può essere controllato / modificato, aggiungendo all'OTP iniziale una politica "consenti questa azione solo da IP fidati" dovrebbe migliorarlo un po '(limiti l'attacco alla tua rete locale).Ad ogni modo, totalmente d'accordo sull'uso di PGP e altri.

La crittografia della posta elettronica è una delle peggiori esperienze che puoi avere.L'intero processo sembra ancora uscito dagli anni '90 (particolarmente divertente poiché alcuni di questi standard sono più recenti).

@Voo Dipende.Nel mio lavoro abbiamo un plugin per Microsoft Outlook che crittografa le email senza che l'utente debba fare nulla.Ma ovviamente richiede che anche il ricevitore abbia installato il plugin.

@Philipp E che sia presente un'infrastruttura che garantisce che il destinatario abbia già la tua chiave.Ed è qui che inizia il divertimento.Oh, e ovviamente devi ancora essere in grado di inviare e-mail non crittografate alla maggior parte delle altre persone, quindi deve esserci una whitelist.Fin qui tutto bene, ma cosa succede se invii un'e-mail a persone che sono nell'elenco "crittografato" e ad altre che non lo sono?E così via.Non è divertente, ma sicuramente gli utenti lo notano solo se non funziona.

@Neil_UK O un KeepassDB e dai la password al db per telefono o altro mezzo.

Hai mai provato ad allegare un file .zip crittografato tramite Gmail?Non sarà accettato;IOW, * è impossibile *.Ho provato una volta, IIRC per inviare un file .exe, che neanche Gmail consentirà.

@MikeWaters A volte puoi ingannare i filtri _rimuovendo_ le estensioni dei file e poi, nel corpo dell'email, chiedendo all'utente di aggiungere nuovamente l'estensione corretta dopo aver scaricato il file, che dovresti specificare nel corpo dell'email.

Peteris

2019-04-03 16:20:28 UTC

view on stackexchange narkive permalink

Due fattori

Forse non è letteralmente appropriato per la tua situazione, ma un modo ragionevole per inviare dati sensibili su canali che non sono del tutto sicuri è assicurarsi che siano necessari due fattori separati per accedere a quei dati e che vengono inviati tramite canali diversi. Ad esempio, ho visto approcci in cui i dati vengono inviati tramite posta elettronica in un file zip crittografato e la password per tali dati viene inviata tramite SMS. In questo modo né qualcuno che ha quell'email né qualcuno che ha accesso al tuo telefono può accedere alle informazioni sensibili.

In modo simile, potrebbe essere una pratica migliore se invii le informazioni di connessione tramite email e la password può essere pronunciata al telefono (soprattutto se è come una passphrase), ma questa scelta spetta principalmente all'organizzazione che invia i dati (che è presumibilmente lo stakeholder che ha bisogno di tali dati per essere mantenuti riservati ), non a qualcuno che lo sta solo ricevendo.

Questo IMO è il modo giusto per inviare i dati per l'autenticazione: utilizza due canali separati.Tuttavia vorrei aggiungere una nota importante: sia il mittente che il destinatario dovrebbero quindi cancellare i dati il prima possibile, eliminando l'email, o l'SMS, o il messaggio whatsapp, ecc. Inoltre, penso che i messaggi whatsappsono probabilmente migliori degli SMS.Tu (e l'altra parte) devi solo ricordarti di eliminare il messaggio una volta che la password è stata memorizzata da qualche altra parte in modo sicuro.

@reed Se le chiavi ricevute tramite due canali sono una tantum e all'utente viene richiesto di immettere una password generata dall'utente immediatamente dopo averle utilizzate, non è necessario rimuovere i messaggi.

Questo è il modo in cui lo faccio di solito.E mi assicuro di non menzionare nulla sull'host o sul login nel testo contenente la password.Nota che questo è anche un buon momento per incoraggiare le persone a usare il segnale in modo che il testo stesso sia crittografato

Signal è probabilmente il modo più sicuro per inviare un messaggio al telefono di qualcuno, supponendo che entrambe le parti abbiano Signal installato.

user137369

2019-04-03 19:32:27 UTC

view on stackexchange narkive permalink

Se ti fidi, onetimesecret (che è open source) esiste proprio per questo scopo.

Quando invii persone sensibili informazioni come password e collegamenti privati via e-mail o chat, ci sono copie di tali informazioni memorizzate in molti posti. Se invece utilizzi un collegamento una tantum, le informazioni persistono per una singola visualizzazione, il che significa che non possono essere lette da qualcun altro in seguito. Ciò ti consente di inviare informazioni sensibili in modo sicuro sapendo che sono viste da una sola persona. Consideralo come un messaggio che si autodistrugge.

Creare il tuo sistema univoco segreto è abbastanza banale.Qualche anno fa ho scritto un PoC in una dozzina di righe di perl.La memorizzazione di un segreto (testo) produce un URL che può essere spedito in sicurezza. L'URL può essere aperto esattamente una volta, dopodiché il segreto viene sovrascritto e quindi eliminato.Se si tenta di aprirlo di nuovo si ottiene un messaggio di errore simile a 404 che informa anche il visitatore che se vede quel messaggio la prima volta che l'URL viene visitato, qualcun altro lo ha visto prima, più come un'intercettazione della posta conil link.

llmora

2019-04-03 16:20:02 UTC

view on stackexchange narkive permalink

La posta elettronica non è un buon meccanismo per condividere password in chiaro data la sua natura intrinsecamente non crittografata.

Se le password vengono condivise in questo modo, il servizio dovrebbe garantire che la password venga modificata al primo accesso per ridurre il esposizione (e per consentire di rilevare se qualcuno ha utilizzato la password rubata), non un'opzione perfetta in quanto consente comunque a qualcuno di sfruttare la finestra di opportunità per accedere al sito ma è meglio che non sapere che qualcun altro ha la password .

Poiché questa non sembra essere un'opzione per te data la tua risposta al commento di schroeder, ti suggerirei di guardare a un meccanismo che garantisca la crittografia della password per tutto il percorso tra il tuo cliente e te stesso, sia attraverso crittografia end-to-end del contenuto della posta elettronica o utilizzo di un sito di condivisione autenticato e crittografato in cui è possibile crittografare le password in chiaro. Pensa anche se sei davvero a tuo agio con altre persone (il tuo cliente, gli altri membri del tuo team) che conoscono la tua password, qualcosa che dipenderebbe dai requisiti di sicurezza dell'applicazione a cui stai accedendo.

Il rischio principale qui sarebbe essere chi, a parte te stesso, conosce la password. Nel tuo caso questo sarebbe almeno:

La persona dell'organizzazione del tuo cliente che ha generato la password e te l'ha inviata per posta elettronica
Chiunque gestisca qualsiasi e-mail infrastruttura tra te e il tuo cliente
Chiunque abbia accesso alla rete in uno qualsiasi dei percorsi di posta elettronica tra te e il tuo cliente
Gli altri membri del team che lavorano con lo stesso account e password (dedotto dalla tua risposta al commento di schroeder)
Chiunque possa avere accesso alla tua casella di posta (es. il tuo commento sul lasciare incustodito il tuo client di posta)

Se l'unico obiettivo della password è evitare l'accesso non autorizzato ai servizi B2B e sei a tuo agio con altre persone che conoscono la tua password, puoi esaminare la crittografia per la distribuzione della password. Sebbene molti server SMTP implementino la crittografia per il trasferimento dei dati tra gli hop del server di posta, non è garantita la crittografia, inoltre le e-mail intrinsecamente non sono crittografate, quindi la password risiederà in testo normale almeno durante la sua elaborazione a ciascuno degli hop di trasferimento della posta (SMTP).

Ciò significa che è necessario esaminare la crittografia end-to-end per garantire che la password non sia disponibile a chiunque ficcanaso, come PGP, S / MIME o qualche altra tecnologia proprietaria di crittografia asimmetrica. Ciò garantirebbe la riservatezza della password durante il transito e puoi ancora utilizzare la posta elettronica per la sua distribuzione, con il compromesso di una configurazione difficile e costi operativi.

Potresti compromettere e utilizzare qualcosa come File ZIP o documento di Office con una password di crittografia predefinita condivisa tramite un canale protetto (ad esempio una telefonata), che ridurrà sia l'overhead operativo che la protezione della password. Allo stesso modo, un file ospitato nel cloud con le password e protetto con un segreto condiviso in modo sicuro avrebbe gli stessi vantaggi / svantaggi.

AccountantM

2019-04-03 20:40:10 UTC

view on stackexchange narkive permalink

Non capisco perché stai inviando loro le password?

I client impostano la loro password preferita, la hash, memorizzano l'hash e nessuno lo sa tranne il client / il suo programma di gestione delle password la password originale (nemmeno tu), e quando la dimenticano, mandi loro un link di ripristino.

Tuttavia se devi davvero inviargli la password, ti suggerisco di inviargli un link a generato dinamicamente pagina web che mostra la sua password (solo per 1 volta).

devi memorizzare temporaneamente qualcosa di simile nel tuo database

  emailTocken char (32) password varchar + - -------------------------------- + ----------------- - + | emailTocken | password | + ---------------------------------- + -------------- ---- + | 202CB962AC59075B964B07152D234B70 | jhds7ytht_id | | CF297E613A7F7892A3BF348EE526ABAD | hdhdbdue874 # | | 8F14E45FCEEA167A5A36DEDD4BEA2543 | yeheb8cvddt5) | | 2510C39011C5BE704182423E3A695E91 | 6 # hdyd98_jee | | 8F14E45FCEEA167A5A36DEDD4BEA2543 | yhrtxbxv48_e | + ---------------------------------- + -------------- ---- +

e inviagli un'e-mail in cui esponi solo l'e-mail Blocca non la password

  Ciao, cliente Segui questo link per vedere il tuo password https://example.com/showPassword?emailTocken=8F14E45FCEEA167A5A36DEDD4BEA2543

sul server web quando qualcuno richiede questo collegamento, fai quanto segue

seleziona la password che ha l'emailTocken fornito
elimina il suo record dal database

Ora il primo che richiede questo collegamento vedrà qualcosa come

  Ciao, cliente la tua password è yeheb8cvddt5) NOTA: CANCELLEREMO QUESTA PASSWORD DAI NOSTRI SERVER, QUINDI DEVI RICORDARLA / SALVARLA

Se qualcuno successivamente richiede lo stesso link vedrà qualcosa come

  Spiacenti, questa password non esiste o è stata visualizzata prima!

Vantaggi di questo approccio rispetto all'invio della password tramite posta elettronica:

la password viene esposta solo 1 volta per il primo visualizzatore, non per chi vede l'email in seguito .
se qualcun altro ha visualizzato la password per prima (un uomo nel mezzo), l'utente legittimo non sarà in grado di vederla e chiederà aiuto, il che ci farà sapere che c'è è successo qualcosa di sbagliato, meglio di come lo vede qualcun altro, e non lo sappiamo nemmeno. Spero che il tuo programma di posta elettronica non lo richieda automaticamente per nessun motivo :( .

svantaggi di questo approccio rispetto all'invio della password tramite posta elettronica:

richiede un server web
più lavoro che inviare facilmente la poassword tramite posta elettronica

Come io ti ho detto prima, nessuno tranne il client dovrebbe conoscere la password, e non ho mai provato questo approccio, ma almeno è meglio che esporre la password in testo normale in un EMAIL che può risiedere su molti computer / server per un po '.

Ho pensato a questa soluzione prima, ma come tutti sappiamo io (cioè il programmatore medio) nel 99,91% dei casi è ben consigliato di non creare strumenti di sicurezza personalizzati.Quindi mi sono sempre chiesto, ** se questa è davvero una buona idea, dov'è lo strumento Open Source testato e collaudato, che fa esattamente questo, allora? **

@s1lv3r Come ho accennato nella risposta, non l'ho mai provato, ho solo cancellato le password salate e salvato l'hash, e quando i miei clienti chiedono la password, do loro un link di ripristino.** Tuttavia la soluzione suggerita è migliore rispetto alla semplice password nelle e-mail! **

@s1lv3r controlla [questa risposta] (https://security.stackexchange.com/a/206724/149722), l'ha fatto davvero.E anche [questo] (https://security.stackexchange.com/a/206709/149722)

Questo è un modo ragionevole per implementare le password in un sistema personalizzato, ma la mia impressione è che l'OP chieda informazioni sulle situazioni in cui le aziende con cui lavorano generano password per vari software e servizi di terze parti che utilizzano.

@XiongChiamiov Sì, lo capisco.Invece di generare password e inviarle ai proprietari tramite e-mail, generare le password e salvarle nel database e inviare i collegamenti.

GrumpyCrouton

2019-04-03 21:08:14 UTC

view on stackexchange narkive permalink

Ho un piccolo progetto che ho creato che chiamo "Secure Messaging Service" che ti permetterà di digitare un messaggio e generare un collegamento per visualizzare quel messaggio. Una volta visualizzato il messaggio, viene rimosso dal database. Supporta anche l'invio di un'e-mail quando il messaggio è stato letto!

Digita un messaggio e premi "invia", il nostro server genererà un GUID basato su uuidgenerator.net, una passphrase casuale di 8 caratteri su passwordwolf.com (che non è memorizzato nel nostro database) e crittograferà il tuo messaggio utilizzando AES-256-CBC. Riceverai quindi un collegamento che contiene il GUID e la passphrase per visualizzare il messaggio (o da inviare a qualcuno per visualizzare il messaggio), non appena il collegamento viene utilizzato il messaggio non esisterà più nel nostro database.

Ora hai la possibilità per il nostro servizio di inviarti un'e-mail quando il tuo messaggio viene letto dal destinatario. Quando fornisci la tua email, la crittografiamo prima di inserirla nel nostro database utilizzando lo stesso metodo di crittografia del tuo messaggio segreto, inclusa la stessa passphrase. Questa passphrase non è memorizzata nel nostro server, viene fornita come parte del collegamento per visualizzare il messaggio.

Poiché tutto ciò che viene inviato al nostro server è crittografato con AES-256-CBC e la passphrase esiste solo in il collegamento fornito, ciò significa che solo tu e chiunque tu invii il collegamento potete visualizzare il messaggio. Se qualcun altro vuole vederlo, deve forzarlo. Cinquanta supercomputer che potrebbero controllare un miliardo di miliardi (1018) di chiavi AES al secondo (se un dispositivo del genere potesse mai essere realizzato) richiederebbero, in teoria, circa 3 × 1051 anni per esaurire lo spazio delle chiavi a 256 bit. Abbiamo fatto del nostro meglio per rendere questi messaggi non visualizzabili da nessuno tranne la persona con il collegamento, anche se quella persona ha accesso al database, ma non garantiamo e non siamo responsabili per eventuali danni causati dall'utilizzo di questo servizio.

Il servizio di messaggistica sicura ha anche il supporto API, il che significa che potresti potenzialmente generare e inviare automaticamente un'e-mail agli utenti che si stanno registrando con un link per visualizzare la loro password.

Ecco come i dati nel database è memorizzato, come puoi vedere, non c'è modo di recuperare il contenuto del messaggio utilizzando le informazioni nella tabella, perché richiede una passphrase speciale che viene aggiunta solo al collegamento che ti viene fornito al momento della creazione il messaggio e non è memorizzato nel database.

Interfaccia utente bella, semplice e amichevole, questo è ciò che intendevo con la mia risposta, aggiungerò il tuo servizio ai preferiti per usarlo quando ne ho bisogno, grazie.

-1

Ti suggerisco di ottenere l'effettivo messaggio segreto ed eliminarlo quando l'utente passa il mouse / clicca su questa casella (tramite una richiesta AJAX), ciò impedirà che la password venga eliminata dalle richieste automatiche effettuate dagli agenti di posta elettronica o da WhatsApp, i bot di Facebook * (Se ioinvia il link al mio amico su whatsapp o facebook, questi programmi bot faranno automaticamente una richiesta che farà cancellare il segreto) *.a parte questo è molto carino

@Accountant Buona idea, prenderò sicuramente in considerazione l'aggiunta.

Questo potrebbe essere un servizio utile per alcune persone, ma perché dovremmo fidarci di te?

@aCVn valida preoccupazione, ma perché dovremmo fidarci dei nostri produttori di sistemi operativi, società di web hosting, programmi di tutti i giorni?**LEGGE**.sarà sufficiente un piccolo accordo con l'utente, oltre a questo, tecnicamente ci fidiamo o conosciamo anche ogni riga di codice che usiamo ogni giorno?un altro motivo per me di fidarmi di lui è che questo è un servizio leggero che non richiede registrazione, il che gli fa non sapere chi sono io o chi è la persona a cui ho inviato la password, o anche quale password è questa,dove può essere utilizzato?** Vede solo segreti per gli utenti di cui non sa nulla più dei loro IP / browser user-agent. **

@aCVn Semplice, se non ti fidi del servizio, non usarlo.Ci sono molti altri servizi che fanno cose simili.Nella pagina delle informazioni ho spiegato esattamente come funziona, cosa memorizza, e questo è tutto quello che posso fare per provare a "dimostrare" alle persone che possono fidarsi del servizio.Inoltre, non vedo cosa potrei guadagnare mentendo su tutto ciò, considerando che il servizio è anonimo.

@aCVn Ho aggiunto un'immagine che mostra come tutto è memorizzato nel database.Potrei anche considerare di caricare il codice su GitHub se smetto di essere pigro un giorno

@AccountantM Non sono sicuro che tu sia ancora interessato a questo progetto, o addirittura lo ricordi (me ne sono dimenticato, anche se lo stavo ancora ospitando), ma qualcuno ha votato positivamente la mia risposta qui che mi ha ricordato questo progetto.È venuto fuori che ha visto un certo utilizzo negli ultimi mesi, di cui non ero nemmeno a conoscenza.Ci è voluto del tempo oggi per riscriverlo completamente.Guarda le modifiche che ho fatto!

@GrumpyCrouton Ciao, sì, ricordo il tuo progetto ed è ancora nei miei siti segnalibri, ma non l'ho ancora usato.Congratulazioni per i nuovi cambiamenti nell'aspetto (sembra migliore), non ho ancora controllato il traffico di rete, ma stasera darò uno sguardo più approfondito.

@AccountantM Fantastico.Sto pensando di implementare un modo per consentire alle persone di _rispondere_ ai messaggi che vengono inviati (se il mittente ha immesso un'e-mail, ma senza mostrare effettivamente l'e-mail del mittente al destinatario), un po 'come funziona la pagina Contattaci.Un'altra idea che ho avuto è stata quella di consentire ai mittenti di impostare una password aggiuntiva che il destinatario deve inserire manualmente prima di rivelare il segreto.Fatemi sapere cosa ne pensate!

Perkins

2019-04-04 00:07:15 UTC

view on stackexchange narkive permalink

Per cominciare, questa è una specie di brutta situazione. Sembra che tu stia condividendo account utente. A volte non c'è una buona alternativa a questo, ma non dovrebbe essere usato con qualcosa di particolarmente sensibile perché diventa molto più difficile controllare l'uso della risorsa quando ci sono più persone che accedono con lo stesso nome.

Se è davvero necessario che più persone utilizzino gli stessi account, quindi le credenziali dovrebbero essere consegnate di persona.

Probabilmente non è pratico, quindi la tua prossima migliore opzione è inviarle tramite telefono fisso. (Almeno nella maggior parte dei paesi.) I telefoni fissi sono relativamente difficili da intercettare e nella maggior parte dei paesi è vietato alla compagnia telefonica di ascoltare senza un ordine del tribunale. Le agenzie di spionaggio governative potrebbero essere in ascolto, ma se vogliono le tue password ti picchiano finché non le consegni comunque.

Circa lo stesso livello di sicurezza è la posta elettronica crittografata tramite GPG o simili. È più facile per terze parti intercettare e memorizzare i dati, ma più difficile per loro leggerli finché non hanno abbastanza tempo per decifrare la chiave. Assicurati di cambiare la password ogni pochi anni e assicurati di non utilizzare la stessa lettera modulo ogni volta in quanto ciò semplifica il cracking.

Se non riesci a farli accettare con quello, allora un il codice del libro è la tua prossima migliore scommessa. Deve essere un libro che tutti hanno e che usano sempre comunque, quindi potrebbe essere un po 'complicato. Il formato tipico è qualcosa di simile a pagenumber-paragraphnumber-wordnumber. Rendi le password di quattro o cinque parole e funzionerà bene. Oppure compilarlo usando la prima lettera di ogni parola specificata, se necessario.

Se il codice di un libro non funziona, fintanto che la password non contiene parole o strutture simili a parole, una semplice sostituzione o una cifratura di trasposizione come quella usata per i crittogrammi nel giornale sarà attaccanti più determinati. Ma la password deve essere costituita da caratteri casuali o l'analisi statistica ne farà un lavoro breve e dovrai comunque fornire la chiave di crittografia tramite un canale sicuro. Ovviamente con questo metodo si crittografa solo la password per limitare la superficie di attacco e, preferibilmente, non si fa assolutamente menzione del fatto che l'hai criptata nel resto dell'email. Tutte le discussioni sul fatto che la password è crittografata e come deve essere tramite un canale sicuro.

borjab

2019-04-04 01:13:19 UTC

view on stackexchange narkive permalink

Esiste un tipico caso d'uso per i team di sviluppo distribuiti in cui SysOps e TeamMembers creano le credenziali per una risorsa (DataBase, servizio, server) e devono comunicarlo al team. SE aggiungi un nuovo membro al team:

Non puoi semplicemente cancellare la password.
Non puoi semplicemente reimpostare la password o smetterà di funzionare per il resto del team.

Usiamo un gestore di password distribuito. Questo ci permette di aggiungere una nuova password e condividerla con individui o gruppi. Riceverai un'e-mail del tipo "BOFH-1 ha condiviso la password 'JenkinAdmin'". Devi accedere per vedere la vera password che viaggerà attraverso https.

Uno strumento centralizzato può essere eccessivo per alcuni scenari in quanto ti obbliga a eseguire alcune installazioni e configurazioni. È fantastico se tutto il tuo dipartimento lo utilizza per aggiornarlo. Solo una persona deve aggiornare le credenziali nel gestore delle password. Utilizziamo uno strumento open source, ma i programmi specifici sono discussi meglio in Consigli sul software

Questo è già coperto dalla risposta più generica del gestore di password.Si prega di non pubblicare annunci per prodotti specifici.

@schroeder avevo rimosso il riferimento alla soluzione anche se è open source.

Douglas Held

2019-04-04 02:03:47 UTC

view on stackexchange narkive permalink

Esatto, non è sicuro inviare una password in un'e-mail.

Un protocollo di account iniziale sicuro è:

Invia all'utente un collegamento ipertestuale monouso, in scadenza e consenti all'utente per impostare la password iniziale da quel collegamento. Quindi, facoltativamente verificare che l'utente abbia impostato il secondo fattore. Quindi, facoltativamente verificare l'identità dell'utente in qualche altro modo (videochiamata?) Infine, fornire all'account dell'utente l'accesso richiesto.

Chloe

2019-04-04 02:20:27 UTC

view on stackexchange narkive permalink

Suggerirei di utilizzare Signal per inviare e ricevere password. È un'app di chat crittografata end-to-end.

I messaggi di segnalazione e le chiamate sono sempre crittografati end-to-end e meticolosamente progettati per mantenere la tua comunicazione al sicuro. Non possiamo leggere i tuoi messaggi o vedere le tue chiamate e nessun altro può farlo.

Nessuna email non è sicura perché anche se usi SSL sui tuoi server di posta c'è un record di il messaggio sul disco del server che può essere letto da un amministratore. Solo le email crittografate con PGP / GPG o SMIME sarebbero sicure.

Qualcuno ha aggiunto quanto segue alla mia risposta. Non ne ho sentito parlare, quindi non posso consigliarlo.

Oltre a Signal, è possibile utilizzare un'altra opzione crittografata per lo scambio di messaggi, che non richiede la conferma del tuo ID facendo clic sui link o fornendo posta elettronica ecc. È anche multipiattaforma, il che è molto importante. È

per Android: app di conversazione
per Linux e Windows: app Gajim

Può utilizzare la crittografia PGP o OMEMO - il plug-in potrebbe dover essere installato separatamente.

Esiste anche un altro metodo, probabilmente il migliore nella tua situazione.

Richiede che tu abbia un sito web con SSL e su un sito web e scatola incorporata. Qualcuno può scrivere un messaggio in quella casella e, al momento dell'invio, il messaggio deve essere crittografato con [es.] Chiave pubblica PGP che può essere decrittografata automaticamente solo sull'e-mail del PC.

@Over-heads Sei in divieto di risposta a causa di una risposta negata / cancellata?Se sì, potresti ricordare, 1) quante risposte hai scritto?2) da quanti di loro hai visto che avevano un voto negativo (il numero in alto a sinistra era negativo)?|A proposito, probabilmente puoi pubblicare di nuovo tra 2 settimane.

@Over-heads Qui vedi l'elenco delle tue risposte cancellate.Quante risposte ci sono e quante di esse hanno un punteggio negativo?https://security.stackexchange.com/users/recently-deleted-answers/203877

Monica Apologists Get Out

2019-04-04 17:54:07 UTC

view on stackexchange narkive permalink

Chiedi loro di alzare il telefono e chiamarti. L'uso della comunicazione fuori banda riduce significativamente la probabilità che un intercettatore abbia accesso alle tue informazioni. Ciò è in parte dovuto al fatto che non è improbabile che un utente malintenzionato abbia compromesso il tuo sistema di posta elettronica o il tuo sistema telefonico, ma le probabilità che abbiano compromesso entrambi sono basse. se puoi suddividere le informazioni vitali (ad es. nome utente nell'e-mail, password per telefono, ecc.), diventa più difficile per l'aggressore, in relazione all'aumento del lavoro richiesto.

Sì, ho usato "leggere una password temporanea al telefono" alcune volte quando ho a che fare con persone meno esperte dall'altra parte che non potevano far funzionare cose come GPG.Fastidioso, ma pratico.

WoJ

2019-04-03 20:33:38 UTC

view on stackexchange narkive permalink

Se la tua email è preimpostata dall'azienda, una soluzione è quella di non avere affatto una password (la password è seminata con una stringa lunga, complicata, ecc. che nessuno conosce).

Quindi richiedi uno nuovo (tramite la funzionalità "Password dimenticata"), che ti invia un link di reimpostazione alla tua email.

questo è trattato nei commenti alla domanda

bremen_matt

2019-04-04 10:31:48 UTC

view on stackexchange narkive permalink

La buona vecchia telefonata è un metodo collaudato.

A parte questo, una stretta di mano SSH è un buon metodo ...

Sia tu che il destinatario generate una chiave SSH. Si genera una password e si crittografa la password utilizzando la propria chiave. Si invia la password crittografata al client. Aggiungono una crittografia aggiuntiva al tuo messaggio utilizzando la loro chiave. Quindi ti rimandano indietro il messaggio con doppia crittografia. Decifrate questo messaggio, lasciando solo la password crittografata dalla chiave del destinatario. Restituisci questo messaggio. Lo decrittano usando la loro password per ottenere la password. In questo modo i dati non crittografati non toccano mai il web.

Perché farlo quando puoi semplicemente usare PGP, che in realtà è inteso per cose come questa?

n0rd

2019-04-04 09:46:36 UTC

view on stackexchange narkive permalink

OAuth è l'alternativa per accedere a sistemi di terze parti senza la necessità di impostare l'autenticazione della password in tali sistemi ed elimina la necessità di scambiare password. Ovviamente, ciò richiederebbe che i sistemi supportino OAuth, il che non è sempre il caso.

Questo non risponde alla domanda

@schroeder, potresti elaborare?

Voglio dire, in che modo "OAuth" non è una risposta a "Esiste un'alternativa all'invio di password tramite posta elettronica ..."?(Partendo dal presupposto che solo "sì" non è abbastanza)

Questa è un'alternativa alla necessità di inviare una password.È una riformulazione del problema.L'implicazione è che è necessario comunicare una password.

Le alternative sono esattamente ciò di cui tratta questa domanda.Non vi è alcuna premessa che OAuth non sia un'opzione.Molte applicazioni B2B con cui ho avuto a che fare lo supportano, ma le persone che lo usano spesso ignorano questa capacità.

Il set di app con cui ho lavorato è decisamente distorto, poiché sono per lo più ospitate in Azure e supportano Azure AD.

iBug

2019-04-05 20:47:43 UTC

view on stackexchange narkive permalink

La prima cosa che mi viene in mente è la crittografia asimmetrica (ad esempio GPG). Ciò potrebbe essere particolarmente utile senza complicare eccessivamente le cose.

Trova o imposta un server di chiavi pubbliche e consenti a tutti di condividere le proprie chiavi pubbliche. Quindi, ogni volta che devi condividere qualcosa di sensibile per un destinatario specifico, puoi prendere la sua chiave e crittografare il contenuto. Nessun altro conoscerà il contenuto originale tranne il destinatario.

Un'email di esempio diventerebbe:

Ciao iBug,

Ecco le tue credenziali di accesso a Scambio di stack di sicurezza delle informazioni. È crittografato con la tua chiave DEADBEEF trovata sul nostro server delle chiavi aziendale.
  < GPG Encrypted Message >  

già coperto da altre risposte

Toine-L

2019-09-26 22:40:59 UTC

view on stackexchange narkive permalink

Potresti usare SendPass ( https://sendpass.app)

Secondo me, i due maggiori rischi dell'invio di password in testo normale sono che potrebbero risiedere in archivi, log o ancora nella casella di posta dell'utente, e la seconda è l'intercettazione della password e l'effettivo destinatario che non ne è a conoscenza (e quindi non avvisa l'amministratore).

Per affrontare questi rischi, ho creato un'applicazione gratuita che puoi utilizzare per inviare un codice monouso che può essere utilizzato dal destinatario per recuperare la password. Ho pubblicato SendPass per aiutare gli altri, specialmente le persone non tecniche, ma potrebbe essere utile anche a te.

SendPass ti offre un modo gratuito, facile e sicuro per condividere le password. SendPass funziona generando un codice unico e monouso che puoi inviare al tuo destinatario. Il codice può essere utilizzato solo una volta, dopodiché la password verrà immediatamente cancellata.