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

Implementa le funzionalità di cui hanno bisogno in modo sicuro. Gli amministratori che accedono come un altro utente possono essere implementati senza che conoscano la password dell'utente. Possono accedere come se stessi e quindi avere una funzione di 'change-identity' disponibile.

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

Devi convincerli che in realtà non devono essere responsabili civilmente nel caso in cui il loro server venga violato. Né hanno bisogno del contraccolpo di una base di utenti informata che si rende conto di essere negligenti.

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

Guarda cosa è successo a Sony. Inoltre, il nostro sito è stato compromesso di recente, e una delle cose che ha impedito che si trasformasse in un disastro totale è stata l'utilizzo di una (relativamente) buona funzione di hashing unidirezionale (SHA512). Da allora siamo passati a bcrypt per prevenire attacchi di forza bruta / dizionario (o almeno renderli non controllabili). Semplicemente non trovo nient'altro di conscevole.

Fatto: le persone usano la stessa password su molti siti

Probabilmente il tuo capo non si rende conto che le persone spesso usano una singola password (o una serie molto limitata di esse) per tutti i tipi di servizi (inclusi servizi bancari o Facebook e simili). Se gli utenti possono modificare la propria password nel proprio sistema, è molto probabile che utilizzino la stessa password come altrove.

Se il tuo capo pensa che questa password non sia un problema, dovresti dire loro questo fatto e forse inizieranno a pensare in modo diverso. Anche se la tua app è dietro il muro e non è accessibile pubblicamente, può rappresentare una minaccia per la sicurezza su altri servizi online. I nomi utente (soprattutto quando sono e-mail) sono piuttosto facili da indovinare. Non riesco a immaginare quanto sarebbe divertente accedere al conto Facebook di Boss e mettere qualcosa sul loro muro.

Le password degli utenti dovrebbero sempre essere trattate come massima riservatezza / informazioni riservate a cui solo un numero limitato di persone ha accesso. È meglio evitare di memorizzare tali informazioni volatili. E anche quando lo fai, ti dovrebbe essere garantito ogni singolo accesso a queste informazioni. Come ottenere un documento confidenziale da una cassastrong 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 degli account nella tua applicazione dovrebbe essere fatta in modo diverso.

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

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

È vero che dovrebbe essere sviluppata una nuova schermata per consentire l'accesso delegato, ma comunque.

Perché l'accesso delegato è migliore?

Potresti anche fornire funzionalità aggiuntive che renderebbero chiaro che alcune azioni sono state eseguite dall'amministratore per conto di alcuni utenti (che non puoi sapere ora perché gli amministratori agiscono come dei e accedono come chiunque e potrebbero fare cose che può danneggiare la reputazione reale dei dipendenti).

Devi essere d'accordo sul fatto che le persone commettano 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ò lo renderà più sicuro per gli utenti non amministratori, quindi la loro reputazione nel mondo reale non risentirà degli errori di altre persone.

Non parli di cosa fa l'applicazione. Se si tratta di applicazioni per passaporti, piene di informazioni di furto d'identità che devono essere protette, merita la massima protezione. Ma se "mi dicono gli incidenti stradali sulla mia rotta verso casa" quali sono le conseguenze di una violazione della password? Alcuni sistemi che ho scritto non hanno nemmeno password: inserisci semplicemente la tua email o il numero dello studente o qualche altro identificatore che le persone spesso conoscono l'uno dell'altro, ei proprietari del sistema apprezzano la facilità d'uso e l'impossibilità di essere bloccati oltre la possibile violazione della privacy se le persone si impersonano a vicenda. Non ho alcun problema con quello, neanche. Perché ho bisogno di una password per impostare il mio programma di sessioni preferite in una conferenza, per esempio?

Quindi, se venissi presentato per la revisione del codice e tu me l'avessi dato, è da lì che avremmo iniziato. 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 di tutti i dati archiviati? Forse sono orribili. Li elencheresti per me. Quindi, quali sono le conseguenze delle persone che non sono in grado di fare clic su "inviami la mia password" ma invece di dover fare clic su "reimposta la mia password"? Smetterebbero di usare il sito? E il personale che accede come persona? È questo il risparmio di tempo, denaro, vendite perse o cosa?

