Cosa succede se il client ha bisogno della capacità di recuperare le password?

Al momento ho ereditato un'applicazione al lavoro e, con mio grande sgomento, mi sono reso conto che le password dell'utente archiviate nel database sono crittografate utilizzando una funzione di crittografia interna, che include anche la possibilità di decrittografare.

Quindi tutto ciò che qualcuno deve veramente fare è copiare la tabella utente e copiare l'assembly di crittografia (chiunque abbia accesso alla produzione del database) e quindi avrebbero accesso a 100.000 indirizzi e-mail e potenziali password per loro.

Sto cercando di spiegare al business perché questa non è una buona idea, ma i concetti di sicurezza sembrano andare oltre la testa perché non sono così tecnicamente orientati (è per il governo). Inoltre ci sono funzionalità esistenti all'interno dell'applicazione per consentire agli utenti amministratori di recuperare le password degli utenti al fine di accedere come loro e fare cose (che hanno detto, che richiedono).

Quindi non comprendono le implicazioni per la sicurezza. E al fine di implementare una politica di sicurezza più forte (password di hashing in modo che non possano essere facilmente recuperate), devo rimuovere le funzionalità esistenti per loro.

Cosa dovrei fare? Non ho creato il sistema di password in primo luogo, quindi non è come se potessi essere incolpato se qualcosa va storto. D'altra parte, non mi sento bene e non voglio avere accesso a 100.000 potenziali accessi e-mail.

Implementa le funzionalità di cui hanno bisogno in modo sicuro. Gli amministratori che accedono come un altro utente possono essere implementati senza che siano a conoscenza della password dell'utente. Possono accedere come se stessi e quindi avere a disposizione una funzione di "modifica identità".

La protezione di un database di password non è un problema aziendale, è un problema tecnico. Non farlo è un bug. Se l'azienda considera la sicurezza come un compromesso di funzionalità, la sicurezza perderà. Non dovresti dare loro alcun motivo per pensarlo in questo modo.

Devi convincerli che in realtà non hanno bisogno di essere responsabili civili nel caso in cui il loro server venga rotto. Né hanno bisogno del contraccolpo da una base di utenti informata che si rende conto di essere negligente.

A volte ci sono casi chiari in cui una parte ha torto e l'altra ha ragione. Questa è una di quelle volte.

Guarda cosa è appena successo a Sony. Inoltre, il nostro sito è stato hackerato di recente e una delle cose che ha impedito che si trattasse di un disastro non mitigato è che abbiamo usato una (relativamente) buona funzione di hashing unidirezionale (SHA512). Da allora siamo passati a bcrypt per prevenire persino attacchi di forza bruta / dizionario (o almeno renderli insostenibili). Semplicemente non trovo nient'altro che sia conscionabile.

Fatto: le persone usano la stessa password su molti siti

Il tuo capo probabilmente non si rende conto che le persone usano spesso una singola password (o un set molto limitato di esse) per tutti i tipi di servizi (incluso bancario o Facebook e simili). Se gli utenti possono modificare la propria password nel proprio sistema, è molto probabile che utilizzino la stessa password utilizzata altrove.

Se il tuo capo pensa che questo accesso con password non sia un problema, dovresti anche dirglielo e forse inizieranno a pensare diversamente. Anche se l'app è nascosta e non accessibile pubblicamente, può rappresentare una minaccia per la sicurezza di altri servizi online. I nomi utente (specialmente quando sono e-mail) sono piuttosto facili da indovinare. Non riesco a immaginare quanto sarebbe divertente accedere all'account Facebook del boss e mettere qualcosa sulla loro bacheca.

Le password degli utenti devono essere sempre trattate come informazioni riservate / riservate di massimo livello a cui solo un numero limitato di persone ha accesso. È meglio evitare di archiviare tali informazioni volatili. E anche quando lo fai, ti dovrebbe essere concesso ogni singolo accesso a queste informazioni. Come ottenere un documento riservato da una cassaforte altamente sicura che può essere aperta solo con più chiavi. Quindi le persone sanno a chi è stato concesso l'accesso e quando.

Come implementare la delega dell'account

La delega dell'account nella domanda deve essere eseguita in modo diverso.

1. Gli amministratori devono accedere come se stessi e quindi
2. o (poiché sono utenti privilegiati)
   • inserisci solo UserName o
   • selezionare un determinato utente da un elenco per accedere come tali

Non dovrebbe assolutamente essere fatto accedendo con la combinazione UserName + Password .

