Come dovrei eticamente approccio di memorizzazione delle password utente per dopo il recupero testo in chiaro?

https://stackoverflow.com/questions/2283937

21-09-2019
|

Domanda

Mentre continuo a costruire sempre di più siti e applicazioni web Spesso mi viene chiesto di memorizzare le password degli utenti in modo che possano essere recuperate se / quando l'utente ha un problema (sia per e-mail un link password dimenticata, loro piedi attraverso oltre al telefono, etc.) Quando posso mi lottare aspramente contro questa pratica e fare un sacco di programmazione 'extra' per rendere la reimpostazione delle password e l'assistenza amministrativa possibili senza memorizzare la propria password attuale.

Quando non riesco a combatterla (o non posso vincere) poi ho sempre codificare la password in qualche modo in modo che, almeno, non è memorizzato come testo in chiaro nel database, anche se sono consapevole che se il mio DB viene violato non ci sarebbe voluto molto per il colpevole per rompere le password, in modo che mi mette a disagio.

In un perfetto gente mondo sarebbe aggiornare le password di frequente e non duplicarli in molti diversi siti-purtroppo so che la gente molti che hanno lo stesso / home / email / password banca lavoro, e hanno anche dato liberamente a me quando ne hanno bisogno assistenza. Io non voglio essere il responsabile della loro scomparsa finanziaria se le mie procedure di sicurezza DB non riescono per qualche motivo.

moralmente ed eticamente mi sento responsabile per la protezione di ciò che può essere, per alcuni utenti, la loro vita, anche se stanno trattando con molto meno rispetto. Sono certo che ci sono molte strade per avvicinarsi e argomenti da effettuare per la salatura hash e le diverse opzioni di codifica, ma c'è un solo ‘best practice’ quando si deve memorizzare loro? In quasi tutti i casi Sto usando PHP e MySQL se questo fa alcuna differenza nel modo in cui devo gestire le specifiche.

Informazioni aggiuntive per Bounty

Ci tengo a precisare che so che questo non è qualcosa che si vuole avere a che fare e che nella maggior parte dei casi il rifiuto di farlo è meglio. Sto, tuttavia, non alla ricerca di una conferenza sui meriti di questo approccio sto cercando i migliori passi da compiere se si prende questo approccio.

In una nota di seguito ho fatto il punto che i siti web orientati principalmente verso gli anziani, con problemi mentali, o molto giovane può diventare fonte di confusione per le persone quando gli viene chiesto di eseguire una routine di ripristino delle password sicura. Anche se possiamo trovare semplice e banale in questi casi alcuni utenti hanno bisogno di assistenza supplementare di entrambi avere un aiuto di servizi di tecnologia di loro nel sistema o averlo inviato via email / visualizzato direttamente a loro.

In tali sistemi il tasso di abbandono da questi dati demografici potrebbero ostacolare l'applicazione se gli utenti non sono stati dati questo livello di assistenza di accesso, quindi si prega di rispondere con una tale impostazione in mente.

Grazie a tutti

Questa è stata una domanda divertente con un sacco di dibattito e ho goduto. Alla fine ho scelto una risposta che sia conserva la sicurezza delle password (non dovrò tenere testo normale o password recuperabili), ma rende anche possibile per la base di utenti ho specificato per accedere a un sistema senza gli svantaggi principali che ho trovato da normale recupero della password.

Come sempre ci sono stati circa 5 risposte che vorrei aver segnato come corretta per diversi motivi, ma ho dovuto scegliere il migliore - tutto il resto ha un +1. Grazie a tutti!

Inoltre, grazie a tutti nella comunità Stack che hanno votato per questa domanda e / o contrassegnato come preferito. Prendo colpendo 100 fino voti come un complimento e spero che questa discussione ha aiutato qualcun altro con la stessa preoccupazione che ho avuto.

Soluzione

Che ne dite di prendere un altro approccio o l'angolo a questo problema? Chiedi perché la password è necessaria per essere in chiaro: se è così che l'utente può recuperare la password, quindi a rigor di termini non si ha realmente bisogno per recuperare la password si misero (non mi ricordo di cosa si tratta in ogni caso), è devono essere in grado di dare loro una password che può usare .

Pensateci: se l'utente ha bisogno di recuperare la password, è perché hanno dimenticato. In questo caso una nuova password è altrettanto buono come quello vecchio. Ma, uno degli svantaggi dei meccanismi di ripristino di password comuni utilizzati oggi è che la password generate prodotte in un'operazione di ripristino sono generalmente un gruppo di caratteri casuali, quindi sono difficile per l'utente di digitare semplicemente correttamente a meno che non copia-N- incolla. Questo può essere un problema per gli utenti di computer meno esperti.

Un modo per aggirare il problema è quello di fornire le password generate automaticamente che sono più o meno il testo in linguaggio naturale. Mentre le stringhe in linguaggio naturale potrebbero non avere l'entropia che una stringa di caratteri casuali della stessa lunghezza è, non c'è niente che dice che la password generata automaticamente deve avere solo 8 (o 10 o 12) caratteri. Prendi un alta entropia passphrase auto-generata concatenando più parole casuali (lasciare uno spazio tra di loro, in modo che siano ancora riconoscibili e tipizzabile da chiunque in grado di leggere). Sei parole casuali di varia lunghezza sono probabilmente più facile da digitare in modo corretto e con fiducia di 10 caratteri casuali, e possono avere un entropia più alto pure. Ad esempio, l'entropia di una password di 10 caratteri disegnata in modo casuale da maiuscole, minuscole, cifre e 10 simboli di punteggiatura (per un totale di 72 simboli validi) avrebbe un entropia di 61,7 bit. Usando un dizionario di 7776 parole (come utilizza Diceware) che può essere selezionato in modo casuale per una parola di sei passphrase, la frase avrebbe un entropia di 77,4 bit. Vedere la Diceware FAQ per ulteriori informazioni.

una passphrase con circa 77 bit di entropia: "ammettere prosa tavolo bagliore flair acuta"
una password con circa 74 bit di entropia: "K: & $ R ^ tt ~ QKD"

Lo so io preferirei digitando la frase, e con copia-n-incolla, la frase non è meno facile da usare che la password sia, quindi nessuna perdita di lì. Naturalmente, se il tuo sito web (o qualunque sia il bene protetto è) non ha bisogno di 77 bit di entropia di una passphrase auto-generata, generare un minor numero di parole (che sono sicuro che gli utenti apprezzerebbero).