L'ultimo pezzo della storia dei costi / benefici, e uno che si ottiene solo se c'è una grande differenza tra i negativi a cui sei esposto ora e i negativi che otterrai quando rimuovi la funzionalità, è il costo per aggiustalo. Potrei spendere un milione per risparmiarmi l'opportunità 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 è entrato in funzione con un sito di domanda per il tuo passaporto con ID nell'URL: se hai modificato l'URL con un ID diverso, hai visto la forma incompleta di un altro cittadino casuale. E ho clienti che accedono come clienti ai fini del servizio clienti per la felicità generale, quindi vedo il lato positivo di questo, anche se non lo tollererei se i dati dietro la password fossero effettivamente importanti per gli estranei. p>     

Potrebbe essere contro la legge e potrebbe aprirli per essere denunciati. Se conservano qualsiasi tipo di informazione personale sull'utente, o il sistema interagisce con altri sistemi come l'utente che potrebbe essere necessario verificare per vedere se il sistema rientra in uno Stato o leggi sulla privacy o leggi federali. vale a dire. Sarbanes / Oxley, California OOPA, ecc.

A parte i potenziali problemi legali, puoi anche segnalare che qualsiasi amministratore può in qualsiasi momento scaricare l'intera tabella su una chiavetta dati portatile e partire con la possibilità di accedere come qualsiasi utente e causare scompiglio o vendere i dati.

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

Inoltre non hai bisogno della password di un utente per eseguire operazioni come loro. Puoi implementare una funzione sudo -like.

Questo non può essere un sistema di governo federale in quanto i requisiti FIPS e FISMA proibirebbero la crittografia reversibile per le password, e il dipartimento dei genitori li schiafferebbe sulla luna.