È vero che il nuovo schermo dovrebbe essere sviluppato per consentire l'accesso delegato, ma comunque.

Perché l'accesso delegato è migliore?

Potresti anche fornire funzionalità aggiuntive che chiarirebbero che alcune azioni sono state fatte dall'amministratore per conto di alcuni utenti (cosa che non puoi sapere ora perché gli amministratori agiscono come dei e fanno il login come chiunque e potrebbero fare cose che possono ferire reale reputazione dei dipendenti).

Devi essere d'accordo sul fatto che le persone commettono errori. Anche gli amministratori sono persone. E se commettono un errore per conto di qualcun altro, cercheranno di biasimarli. Ne sono sicuro al 100%. Ciò renderà più sicuro per gli utenti non amministratori, quindi la loro reputazione nel mondo reale non soffrirà di errori altrui.

Non dici cosa fa l'applicazione. Se si tratta di applicazioni per passaporti, piene di informazioni sul furto di identità che devono essere protette, merita la massima protezione. Ma se è "dimmi gli incidenti stradali sul mio percorso verso casa" quali sono le conseguenze di una violazione della password? Alcuni sistemi che ho scritto non hanno nemmeno password: inserisci semplicemente la tua e-mail o il tuo numero di studente o qualche altro identificatore che le persone spesso conoscono l'uno sull'altro, ei proprietari del sistema apprezzano la facilità d'uso e l'incapacità di essere bloccati sulla possibile violazione della privacy se le persone si impersonano a vicenda. Non ho problemi con questo, neanche. Perché ho bisogno di una password per impostare il mio programma di sessioni preferite in una conferenza, ad esempio?

Quindi, se venissi portato per la revisione del codice e tu me lo avessi segnalato, è da lì che inizieremmo. Cosa stai proteggendo? Quali sono le conseguenze negative di una persona che riesce ad accedere come un'altra persona? Quali sono le conseguenze negative dell'esposizione dei dati archiviati da tutti? Forse sono orribili. Li elencheresti per me. Quindi, quali sono le conseguenze del fatto che le persone non sono in grado di fare clic su "inviami la mia password" ma devono invece fare clic su "Reimposta la mia password"? Smetterebbero di usare il sito? E lo staff che accede come persona? Ciò consente di risparmiare tempo, denaro, vendite perse o cosa?

Il pezzo finale della storia di costi / benefici, e quello a cui arrivi solo se c'è una differenza davvero grande tra i negativi a cui sei esposto ora e quelli negativi che otterrai quando rimuovi la funzionalità, è il costo per risolverlo. Spenderei un milione per risparmiarmi la possibilità di un'esposizione da mille dollari? No. E il contrario? Dipende dalle probabilità, immagino, ma la mia prima risposta sarebbe sì.

ps - il governo canadese è andato in diretta con un sito per richiedere il passaporto che aveva ID nell'URL: se hai modificato l'URL con un ID diverso, hai visto la forma compilata per metà di qualche altro cittadino casuale. E ho clienti che accedono come loro clienti ai fini del servizio clienti per la felicità generale, quindi vedo il lato positivo di esso, anche se non lo sopporterei se i dati dietro la password fossero effettivamente importanti per gli estranei.

Potrebbe essere contro la legge e potrebbe aprirli per essere citati in giudizio. Se vengono conservate informazioni personali sull'utente o se il sistema interagisce con altri sistemi in quanto l'utente, potrebbe essere necessario verificare se il sistema rientra in una delle leggi o leggi sulla privacy statali o federali. vale a dire. Sarbanes / Oxley, California OOPA, ecc.

A parte i potenziali problemi legali, puoi anche sottolineare che qualsiasi amministratore può in qualsiasi momento scaricare l'intero tavolo su un dispositivo portatile portatile e lasciare con la possibilità di accedere come qualsiasi utente e causare il caos o vendere i dati.

Anche se si presume che tutti gli amministratori siano affidabili, ciò rende devastante anche il compromesso di una password dell'amministratore.

Inoltre non è necessaria la password di un utente per eseguire le operazioni come tali. È possibile implementare una sudofunzione simile.

Questo non può essere un sistema del governo federale poiché i requisiti FIPS e FISMA proibirebbero la crittografia reversibile per le password e il dipartimento padre le schiaffeggerebbe sulla luna.

E al fine di implementare una politica di sicurezza più forte (password di hashing in modo che non possano essere facilmente recuperate), devo rimuovere le funzionalità esistenti per loro.

