Memorizzazione delle password delle app Web in modo che possano essere recuperate

2

Versione breve

Il mio capo vuole che memorizzi le password di utente per un'app Web di ASP.NET Web Form che stiamo sviluppando in testo non crittografato, in modo che un utente con diritti di amministratore possa fare clic su un pulsante e tornare indietro password correnti per gli account che controlla.

Non voglio farlo , perché mi interessa profondamente la sicurezza e la privacy degli utenti di un'app Web con cui sono coinvolto in qualsiasi modo.

Quale sarebbe un buon modo per archiviare le password in un formato crittografato, che può comunque essere decodificato?

Non posso contare su utenti con un indirizzo email, quindi inviare all'utente un link per reimpostare la password non è un'opzione.

Leggi quanto segue per più contesto.

Alcuni contesti

Questa app è stata scritta da persone che hanno poca idea di come scrivere il software. Un sacco di codice duplicato, rischi per l'iniezione SQL ovunque, nessun test unitario di qualsiasi tipo, una nuova connessione viene istanziata e aperta per ogni singola query ... indica una cattiva pratica, la troverai in questo codebase.

Le password sono attualmente memorizzate come un semplice MD5 della stringa originale, che è debole, orribile e tutto, ma ancora un po 'meglio del testo in chiaro.

Ho appena finito di implementare una richiesta di funzionalità in cui l'amministratore di cui stavo parlando può fare clic su un pulsante e avere un account creato automaticamente per ogni dipendente che gestisce, con una password casuale. Mi imbarazzo durante la scrittura di questo, ma uno dei requisiti era quello di esportare le credenziali in un foglio di calcolo di Excel . Cosa ho fatto.

Questo è un problema di per sé, ma poi il mio capo ha detto "Cosa succede se l'utente perde il foglio di calcolo? Gli utenti sono stupidi, sai. Ci deve essere un modo per riavere le password."

Bang.

Fargli ascoltare le persone che sanno di cosa stanno parlando non è un'opzione, purtroppo.

L'ovvio suggerimento sarebbe "GTFO", lo so, ma ti assicuro che è qualcosa che farò il prima possibile.

Nel frattempo, ho bisogno di imbrogliare e fingere di archiviare le password in chiaro, mentre faccio le cose nel modo migliore possibile per proteggere le password dei miei utenti.

Modifica

Per qualche motivo le persone che rispondono stanno presumendo che io sia una ragazza, quindi, per la cronaca, vorrei chiarire che sono un ragazzo. Non che dovrebbe fare alcuna differenza, ma hey;)

    
posta s.m 12.02.2014 - 17:46
fonte

4 risposte

5

Se è necessario eseguire questa operazione perché non viene fornita un'opzione, è possibile crittografare le password con una password che non è memorizzata nel codice o nel database. Effettua il recupero "su richiesta" del cliente (devono chiamarti per farlo) e qualcuno da parte tua dovrebbe inserire la password per rigenerare l'elenco utenti / pass.

Non preoccuparti della stupidità. Hai indicato le procedure più sicure, il tuo capo le ha ignorate. Probabilmente non ti farebbe male ricevere le tue obiezioni per iscritto (email) nel caso ci fosse un problema e provassero a biasimarti.

    
risposta data 12.02.2014 - 17:55
fonte
2

Archivali in un file e crittografalo con una chiave collegata all'account dell'utente connesso. Windows gestisce quindi la crittografia e la sicurezza di poter decodificare il file.

In questo modo la sempre password sarà in chiaro ... se hai effettuato l'accesso come utente che ha il permesso di leggere quel file. Potrebbe essere necessario codificare l'intera unità per essere totalmente sicuro, ma un'app rapida può farlo (consultare 'configurazione protetta' per esempi di protezione dei file app.config - potrebbe essere usato qui un codice simile, presumo) ma basato su codice la soluzione non ti permetterebbe di vedere i contenuti in un visualizzatore esterno (ad es. excel), ma potresti facilmente archiviare il file crittografato e dare loro un'app visualizzatore speciale "per sicurezza" in modo che solo l'amministratore possa vederli in chiaro. Immagino che questo sia il vero requisito, non che possano usare Excel, ma possono vedere le password.

    
risposta data 12.02.2014 - 18:43
fonte
2

risks for SQL injection everywhere

Questa è la tua occasione. Sfrutta questo e mostra al tuo capo, quanto è facile per qualsiasi estraneo leggere l'intero database, inclusa la password del tuo capo. Poi chiedigli, su quanti siti web usa personalmente la stessa password. Dopo che ha risposto, è ora di spiegare, quali hash salati nella tua app Web possono fare per il suo account PayPal.

Soprattutto dato questo software cheesy, dove trovare (e tanto meno aggiustare) tutte le falle della sicurezza impiegheranno molto tempo, un pwd irreversibile con hash dà una grande quantità di sicurezza ADESSO, oggi.

A proposito, i problemi di SQL injection potrebbero essere utilizzati anche per sovrascrivere le password memorizzate? Sto solo chiedendo ...

    
risposta data 31.03.2014 - 00:25
fonte
-1

Se sei morto nel tentativo di recuperare la "password", sarei tentato di provare a dare ai tuoi utenti una minima quantità di sicurezza tagliando le password in modo tale da renderlo banale da creare una password che esegue lo hash allo stesso valore senza necessariamente la stessa password. (Ricorda che un'alta percentuale di utenti utilizzerà la stessa password per le loro banche, carte di credito e conti di pensionamento !!!) In questo modo, puoi stampare per il tuo capo una password che consentirà l'accesso all'account, senza necessariamente identico alla password dell'utente. Se si costruisce un hash a 60 bit con attenzione (descritto di seguito), è possibile invertire l'hash per tutte le password più brevi di 10 caratteri. Le password più lunghe comportano una falsa inversione ... un alias password che crea una collisione hash con la vera password.

Se usi un hash a 60 bit, la probabilità di una collisione è circa 1 in un sestilione. In altre parole, se a un utente malintenzionato è consentito 1 miliardo di tentativi di accesso al secondo, in media saranno necessari circa 17 anni per accedere se l'utente utilizza una password complessa.

Una possibile implementazione è creare un registro a scorrimento di feedback generalizzato di 9 cifre base94. pow (94,9) è solo timido di pow (2, 60). I caratteri possono essere semplicemente letti dal registro di feedback. Tuttavia, se la password è più lunga di 9 caratteri, il feedback inizierà a mescolare entropia di caratteri precedenti nei caratteri successivi, quindi le password più lunghe saranno aliasate da password più brevi.

Se stai supportando le password Unicode, scegli una normalizzazione, normalizza e converti in UTF-8 prima dell'hashing. Tutte le password contenenti caratteri non inglesi verranno alterate alle password dei caratteri inglesi.

Ho scritto un breve programma di 100 linee C che implementa quanto sopra e ne dimostra la reversibilità. Il programma prende una chiave di offuscamento base64 da 20 caratteri seguita dalla password. Cancella la password e stampa l'hash e la password di back-out dall'hash allo stdout. Può essere trovato all'indirizzo link

    
risposta data 30.03.2014 - 23:19
fonte

Leggi altre domande sui tag