And in order to implement a stronger security policy (hashing passwords so they can't be easily retrieved), I have to remove existing functionality for them.

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

Plus there are actually existing functionality within the application for admin users to retrieve user's passwords in order to log in as them and do stuff (which they have said, they require).

L'ho visto implementato in un istituto finanziario. Le persone presso l'area di supporto clienti si collegheranno con le proprie credenziali e, se avessero i diritti per farlo, potrebbero fingere di accedere come cliente. Questo non li ha registrati come cliente, ha solo impersonato il cliente . In questo modo, se il rappresentante del servizio clienti decidesse di prelevare denaro, non comparirebbe come il cliente lo fa nei registri: mostrerebbe al rappresentante del servizio clienti provare a farlo (oltre a inviare un avviso per farli sparare non appena il rentacop potrebbe arrivare al loro piano).

Fatto male, renderebbe lo staff del servizio clienti in grado di far sembrare che l'utente finale abbia intrapreso alcune attività che potrebbero comportare gravi responsabilità finanziarie o legali.

L'ultimo sito Web federale su cui ho lavorato ha raccolto 1/4 miliardi di dollari l'anno da utenti finali (di cui circa 400 utenti), quindi il logging doveva essere molto stretto e che solo l'utente finale autorizzato era permesso di 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 la loro rete di giochi MMORPG, per un totale di oltre 25.000.000 di nomi, indirizzi, numeri di carte di credito, nomi utente e password. Puoi credere che non sono affatto contento (voglio il mio deposito)!

Faccio riferimento al Codice di etica per l'ingegneria del software su questioni come questa. La mia interpretazione, la tua prima priorità, non è di minare l'interesse pubblico (non come nella possibilità di una password compromessa più come questa esempio qui dove un'azienda ha modificato i laptop Dell in modo che la società di noleggio possa spiare i propri affittuari senza che loro lo sappiano). Dopo di ciò, la tua responsabilità è di INFORMARE il tuo cliente di potenziali rischi e lasciarli prendere in considerazione. Ovviamente questa è la base minima. Devi usare il tuo giudizio sul fatto che tu pensi che sia ancora più di quanto tu possa sopportare e permettere.

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

Potresti stampare l'elenco di e-mail e password decifrate e metterle sulla scrivania del tuo capo, con un grande avviso sulla copertina: "Confidenziale"

Riduci il carattere in modo da non sprecare carta.

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 per evitare questo e archiviare solo gli hash delle password, non le password stesse o tutto ciò che può essere ricondotto a una password.

Ci sono momenti, tuttavia, quando è 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é recuperare la password esistente.

Un'altra possibilità, tuttavia, è quella di consentire all'utente di memorizzare i dati sul server crittografato con la propria password. In questo caso, consentire semplicemente a un amministratore di modificare la password è sufficiente non . 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, c'è un'alternativa che è ragionevolmente sicura, e consente comunque il recupero quando realmente necessario.

Invece di usare la password dell'utente per crittografare i dati, si crea una chiave casuale per crittografare i dati stessi. Quindi memorizzi quella chiave, in un paio di punti: una volta crittografata con la password dell'utente e in un altro posto crittografata con una password 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 decodificare la chiave reale e utilizzarla per recuperare i dati e / o ricodificare 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 di chiavi di amministrazione e desideri che almeno tre di esse siano d'accordo prima di poter recuperare una chiave. In questo caso, quando si archivia la password crittografata per scopi amministrativi, la si memorizza più volte, una volta per ogni gruppo di tre dei cinque amministratori (che non occupa molto spazio, poiché si memorizzano solo tasti , a ~ 256 bit a testa, non più copie dei dati). Ognuna di queste copie viene successivamente crittografata con (gli hash di) ciascuna delle password per questi tre amministratori.

Per decrittografarlo, devi identificare i tre amministratori che stanno inserendo le loro password e scegliere la chiave crittografata appropriata per quel gruppo di tre, quindi decifrare usando ciascuna delle tre password per ottenere finalmente la chiave originale. Puoi quindi usarlo per recuperare i dati stessi, oppure puoi semplicemente ricodificarlo con la (nuova) password dell'utente, in modo che possano comunque accedere ai loro dati.

Quando lo fai, però veramente devi usare un algoritmo di crittografia standard e (con una strong preferenza) un'implementazione standard, ben nota e accuratamente studiata.

Questo mi preoccupa, dato che è per un progetto governativo. Recuperare la password di un utente per eseguire un'azione sotto il proprio ID rende assurda qualsiasi tipo di controllo di sicurezza. L'unica ragione per cui posso vederlo è creare una falsa pista di controllo.

Non c'è davvero bisogno di usare la crittografia reversibile per le password. Se c'è sempre un motivo legittimo per falsificare un ID utente, può essere fatto da:

• Salva l'hash della password attuale
• Sostituzione con un valore noto
• (Attività di attività di audit fasullo, ad esempio trasferimento di fondi su un conto offshore)
• Sostituisci l'hash della password originale

Sarei a disagio con l'ultimo passaggio: chiunque sia stato impersonato sul sistema dovrebbe sapere che è successo. Forse puoi persuadere il business dicendo "È come se la tua banca mi permettesse di accedere al tuo account a tua insaputa, perché ho detto che avevo davvero bisogno di farlo"

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

Modifica: non potranno mai e poi mai comprendere completamente il problema di sicurezza della password, ma capiscono di perdere funzionalità. Fai questa proposta e vedi se puoi ottenere l'approvazione per apportare le modifiche necessarie. Non sanno nemmeno se ci vorrà un'ora o un anno. È un cambio di funzionalità e non una ricostruzione completa.

Considerando gli eventi attuali (perdita di dati Epsilon e perdita di dati della rete di Playstation), ci si aspetterebbe che i problemi sarebbero evidenti.

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

Farei del mio meglio per mostrare il potenziale di scandalo e spesa, che dovrebbe essere facile, sempre in considerazione degli eventi attuali. Ma se questo non ha successo, cosa puoi fare davvero. Non tanto. Esci per protesta, dimostra la vulnerabilità per attirare l'attenzione. Né sembrano grandi opzioni.

Mi sconsiglio di farlo, ma se si deve assolutamente avere la possibilità di decodificare le password, è necessario utilizzare 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, e si può mantenere la chiave privata da qualche altra parte (non sul computer di produzione).

Di solito il motivo per cui un amministratore vede la password dell'utente è nel caso in cui lo perdano, possono darlo all'utente. Per quello che posso dire, Windows non consente all'amministratore di vedere la password, quindi perché dovrebbe essere la tua applicazione? Qualsiasi libreria di crittografia interna è sicura di essere rotta perché sono sicuro che chiunque l'abbia scritta non funziona per la NSA.