Domanda:
Come posso convincere il mio capo che memorizzare le password di terze parti in testo normale è una cattiva idea?
Selkie
2018-02-23 22:51:54 UTC
view on stackexchange narkive permalink

Mantenere le cose sul vago: lavoro in un'azienda che gestisce i problemi di conformità per i nostri clienti. Molto spesso, questo significa che dobbiamo accedere ai loro vari account per varie entità. Memorizziamo il loro nome utente e password, sia per renderli più facili da ricordare e avere accesso, sia per permetterci di accedere al loro account.

Ignorando per un minuto il completo e totale incubo della sicurezza della condivisione degli accessi, il nome utente e le password sembrano essere memorizzati in chiaro. Evviva.

Come posso convincere il mio capo, e i superiori, che A) Questa è un'idea terribile, B) un metodo / modo migliore per archiviarli

Perché dovresti accedere all'account dell'utente?Cosa stai cercando di ottenere accedendo all'account dell'utente?
Fare il lavoro di preparazione / compilare il modulo per loro.Ho combattuto anche questo ...
se non è _stored_ in chiaro (per un utente senza password) non è poi così male.l'archiviazione crittografata può essere trasparente e forse è quello che hai.IMHO dovresti ancora avere un'autenticazione su richiesta per accedere a tali informazioni su un sistema in uso.
Il nostro sistema ha un sistema di impersonificazione controllato in modo che tu possa accedere come qualcun altro pur essendo chiaro chi ha effettivamente eseguito l'azione anche se era a nome di qualcun altro (usiamo questo principalmente per vedere bug che richiedono esattamente i suoi dati per apparire).Potrebbe funzionare per la tua azienda?
Sì, se si tratta di sistemi interni dovresti essere in grado di eseguire azioni come un utente diverso se sei un amministratore.Molte persone usano la stessa password ovunque e si aspettano che nessuno sia in grado di vederla in testo normale.Usa hash e sale le tue password.
C'è sicuramente qualcosa di ironico in un'azienda che fornisce servizi di conformità che lascia cadere la palla in modo così palese.
Puoi darci un suggerimento sul tipo di sistema di cui stai parlando (ad esempio, di cosa stanno eseguendo i tuoi clienti, dove il tuo personale accede utilizzando le credenziali dei clienti)?Ad esempio, è Windows o qualche altro sistema closed-source con funzionalità limitate per la configurazione?Accesso shell a un sistema Unix / Linux, dove dovresti usare accessi ssh senza password basati su chiave e potresti essere in grado di configurare I&A con PAM?Un'applicazione web?Quanto puoi personalizzare le funzionalità di sicurezza di quel sistema?
È una pagina web a cui andiamo e accediamo.
"Stiamo facendo qualcosa di orribilmente sbagliato dal punto di vista della sicurezza?"Sì.Senza leggere il corpo della domanda, solo in linea di principio, se abbiamo imparato qualcosa dagli ultimi 20 anni circa, la risposta alla domanda posta nel titolo è quasi certamente sì, per qualsiasi valore di "noi" che è un'organizzazionenell'industria informatica.: P
Non vedo cosa c'è di così orribile nell'archiviare le password in testo normale?Confronta l'archiviazione delle password in testo normale su un computer non in rete archiviato in un vault con l'archiviazione delle password crittografate su una pagina Web pubblica con la passphrase comodamente memorizzata sulla stessa pagina.Qual è il peggiore?La cattiva pratica è qualunque cosa ti faccia avere bisogno della password in chiaro, non che tu memorizzi le password in chiaro.
@emory Che punto stai cercando di fare?Ovviamente memorizzare una password crittografata è meglio del testo in chiaro.Certo, con il tuo esempio artificioso, memorizzare in chiaro è meglio ma piuttosto irrilevante.
La crittografia @Confuzing non è polvere magica.Se la società dell'OP semplicemente crittografa il proprio elenco di password di terze parti, sarà comunque una cattiva idea.
Chiedi al tuo capo di creare un file di testo semplice con il codice account e la password per il suo conto bancario, quindi digli che memorizzerai la password sul Drive condiviso dell'azienda.Se non pensa che sia una brutta cosa da fare, allora davvero non lo capisce, perché qualcuno nell'elenco di email / password che hai in testo normale avrà la stessa identica email / password per il LORO conto bancario.
@RichardTingle: Per rispondere alla tua domanda, no, non possiamo usare un sistema di imitazione: stiamo accedendo a un sistema completamente diverso con il nome utente e le password (in realtà accediamo a circa 200 sistemi diversi - cercando di non rivelare troppo)
Dieci risposte:
#1
+75
user196499
2018-02-24 00:26:45 UTC
view on stackexchange narkive permalink

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)

