Come posso convincere il mio capo che la memorizzazione di password di terze parti in testo semplice è una cattiva idea?

Perché è una pessima idea?

Registrando le credenziali di accesso degli altri, la società si assume una responsabilità . Poiché la società è ora responsabile della malizia che potrebbe verificarsi utilizzando tali credenziali, la società 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 gli affari se un incidente diventa pubblico (come menzionato da symbbean)

L'archiviazione delle password in testo semplice (come sai) non fornisce alcuna protezione contro tale rischio.

Qual è una soluzione migliore?

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

Dato che c'è molto margine di errore quando si parla di crittografia, suggerisco di utilizzare un gestore di password stabilito. Puoi trovare infiniti paragoni online, ma alla fine le tue scelte includono quelle basate su una GUI (come 1password, LastPass, keepass, ecc.) O una basata su un cli per l'accesso automatico (come pass o tramite il cli LastPass)

Sì, stai facendo qualcosa di terribilmente sbagliato. Che il tuo datore di lavoro sembra specializzarsi in conformità lo rende molto, MOLTO peggio. L'attività della società si basa sulla reputazione di eccellenza nella conformità che stai calpestando attivamente.

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

• è stato detto che memorizzi le loro credenziali in testo non crittografato (presumibilmente senza alcun controllo di revisione / controllo sull'uso)
• hanno letto sul giornale che un altro cliente era stato compromesso in seguito a questa pratica

Per quanto riguarda l'approccio migliore ... vorresti davvero l'approccio giusto , bilanciando riservatezza, integrità, disponibilità e budget. Ci sono prodotti commerciali e open source che potrebbero aiutare in questo, ma avrebbe bisogno di molte più indagini e analisi di quanto sia appropriato 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 vengono facilmente condivise, perdendo la responsabilità, ovvero come fai a sapere che era l'utente e non qualcun altro a utilizzare il proprio account?
• Se viene aggiornata una password (ad esempio viene scoperto un agente non valido e si desidera impedire ulteriori accessi), deve essere aggiornato ovunque sia utilizzato

Queste sono alcune opzioni, suddivise per scenario:

1. Se i sistemi che stai utilizzando sono tuoi e vengono mantenuti attivamente, puoi chiedere una funzione di spoofing degli utenti. Ogni persona con accesso amministratore accede con il proprio account amministratore che è autorizzato a passare all'account di qualsiasi utente di base senza conoscere la propria password. In questo modo, hai un auditing migliore. Si può vedere che non era l'utente reale a compiere le azioni, ma l'utente amministratore specifico che ha spoofing 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 provare che l'utente ha la password di amministratore o che l'amministratore ha la password dell'utente e sta usando il proprio account direttamente.

   • Hai solo la conoscenza della tua password e non puoi scoprire la password di nessun altro utente, anche se minacciata (un buon schema di hashing impiega in media centinaia di anni per infrangere una password, in media)
   • Sei responsabile solo delle tue azioni, non di tutti gli altri
   • Se la password di un utente viene aggiornata, non influisce su di te perché non cambia la modalità di accesso al proprio account

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

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

Ricorda che 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. Al suo posto viene invece memorizzato un hash irreversibile .

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

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

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

Se hai bisogno di accedere a un account straniero di qualcun altro, hai bisogno del suo nome utente e password. Non c'è modo di aggirare questo. Non puoi hash o criptare ¹ , hai bisogno dei valori semplici.

Ovviamente è un incubo, poiché gli utenti devono rivelare le proprie credenziali. Si fidano che non li stai abusando. Supponendo che non li stai intenzionalmente abusando (come venderli sul mercato nero come parte del tuo modello di business), devi evitare la perdita. Ciò include le violazioni dei dati nell'infrastruttura o gli amministratori del database che possono accedervi. Pertanto, la best practice qui dovrebbe non memorizzarli affatto . Il business delle aziende è di aiutare l'utente a compilare moduli, non fornendo un servizio di gestione password. Per " rendere più facile per [gli utenti] ricordare " le loro credenziali non è il tuo lavoro.

Una soluzione potrebbe essere quella di scrivere un'estensione del browser per l'installazione da parte degli utenti. Accedono a questi account stranieri da soli, sulla loro macchina, e il tuo plugin fa il suo lavoro lì. Il tuo server non entra mai in contatto con le credenziali. (Ovviamente l'utente deve ancora fidarsi dell'estensione per non spiarli).

Se questa non è un'opzione e il lavoro, incluso il login, deve essere fatto sul tuo server, allora non dovresti ancora 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'autore dell'attacco 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 effettuare il login più volte.

_{1: Naturalmente dovresti criptare sempre tutti i dati sensibili quando li memorizzi ovunque, ma alla fine la chiave deve risiedere da qualche parte sul tuo server, a cui un presunto hacker potrebbe guadagnare accesso pure.}

I manager parlano la lingua degli affari, non la tecnologia.

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

Oltre ai potenziali danni derivanti da reclami contrattuali nei confronti dell'utente da parte delle aziende clienti, è necessario considerare anche le responsabilità civili e penali dovute a negligenza grave. Una possibilità di andare in prigione è un'altra cosa che tende ad attirare l'attenzione del manager.

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

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

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

Dovresti anche avere un criterio di gestione delle password che documenta come vengono gestite le password e contiene le sanzioni per violarlo. I filtri Egress potrebbero impedire un disastro e-mail.

Sì, la memorizzazione delle password in chiaro è stupida. Abbiamo persino mandato uno staffer a spedire per errore tutte le password "memorizzate" a una lista di distribuzione interna in un incidente di copia-incolla. Fortunatamente nessun cliente era nella lista.

Quindi ci siamo spostati sull'uso di Teampass che funziona molto bene come database centralizzato di informazioni sulla password.

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

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

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

link

Un altro angolo tranne l'ovvio (che già conosci, come mostri nella domanda - la memorizzazione di password non criptate è sbagliata):

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

Se fossi il tuo cliente, e il tuo datore di lavoro mi ha chiesto una password, vorrei a) non dartelo e b) correre alla mia gestione abbastanza rapidamente. Vorrei davvero fare in modo che non fossimo il tuo cliente in qualsiasi momento.