Capisco le argomentazioni che ci sono beni protetti da password che in realtà non hanno un alto livello di valore, quindi la violazione di una password potrebbe non essere la fine del mondo. Per esempio, io probabilmente non mi importerebbe se l'80% delle password che uso su vari siti web è stato violato: tutto ciò che potrebbe accadere è un qualcuno spamming o la pubblicazione sotto il mio nome per un po '. Non sarebbe grande, ma non è come essi sarebbero rottura nel mio conto in banca. Tuttavia, dato il fatto che molte persone usano la stessa password per i loro siti web forum come fanno per i loro conti bancari (e basi di dati di sicurezza probabilmente nazionali), penso che sarebbe meglio per gestire anche le password 'di basso valore' come non -recoverable.

Altri suggerimenti

Immaginate qualcuno ha commissionato un grande edificio da costruire - un bar, diciamo - e la seguente conversazione avviene:

Architetto:. Per un edificio di queste dimensioni e capacità, è necessario il fuoco esce qui, qui, e qui
Cliente:. No, è troppo complicato e costoso da mantenere, non voglio che le porte laterali o porte posteriori
Architetto:. Sir, uscite di sicurezza non sono optional, sono tenuti come da codice del fuoco della città
Cliente: non sto pagando a discutere. Solo quello che ho chiesto.

Il dell'architetto poi chiedere come costruire eticamente questo edificio senza uscite di sicurezza?

Nel settore edilizia e l'ingegneria, la conversazione è più probabile che alla fine in questo modo:

Architetto: Questo edificio non può essere costruito senza uscite di sicurezza. Si può andare in qualsiasi altro professionista abilitato e lui vi dirà la stessa cosa. Me ne sto andando adesso; richiamami quando si è pronti a collaborare.

Programmazione informatica non può essere un con licenza professione, ma la gente spesso sembrano chiedersi perché la nostra professione non ottiene lo stesso rispetto di un ingegnere civile o meccanico - beh, non cercate oltre. Quelle professioni, quando spazzatura consegnato (o addirittura pericolosa) esigenze, semplicemente rifiutare. Sanno che non è una scusa per dire: "Bene, ho fatto del mio meglio, ma lui ha insistito, e io devo fare quello che dice." Essi potrebbero perdere la loro licenza per questa scusa.

Non so se voi oi vostri clienti sono parte di qualsiasi società quotata in borsa, ma la memorizzazione di password in qualsiasi forma recuperabile causare a fallire diversi tipi di audit di sicurezza. Il problema non è quanto sia difficile sarebbe stato per un po ' "hacker" che ha ottenuto l'accesso al database per recuperare le password. La maggior parte delle minacce alla sicurezza sono interni. Quello che vi serve per la protezione contro è qualche dipendente scontento piedi fuori con tutte le password e la loro vendita al miglior offerente. Utilizzando la crittografia asimmetrica e memorizzare la chiave privata in un database separato non fa assolutamente nulla per evitare questo scenario; c'è sempre sarà qualcuno con accesso al database privato, e questo è un grave rischio per la sicurezza.

Non c'è modo etico o responsabile per memorizzare le password in una forma recuperabile. Periodo.

Si potrebbe criptare la password + un sale con una chiave pubblica. Per gli accessi basta controllare se il valore memorizzato è uguale al valore calcolato a partire dalla input dell'utente + sale. Se arriva un momento, quando la password deve essere ripristinato in chiaro, è possibile decifrare manualmente o semi-automaticamente con la chiave privata. La chiave privata può essere conservato altrove e può inoltre essere criptati in modo simmetrico (che avrà bisogno di un interazione umana per decriptare la password poi).

Credo che questo sia in realtà tipo di simile al modo in cui il di Windows Recovery Agent funziona.

Le password vengono memorizzate crittografate
La gente può accedere senza decrittografare al testo in chiaro
Le password possono essere recuperati al testo in chiaro, ma solo con una chiave privata, che possono essere archiviati al di fuori del sistema (in una banca sicura, se si vuole).

Non mollare. L'arma è possibile utilizzare per convincere i vostri clienti non è repudiability. Se si riesce a ricostruire le password degli utenti tramite qualsiasi meccanismo, avete dato loro i clienti di un meccanismo non ripudio legale e possono ripudiano qualsiasi transazione che dipende da quella password, perché non v'è alcun modo il fornitore può dimostrare che essi non ricostruiscono la password e mettere la transazione attraverso se stessi. Se le password vengono memorizzate correttamente come digest anziché testo cifrato, questo è impossibile, ergo sia il cliente finale ha eseguito l'operazione se stesso o ha violato il suo dovere di diligenza w.r.t. la password. In entrambi i casi che lascia la responsabilità ad angolo retto con lui. Ho lavorato su casi in cui che ammonterebbe a centinaia di milioni di dollari. Non qualcosa che si desidera ottenere sbagliato.

Non è possibile memorizzare le password eticamente per dopo il recupero di testo in chiaro. E 'così semplice. Anche Jon Skeet non può memorizzare le password eticamente per dopo il recupero di testo in chiaro. Se gli utenti possono recuperare le password in formato testo un modo o nell'altro, quindi potenzialmente possono farlo anche un hacker che trova una vulnerabilità di sicurezza nel codice. E non è solo la password di un utente venga compromessa, ma tutti loro.

