Perché è un'idea terribile?

Registrando le credenziali di accesso di altri, l'azienda si assume una responsabilità . Poiché la società è ora responsabile della malizia che potrebbe verificarsi utilizzando tali credenziali, l'azienda dovrebbe adottare misure per ridurre al minimo il rischio. Inoltre, le aziende che interagiscono con la tua devono assumersi la responsabilità di fidarsi di te, qualcosa che può danneggiare il business se un incidente diventa pubblico (come menzionato da symcbean)

Memorizzare le password in chiaro (come sai) non fornisce alcuna protezione contro questo rischio.

Qual è una soluzione migliore?

Come hai detto in un commento, ciò di cui hai bisogno è qualcosa come un gestore di password . In effetti, quello che vuoi è un gestore di password.

Dato che c'è molto spazio per gli errori quando si tratta di crittografia, suggerisco di utilizzare un gestore di password consolidato. Puoi trovare innumerevoli confronti online, ma alla fine le tue scelte includono quelli basati su una GUI (come 1password, LastPass, keepass, ecc.) O basata su un cli per l'accesso automatico (come pass o tramite il cli LastPass)

Sì, stai facendo qualcosa di terribilmente sbagliato. Il fatto che il tuo datore di lavoro sembri specializzato in conformità rende le cose molto, MOLTO peggio. L'attività dell'azienda si basa su una reputazione di eccellenza nella conformità che stai attivamente violando.

Sfortunatamente a tutti i livelli in un'organizzazione, convincere i tuoi superiori che quello che stanno facendo è una cattiva idea è difficile. Se fossi in te, suggerirei loro di considerare come reagirebbero i loro clienti se:

• gli fosse stato detto che memorizzi le loro credenziali in testo non crittografato (presumibilmente senza alcun controllo di rilascio / audit sull'utilizzo)
• hanno letto sul giornale che un altro cliente era stato compromesso a causa di questa pratica

Riguardo a quale sarebbe un approccio migliore . .. vuoi davvero l'approccio giusto , bilanciando riservatezza, integrità, disponibilità e budget. Esistono prodotti commerciali e open source che aiuterebbero in questo, ma richiederebbero molte più indagini e analisi di quelle appropriate per questo forum.

Non vuoi affatto memorizzare le password degli utenti, nemmeno in KeePass o qualcosa di simile.

• Le informazioni sono nascoste per impostazione predefinita ma possono comunque essere visualizzate facilmente
• Le password sono facilmente condivise, perdendo la responsabilità, ovvero come fai a sapere che è stato l'utente e non qualcun altro a utilizzare il proprio account?
• Se una password viene aggiornata (ad esempio, viene scoperto un cattivo agente e tu desidera impedire ulteriori accessi), deve essere aggiornato ovunque venga utilizzato

Queste sono alcune opzioni, suddivise per scenario:

1. Se i sistemi che stai utilizzando sono tuoi e sono gestiti attivamente, puoi richiedere una funzione di spoofing dell'utente. Ogni persona con accesso amministratore accede con il proprio account amministratore a cui è consentito passare a qualsiasi account utente di base senza dover conoscere la propria password. In questo modo, hai un auditing migliore. Puoi vedere che non è stato l'utente reale a eseguire le azioni, ma l'utente amministratore specifico che falsifica l'utente. Questo protegge sia te che l'utente poiché nessuno dei due può accusare l'altro di malizia, a meno che non si possa dimostrare che l'utente aveva la password dell'amministratore o l'amministratore aveva la password dell'utente e stava usando direttamente il proprio account.

   • Hai solo la conoscenza della tua password e non puoi scoprire la password di nessun altro utente, anche se minacciato (un buon schema di hashing richiede centinaia di anni per violare una password, in media)
   • responsabile solo delle tue azioni, non di tutti gli altri
   • Se la password di un utente viene aggiornata, non ti riguarda perché non cambia il modo in cui accedi al suo account

2. Se i sistemi sono esterni, cioè di terze parti, puoi provare a negoziare lo stesso tipo di funzionalità di spoofing degli utenti, tenendo presente che questa potrebbe essere una priorità molto bassa o nemmeno una priorità per alcune aziende, ad esempio, potrebbe non accadere mai o potrebbe accadere molto lentamente (pensare anni).

3. Se i sistemi non vengono più mantenuti, sei sfortunato. Le tue scelte sono di smettere di usarle a causa del rischio o di continuare a memorizzare le password in locale e ad accettare il rischio.

Ricorda, non è una questione di se si verificherà una violazione, ma quando si verificherà una violazione.

Sì, più cose. Memorizzare le password in chiaro è ovviamente una cattiva idea. Crittografarli è meglio, ma in genere le password non vengono memorizzate affatto. Viene invece memorizzato un hash irreversibile.

Ma il problema più grande qui è che usare una password utente per compilare i moduli significa che non c'è modo di sapere chi ha fatto cosa con queste password. Supponiamo che uno degli utenti nella tua base di clienti faccia qualcosa di sbagliato, persino illegale. Affermano che deve essere stato qualcuno nella tua organizzazione. Puoi provare che non lo era? Gli utenti sanno che hai accesso alle password, giusto?

E come menzionato nelle altre risposte, è molto più probabile che terze parti possano ottenere queste credenziali e utilizzarle. Se ciò accade, la tua organizzazione è di nuovo potenzialmente il bersaglio della colpa.

Se fossi in te, spiegherei i rischi a chiunque tu possa ascoltare. Se ho capito bene, queste credenziali sono per sistemi di terze parti. Idealmente, dovresti avere account su quei sistemi che sono per i tuoi utenti interni. Se non puoi farlo, dovresti provare ad avere una sorta di implementazione che impedisca alle persone della tua organizzazione di essere in grado di vedere le password e i log quando accedono a ciascun sistema.

Se devi accedere a un account straniero di qualcun altro, hai bisogno del suo nome utente e password. Non c'è modo di aggirarlo. Non puoi hash o crittografarli ¹ , hai bisogno dei valori normali.

Ovviamente è un incubo, poiché gli utenti devono rivelarti le loro credenziali. Credono che tu non stia abusando di loro. Supponendo che tu non li stia abusando intenzionalmente (come venderli sul mercato nero come parte del tuo modello di business), devi prevenire le perdite. Ciò include violazioni dei dati nella tua infrastruttura o la possibilità per gli amministratori di database di accedervi. Quindi la best practice qui sarebbe quella di non archiviarli affatto . Il compito della tua azienda è aiutare l'utente a compilare moduli, non fornire un servizio di gestione delle password. " rendere più facile per [gli utenti] ricordare " le proprie credenziali non è compito tuo.

Una soluzione potrebbe essere scrivere un'estensione per il browser che i tuoi utenti possono installare. Accedono a quegli account stranieri da soli, sulla loro macchina, e il tuo plugin fa il suo lavoro lì. Il tuo server non entra nemmeno in contatto con le credenziali. (Ovviamente l'utente deve ancora fidarsi dell'estensione per non spiarlo).

Se questa non è un'opzione e il lavoro, incluso il login, deve essere fatto sul tuo server, allora dovresti comunque non memorizzare le credenziali dell'utente. Basta inoltrarli al servizio di accesso esterno e quindi memorizzare solo il token di sessione che deve essere utilizzato con l'API nel database per tutto il tempo necessario. Se il database viene violato, l'aggressore potrebbe essere in grado di dirottare le sessioni (peggio ancora), ma non ottiene la password in chiaro. Chiedi all'utente di fornire nuovamente le credenziali se il tuo server deve accedere più volte.

_{1: Ovviamente dovresti crittografare sempre tutti i dati sensibili quando li memorizzi ovunque, ma alla fine la chiave per farlo deve risiedere da qualche parte sul tuo server, a cui anche un presunto aggressore potrebbe avere accesso.}

I manager parlano la lingua del business, non la tecnologia.

Fai una stima del rischio che la tua azienda deve affrontare con queste pratiche, espresso in valuta (USD, EUR, qualunque è appropriato). Esistono vari metodi per farlo. Un buon approccio consiste nel valutare sia uno scenario realistico che uno scenario peggiore. Dire a un manager che c'è una probabilità del 10% all'anno di un incidente di sicurezza che potrebbe costare all'azienda fino a 5 milioni di danni dovrebbe essere ascoltato.

Oltre ai potenziali danni derivanti da richieste di risarcimento contrattuali nei tuoi confronti da parte di le aziende clienti, dovresti anche considerare le responsabilità civili e penali causate da negligenza grave. La possibilità di finire in prigione è un'altra cosa che tende ad attirare l'attenzione del manager.

Se la tua azienda ha in atto la gestione del rischio, coordinati con i ragazzi di lì per quanto riguarda metodi e stime, seguendo le pratiche aziendali il tuo approccio più rispettabile.

La precauzione minima che devi prendere è usare un gestore di password o un altro sistema che a) memorizzi le password crittografate eb) decifra solo la password necessario, quando necessario.

Idealmente dovresti passare a un metodo basato su certificati, ma questo dipende anche dai tuoi clienti e non è interamente sotto il tuo controllo.

Dovresti anche disporre di una norma sulla gestione delle password che documenta il modo in cui vengono gestite le password e contiene sanzioni in caso di violazione. I filtri in uscita potrebbero impedire un problema di posta elettronica.

Sì, memorizzare le password in chiaro è stupido. In un incidente di copia-incolla, un membro dello staff ha anche accidentalmente inviato per email tutte le password "memorizzate" a una lista di distribuzione interna. Fortunatamente non c'erano clienti nell'elenco.

Quindi siamo passati a utilizzare Teampass che funziona molto bene come database centralizzato di informazioni sulle password.

Consente anche a gruppi con diversi livelli di accesso e ogni utente può avere il proprio set di password private memorizzate che nessun altro può leggere.

