linee guida per i gestori di password

2

Uso Lastpass e sto testando altri gestori di password per impostare la politica per l'uso organizzativo. A seconda delle impostazioni, ho scoperto che questi programmi possono inviare automaticamente la tua password in luoghi imprevisti. Ad esempio:

Password Safe: la funzione "sfoglia per URL e autotype" di Password safe apre il browser predefinito, inserisce nome utente e password e genera un ritorno a capo! In IE e Chrome, questo si traduce in una ricerca sul Web con la mia password come termine di ricerca, trasmettendo la mia password in un posto inaspettato.

LastPass: Lastpass a volte ha problemi a distinguere tra "hr.company.com" e "testing-apps.hr.company.com". Ho abilitato l'accesso automatico per hr.company.com . Lastpass ha quindi provato ad accedere automaticamente a testing.hr.company.com e non è riuscito. Dal momento che stiamo testando, questo ha generato una voce del file di registro contenente le mie credenziali per hr.company.com . Mi ha costretto a cambiare rapidamente la mia password e rivalutare il mio utilizzo delle impostazioni di accesso automatico.

La mia domanda è questa: questi non possono essere gli unici esempi di utilizzo non sicuro dei gestori di password. Quali altri trucchi ci sono là fuori? Qualcuno può raccomandare linee guida per l'uso sicuro dei gestori di password in un'organizzazione?

    
posta mcgyver5 15.12.2014 - 18:45
fonte

2 risposte

3

I nomi host hr.company.com e testing-apps.hr.company.com non causeranno la corretta segregazione del modello di sicurezza del browser - è possibile che hr.company.com imposti cookie che possono essere letti da testing-apps.hr.company.com e testing-apps.hr.company.com sarà in grado di impostare i cookie su il dominio hr.company.com . Quindi devi fidarti sia di hr.company.com sia di testing-apps.hr.company.com per poter usare entrambi, quindi si potrebbe sostenere che LastPass accidentalmente completare i dettagli della password su una sola applicazione non è un grosso difetto: l'ambiente di test dovrebbe essere completamente dominio separato per prevenire eventuali vulnerabilità rilevate dall'esposizione del dominio attivo. Inoltre, le password non dovrebbero mai essere archiviate in file di log, quindi mentre potrebbe essere considerato un piccolo bug (forse dovrebbe richiedere prima di compilare un modulo su un sottodominio diverso), non è un enorme punto debole di sicurezza in sé stesso - l'applicazione web sottostante deve essere fidati, che include considerando il modello di sicurezza del browser. Potrebbe essere che testing-apps.hr.company.com sia disponibile solo internamente. tuttavia ciò potrebbe consentire a un utente malintenzionato locale di compromettere l'account live di un altro dipendente utilizzando un difetto nella versione di prova.

In questo caso puoi rendere questo particolare gestore di password più sicuro tramite la configurazione. per esempio. disabilitando il riempimento automatico, e c'è anche un'opzione nelle impostazioni denominate Regole URL . Qui puoi impostare se il nome host deve essere una corrispondenza esatta. Non puoi impedire alle persone di usare software in modo non sicuro, puoi solo guidarli ed educarli, come hai sottolineato.

My question is this: These can't be the only examples of unsafe use of password managers. What other gotchas are out there? Can anyone recommend guidelines for safe use of password managers in an organization?

Ci saranno dei difetti in tutte le applicazioni, a livello aziendale o meno. Il vantaggio dei gestori di password basati su browser è che è in grado di proteggere dagli attacchi di phishing. L'URL è convalidato e come impostazione predefinita verranno completate solo le credenziali salvate per quell'URL. Se questo è qualcosa su cui si vuole proteggere, sarà necessario utilizzare un gestore di password basato su browser. Se si utilizza un browser basato su un rischio troppo elevato, è possibile utilizzare un'applicazione separata, ma è necessario accettare che un utente inconsapevole acceda accidentalmente a un sito Web errato, che sia malevolo o meno, esponendo potenzialmente le proprie credenziali di accesso a un terzo partito.

Le linee guida specifiche saranno diverse a seconda del software utilizzato e di come vengono utilizzate le password all'interno dell'organizzazione, nonché dell'organizzazione stessa. Per esempio. l'organizzazione si fida del cloud o tutto è fatto in casa? Memorizzare i dati della password su server interni fidati potrebbe essere migliore, tuttavia l'organizzazione sta quindi assumendo il lavoro supplementare per assicurarsi che l'infrastruttura sia protetta in modo corretto e assicurare che i dati siano crittografati correttamente e le chiavi di crittografia siano archiviate in modo sicuro.

    
risposta data 16.12.2014 - 11:38
fonte
2

Gli strumenti di gestione delle password come Lastpass memorizzano i tuoi dati sui loro server, il che è ciò che li ha spinti a enorme vulnerabilità all'inizio di quest'anno . Anche se Lastpass può essere utile per le macchine basate sulla casa, i gestori di password aziendali esistono e dovrebbero risiedere nella tua infrastruttura. Ci saranno alcuni che discuteranno: "il cloud è altrettanto sicuro" a cui dirò: "le reti scendono ... se il tuo fornitore di cloud fallisce ... anche le tue password". In entrambi i casi, NIST ha SP800-118: Guida alla gestione delle password aziendali è in forma di bozza, ma dovrebbe dare qualche indicazione

    
risposta data 15.12.2014 - 23:06
fonte

Leggi altre domande sui tag