Se i vostri clienti hanno un problema con questo, dire loro che la memorizzazione delle password recoverably è contro la legge. Qui nel Regno Unito, in ogni caso, il Data Protection Act 1998 (in particolare, l'Allegato 1, parte II, Paragrafo 9) richiede i titolari del trattamento di utilizzare le misure tecniche appropriate per mantenere i dati personali protetti, tenendo conto, tra l'altro, la danno che potrebbe essere causato se sono stati compromessi i dati - che potrebbe essere notevole per gli utenti che condividono le password tra i siti. Se hanno ancora difficoltà a Grokking il fatto che si tratta di un problema, li puntare ad alcuni esempi reali, come ad esempio questo .

Il modo più semplice per consentire agli utenti di recuperare un account di accesso è quello di e-mail un link di una volta che li registra automaticamente e li porta direttamente a una pagina in cui si può scegliere una nuova password. Creare un prototipo e mostrarlo in azione a loro.

Ecco un paio di post di blog che ho scritto sul tema:

Aggiornamento: ora stiamo iniziando a vedere le cause e le azioni penali contro le compagnie che non riescono a proteggere le password dei propri utenti in modo corretto. Esempio: LinkedIn bollato con 5 milioni di $ classe azione legale ; Sony multato £ 250.000 su PlayStation dati scribacchino . Se non ricordo male, LinkedIn è stato effettivamente crittografia delle password dei suoi utenti, ma la crittografia che stava usando era troppo debole per essere efficace.

Dopo aver letto questa parte:

In una nota qui sotto ho fatto il punto che   siti web orientata in gran parte verso la   anziani, con problemi mentali, o molto   giovane può diventare fonte di confusione per le persone   quando viene chiesto loro di eseguire un   sicuro di routine il recupero della password.   Anche se possiamo trovare in modo semplice e   mondano in quei casi alcuni utenti hanno bisogno   l'assistenza supplementare di entrambi avere   un tecnico di servizio li aiutano nella   Sistema o averlo inviato via email / visualizzato   direttamente a loro.

In tali sistemi il tasso di abbandono   da questi dati demografici potrebbero zoppicare   la domanda se gli utenti non fossero   dato questo livello di assistenza di accesso,   quindi si prega di rispondere con una tale impostazione in   mente.

sono lasciato chiedo se qualcuno di questi requisiti del mandato di un sistema di password recuperabili. Per esempio: La zia Mabel chiama e dice: "Il tuo programma di Internet non funziona, non so la mia password". "OK", dice il servizio drone cliente "fammi controllare alcuni dettagli e poi ti vi darà una nuova password . Quando il prossimo log in esso vi chiederà se si desidera mantenere quella password o cambiarlo in qualcosa che si può ricordare più facilmente. "

Quindi il sistema è impostato per sapere quando una reimpostazione della password è accaduto e visualizzare un "ti piacerebbe mantenere la nuova password o scegliere un nuovo" messaggio.

Come è peggio per i meno PC-letterato che viene detto loro vecchia password? E mentre la persona del servizio clienti può arrivare fino a male, il database stesso è molto più sicuro nel caso in cui sia disatteso.

commento Cosa è male il mio suggerimento e io suggerisco una soluzione che in realtà fa quello che inizialmente voleva.

Michael Brooks è stato piuttosto vocale circa CWE-257 - il fatto che qualunque metodo utilizzato, si (l'amministratore) è ancora possibile recuperare la password. Così come su queste opzioni:

crittografare la password con chiave di qualcun altro pubblico - una qualche autorità esterna. In questo modo, non si può ricostruire personalmente, e l'utente dovrà andare a quella un'autorità esterna e chiedere che la loro parola d'accesso recuperata.
Crittografare la password utilizzando una chiave generata da un secondo passphrase. Fate questo crittografia lato client e non trasmetterla in chiaro al server. Poi, per recuperare, fare di nuovo la decrittografia lato client da ri-generare la chiave dal loro input. Certo, questo approccio è fondamentalmente utilizza una seconda password, ma si può sempre dire loro di scrivere in giù, o utilizzare il vecchio approccio di sicurezza-domanda.

Credo 1. è la scelta migliore, perché consente di designare qualcuno all'interno dell'azienda cliente per tenere la chiave privata. Assicurarsi che essi generano la chiave di se stessi, e lo immagazzinano con istruzioni in una cassetta di sicurezza, ecc Si potrebbe anche aggiungere la sicurezza scegliendo di crittografare e solo fornire alcuni personaggi dalla password a terzi interno, in modo che avrebbero dovuto rompere la password da indovinare esso. Fornire questi personaggi per l'utente, che probabilmente ricordano quello che era!

Ci sono state molte discussioni di problemi di sicurezza per l'utente in risposta a questa domanda, ma mi piacerebbe aggiungere una menzione di benefici. Finora, non ho mai visto legittima beneficio menzionato per avere una password recuperabili memorizzato nel sistema. Considerate questo:

Fa il beneficio all'utente di avere la propria password inviata per loro? No. Essi ricevono più benefici da un one-time-use link di reimpostazione della password, che si spera permetterà loro di scegliere una password che ricordare.
Fa il beneficio all'utente di avere la propria password visualizzata sullo schermo? No, per lo stesso motivo di cui sopra; essi dovrebbero scegliere una nuova password.
Il beneficio all'utente di avere una persona di supporto parla la password per l'utente? No; ancora una volta, se la persona di sostegno ritiene la richiesta dell'utente per la loro password come correttamente autenticato, è più a beneficio dell'utente da dare una nuova password e la possibilità di cambiarlo. Inoltre, il supporto telefonico è più costoso di reimpostazione delle password automatizzati, per cui l'azienda anche non beneficia.

Sembra che gli unici che possono beneficiare di password recuperabili sono quelli con intenti malevoli o sostenitori di API poveri che necessitano di scambio di password di terze parti (si prega di non utilizzare le API detto mai!). Forse si può vincere la tua argomentazione sinceramente dichiarando ai vostri clienti che i guadagni aziendali benefici e solo passività per memorizzare le password recuperabili .

Leggendo tra le righe di questo tipo di richieste, vedrete che i vostri clienti probabilmente non capiscono o in realtà anche importava affatto di come vengono gestite le password. Quello che vogliono davvero è un sistema di di autenticazione che non è così difficile per i loro utenti. Quindi, oltre a raccontare loro come in realtà non vogliono password recuperabili, si dovrebbe offrire loro modi per rendere il processo di autenticazione meno doloroso, soprattutto se non hai bisogno di livelli di sicurezza pesanti, per esempio, una banca:

Consente all'utente di utilizzare il loro indirizzo di posta elettronica per il loro nome utente. Ho visto innumerevoli casi in cui l'utente dimentica il proprio nome utente, ma pochi dimenticare il loro indirizzo email.
Offrire OpenID e lasciare che una terza parte a pagare per i costi di dimenticanza dell'utente.
Ease off le restrizioni di password. Sono sicuro che tutto quello che abbiamo incredibilmente infastidito quando alcuni siti web non consente la password preferita a causa dei requisiti inutili come "non è possibile utilizzare i caratteri speciali" o "la tua password è troppo lunga" o "la password deve iniziare con una lettera." Inoltre, se la facilità d'uso è una preoccupazione più grande di sicurezza della password, è possibile allentare anche le richieste non stupidi, consentendo password brevi o che non richiedono un mix di classi di personaggi. Con restrizioni sciolte, gli utenti saranno più propensi a usare una password che non si dimentica.
non scadono le password.
Consente all'utente di riutilizzare una vecchia password.
Consente all'utente di scegliere il proprio questione di reimpostazione password.

Ma se, per qualche motivo (e per favore dirci il motivo) davvero, davvero, davvero devono essere in grado di avere una password recuperabile, si potrebbe proteggere l'utente da compromettendo potenzialmente la loro altra conti online dando loro un sistema di autenticazione non basato su password. Perché le persone hanno già familiarità con i sistemi di nome utente / password e sono una soluzione ben esercitato-, questo sarebbe l'ultima risorsa, ma c'è sicuramente un sacco di alternative creative per le password:

permettere all'utente di scegliere un perno numerico, preferibilmente non 4 cifre, e preferibilmente solo se forza bruta tentativi sono protetti.
Avere all'utente di scegliere una domanda con una breve risposta che solo loro conoscono la risposta a, non cambierà mai, saranno sempre ricordare, e non importa altre persone scoprire.
Far all'utente di inserire un nome utente e quindi disegnare una forma facile da ricordare con permuta sufficientizioni per la protezione contro indovinare (vedi questa foto nifty di come il G1 fa questo per lo sblocco il telefono).
per il sito web per bambini, si potrebbe generare automaticamente una creatura confusa in base al nome utente (come una sorta di Identicon) e chiedere all'utente di dare alla creatura un nome segreto. Possono quindi essere richiesto di inserire il nome segreto della creatura effettuare il login.

Ai sensi del commento che ho fatto sulla questione:
Un punto importante è stato molto sorvolato da quasi tutti ... La mia reazione iniziale è stata molto simile a @ Michael Brooks, finché mi sono reso conto, come @stefanw, che il problema qui è requisiti rotto, ma queste sono quello che sono.
Ma poi, si è verificato a me che che potrebbe anche non essere il caso! Il punto manca qui, è il non detto Valore di attività dell'applicazione. Semplicemente parlando, per un sistema di basso valore, un meccanismo di autenticazione completamente sicuro, con tutto il processo in questione, sarebbe eccessivo, e il sbagliato scelta di sicurezza.
Ovviamente, per una banca, le "best practices" sono un must, e non v'è alcun modo per violare eticamente CWE-257. Ma è facile pensare a sistemi di valori bassi dove non è solo vale la pena (ma una semplice password è ancora necessaria).

E 'importante ricordare, vera esperienza di sicurezza sta nel trovare compromessi appropriate, non nelle dogmaticamente sputa le "Best Practices" che chiunque può leggere on-line.

In quanto tale, suggerisco un'altra soluzione:
A seconda del valore del sistema, e SOLO SE il sistema è opportunamente basso valore senza patrimoniale "costoso" (l'identità stessa, incluso), e non sono validi requisiti di business che rendono processo corretto impossibile (o sufficientemente difficile / costoso), e il cliente è a conoscenza di tutti gli avvertimenti ...
Allora potrebbe essere opportuno consentire semplicemente crittografia reversibile, senza cerchi speciali per saltare attraverso.
Sto fermandosi poco prima di dire di non perdere tempo con la crittografia a tutti, perché è molto semplice / economico per implementare (anche considerando la gestione delle chiavi passible), e lo fa fornire una certa protezione (più del costo della sua applicazione). Inoltre, la sua pena di guardare a come fornire all'utente la password originale, sia tramite e-mail, visualizzando sullo schermo, ecc
Dal momento che l'ipotesi è che il valore della password rubate (anche in forma aggregata) è piuttosto basso, una qualsiasi di queste soluzioni possono essere valide.

Poiché non v'è una vivace discussione in corso, discussioni animate in realtà diverse, nei diversi post e discussioni commento separate, vorrei aggiungere alcune precisazioni, e rispondere ad alcuni dei punti molto buoni che sono state sollevate altrove qui.

Per cominciare, penso che sia chiaro a tutti che qui permettendo la password originale dell'utente da recuperare, è cattiva pratica, e in generale non una buona idea. Questo non è affatto oggetto di contestazione ...
Inoltre, voglio sottolineare che in molti, anzi la maggior parte, le situazioni - è veramente sbagliato, anche fallo, brutto E brutto .

Tuttavia, il nocciolo della questione è di circa il principio , C'è qualche situazione in cui potrebbe non essere necessario di vietare questo, e se sì, come fare così nel modo più corretto adeguata alla situazione .

Ora, come @Thomas, @sfussenegger e pochi altri accennato, l'unico modo corretto di rispondere a questa domanda, è quello di fare un approfondito analisi del rischio di una situazione data (o ipotetico), per capire cosa c'è in gioco, quanto vale la pena di proteggere, e quali altre mitigazioni sono in gioco per permettersi tale protezione.
No, non è una parola d'ordine, questo è uno dei fondamentali, più importanti strumenti per un vero e proprio-live professionista della sicurezza. Le migliori pratiche sono buone fino ad un punto (di solito come linee guida per l'inesperto e gli hack), dopo che l'analisi punto di rischio ponderato prende il sopravvento.

Sai, è divertente - mi sono sempre considerato uno dei fanatici di sicurezza, e in qualche modo io sono sul lato opposto di quei cosiddetti "esperti di sicurezza" ... Beh, la verità è - perché sono un fanatico, e un esperto di sicurezza reale di vita reale - non credo in schizzando dogma "Best Practice" (o CWEs) sENZAil fondamentale analisi del rischio .
"Attenzione la zelota di sicurezza che è veloce da applicare tutto quanto in loro strumento di cintura senza sapere qual è il problema reale è di difendere contro. Più sicurezza non equivale necessariamente ad una buona sicurezza."
L'analisi del rischio, e fanatici di sicurezza vero, sarebbe puntare a un più intelligente, il valore / rischio basata su compromesso, in base al rischio, perdita potenziale, possibili minacce, mitigazioni complementari, ecc Qualsiasi "Security Expert" che non può puntare a suonare analisi dei rischi come il base per le loro raccomandazioni, o sostenere compromessi logiche, ma sarebbe invece preferisce becco dogmi e CWEs senza nemmeno capire come eseguire un'analisi dei rischi, sono nient'altro che sicurezza Hacks, e la loro esperienza non vale la carta igienica hanno stampato su.

In effetti, è così che si ottiene il ridicolo che è l'aeroporto di sicurezza.

Ma prima di parlare di compromessi appropriate per fare in questa situazione, diamo uno sguardo ai rischi apparenti (apparenti, perché non abbiamo tutte le informazioni di base su questa situazione, siamo tutti ipotizzando - in quanto la questione è ciò che ipotetica situazione potrebbe esserci ...
) Supponiamo che un sistema di basso valore, ma non così banale che è l'accesso del pubblico - il proprietario del sistema vuole impedire la rappresentazione informale, eppure "alta" la sicurezza non è di primaria importanza come la facilità d'uso. (Sì, è un compromesso legittima ad accettare il rischio che qualsiasi esperto di script-kiddie può hackerare il sito ... Aspetta, non è adatto in voga adesso ...?)
Solo per esempio, diciamo che sto organizzando un semplice sito per una grande riunione di famiglia, permettendo a tutti di riflettere su dove vogliamo andare il nostro viaggio in campeggio di quest'anno. Sono meno preoccupato di qualche hacker anonimi, o anche il cugino Fred spremitura in suggerimenti ripetuti di tornare a Lago Wantanamanabikiliki, come sto zia Erma non essere in grado di accedere quando ha bisogno di. Ora, la zia Erma, essendo un fisico nucleare, non è molto bravo a ricordare le password, o anche con l'utilizzo di computer a tutti ... Quindi voglio per rimuovere tutti gli attriti possibile per lei. Anche in questo caso, io non sono preoccupato per hack, ho appena non voglio errori stupidi di login sbagliato - Voglio sapere chi sta arrivando, e che cosa vogliono.

In ogni caso.
Ma quali sono i nostri principali rischi qui, se ci simmetricamente crittografare le password, invece di utilizzare un hash a senso unico?

Impersonare utenti? No, ho già accettato tale rischio, non è interessante.
amministratore Male? Beh, forse ... Ma ancora una volta, non mi importa se qualcuno può impersonare un altro utente, INTERNO o no ... e in ogni caso un amministratore dannoso è andando ottenere la password non importa ciò che - se il tuo amministratore andato male, il suo game over in ogni caso.
Un altro problema che è stato sollevato, è l'identità è in realtà condiviso tra più sistemi. Ah! Questo è un rischio molto interessante, che richiede uno sguardo più attento.
Vorrei iniziare affermando che non è il vero e proprio identity thats condivisi, piuttosto la prova di , o le credenziali di autenticazione. Va bene, dal momento che una password condivisa sarà effettivamente mi consentirà l'ingresso ad un altro sistema (ad esempio, il mio conto in banca, o gmail), questo è effettivamente la stessa identità, quindi è solo semantica ... Solo che Non . Identità è gestito separatamente da ciascun sistema, in questo scenario (anche se ci potrebbero essere i sistemi di terze parti, come ad esempio id OAuth - ancora, la sua separata dall'identità in questo sistema - ne parleremo più avanti).
Come tale, il punto centrale del rischio qui, è che l'utente volontariamente ingresso sua (stessa) la password in diversi sistemi diversi - e ora, io (l'amministratore) o qualsiasi altro di hacker del mio sito avrà accesso alle password di zia Erma per il sito missile nucleare.