È una configurazione da un gestore di password individuale in cui ognuno conserva una copia delle password localmente. Quindi, se la password di un servizio viene aggiornata, tutti vedono quell'aggiornamento.

Anche la cronologia viene mantenuta, così puoi ottenere le password precedenti per il servizio X (forse un host non è stato aggiornato e devi tornare indietro nel tempo)

https://teampass.net/

Un altro angolo ad eccezione dell'ovvio (che conosci già, come mostri nella domanda - memorizzare le password non crittografate è un male):

Non condividere / dare password è o dovrebbe essere uno dei primi punto elenco in qualsiasi linea guida sulla sicurezza. Nessuna banca sana, servizio online o qualunque entità chiederà mai una password. Questo è radicato in ogni utente, per buone ragioni.

Se fossi il tuo cliente e il tuo datore di lavoro mi chiedesse una password, a) non te la darei eb) correrei al mio gestione abbastanza rapidamente. Cercherei davvero di assicurarmi che non fossimo tuoi clienti più a lungo.

Non fornisco nemmeno la mia password ai miei ragazzi dell'assistenza (nel caso improbabile che abbiano bisogno di me per accedere per loro durante una sessione di supporto lo farò io stesso). Ho ricevuto i controlli di sicurezza (per sistemi e / o applicazioni) e non è mai stato passato alcun account utente effettivo alla società di sicurezza. Se hanno bisogno di accedere, ottengono i propri account temporanei. Ho chiesto ai clienti di provare a dirmi la loro password e mi assicuro di interromperli immediatamente e di farli digitare da soli.

TL; DR: Sentiti libero di mostrare alla tua direzione questa risposta - lo farei essere un cliente perso per te.

La risposta migliore è non avere o utilizzare affatto le credenziali del cliente. L'atto di chiederli al tuo cliente è un enorme no-no per la sicurezza e dovrebbe far apparire bandiere rosse per chiunque presso i tuoi clienti abbia qualsiasi tipo di conoscenza della sicurezza.

In effetti, lo farei diciamo che facendo questo probabilmente stai già perdendo affari tra potenziali clienti che hanno qualsiasi tipo di politica di sicurezza. Il mio datore di lavoro ha una rigorosa politica sulle password e sarebbe probabilmente considerato motivo di licenziamento da parte mia condividere una qualsiasi delle nostre password con te.

Un altro fattore molto importante su cui nessun altro ha toccato è la responsabilità . Condividendo una password con te, il cliente si è aperto a potenziali problemi se l'account viene utilizzato in modo improprio. Un dipendente disonesto all'interno dell'azienda può essere quello da incolpare, ma se la password è stata condivisa apre una strada di plausibile negabilità. Possono gettare sospetti su di te e rendere le indagini molto più difficili.

Ma devi accedere a questo sito remoto come loro per vedere cosa stanno facendo in modo da poter verificare la loro conformità, quindi come fare puoi aggirare il problema senza avere le loro password?

Ci sono una serie di opzioni qui. Richiederanno tutti più lavoro di quello che stai facendo ora, ma dovrai accettarlo.

1. Scopri se il sito remoto offre spoofing dell'account o multiutente conti. In tal caso, dovrebbe essere possibile accedere alle stesse informazioni senza dover utilizzare le stesse credenziali. Il fornitore del sito o il client dovrebbe impostare un set aggiuntivo di credenziali solo per te con accesso per visualizzare i dati del cliente sul sito. Questo login sarebbe diverso dal login principale del client e la password per il login sarebbe solo tua, quindi non ci sarebbero problemi di archiviazione. Idealmente questo account per te avrebbe ridotto le autorizzazioni di sola lettura, per ridurre al minimo qualsiasi rischio di responsabilità per te stesso.

2. Discuti con il fornitore del sito remoto la possibilità che ti fornisca una copia offline dei dati pertinenti. Questo può essere sotto forma di un dump del database, un'API o un file di registro; qualunque cosa sia, non comporterebbe la necessità di accedere effettivamente all'account del cliente; potresti semplicemente richiedere l'ultima copia dei dati dal sito e rivederla per scoprire cosa vuoi sapere. Ovviamente questo dovrebbe essere concordato con il cliente, e se il fornitore del sito non ha queste strutture disponibili, potrebbe addebitarti il ​​lavoro per crearle, ma ti darebbe pieno accesso a ciò di cui hai bisogno, pur rimanendo isolato dal dover accedere al sito effettivo.

La FTC ha perseguito le aziende per tali cattive pratiche ( vedi sezioni 3 & 4), litigando contro di loro finanziariamente e pubblicamente svergognandole.

FTC ha anche il Regola di salvaguardia che fornisce alcune indicazioni (alcune pratiche tecniche di alto livello ma soprattutto procedurali). Sebbene si riferisca a organizzazioni finanziarie, la loro definizione è piuttosto ampia, in ogni caso un buon punto di partenza.