Non ho nemmeno dato la mia password ai miei ragazzi di supporto (nel caso improbabile che abbiano bisogno di me per accedere a loro durante una sessione di supporto, lo farò anch'io). Sono stato sul lato ricevente dei controlli di sicurezza (per sistemi e / o applicazioni) e mai è stato passato alcun account utente reale alla società di sicurezza. Se hanno bisogno di accedere, stanno ottenendo i propri account temporanei. Ho chiesto ai clienti di dirmi la loro password e sono abbastanza sicuro di interromperli immediatamente e chiedergli di digitarli da soli.

TL; DR: Sentiti libero di mostrare alla tua gestione questa risposta - Sarei un cliente perso per te.

La migliore risposta è di non avere o utilizzare le credenziali del cliente. L'atto di chiederli al tuo cliente è un enorme no-no di sicurezza, e dovrebbe portare bandiere rosse per chiunque nei tuoi clienti che abbia qualche tipo di conoscenza della sicurezza.

In realtà, direi che il tuo fare probabilmente sta perdendo la tua attività già tra potenziali clienti che hanno un qualche tipo di politica di sicurezza. Il mio datore di lavoro ha una politica rigorosa in materia di password e sarebbe probabilmente considerato motivo di licenziamento per me condividere con voi una qualsiasi delle nostre password.

Un altro fattore davvero importante che nessun altro ha toccato è la responsabilità. Condividendo una password con te, il cliente si è aperto a potenziali problemi se l'account è stato utilizzato in modo improprio. Un dipendente canaglia all'interno dell'azienda può essere il colpevole, ma se la password è stata condivisa, si 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 fai a spostarti senza avere le loro password?

Ci sono un certo numero di opzioni qui. Avranno tutti bisogno di più lavoro di quello che stai facendo ora, ma dovrai accettarlo.

1. Scopri se il sito remoto offre spoofing dell'account o account multiutente. In tal caso, dovrebbe essere possibile accedere alle stesse informazioni senza utilizzare le stesse credenziali. Il fornitore del sito o il cliente devono 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 l'accesso sarebbe solo la 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. Discutere con il fornitore del sito remoto la possibilità che forniscano una copia offline dei dati rilevanti. Questo può essere sotto forma di un dump del database o di un'API o di un file di registro; qualunque esso sia, non implicherebbe la necessità di accedere effettivamente all'account del cliente; potresti semplicemente richiedere l'ultima copia dei dati dal sito e rivederli per scoprire cosa vuoi sapere. Questo ovviamente dovrebbe essere concordato con il cliente, e se il venditore del sito non ha queste strutture disponibili, potrebbe addebitarti il lavoro per crearle, ma ti darebbe pieno accesso a ciò che ti serve, pur rimanendo isolato dal dover accedere al sito reale.

La FTC ha inseguito le aziende per tali cattive pratiche ( vedere le sezioni 3 & 4 ), contendendoli contro di loro finanziariamente e pubblicamente shaming loro.

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