Hmmm.

C'è qualcosa qui sembra fuori a voi?

Si dovrebbe.

Cominciamo con il fatto che la protezione del sistema di missili nucleari è non mia responsabilità , sono solo building un sito di famiglia gita frakkin (per la mia famiglia). Quindi, chi è la responsabilità? Umm ... Come circa il sistema di missili nucleari? Duh.
In secondo luogo, se avessi voluto rubare la password (qualcuno che è noto per più volte utilizzare la stessa password tra i siti sicuri e quelli non-così-sicure) di qualcuno - perché dovrei preoccuparsi di hacker tuo sito? O la lotta con il tuo crittografia simmetrica? Goshdarnitall, posso solo mettere in su il mio sito web semplice , avere gli utenti si iscrivono per ricevere notizia molto importante su quello che vogliono ... Puffo Presto, ho "rubato" le loro password.

Si, formazione degli utenti sempre vuol tornare a mordere noi nel hienie, non è vero?
E non c'è niente che tu possa fare che ... Anche se si dovesse hash le loro password sul vostro sito, e fare tutto il resto la TSA può pensare, si è aggiunto la protezione per la propria password NON UN BRICIOLO , se andranno a mantenere promiscuamente attaccare le proprie password in ogni sito che urtano. Non si preoccupano neppure di provare.