Per la mia azienda precedente, ho continuato a lottare per la possibilità di inviare e-mail di reimpostazione della password per aggirare questo problema. E continuavo a essere annullato. Alla fine, mi sono stancato di spalare la cacca contro la marea, quindi me ne sono andato. Questo era anche un capo dai capelli a punta che pensava che le stupide domande poste da alcuni siti Web bancari fossero considerate "autenticazione a 2 fattori". Discutere con lui era come un cartone animato di Dilbert (aveva la forma del PHB).

Inoltre ci sono funzionalità esistenti all'interno dell'applicazione per consentire agli utenti amministratori di recuperare le password degli utenti al fine di accedere come loro e fare cose (che hanno detto, che richiedono).

L'ho visto implementato in un istituto finanziario. Le persone nell'area dell'assistenza clienti accederanno con le proprie credenziali e, se avessero i diritti per farlo, potrebbero fingere di accedere come cliente. Ciò non li ha registrati come cliente, ma solo come il cliente . In questo modo se il rappresentante del servizio clienti decidesse di prelevare denaro, non verrà mostrato come il cliente lo fa nei registri: mostrerebbe al rappresentante del servizio clienti che tenta di farlo (oltre a inviare un avviso per farli licenziare non appena il rentacop potrebbe arrivare al loro piano).

Fatto male, renderebbe il personale dell'assistenza clienti in grado di far apparire l'utente finale impegnato in qualche attività che potrebbe comportare gravi responsabilità finanziarie o legali.

