Non lo fai.

Quando insegni agli utenti a fornire il proprio nome utente e password a qualcuno, li insegni a essere vulnerabili al phishing o ad altri attacchi di ingegneria sociale.

Piuttosto, progetta il sistema in modo che un amministratore possa visualizzare e modificare queste impostazioni senza richiedere le credenziali dell'utente.

Quando ti trovi in ​​una situazione in cui hai davvero bisogno di vedere le cose dal punto di vista dell'utente per risolvere un problema, chiedi all'utente di digitare la password per te e poi lascia che ti mostri il problema. Questo può essere fatto di persona o con uno strumento di amministrazione remota.

Quando ti trovi in ​​una situazione in cui il cliente dispone delle credenziali necessarie nella tua applicazione per integrarsi con una soluzione di terze parti, sviluppa la tua applicazione in un modo in cui un utente non tecnico dispone di un'interfaccia utente facile da usare per impostare queste credenziali. Ne avrai comunque bisogno nel caso in cui il cliente abbia bisogno di modificarli e tu non sia disponibile.

L'utente non dovrà inserirlo finché l'applicazione non verrà distribuita sui propri server. Durante lo sviluppo dovresti utilizzare un account di prova da parte tua per interfacciarti con le terze parti. Sicuramente non vuoi causare alcun costo al tuo cliente perché hai eseguito alcuni test sulle interfacce di pagamento di terze parti che non hanno funzionato come previsto.

Esistono numerosi "gestori di password per i team" che consentono ai team di condividere, modificare e revocare l'accesso alle credenziali. La maggior parte sono pagati (o gratuiti per piccole squadre), ma questo è probabilmente il modo migliore per farlo. In genere forniscono la crittografia, nonché il controllo degli accessi sull'accesso a credenziali specifiche.

L'unica opzione praticabile che vedo (che non è stata ancora menzionata, strano) è avere gli account di configurazione del client con le autorizzazioni appropriate per l'utilizzo su questi sistemi / servizi Internet. In questo modo, gestiscono le relazioni con i fornitori e i pagamenti, ma tu disponi di account che dispongono dell'accesso di cui hai bisogno.

Come affermato nella risposta di Phillip, semplicemente non chiedi né partecipi nella condivisione delle password. È solo brutto tutto intorno, perché ti stai mettendo nella posizione di essere incolpato se qualcosa va storto quando qualcun altro usa l'account condiviso. (" So che i miei dipendenti non farebbero mai una cosa del genere e tu sei le uniche persone con cui abbiamo condiviso la password, quindi deve essere qualcosa che hai fatto tu ! ! ")

Riassumo la situazione come segue

• hai bisogno di accedere a un servizio di terze parti con l'account del tuo cliente
• non è facile raggiungere un incontro di persona
• una soluzione che coinvolga il client che installa software o segue una procedura complessa non è desiderabile

Penso che la soluzione migliore sarebbe: Invia LORO una nuova password

Tu inviare loro una password in modo sicuro e fornire loro istruzioni (tramite telefono?) per impostare temporaneamente la password sui loro account con la password proposta. - Quindi puoi usarlo per accedere alla pagina. E quando hai finito, possono reimpostare la password al valore originale.

Un modo semplice sarebbe un collegamento una tantum nella posta, che porta a una pagina che mostra la password. Il cliente può fare clic su di esso, copiare la password. E un utente malintenzionato non sarà in grado di accedere allo stesso collegamento alla password. (Ovviamente un attacco MitM mirato con la modifica del contenuto della posta sarebbe ancora possibile e potrebbe essere mitigato firmando la posta)

Potresti anche dire loro la password temporanea tramite telefono, la annotano e cambiano la loro password dell'account temporaneamente a quella che gli dici.

Questo modo all'indietro ha diversi vantaggi:

• Il tuo cliente può rispettare la regola "Non condividere mai la tua password"
• Puoi scegliere un modo sicuro per trasmettere la password, non devi insegnare al tuo cliente un modo sicuro.
• Il tuo cliente ha il controllo di dare e revocare il tuo accesso

Esistono letteralmente tantissime soluzioni per la trasmissione di dati (ad es. credenziali) in modo sicuro.

• Se il client supporta la crittografia PGP / GPG, puoi scambiare chiavi pubbliche e crittografare le email
• Ci sono anche aziende specializzate in SecureMail (ZixCorp) oppure puoi acquistare il tuo (Cisco Ironport).
• Se si dispone di un sito di collaborazione (ad esempio, portale clienti per il cliente) possono caricare le credenziali sul portale. FYI Alfresco è un'applicazione freeware che fa un buon lavoro in questo senso.
• Anche se il contatto umano è fuori questione, sei in grado di inviare messaggi? Forse possono inviare un messaggio di testo della password e fornire il nome utente tramite un altro canale.
• Se tutto il resto fallisce, i segnali di fumo e la posta ordinaria sono ancora una cosa, ma i metodi sopra sono i vettori più comuni.

Sii semplice, ma utilizza solo due forme di comunicazione. Ad esempio, in un'e-mail che richiede le credenziali, chiedi loro di rispondere solo con il nome utente e quindi invia una password temporanea al tuo numero. Appena possibile dopo aver ottenuto le credenziali, cambia la password temporanea con qualcos'altro.

Sì, in teoria, qualcuno potrebbe vedere l'email e hackerare SS7 per ottenere la password, ma se può farlo prima che tu possa cambiare la password temporanea, sei comunque pwnato.

Non dovresti essere programmato come callback per rispondere a nome utente / password specifici. Se hai a che fare con strumenti di terze parti, dovresti configurare tali account per loro e interagire con tali strumenti tramite token API. Molto meglio che crei l'account e alla fine assegni le credenziali dell'account al cliente.

Strano che nessuno abbia menzionato OAuth, che, a prima vista, è la soluzione perfetta per il problema, come riformulato dopo l'aggiornamento.