Detto in altro modo, non si possiede la propria password , in modo da smettere di cercare di agire come si fa.

Quindi, gli esperti di sicurezza mio caro, come una vecchia signora usato per chiedere Wendy, "Dov'è il rischio?"

Un altro paio di punti, in risposta ad alcune questioni sollevate sopra:

CWE non è una legge, o regolamento, o addirittura uno standard. Si tratta di una raccolta di debolezze comuni , vale a dire l'inverso di "Best Practices".
La questione dell'identità condiviso è un problema reale, ma frainteso (o travisato) dagli oppositori qui. Si tratta di un problema di condividere l'identità in sé e per sé (!), Non si tratta di violare la password su sistemi di basso valore. Se stai condividendo una password tra un basso valore e di un sistema di alto valore, il problema è già lì!
A proposito, il punto precedente sarebbe effettivamente indicare CONTRO utilizzando i sistemi ad alto valore bancari OAuth e simili per entrambi questi sistemi di basso valore, e.
So che era solo un esempio, ma (purtroppo) i sistemi FBI non sono davvero il più fissato attorno. Non proprio come i server del blog del vostro gatto, ma non fanno a superare alcune delle banche più sicure.
conoscenza Spalato, o doppio controllo, delle chiavi di crittografia non accadono solo in campo militare, infatti PCI-DSS ora richiede questo da praticamente tutti i commercianti, quindi la sua non ci davvero così lontano più (se il valore giustifica).
A tutti quelli che si lamentano che domande come queste sono ciò che rende la professione sviluppatore sembra così male: è risposte come quelle, che fanno la professione di sicurezza guardare anche peggio. Anche in questo caso, l'analisi dei rischi business focalizzato è ciò che è necessario, altrimenti ti fai inutile. Oltre ad essere sbagliato.
Credo che questo è il motivo per cui non è una buona idea di prendere solo uno sviluppatore regolare e rilasciare più responsabilità di sicurezza su di lui, senza l'addestramento a pensare in modo diverso, e di cercare i compromessi giusti. Senza offesa, a quelli di voi qui, sono tutti per esso - ma più formazione è in ordine

Accidenti. Che un lungo post ...
Ma per rispondere alla tua domanda iniziale, @Shane:

Illustrare al cliente il modo corretto di fare le cose.
Se insiste ancora, spiegare alcune di più, insistono, discutere. Capricci, se necessario.
Spiegare il rischio d'impresa a lui. I dettagli sono buone, le figure sono meglio, una dimostrazione dal vivo di solito è meglio.
se ancora insiste e presenta valide ragioni commerciali - è il momento per voi di fare una chiamata in giudizio:
È questo sito al basso al più alcun valore? E 'davvero un caso aziendale valida? E 'abbastanza buono per voi? Non ci sono altri rischi si possono prendere in considerazione, atti a compensare valide ragioni commerciali? (E, naturalmente, è il NON cliente un sito dannoso, ma questo è stato derubato).
Se è così, basta andare avanti a destra. Non vale la pena, l'attrito, e il loro utilizzo ha perso (in questa situazione ipotetica)mettere il necessario processo in atto. Qualsiasi altra decisione (ancora una volta, in questa situazione) è un cattivo compromesso.

Linea Così, in basso, e una risposta reale - cifrare con un semplice algoritmo simmetrico, proteggere la chiave di crittografia con ACL forti e preferibilmente DPAPI o simili, documentare e avere il client (qualcuno abbastanza anziano per prendere questa decisione) firmare su di esso.

Che ne dite di una casa di accoglienza?

Conservare le password con una crittografia forte, e non abilitare azzera.

Invece di reimpostazione delle password, consentire l'invio di una password one-time (che deve essere cambiato non appena si verifica il primo accesso). Lasciate che l'utente poi cambiare a tutto ciò la password che vogliono (il precedente, se scelgono).