L'ultimo sito Web federale su cui ho lavorato ha raccolto 1/4 miliardi di dollari all'anno dagli utenti finali (di cui c'erano circa 400 utenti), quindi la registrazione doveva essere molto rigorosa e che solo l'utente finale autorizzato poteva toccare le pagine web in cui hanno segnalato le cose su cui hanno pagato le accise.

Sony è stata una delle aziende con l'ultima violazione della sicurezza. Non era solo la rete PS3, era anche la loro rete di giochi MMORPG, che ammontava a un totale di 25.000.000 di nomi, indirizzi, numeri di carte di credito, nomi utente e password. Puoi credere che non sono affatto felice (voglio il mio evercrack!).

Mi riferisco al Codice Etico di ingegneria del software su preoccupazioni come questa. La mia interpretazione, la tua prima priorità non è quella di minare l'interesse pubblico (non come nella possibilità di password compromessa più come questo esempio qui in cui una società ha modificato i laptop Dell in modo che la società di noleggio possa spiare i propri affittuari a loro insaputa). Dopodiché la tua responsabilità è quella di INFORMARE il tuo cliente sui potenziali rischi e lasciarlo prendere in considerazione. Ovviamente questa è la base minima. Devi usare il tuo giudizio se ritieni che questo sia ancora più di quello che puoi stare in piedi e consentire.

Ovviamente quando menzioni un progetto governativo, se le informazioni private dei cittadini sono a rischio a causa di queste pratiche, allora stanno minando l'interesse pubblico.

Puoi stampare l'elenco di e-mail e password decrittografate e metterlo sulla scrivania del tuo capo, con un grande avviso sulla copertina: "Riservato"

Rendi il carattere minuscolo per non sprecare carta però.

Puoi anche mostrare loro come bugzilla consente agli amministratori di impersonare le persone senza usare la loro password.

Prima di tutto, sono d'accordo con le altre risposte sottolineando che è molto più sicuro evitarlo e archiviare solo hash di password, non le password stesse o tutto ciò che può essere trasformato in una password.

Ci sono momenti, tuttavia, in cui è più o meno necessario consentire il recupero. Nel caso delle password, in genere si desidera ripristinare semplicemente consentendo a un amministratore di modificare la password quando / se necessario anziché ripristinare la password esistente.

Un'altra possibilità, tuttavia, è quella di consentire all'utente di archiviare dati sul server crittografati con la propria password. In questo caso, consentire semplicemente a un amministratore di modificare la password non è sufficiente. La nuova password non funzionerà per decrittografare i dati e la maggior parte degli utenti troverà inaccettabile che tutti i loro dati crittografati diventino inaccessibili quando / se dimenticano / perdono una password. Per questa situazione, esiste un'alternativa che è ragionevolmente sicura e consente comunque il ripristino quando è realmente necessario.

Invece di utilizzare la password dell'utente per crittografare i dati, si crea una chiave casuale per crittografare i dati stessi. Quindi archiviare quella chiave, in un paio di posizioni: una volta crittografata con la password dell'utente e in un'altra posizione crittografata con una password dell'amministratore. Quindi quando (non proprio se) l'utente perde la propria password e non può più accedere direttamente ai dati, è possibile utilizzare la password dell'amministratore per decrittografare la chiave reale e utilizzarla per recuperare i dati e / o crittografare nuovamente la chiave con la nuova password dell'utente.

Se non vuoi fidarti completamente di un singolo amministratore, puoi gestirlo anche tu. Ad esempio, puoi decidere che 5 persone disporranno delle chiavi di amministratore e desideri che almeno tre di esse siano d'accordo prima che una chiave possa essere recuperata. In questo caso, quando memorizzi la password crittografata per scopi amministrativi, la memorizzi più volte, una volta ciascuna per ciascuna serie di tre dei cinque amministratori (che non occupa molto spazio, poiché stai memorizzando solo più chiavi , a ~ 256 bit ciascuno, non più copie dei dati). Ognuna di quelle copie viene successivamente crittografata con (gli hash di) ciascuna delle password per quei tre amministratori.

Per decrittografarlo, devi identificare i tre amministratori che stanno inserendo le loro password e scegliere la chiave crittografata appropriata per quel set di tre, quindi decrittografare utilizzando ciascuna delle tre password per ottenere finalmente la chiave originale. Puoi quindi usarlo per recuperare i dati stessi, oppure puoi semplicemente crittografarli nuovamente con (hash of) la nuova password dell'utente in modo che possano ancora accedere ai loro dati.

Quando si esegue questa operazione, però, è davvero necessario utilizzare un algoritmo standard di crittografia, e (da una forte preferenza) uno standard, ben noto, accuratamente studiato implementazione di esso.

Questo mi preoccupa, dato che è per un progetto governativo. Il recupero della password di un utente per eseguire un'azione con il proprio ID comporta l'assurdità di qualsiasi tipo di controllo di sicurezza. L'unica ragione per cui riesco a capire è creare un audit trail falso.

Non è davvero necessario utilizzare la crittografia reversibile per le password. Se esiste mai un motivo legittimo per falsificare un ID utente, è possibile farlo:

• Memorizza l'hash della password corrente
• Sostituzione con un valore noto
• (Attività di audit trail falsi, ad es. Trasferimento di fondi sul conto offshore)
• Sostituisci l'hash della password originale

Mi sentirei a disagio con l'ultimo passaggio: chiunque fosse impersonato nel sistema dovrebbe sapere che è successo. Forse puoi convincere il business dicendo "È come se la tua banca mi permettesse di accedere al tuo account a tua insaputa, perché ho detto che dovevo davvero"

La loro convinzione in un sistema di password migliore non è il problema. Crea una soluzione per consentire a un amministratore / supporto di rappresentare un account utente e fornire la tua correzione per le password. La sicurezza soffre spesso per comodità. Rendilo comodo e sicuro.

Modifica: non saranno mai e poi mai mai in grado di comprendere appieno il problema di sicurezza della password, ma comprendono la perdita di funzionalità. Presentare questa proposta e vedere se è possibile ottenere l'approvazione per apportare le modifiche necessarie. Non sanno nemmeno se ci vorrà un'ora o un anno. È una modifica delle funzionalità e non una ricostruzione completa.

Considerando gli eventi attuali (la perdita di dati Epsilon e la perdita di dati della rete Playstation), si spera che i problemi siano palesemente ovvi.

A volte, tuttavia, come sviluppatore non puoi semplicemente influenzare la politica.

Farei del mio meglio per mostrare il potenziale di scandalo e spese, che dovrebbe essere facile, considerando ancora una volta gli eventi attuali. Ma se ciò non ha successo, cosa puoi davvero fare. Non tanto. Smetti di protestare, dimostra la vulnerabilità per attirare l'attenzione. Nessuno dei due sembra grandi opzioni.

Lo sconsiglio, ma se devi assolutamente poter decifrare le password, dovresti usare la crittografia a chiave pubblica. In questo modo, puoi crittografare tutte le password utilizzando la chiave pubblica. È possibile verificare le password crittografando con la chiave pubblica e confrontando, nonché conservare la chiave privata altrove (non sul computer di produzione).

Di solito il motivo per cui un amministratore vede la password dell'utente è nel caso in cui la perda, la può dare all'utente. Per quanto ne so, Windows non consente all'amministratore di vedere la password, quindi perché l'applicazione dovrebbe essere? Qualsiasi libreria di crittografia interna verrà sicuramente interrotta perché sono sicuro che chiunque lo abbia scritto non funziona per l'NSA.