Come richiedere in modo sicuro le password del cliente come società di consulenza?

Non lo fai.

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

Invece, progetta il sistema in modo che un amministratore possa visualizzare e modificare queste impostazioni senza richiedere le credenziali degli utenti.

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 lascia che mostrino il problema. Questo può essere fatto di persona o con uno strumento di amministrazione remoto.

Quando ti trovi in una situazione in cui il cliente ha le credenziali necessarie per integrare la tua applicazione con una soluzione di terze parti, sviluppa la tua applicazione in modo che un utente non tecnico abbia un'interfaccia utente facile da usare per impostare queste credenziali . Ne avrai comunque bisogno nel caso in cui il cliente debba cambiarle e tu non sia disponibile.

L'utente non dovrà inserire questo finché l'applicazione non viene distribuita sui propri server. Durante lo sviluppo dovresti utilizzare un account di prova sul tuo terminale per interfacciarlo 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 funzionavano nel modo previsto.

Esistono numerosi "gestori di password di 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 andare. In genere forniscono la crittografia e il controllo dell'accesso sull'accesso a credenziali specifiche.

L'unica opzione valida che vedo (che non è stata ancora menzionata, dispari) è quella di avere gli account di configurazione del client con le autorizzazioni appropriate da utilizzare su questi sistemi / servizi Internet. In questo modo, gestiscono le relazioni con i fornitori e il pagamento, ma tu hai degli account che ti richiedono l'accesso.

Come ha dichiarato la risposta di Phillip , semplicemente non chiedi o non partecipi alla condivisione delle password. È solo brutto tutto intorno, dato che ti stai mettendo nella posizione di essere incolpato se qualcosa va storto quando qualcun altro usa l'account condiviso. ("I know i miei dipendenti non farebbero mai una cosa del genere, e tu sei l'unica persona con la quale abbiamo condiviso la password, quindi deve essere qualcosa di tu ! ! ")

Riassumo la situazione nel modo seguente

• devi accedere a un servizio di terze parti con account del tuo cliente
• l'incontro di persona non è facilmente raggiungibile
• una soluzione che coinvolge il client che installa software o che segue una procedura complessa è indesiderabile

Penso che la soluzione migliore sarebbe: inviare una nuova password a loro

Inviate loro una password in modo sicuro e fornite loro istruzioni (via telefono?) per impostare temporaneamente la password dei loro account sulla vostra 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 occasionale nella posta, che conduce a una pagina che visualizza la password. Il client può fare clic su di esso, copiare la password. E un utente malintenzionato non sarà in grado di accedere allo stesso link di password. (Di couse 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 via telefono, la annotano e cambiano temporaneamente la password dell'account in quella che hai detto loro.

Questa modalità a ritroso offre 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 in modo sicuro.
• Il tuo cliente mantiene il controllo sul dare e revocare il tuo accesso

Esistono letteralmente tonnellate di soluzioni per trasmettere dati (ad es. credenziali) in modo sicuro.

• Se il client supporta la crittografia PGP / GPG, puoi scambiare le chiavi pubbliche e crittografare le email
• Ci sono anche aziende specializzate in SecureMail (ZixCorp) o puoi acquistare la tua (Cisco Ironport).
• Se si dispone di un sito di collaborazione (ad es. portale clienti per il cliente), è possibile caricare le credenziali sul portale. FYI Alfresco è un'applicazione freeware che fa un buon lavoro.
• Anche se il contatto umano è fuori discussione, 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 di lumaca sono ancora una cosa, ma i metodi sopra riportati sono i vettori più comuni.

Semplifica, ma usa solo due forme di comunicazione. Ad esempio, in un'e-mail che richiede le credenziali, chiedere loro di rispondere solo con nome utente e quindi inviare una password temporanea al proprio numero. Appena possibile dopo aver ottenuto le credenziali, cambiare la password temporanea in qualcos'altro.

Sì, in teoria, qualcuno potrebbe vedere l'e-mail e hackerare SS7 per ottenere la password, ma se possono farlo prima che tu possa cambiare dalla password temporanea, sei comunque bloccato.

Non dovresti fare callback hard-coding per rispondere a specifici username / password. Se hai a che fare con strumenti di terze parti dovresti configurarli per questi account e interagire con questi strumenti tramite token API. È molto meglio che tu 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.