Attualmente stiamo utilizzando il nostro software creato in casa per archiviare e tenere traccia di tutti questi elementi: esiste un gestore di password consolidato che potrei indicare alla direzione di prendere in considerazione (e lasciare che gli sviluppatori facciano il vero lavoro sul problema?)
Consiglierei 1password (https://1password.com) o LastPass (https://lastpass.com).Entrambi hanno una GUI e una cli per l'accesso automatizzato.
Suddividerei le opzioni in una GUI basata sul Web, una GUI basata su file locali.Il file CLI o basato sul web?O sono disponibili anche in entrambe le varietà?
@Selkie avrei inserito una presa per [Thycotic Secret Server] (https://thycotic.com/products/secret-server/).Esiste (o esisteva) una versione gratuita che ho usato per anni in un paio di datori di lavoro diversi e l'attuale datore di lavoro ha recentemente sborsato per passare a una licenza a pagamento.Bilancia bene, in sede, facile da usare e amministrare.
Non consiglierei un gestore di password per tali usi.Se il computer è compromesso, lo sono anche le password: non importa quale gestore viene utilizzato quando si verifica un attacco mirato (che sembra il caso più probabile in questa situazione).
@Naim - cos'altro consiglieresti per tali usi?Direi che questo uso è una pratica molto scarsa e non dovrebbero farlo affatto (utilizzando le password dei clienti per accedere come loro), ma se devono farlo in questo modo, se non un gestore di password, allora cosa?Password scritte a mano?Se un computer viene compromesso, qualsiasi password utilizzata su quel computer viene compromessa.
Un gestore di password consente comunque ai singoli utenti, che hanno accesso al gestore di password, di visualizzare le password.Invece il sistema dovrebbe essere completamente automatizzato, le password archiviate crittografate, decrittografate e passate dal sistema automatizzato quando necessario, senza che nessuno le visualizzi effettivamente.I gestori di password basati su cloud ti aprono anche a un intero carico di responsabilità extra lasciando queste password fuori dalla tua azienda, anche se crittografate.Se hai intenzione di utilizzare un gestore di password, usane almeno uno locale come KeePass.
@SeanBurton Esistono gestori di password aziendali, come quello che ho collegato, che hanno queste caratteristiche e sono molto superiori (per usi multiutente e funzioni aziendali) a un vault password personale come KeePass o whathaveyou.
@HopelessN00b Sono sicuro che vanno bene per memorizzare le password dei tuoi dipendenti, ma se stai archiviando le password di qualcun altro sarei molto cauto nel trasmetterle a terzi senza previa approvazione o almeno passandole davanti ai tuoi avvocati ...
@SeanBurton Ancora una volta, è una configurazione del server in sede, non un cloud qualunque.(e non è l'unico) Il punto è che esiste un'intera classe di prodotti per la gestione delle password aziendali che potrebbero soddisfare le esigenze dell'OP.(Anche se, onestamente, quasi tutto è un passo nella giusta direzione, considerando quello che stanno facendo ora.)
Abbastanza giusto, il mio punto principale era semplicemente non usare quelli basati su cloud off-premise (lastpass, ecc.), Se sono on-premise, suonano come una buona opzione.
#2
+34
symcbean
2018-02-23 23:10:32 UTC
view on stackexchange narkive permalink

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.

Abbastanza giusto - mi chiedevo se ci fosse qualcosa come "Sì, crittografa le password usando X, quindi hai la possibilità di spostare le password negli appunti senza vederle", un po 'come un gestore di password.
Bene, ma potresti definire un possibile approccio migliore?
Se si utilizza SQL Server per l'archiviazione dei dati, è possibile utilizzare la funzionalità di crittografia delle colonne del database.Non ricordo da quale versione è stata aggiunta la crittografia dei dati al server SQL, ma potrebbe essere quello che stai cercando.
A proposito, abbiamo implementato una soluzione per questi casi.Un utente può "delegare" il proprio ruolo di account a un altro utente per un intervallo di date specifico.Quando hai bisogno di vedere cosa sta vedendo l'utente, chiedi all'utente di delegare il suo account a te.Accedi con le tue credenziali e il sistema ti consente di scegliere di accedere come te stesso o con l'altro utente.Se selezioni l'altro utente, la tua sessione avrà tutti i permessi dell'altro utente tranne alcune pagine.Utilizzando questa funzione, non è necessario accedere alle password di altri utenti, quindi è possibile effettivamente eseguire correttamente l'hashing delle password e allontanarsi dalle password in testo normale
"l'utilizzo di un server SQL" o qualsiasi altro sistema di gestione del database non risolve il problema del controllo e dell'audit degli accessi.Gettare la crittografia nel mix aggiunge complicazioni.
Esistono diversi prodotti open source che potrebbero essere appropriati: mi vengono in mente passbolt, teampass, Vaultier.Esistono anche soluzioni commerciali come il cyberark
#3
+21
CJ Dennis
2018-02-24 08:23:42 UTC
view on stackexchange narkive permalink

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.

La tua ultima frase dovrebbe essere davvero la prima.
#4
+8
JimmyJames
2018-02-24 04:12:40 UTC
view on stackexchange narkive permalink

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.

#5
+6
Bergi
2018-02-24 03:54:26 UTC
view on stackexchange narkive permalink

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 1 , 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.

Sono d'accordo che non puoi eseguirne l'hashing, ma non vedo alcun motivo per cui non puoi crittografarli.
@JonBentley Intendevo "crittografare in modo da non poterlo decrittare da soli".Se tieni vicini i dati crittografati e la chiave di decrittazione, non aiuta molto.Vedi anche la nota a piè di pagina.Come posso esprimerlo meglio?
Come non c'è modo di aggirarlo?Può esserci un sistema che elude completamente il processo di accesso utilizzando più misure di sicurezza come: (i) un URL personalizzato per l'accesso, (ii) e-mail di conferma inviata a account e-mail affidabili, (iii) necessità di una password principale.In questo modo puoi fare in modo che i membri dell'assistenza accedano agli account dei clienti per ricevere assistenza.
@hakermania: Puoi approfondire il tuo riferimento a una "password principale"?ISTM che memorizzare una password principale è altrettanto dannoso quanto memorizzare un gruppo di password individuali e modificare un sistema per * accettare * una password principale rende il sistema meno sicuro.
@Scott sì, sono d'accordo con te.Non dico che dovrebbe esserci una password principale per tutti gli account!Dico solo che può essere utilizzato in combinazione con i miei altri 2 punti in modo da avere un'implementazione sicura
@hakermania Capisco che la società OP ha bisogno di accedere ai conti dei propri clienti su sistemi stranieri.Supponendo che quei sistemi esterni non supportino l'accesso da parte di terzi, le credenziali dell'utente devono essere utilizzate nel normale login.(Ovviamente quando c'è un'API per l'accesso di terze parti, quella dovrebbe essere usata).Non capisco cosa intendi per "URL personalizzato + email attendibile + password principale".
@Bergi hai ragione Ho letto male la domanda e ho pensato che OP stesse parlando dei clienti del loro sito web
La password principale non deve essere memorizzata;può essere reinserito ogni volta che qualcuno vuole accedere alle password.Per lo meno, può essere memorizzato in una forma separata.Quindi, ad esempio, le password potrebbero essere memorizzate su un server mentre la password principale è memorizzata in una chiavetta USB.Non infallibile, ma almeno un altro punto di errore.
"ma alla fine la chiave per farlo deve risiedere da qualche parte sul tuo server" - Non penso che questo sia del tutto vero.Qualche tipo di token di sicurezza hardware (come uno yubikey, ma qualcos'altro potrebbe essere migliore) potrebbe avere la chiave di decrittazione e fornire una sicurezza molto migliore, a seconda dei vincoli.
@Accumulation chi controlla la chiavetta USB (presumo) e chi ha bisogno delle password (presumo tu)?e se avessi bisogno di lavorare durante i fine settimana ma io non voglio.finirò per lasciare la chiave collegata al server (nessun vantaggio reale nel metterla su una chiavetta rimovibile)?o creerò una copia decrittografata per te (nessun vantaggio reale per la crittografia)?o ti darò una chiavetta USB (più chiavi significa che è più facile perderne una)?Se una singola credenziale costa 64Kb, una chiavetta da 64Gb dovrebbe contenere 8.000.000 di utenti ... perché non metterli tutti sulla chiavetta e non sul server?
@IanD.Scott lo yubikey è bello, ma non vedo come potrebbe aiutare il problema dell'OP.In realtà interromperebbe gli affari dell'OP.ad esempio, sono un utente.Ho stupidamente fornito a OP le mie credenziali nome utente / password in modo che OP potesse compilare alcuni moduli per me.Più tardi mi iscrivo a yubikey.Ora, quando OP cerca di accedere al mio account per compilare i moduli, sfida OP per lo yubikey.
@emory Lo yubikey può fare diverse cose;incluso gpg.Crittografa le password con gpg ('pass' fa questo) e usa la chiave di decrittazione su yubikey.
Alcuni siti web utilizzano i cookie per evitare di chiedere all'utente di inserire la propria password troppo spesso.Mi chiedo se l'ottenimento di un cookie di accesso dal client dopo il login possa effettivamente consentire all'azienda dell'OP di accedere al sito Web senza dover conoscere la password del cliente.
@LucaCiti Sì, questo è il * token di sessione * di cui parlavo.Tuttavia, dal punto di vista dell'usabilità non è possibile chiedere a un utente di aprire devtools e cercare il valore di un cookie.
#6
+5
Tom
2018-02-26 14:01:27 UTC
view on stackexchange narkive permalink

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.

È facile spiegare che esiste un rischio, che le conseguenze potrebbero essere gravi e che questo rischio potrebbe essere facilmente mitigato.Ma dare una valutazione precisa (10% all'anno) è molto più difficile.La risposta potrebbe essere: * lo facciamo da 5 anni e ancora nessun problema, quindi la tua valutazione non ha senso *.
Una ** stima ** della probabilità è una necessità assoluta per stimare il rischio.Ovviamente è una stima, ma dovresti almeno essere in grado di dare un intervallo.Se aiuta, puoi invertirlo e indicare non% all'anno ma MTBF - ogni quanti anni ti aspetti che ciò accada?
In secondo luogo, il "non è successo niente di male finora" è un errore comune.È esattamente il pensiero che le persone avevano a Tchernobyl il giorno prima che esplodesse.Se ci si aspetta che succeda qualcosa ogni 5 anni e hai passato 5 anni senza, è tempo di innervosirti perché sei in ritardo.La risposta corretta, tuttavia, è che puoi utilizzare questi dati per rivedere la tua stima.
In caso di violazione, il capo di OP in questo ordine (1) non ne sarà a conoscenza, (2) minimizzerà il suo impatto, (3) acquisterà il monitoraggio del credito, (4) dichiarerà fallimento.C'è una probabilità del 90% che non superi la fase 1. È estremamente improbabile che superi la fase 2. Nel peggiore dei casi, la fase 4, i presidi non saranno materialmente interessati.
Penso che se vuoi fare un business case, dovresti fornire una stima delle dimensioni del mercato che si rifiuterebbe semplicemente di darti le loro credenziali (ad esempio, io).La società di OP sta semplicemente buttando via il segmento del mercato che non sono idioti della sicurezza.Ciò, tuttavia, richiederebbe una completa rielaborazione del processo.
#7
+3
Criggie
2018-02-24 05:32:47 UTC
view on stackexchange narkive permalink

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/

#8
+1
AnoE
2018-02-25 16:54:43 UTC
view on stackexchange narkive permalink

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.

Non c'è [niente di sbagliato nello scrivere le password] (https://www.schneier.com/blog/archives/2005/06/write_down_your.html) se le conservi in un luogo sicuro.
@Bergi, bene, OP ha detto che lo fanno in un luogo non sicuro e non crittografato.Ma ho rimosso due parole per rendere perfettamente chiaro che la mia risposta non riguarda affatto questo, ma l'aspetto della "condivisione dell'identità".E mi attengo fermamente alla proposta secondo cui non è corretto fornire password collegate a veri identità, indipendentemente da dove vengono archiviate le PW.
#9
-1
Simba
2018-02-26 19:32:01 UTC
view on stackexchange narkive permalink

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.

"responsabilità" è coperto dalla risposta più votata
"clienti persi" è coperto anche da un'altra risposta
Il tuo suggerimento n. 1 non è comune e, dato che sembrano esserci molte entità, non è una soluzione scalabile.Il tuo suggerimento n. 2 potrebbe essere peggiore del conoscere la password, a seconda del contenuto dei dati.
@schroeder - # 2 sarebbe solo peggio se tutte le parti coinvolte fossero incompetenti.Dovrebbe fornire al massimo esattamente gli stessi dati visibili accedendo;niente di più e preferibilmente di meno, per coprire solo ciò che è effettivamente necessario.Se il venditore ti invia un dump dell'intero DB, allora sì, questo è un problema più grande, ma si spera che il venditore sappia meglio che farlo e la società dell'OP saprebbe meglio che chiederlo.
Inoltre, "* sembra che ci siano molte entità *" ... in realtà, ho letto il commento dell'OP per indicare che c'era solo un'entità di terze parti coinvolta;ha detto * "È una pagina web a cui andiamo e accediamo" *.Se è singolare come l'ho letto, allora queste soluzioni dovrebbero essere perfettamente funzionanti.Anche se si tratta di un numero limitato di siti, dovrebbe essere fattibile.Sì, non si ridimensionerà bene se si tratta di un gran numero di siti e di siti diversi per ogni client, ma non è così che lo legge.
"Dobbiamo accedere ai loro vari account per varie entità" il commento a cui fai riferimento è in risposta al tipo di sistema, il che significa che usare il singolare va bene per riferirsi a un * tipo * di sistema.Non credo che tu possa sostituire il contenuto del post principale con il commento.
#10
-2
HTLee
2018-02-26 20:06:24 UTC
view on stackexchange narkive permalink

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.

il tuo primo collegamento non si applica alla situazione dell'OP se le password sono archiviate e trasmesse in modo sicuro
anche il tuo secondo collegamento non sembra essere applicabile
Primo collegamento aggiornato in modo che comprenda un problema più ampio di archiviazione sicura (cioè non testo normale).Il secondo collegamento si riferisce alla memorizzazione di informazioni sensibili (che possiamo utilizzare per includere le informazioni sull'account) che dovrebbero essere salvaguardate.cc @schroeder
Ho letto quelle sezioni e ancora non si applicano.Ti stai allungando per cercare di adattare qualcosa.Posso soddisfare questi requisiti utilizzando la crittografia completa del disco.Sì, l'OP si trova in una situazione negativa, tuttavia questi collegamenti non sono utili come suggerimenti per un'azione migliore.
Oltre ai punti di Schroeder, questo è applicabile solo se l'OP è negli Stati Uniti.Qualcosa che non credo sappiamo.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...