Si può "vendere" questo come un meccanismo sicuro per la reimpostazione delle password.

L'unico modo per consentire a un utente di recuperare la password originale, è quello di cifrare con la propria chiave pubblica dell'utente. Solo che l'utente può quindi decifrare la loro password.

Quindi, la procedura potrebbe essere:

registri utente sul sito (su SSL ovviamente) senza ancora impostando una password. li Log in automatico o fornire una password temporanea.
Si offrono per memorizzare la loro chiave PGP pubblica per il futuro recupero della password.
Si caricare i loro chiave PGP pubblica.
Si chiede loro di impostare una nuova password.
Esse fanno valere la loro password.
hash la password utilizzando il miglior algoritmo di hashing della password disponibili (ad esempio bcrypt). Utilizzare questa funzione quando la convalida del successivo accesso.
crittografare la password con la chiave pubblica, e negozio che separatamente.

Qualora l'utente poi chiedere la password, si risponde con il (non hash) password crittografata. Se l'utente non vuole essere in grado di recuperare la propria password in futuro (che sarebbe solo in grado di ripristinarlo a un servizio generati uno), punti 3 e 7 possono essere saltati.

Credo che la vera domanda da porsi è: 'Come posso essere meglio a convincere la gente'

Ho lo stesso problema. E allo stesso modo in cui ho sempre pensato che qualcuno incidere il mio sistema non è una questione di "se", ma di "quando".

Così, quando devo fare un sito web che ha bisogno di memorizzare informazioni riservate recuperabile, come una carta di credito o di una password, quello che faccio è:

cifrare con: openssl_encrypt (string $ dati, string $ metodo, string $ password)
- manuale di PHP .
dati arg :
- le informazioni sensibili (ad esempio la password dell'utente)
- serializzare se necessario, ad esempio se l'informazione è un array di dati, come più informazioni sensibili
Password arg : utilizzare un'informazione che solo l'utente conosce come:
- la piastra di licenza con l'utente
- numero di previdenza sociale
- il numero di telefono dell'utente
- il nome utente madre
- una stringa casuale inviata dal email e / o cellulare al momento registro
metodo arg :
- scegliere un metodo di cifratura, come "AES-256-CBC"
Mai memorizzare le informazioni utilizzate nell'argomento "password" al database (o qualunque posto nel sistema)

Quando necessario retrive questi dati basta usare il "openssl_decrypt) (" la funzione e chiedere all'utente per la risposta. Es .: "Per ricevere la password di rispondere alla domanda:? Qual è il tuo numero di cellulare"

PS 1 : Non usare mai come password di dati memorizzati nel database. Se avete bisogno di memorizzare il numero utente del cellulare, quindi non utilizzare queste informazioni per codificare i dati. Utilizzare sempre un informazione che solo l'utente conosce o che è difficile sapere a qualcuno non parente.

PS 2 : per la carta di credito, come "uno scatto d'acquisto", quello che faccio è usare la password di accesso. Questa password viene hash nel database (SHA1, MD5, ecc), ma al momento del login mi memorizzare la password di testo semplice in sessione o in un non-persistente (vale a dire a memoria) cookie sicuro. Questa password plain mai rimanere in banca dati, anzi è sempre rimanere nella memoria, distrutta alla fine della sezione. Quando l'utente fa clic su "uno scatto d'acquisto" tasto del sistema di utilizzare questa password. Se l'utente è stato registrato con un servizio come Facebook, Twitter, ecc, poi ho indurre le password di nuovo a guadagnare tempo (ok, non è completamente "al clic") o quindi utilizzare alcuni dati del servizio che l'utente utilizzato per effettuare il login (come il facebook id).

Protezione delle credenziali non è un'operazione binaria: sicuro / non sicuro. La sicurezza è tutta una questione di valutazione dei rischi e viene misurata su un continuum. fanatici di sicurezza odiano a pensare in questo modo, ma la brutta verità è che nulla è perfettamente sicuro. le password hash con requisiti per la password rigorosi, campioni di DNA, e le scansioni della retina sono più sicuri, ma ad un costo di sviluppo e l'esperienza utente. password in chiaro sono molto meno sicuro, ma sono più economici da implementare (ma dovrebbe essere evitato). Alla fine della giornata, si tratta di un'analisi costi / benefici di una violazione. Per implementare la sicurezza in base al valore dei dati che vengono garantiti e il suo tempo-valore.

Qual è il costo della password di qualcuno uscire in libertà? Qual è il costo della rappresentazione nel sistema dato? Per i computer dell'FBI, il costo potrebbe essere enorme. Per una tantum sito web di cinque pagine di Bob, il costo potrebbe essere trascurabile. Un professionista fornisce opzioni per i loro clienti e, quando si tratta di sicurezza, delinea i vantaggi ei rischi di qualsiasi implementazione. Questo è doppiamente così se il client richiede qualcosa che li potrebbe mettere a rischio a causa di non riuscire a prestare attenzione gli standard del settore. Se un client richiede specificamente la crittografia a due vie, vorrei essere sicuri di documentare le obiezioni, ma che non si deve smettere di attuare nel modo migliore lo sai. Alla fine della giornata, è il denaro del cliente. Sì, si dovrebbe spingere per l'utilizzo di hash a senso unico, ma dire che è assolutamente l'unica scelta e quant'altro è etico è una sciocchezza assoluta.

Se si memorizzano le password con crittografia a due vie, la sicurezza Tutto si riduce alla gestione delle chiavi. Windows fornisce meccanismi per limitare l'accesso ai certificati chiavi private agli account amministrativi e con le password. Se si ospitano su altre piattaforma, si avrebbe bisogno di vedere quali opzioni si hanno a disposizione su quelli. Come altri hanno suggerito, è possibile utilizzare la crittografia asimmetrica.

Non esiste una legge (né la legge sulla protezione dei dati nel Regno Unito) di cui sono consapevole del fatto che prevede espressamente che le password devono essere memorizzati utilizzando hash a senso unico. L'unico requisito in una di queste leggi è semplicemente che ragionevole misure sono adottate per la sicurezza. Se l'accesso alla banca dati è limitato, anche le password in chiaro possono qualificarsi legalmente sotto una tale restrizione.

Tuttavia, questo mettere in luce più un aspetto: la precedenza legale. Se la precedenza legale suggerisce che è necessario utilizzare a senso unico hash dato il settore in cui si sta costruendo il vostro sistema, allora questo è completamente diverso. Ecco le munizioni da utilizzare per convincere il cliente. A parte ciò, il miglior consiglio per fornire una valutazione del rischio ragionevole, documentare le vostre obiezioni e implementare il sistema nel modo più sicuro possibile dato le esigenze del cliente.

Fare la risposta alla domanda di sicurezza per l'utente una parte della chiave di crittografia, e non conservare la risposta alla domanda di sicurezza come testo normale (hash che invece)

a implementare sistemi di autenticazione a più fattori per una vita, quindi per me è naturale pensare che è possibile ripristinare o ricostruire la password, mentre temporaneamente utilizzando uno dei fattori meno per autenticare l'utente solo per il flusso di lavoro di ripristino / ricreazione. In particolare l'uso di OTP (one-time password) come alcuni dei fattori aggiuntivi, attenua gran parte del rischio, se la finestra temporale è breve per il flusso di lavoro suggerito. Abbiamo implementato software generatori di OTP per gli smartphone (che la maggior parte degli utenti già portano con sé tutto il giorno) con grande successo. Prima si lamenta di una spina commerciale apparire, quello che sto dicendo è che siamo in grado di ridurre i rischi insiti di protezione delle password facilmente recuperabili o azzerabile quando non sono l'unico fattore utilizzato per autenticare un utente. Concedo che per il riutilizzo della password tra scenari siti la situazione non è ancora abbastanza, come l'utente insisterà per avere la password originale, perché lui / lei vuole aprire altri siti troppo, ma si può provare a fornire la password ricostruito in il modo più sicuro possibile (HTPPS e l'aspetto discreto sul html).

Siamo spiacenti, ma finché si dispone di un modo per decodificare la password, non c'è modo che sta per essere sicuro. Combatti amaramente, e se si perde, CYA.

Proprio imbattuto in questa discussione interessante e riscaldato. Quello che mi ha sorpreso la maggior parte però era, quanta poca attenzione è stata versata alla seguente domanda fondamentale:

Q1. Quali sono i motivi reali che l'utente insiste per avere accesso al testo normale password memorizzata? Perché è di tanto valore?

Le informazioni che gli utenti sono anziano o giovane in realtà non rispondere a questa domanda. Ma come una decisione di business può essere fatta senza preoccupazione corretta comprensione del cliente?

Ora perché è importante? Perché se la vera causa della richiesta dei clienti è il sistema che è dolorosamente difficile da usare, allora forse affrontando la causa esatta risolverebbe il problema reale?

Come io non ho queste informazioni e non posso parlare a quei clienti, posso solo immaginare:. Si tratta di usabilità, vedi sopra

Un'altra domanda che ho visto chiesto:

Q2. Se l'utente non ricorda la password al primo posto, perché ha importanza la vecchia password?

E qui è possibile risposta. Se avete gatto di nome "miaumiau" e usato il suo nome come password, ma ha dimenticato che hai fatto, si preferisce essere ricordato ciò che è stato o meglio inviato qualcosa come "# zy * RW (ew"?

Un'altra possibile ragione è che l'utente considera un duro lavoro per trovare una nuova password! Quindi, avendo la vecchia password rispedito dà l'illusione di averla salvata da quel doloroso lavoro di nuovo.

Sto solo cercando di capire il motivo. Ma qualunque sia la ragione è, è la ragione per cui non la causa che deve essere affrontato.

Come utente, voglio le cose semplici! Non voglio lavorare sodo!

Se il login per un sito di notizie per leggere i giornali, voglio digitare 1111 come password e essere attraverso !!!

So che è sicuro, ma che mi importa a qualcuno ottenere l'accesso al mio "conto"? Sì, può leggere le notizie troppo!

Fa il negozio le mie informazioni "private"? La notizia che ho letto oggi? Allora è il problema del sito, non il mio! Il sito mostra le informazioni privato a utente autenticato? Quindi non mostrano in primo luogo!

Questo è solo per dimostrare l'atteggiamento dell'utente al problema.

Quindi, per riassumere, non mi sento che è un problema di come "in modo sicuro" le password negozio di testo normale (che sappiamo essere impossibile), ma piuttosto come affrontare i clienti reale preoccupazione.

Manipolazione perso / password dimenticate:

Nessuno dovrebbe mai essere in grado di recuperare le password.

Se gli utenti hanno dimenticato la propria password, devono almeno conoscere i loro nomi utente o indirizzi e-mail. Su richiesta, generare un GUID nella tabella degli utenti e ha inviato una e-mail contenente un link che contiene il GUID come parametro per l'indirizzo e-mail dell'utente.

La pagina dietro il collegamento verifica che il parametro guid esiste davvero (probabilmente con una certa logica timeout), e chiede all'utente per una nuova password.

Se avete bisogno di avere utenti hotline di aiuto, aggiungere alcuni ruoli al modello sovvenzioni e permettere il ruolo hotline per accedere temporaneamente come utente identificato. Log tutti questi accessi hotline. Ad esempio, Bugzilla offre tale funzionalità di rappresentazione per gli amministratori.

Che dire di email la password in chiaro al momento della registrazione, prima di ottenerlo cifrato e ha perso? Ho visto un sacco di siti web farlo, e ottenere che la password da e-mail dell'utente è più sicuro di lasciarlo in giro sul vostro server / comp.

Se non si può semplicemente rifiutare l'obbligo di memorizzare le password recuperabili, come su questo come contro-argomento.

Possiamo o correttamente le password hash e costruire un meccanismo di ripristino per gli utenti, o siamo in grado di rimuovere tutte le informazioni personali dal sistema. È possibile utilizzare un indirizzo di posta elettronica per impostare le preferenze dell'utente, ma che su di esso. Utilizzare un cookie per tirare automaticamente le preferenze durante le visite successive e gettare i dati via dopo un periodo di tempo ragionevole.

L'unica opzione che viene spesso trascurato con la politica della password è se una password è davvero anche necessaria. Se l'unica cosa che la vostra politica di password non è causa chiamate al servizio clienti, forse si può sbarazzarsi di esso.

fare: gli utenti davvero necessità di recuperare (ad esempio sentirsi dire) ciò che la password si sono dimenticati fosse, o se invece semplicemente bisogno di essere in grado di ottenere sul sistema? Se ciò che vuole veramente è una password per l'accesso, perché non hanno una routine che cambia semplicemente la vecchia password (qualunque esso sia) ad una nuova password che la persona di sostegno può dare alla persona che ha perso la sua password?

Ho lavorato con i sistemi che fanno esattamente questo. La persona di sostegno non ha modo di sapere che cosa la password corrente è, ma può reimpostare un nuovo valore. Naturalmente tutti questi reset devono essere registrati da qualche parte e le buone prassi sarebbe quella di generare un e-mail per l'utente dicendogli che la password è stata ripristinata.

Un'altra possibilità è quella di avere due password simultanee che consentono l'accesso a un account. Uno è la password "normale" che l'utente gestisce e l'altro è come una chiave di scheletro / master che è conosciuto da solo il personale di supporto ed è lo stesso per tutti gli utenti. In questo modo quando un utente ha un problema la persona di sostegno può accedere al conto con la chiave master e aiutare l'utente a cambiare la propria password a tutto ciò. Inutile dire che tutti i login con la chiave master devono essere registrati dal sistema pure. Come misura supplementare, ogni volta che si utilizza la chiave master è possibile convalidare le credenziali di supporto persone pure.

operativa -Editazione- In risposta alle osservazioni di non avere una chiave master: Sono d'accordo che è male come io credo che sia male per consentire a chiunque altro che all'utente di avere accesso al conto dell'utente. Se si guarda alla domanda, l'intera premessa è che il cliente ha incaricato un ambiente di sicurezza altamente compromessa.

Una chiave master non deve essere così male come potrebbe sembrare a prima vista. Ho usato per lavorare in un impianto di difesa dove hanno percepito la necessità per l'operatore di computer mainframe di avere "accesso speciale" in certe occasioni. Hanno semplicemente messo la password speciale in una busta sigillata e nastrate alla scrivania dell'operatore. Per utilizzare la password (che l'operatore non lo sapeva) ha dovuto aprire la busta. Ad ogni cambio di turno uno dei lavori del capoturno era di vedere se la busta era stata aperta e se così hanno subito la password modificata (da un altro dipartimento) e la nuova password è stata messa in una nuova busta e il processo è iniziato tutto di nuovo. L'operatore sarebbe stato interrogato sul motivo per cui aveva aperto e l'incidente sarebbe stato documentato per il record.

Anche se questa non è una procedura che vorrei progettare, ha funzionato e ha fornito per un'eccellente affidabilità. Tutto è stato registrato e rivisto, oltre a tutti gli operatori avevano distanze segrete DOD e non abbiamo mai avuto alcun abusi.

A causa della revisione e supervisione, tutti gli operatori sapevano che se avessero abusato del privilegio di aprire la busta erano soggetti a licenziamento immediato e possibile azione penale.

Quindi credo che la vera risposta è se si vuole fare le cose quella giusta assume persone che possono fidarsi, fare un controllo dei precedenti e di esercitare un adeguato controllo di gestione e la responsabilità.

Ma poi di nuovo se il cliente questo poveretto ha avuto una buona gestione non avrebbero chiesto una soluzione di sicurezza comprimised, in primo luogo, ora dovrebbero?

Da quel poco che ho capito su questo argomento, credo che se si sta costruendo un sito web con un profilo di accesso / password, allora si dovrebbe nemmeno vedere la password in chiaro sul server a tutti. La password deve essere hash, e, probabilmente, salato, prima di lasciare anche il cliente.

Se non vedi mai la password in chiaro, allora la domanda di recupero non si pone.

Inoltre, mi sembra di capire (dal web) che (presumibilmente) alcuni algoritmi come MD5 non sono più considerati sicuri. Non ho modo di giudicare io stesso, ma è una cosa da considerare.

aprire un DB su un server autonomo e dare un collegamento remoto cifrato per ogni server web che richiede questa funzionalità.
non deve essere un DB relazionale, può essere un file di sistema con accesso FTP, utilizzando le cartelle e file, invece di tabelle e righe.
dare i server web permessi di scrittura solo se è possibile.

Conservare la crittografia non recuperabili della password nel DB del sito (chiamiamola "pass-a"), come le persone normali :)
su ogni nuovo utente (o modifica della password) memorizzare una copia semplice della password nel DB remoto. utilizzare l'ID del server, l'ID dell'utente e "pass-un", come una chiave composta per questa password. si può anche utilizzare una crittografia bidirezionale sulla password per dormire meglio la notte.

Ora, al fine di qualcuno per ottenere sia la password e si tratta di contesto (sito id + id utente + "pass-a"), deve:

hackerare DB del sito web per ottenere un (user id "pass-un",) coppia o coppie.
ottenere l'ID del sito web da parte di alcuni file di configurazione
trovare e hackerare le password remote DB.

è possibile controllare l'accessibilità del servizio di recupero della password (esporla solo come un servizio web protetta, consentire solo certa quantità di password recuperi al giorno, farlo manualmente, ecc), e anche pagare extra per questo "speciali di sicurezza disposizione".
Il DB server password recupero è abbastanza nascosto in quanto non servono molte funzioni e può essere meglio garantiti (è possibile personalizzare le autorizzazioni, processi e servizi strettamente).

tutto sommato, si effettua il lavoro più difficile per l'hacker. la possibilità di una violazione della sicurezza su ogni singolo server è sempre lo stesso, ma i dati significativi (una partita di account e password) sarà difficile da assemblare.

Un'altra opzione potrebbe non avere considerato sta permettendo azioni via e-mail. E 'un po' ingombrante, ma ho implementato questo per un cliente che aveva bisogno di utenti "fuori" il loro sistema per visualizzare (sola lettura) alcune parti del sistema. Ad esempio:

Una volta che un utente è registrato, essi hanno accesso completo (come un normale sito web). La registrazione deve includere una e-mail.
Se sono necessari dati o un'azione e l'utente non lo fa ricordare la propria password, possono ancora eseguire l'azione da clic su un " e-mail me per il permesso" speciale pulsante, proprio accanto al regolare " Invia " pulsante.

La richiesta viene quindi inviato alla mail con un collegamento ipertestuale che chiede se vogliono l'azione da eseguire. Questo è simile a un collegamento e-mail la reimpostazione della password, ma invece di reimpostare la password si esegue la di una volta l'azione .

L'utente quindi fa clic su "Sì", e conferma che i dati devono essere mostrati, o deve essere eseguita l'azione, dati hanno rivelato, ecc.

Come lei ha ricordato nei commenti, questo non funziona se l'email è compromessa, ma lo fa un commento di indirizzo @joachim s' di non voler reimpostare la password. Alla fine, avrebbero dovuto utilizzare la reimpostazione della password, ma potrebbero farlo in un momento più conveniente, o con l'assistenza di un amministratore o un amico, a seconda delle necessità.

Una torsione a questa soluzione sarebbe quella di inviare la richiesta di azione a un amministratore di fiducia di terze parti. Questo potrebbe funzionare meglio nei casi con gli anziani utenti molto giovani o meno confuse, mentalmente disabili,. Naturalmente questo richiede un amministratore di rinomata per queste persone per sostenere le loro azioni.

Sale e hash della password dell'utente come normale. Quando si accede l'utente, consentire sia la password dell'utente (dopo la salatura / hashing), ma anche permettere ciò che l'utente è entrato letteralmente per abbinare anche.

Questo permette all'utente di inserire la propria password segreta, ma consente anche loro di entrare alla versione / hash salata della propria password, che è quello che qualcuno avrebbe letto dal database.

In sostanza, rendono la password / hash salata essere anche un "testo semplice" password.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow