Come dovrei affrontare eticamente l'archiviazione della password dell'utente per il successivo recupero del testo in chiaro?

Mentre continuo a creare sempre più siti Web e applicazioni Web, mi viene spesso chiesto di archiviare le password degli utenti in modo tale che possano essere recuperate se / quando l'utente ha un problema (inviare tramite e-mail un collegamento con password dimenticata, passarle attraverso il telefono, ecc.) Quando posso lottare amaramente contro questa pratica e faccio molta programmazione "extra" per rendere possibili la reimpostazione della password e l'assistenza amministrativa senza memorizzare la password effettiva.

Quando non riesco a combatterlo (o non riesco a vincere) allora codifico sempre la password in qualche modo in modo che, almeno, non sia memorizzata come testo normale nel database, anche se sono consapevole che se il mio DB viene violato non ci vorrebbe molto perché il colpevole decifrasse le password, quindi questo mi mette a disagio.

In un mondo perfetto, le persone aggiornano le password frequentemente e non le duplicano su molti siti diversi, sfortunatamente conosco MOLTE persone che hanno la stessa password lavoro / casa / e-mail / banca e me l'hanno persino dato liberamente quando hanno bisogno di assistenza. Non voglio essere il responsabile della loro crisi finanziaria se le mie procedure di sicurezza del DB falliscono per qualche motivo.

Moralmente ed eticamente mi sento responsabile della protezione di ciò che può essere, per alcuni utenti, il loro sostentamento anche se lo stanno trattando con molto meno rispetto. Sono certo che ci sono molte strade da avvicinare e argomenti da fare per salare gli hash e le diverse opzioni di codifica, ma c'è una sola "best practice" quando devi memorizzarli? In quasi tutti i casi sto usando PHP e MySQL se questo fa la differenza nel modo in cui dovrei gestire le specifiche.

Informazioni aggiuntive per Bounty

Voglio chiarire che so che questo non è qualcosa che vuoi fare e che nella maggior parte dei casi il rifiuto di farlo è meglio. Tuttavia, non sto cercando una lezione sul merito di adottare questo approccio. Sto cercando i passi migliori da seguire se segui questo approccio.

In una nota che segue ho sottolineato che i siti Web orientati in gran parte verso gli anziani, i disabili mentali o i giovani possono diventare fonte di confusione per le persone quando viene loro chiesto di eseguire una routine di recupero della password sicura. Sebbene possiamo trovarlo semplice e banale in quei casi, alcuni utenti hanno bisogno dell'assistenza extra di avere una tecnologia di servizio che li aiuti nel sistema o di averlo inviato via email / visualizzato direttamente a loro.

In tali sistemi il tasso di attrito da questi dati demografici potrebbe ostacolare l'applicazione se agli utenti non fosse fornito questo livello di assistenza per l'accesso, quindi si prega di rispondere con una tale impostazione in mente.

Grazie a tutti

Questa è stata una domanda divertente con molti dibattiti e mi è piaciuto. Alla fine ho selezionato una risposta che mantiene sia la sicurezza della password (non dovrò mantenere il testo semplice né le password recuperabili), ma rende anche possibile per la base di utenti che ho specificato accedere a un sistema senza i principali inconvenienti da cui ho trovato normale recupero della password.

Come sempre c'erano circa 5 risposte che avrei voluto contrassegnare come corrette per diversi motivi, ma ho dovuto scegliere la migliore - tutto il resto ha ottenuto un +1. Grazie a tutti!

Inoltre, grazie a tutti i membri della comunità Stack che hanno votato per questa domanda e / o contrassegnata come preferita. Prendo il 100% dei voti come complimento e spero che questa discussione abbia aiutato qualcun altro con la stessa preoccupazione che avevo.

Che ne dite di adottare un altro approccio o angolo a questo problema? Chiedi perché la password deve essere in testo normale: se è così che l'utente può recuperare la password, quindi a rigor di termini non è necessario recuperare la password impostata (non si ricordano comunque di cosa si tratta), tu devono essere in grado di fornire loro una password che possono usare .

Pensaci: se l'utente deve recuperare la password, è perché l'hanno dimenticata. Nel qual caso una nuova password è valida quanto la vecchia. Ma uno degli svantaggi dei comuni meccanismi di reimpostazione della password utilizzati oggi è che le password generate prodotte in un'operazione di reimpostazione sono generalmente un gruppo di caratteri casuali, quindi sono difficili per l'utente semplicemente digitare correttamente se non copiano-n- incolla. Questo può essere un problema per gli utenti di computer meno esperti.

Un modo per aggirare questo problema è fornire password generate automaticamente che sono più o meno testi in linguaggio naturale. Mentre le stringhe di linguaggio naturale potrebbero non avere l'entropia di una stringa di caratteri casuali della stessa lunghezza, non c'è nulla che dica che la password generata automaticamente deve contenere solo 8 (o 10 o 12) caratteri. Ottieni una passphrase generata automaticamente ad alta entropia mettendo insieme più parole casuali (lascia uno spazio tra loro, quindi sono ancora riconoscibili e tipizzabili da chiunque sia in grado di leggere). Sei parole casuali di diversa lunghezza sono probabilmente più facili da digitare correttamente e con sicurezza rispetto a 10 caratteri casuali e possono anche avere un'entropia più elevata. Ad esempio, l'entropia di una password di 10 caratteri disegnata casualmente da lettere maiuscole, minuscole, cifre e 10 simboli di punteggiatura (per un totale di 72 simboli validi) avrebbero un'entropia di 61,7 bit. Usando un dizionario di 7776 parole (come usa Diceware) che potrebbe essere selezionato in modo casuale per una passphrase di sei parole, la passphrase avrebbe un'entropia di 77,4 bit. Vedi ilDomande frequenti sul Diceware per maggiori informazioni.

• una passphrase con circa 77 bit di entropia: "ammettere flauto acuto da tavolo svasato prosa"

• una password con circa 74 bit di entropia: "K: & $ R ^ tt ~ qkD"

So che preferirei digitare la frase, e con copy-n-paste, la frase non è meno facile da usare della password, quindi nessuna perdita lì. Naturalmente se il tuo sito Web (o qualunque sia la risorsa protetta) non necessita di 77 bit di entropia per una passphrase generata automaticamente, genera meno parole (che sono sicuro che i tuoi utenti apprezzerebbero).

Comprendo gli argomenti secondo cui esistono risorse protette 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. Ad esempio, probabilmente non mi importerebbe se l'80% delle password che utilizzo su vari siti Web fosse stato violato: tutto ciò che potrebbe accadere è che qualcuno invii spam o invii messaggi a mio nome per un po '. Non sarebbe grandioso, ma non è come se si fossero introdotti nel mio conto bancario. Tuttavia, dato che molte persone usano la stessa password per i loro siti di forum Web come fanno per i loro conti bancari (e probabilmente database di sicurezza nazionali), penso che sarebbe meglio gestire anche quelle password di "basso valore" come non -recuperabile.

Immagina che qualcuno abbia commissionato la costruzione di un grande edificio - un bar, diciamo - e che abbia luogo la seguente conversazione:

Architetto: per un edificio di queste dimensioni e capacità, avrai bisogno di uscite di sicurezza qui, qui e qui.
Cliente: No, è troppo complicato e costoso da mantenere, non voglio porte laterali o porte posteriori.
Architetto: signore, le uscite antincendio non sono opzionali, sono richieste secondo il codice antincendio della città.
Cliente: Non ti pago per discutere. Fai solo quello che ti ho chiesto.

L'architetto chiede quindi come costruire eticamente questo edificio senza uscite antincendio?

Nel settore dell'edilizia e dell'ingegneria, è molto probabile che la conversazione finisca in questo modo:

Architetto: questo edificio non può essere costruito senza uscite antincendio. Puoi andare da qualsiasi altro professionista autorizzato e ti dirà la stessa cosa. Me ne sto andando adesso; richiamami quando sei pronto a collaborare.

La programmazione informatica potrebbe non essere una professione autorizzata , ma le persone spesso sembrano chiedersi perché la nostra professione non abbia lo stesso rispetto di un ingegnere civile o meccanico - beh, non cercate oltre. Quelle professioni, quando vengono consegnate spazzatura (o requisiti assolutamente pericolosi), semplicemente rifiuteranno. Sanno che non è una scusa per dire "beh, ho fatto del mio meglio, ma ha insistito e devo fare quello che dice". Potrebbero perdere la licenza per quella scusa.

Non so se tu o i tuoi clienti fate parte di qualsiasi società quotata in borsa, ma la memorizzazione di password in qualsiasi forma recuperabile causerebbe il fallimento di diversi tipi di audit di sicurezza. Il problema non è quanto sarebbe difficile per alcuni "hacker" che hanno avuto accesso al tuo database per recuperare le password. La stragrande maggioranza delle minacce alla sicurezza sono interne. Ciò di cui hai bisogno per proteggere è un dipendente scontento che se ne va con tutte le password e le vende al miglior offerente. L'uso della crittografia asimmetrica e l'archiviazione della chiave privata in un database separato non fa assolutamente nulla per prevenire questo scenario; ci sarà sempre qualcuno con accesso al database privato, e questo è un grave rischio per la sicurezza.

Non esiste un modo etico o responsabile per archiviare le password in una forma recuperabile. Periodo.

È possibile crittografare la password + un salt con una chiave pubblica. Per gli accessi basta verificare se il valore memorizzato è uguale al valore calcolato dall'input dell'utente + salt. Se arriva un momento, quando è necessario ripristinare la password in testo normale, è possibile decrittografare manualmente o semi-automaticamente con la chiave privata. La chiave privata può essere memorizzata altrove e può inoltre essere crittografata simmetricamente (che quindi avrà bisogno di un'interazione umana per decrittografare la password).

Penso che questo sia in realtà un po 'simile al modo in cui funziona l' agente di recupero di Windows .

• Le password sono memorizzate crittografate
• Le persone possono accedere senza decodificare in testo semplice
• Le password possono essere ripristinate in testo semplice, ma solo con una chiave privata, che può essere memorizzata al di fuori del sistema (in una banca sicura, se si desidera).

Non mollare. L'arma che puoi usare per convincere i tuoi clienti è la non ripudio. Se puoi ricostruire le password degli utenti tramite qualsiasi meccanismo, hai fornito ai loro clienti un meccanismo legale di non ripudio e possono ripudiare qualsiasi transazione che dipende da quella password, perché non è possibile che il fornitore possa dimostrare di non aver ricostruito la password e mettere la transazione attraverso se stessi. Se le password sono correttamente memorizzate come digest piuttosto che come testo cifrato, questo è impossibile, ergo o il cliente finale ha eseguito la transazione da solo o ha violato il suo dovere di diligenza con la password. In entrambi i casi questo lascia la responsabilità esattamente con lui. Ho lavorato su casi in cui ciò ammonterebbe a centinaia di milioni di dollari. Non qualcosa che vuoi sbagliare.

Non è possibile archiviare eticamente le password per il successivo recupero del testo in chiaro. E 'così semplice. Persino Jon Skeet non può eticamente archiviare le password per il successivo recupero del testo in chiaro. Se i tuoi utenti possono recuperare le password in testo normale in un modo o nell'altro, anche potenzialmente un hacker può trovare una vulnerabilità di sicurezza nel tuo codice. E questa non è solo la password di un utente compromessa, ma tutte.

Se i tuoi clienti hanno un problema, dì loro che archiviare le password in modo recuperabile è contro la legge. Qui nel Regno Unito in ogni caso, il Data Protection Act 1998 (in particolare, Allegato 1, Parte II, Paragrafo 9) impone ai responsabili del trattamento dei dati di utilizzare le misure tecniche appropriate per proteggere i dati personali, tenendo conto, tra l'altro, del danno che potrebbe essere causato se i dati fossero compromessi, il che potrebbe essere considerevole per gli utenti che condividono le password tra i siti. Se hanno ancora problemi a capire il fatto che si tratta di un problema, indicali ad alcuni esempi del mondo reale, come questo .

Il modo più semplice per consentire agli utenti di recuperare un accesso è inviare loro via e-mail un collegamento singolo che li accede automaticamente e li porta direttamente a una pagina in cui possono scegliere una nuova password. Crea un prototipo e mostralo in azione.

Ecco un paio di post sul blog che ho scritto sull'argomento:

• http://jamesmckay.net/2009/09/if-you-are-saving-passwords-in-clear-text-you-are-probably-breaking-the-law/
• http://jamesmckay.net/2008/06/easy-login-recovery-without-compromising-security/

Aggiornamento: ora stiamo iniziando a vedere azioni legali e azioni penali contro le aziende che non riescono a proteggere correttamente le password dei loro utenti. Esempio: LinkedIn schiaffeggiato con una causa legale di 5 milioni di dollari ; Sony ha multato £ 250.000 per l'hacking di dati PlayStation . Se ricordo bene, LinkedIn stava effettivamente crittografando le password dei suoi utenti, ma la crittografia che stava usando era troppo debole per essere efficace.

Dopo aver letto questa parte:

In una nota che segue ho sottolineato che i siti Web orientati in gran parte verso gli anziani, i disabili mentali o i giovani possono diventare fonte di confusione per le persone quando viene loro chiesto di eseguire una routine di recupero della password sicura. Sebbene possiamo trovarlo semplice e banale in quei casi, alcuni utenti hanno bisogno dell'assistenza extra di avere una tecnologia di servizio che li aiuti nel sistema o di averlo inviato via email / visualizzato direttamente a loro.

In tali sistemi il tasso di attrito da questi dati demografici potrebbe ostacolare l'applicazione se agli utenti non fosse fornito questo livello di assistenza per l'accesso, quindi si prega di rispondere con una tale impostazione in mente.

Mi chiedo se qualcuno di questi requisiti imponga un sistema di password recuperabile. Ad esempio: zia Mabel chiama e dice "Il tuo programma Internet non funziona, non conosco la mia password". "OK" dice il drone del servizio clienti "fammi controllare alcuni dettagli e poi ti darò una nuova password . Al tuo prossimo accesso ti chiederà se vuoi conservare quella password o cambiarla in qualcosa che ricordi più facilmente."

Quindi il sistema è impostato per sapere quando è avvenuta la reimpostazione della password e visualizzare un messaggio "vuoi conservare la nuova password o sceglierne una nuova".

In che modo è peggio per i meno esperti di PC che ricevere la loro vecchia password? E mentre il servizio clienti può mettersi al riparo, il database stesso è molto più sicuro in caso di violazione.

Commenta ciò che è male sul mio suggerimento e suggerirò una soluzione che fa effettivamente ciò che inizialmente volevi.

Michael Brooks è stato piuttosto vocale su CWE-257 - il fatto che qualunque metodo tu usi, tu (l'amministratore) puoi ancora recuperare la password. Che ne dici di queste opzioni:

1. Crittografa la password con la chiave pubblica di qualcun altro - un'autorità esterna. In questo modo non è possibile ricostruirlo personalmente e l'utente dovrà rivolgersi a tale autorità esterna e chiedere il recupero della password.
2. Crittografa la password utilizzando una chiave generata da una seconda passphrase. Esegui questa crittografia lato client e non trasmetterla mai in chiaro al server. Quindi, per ripristinare, eseguire di nuovo la decrittografia lato client rigenerando la chiave dal loro input. Certo, questo approccio utilizza fondamentalmente una seconda password, ma puoi sempre dire loro di scriverla o utilizzare il vecchio approccio alla domanda di sicurezza.

Penso che 1. sia la scelta migliore, perché ti consente di designare qualcuno all'interno dell'azienda del cliente per detenere la chiave privata. Assicurati che generino loro stessi la chiave e la memorizzino con le istruzioni in una cassetta di sicurezza ecc. Potresti persino aggiungere sicurezza scegliendo di crittografare e fornire solo determinati caratteri dalla password alla terza parte interna in modo che debbano decifrare la password per indovinare esso. Fornendo questi personaggi all'utente, probabilmente ricorderanno di cosa si trattava!

Si è discusso molto dei problemi di sicurezza dell'utente in risposta a questa domanda, ma vorrei aggiungere una menzione dei vantaggi. Finora, non ho visto un vantaggio legittimo menzionato per avere una password recuperabile memorizzata sul sistema. Considera questo:

• L'utente trae vantaggio dall'invio della password tramite e-mail? 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 si ricordi.
• L'utente beneficia della visualizzazione della password sullo schermo? No, per lo stesso motivo di cui sopra; dovrebbero scegliere una nuova password.
• L'utente trae vantaggio dall'avere un tecnico dell'assistenza che comunica la password all'utente? No; di nuovo, se la persona dell'assistenza ritiene che la richiesta dell'utente per la propria password sia autenticata correttamente, è più vantaggioso per l'utente ricevere una nuova password e l'opportunità di cambiarla. Inoltre, l'assistenza telefonica è più costosa dei ripristini automatici delle password, quindi anche l'azienda non ne beneficia.

Sembra che le uniche che possano beneficiare di password recuperabili siano quelle con intenzioni dannose o i sostenitori di API scadenti che richiedono lo scambio di password di terze parti (per favore non usare mai tali API!). Forse puoi vincere la tua argomentazione affermando sinceramente ai tuoi clienti che la società non ottiene alcun vantaggio e solo responsabilità archiviando le password recuperabili .

Leggendo tra le righe di questi tipi di richieste, vedrai che i tuoi clienti probabilmente non capiscono o addirittura si preoccupano del modo in cui vengono gestite le password. Quello che vogliono veramente è un sistema di autenticazione che non sia così difficile per i loro utenti. Quindi, oltre a dire loro come in realtà non vogliono password recuperabili, dovresti offrire loro i modi per rendere il processo di autenticazione meno doloroso, soprattutto se non hai bisogno dei pesanti livelli di sicurezza di una banca:

• Consentire all'utente di utilizzare il proprio indirizzo e-mail per il proprio nome utente. Ho visto innumerevoli casi in cui l'utente dimentica il proprio nome utente, ma pochi dimenticano il loro indirizzo e-mail.
• Offri OpenID e consenti a terzi di pagare i costi dell'oblio dell'utente.
• Semplifica le restrizioni sulla password. Sono sicuro che siamo stati tutti incredibilmente infastiditi quando alcuni siti web non consentono la tua password preferita a causa di requisiti inutili come "non puoi usare caratteri speciali" o "la tua password è troppo lunga" o "la tua password deve iniziare con una lettera ". Inoltre, se la facilità d'uso è una preoccupazione maggiore rispetto alla sicurezza delle password, è possibile allentare anche i requisiti non stupidi consentendo password più brevi o non richiedendo una combinazione di classi di caratteri. Con restrizioni allentate, gli utenti avranno maggiori probabilità di utilizzare una password che non dimenticheranno.
• Non scadere le password.
• Consenti all'utente di riutilizzare una vecchia password.
• Consenti all'utente di scegliere la propria domanda di reimpostazione della password.

Ma se tu, per qualche motivo (e per favore, dicci il motivo) , davvero, davvero , devi davvero essere in grado di avere una password recuperabile, potresti proteggere l'utente dal potenzialmente compromettere gli altri suoi account online dando loro una non password- sistema di autenticazione basato. Poiché le persone hanno già familiarità con i sistemi nome utente / password e sono una soluzione ben esercitata, questa sarebbe l'ultima risorsa, ma ci sono sicuramente molte alternative creative alle password:

• Consentire all'utente di scegliere un pin numerico, preferibilmente non a 4 cifre, e preferibilmente solo se i tentativi di forza bruta sono protetti contro.
• Chiedi all'utente di scegliere una domanda con una breve risposta alla quale solo loro conoscono la risposta, che non cambierà mai, che ricorderanno sempre e che non gli dispiace che gli altri lo scoprano.
• Chiedi all'utente di inserire un nome utente e quindi disegna una forma facile da ricordare con permutazioni sufficienti per proteggerti dalle ipotesi (vedi questa elegante foto di come il G1 fa questo per sbloccare il telefono).
• Per un sito Web per bambini, potresti generare automaticamente una creatura fuzzy in base al nome dell'utente (una specie di identicon) e chiedere all'utente di dare alla creatura un nome segreto. A loro può quindi essere richiesto di inserire il nome segreto della creatura per accedere.

In base al commento che ho fatto sulla domanda:
un punto importante è stato chiarito da quasi tutti ... La mia reazione iniziale è stata molto simile a @Michael Brooks, fino a quando ho capito, come @stefanw, che il problema qui è rotto , ma questi sono quelli che sono.
Ma poi mi è venuto in mente che potrebbe non essere nemmeno il caso! Il punto mancante qui è il valore non dichiarato delle risorse dell'applicazione. In parole povere, per un sistema di basso valore, un meccanismo di autenticazione completamente sicuro, con tutto il processo coinvolto, sarebbe eccessivo e la scelta di sicurezza sbagliata .
Ovviamente, per una banca, le "migliori pratiche" sono un must e non c'è modo di violare eticamente CWE-257. Ma è facile pensare a sistemi di basso valore in cui non ne vale la pena (ma è ancora necessaria una semplice password).

È importante ricordare che la vera competenza in materia di sicurezza consiste nel trovare opportuni compromessi, NON nel diffondere dogmaticamente le "Best Practices" che chiunque può leggere online.

Come tale, suggerisco un'altra soluzione: a
seconda del valore del sistema e SOLO SE il sistema ha un valore adeguatamente basso senza risorse "costose" (l'identità stessa, inclusa) E ci sono requisiti aziendali validi che rendono il processo corretto impossibile (o sufficientemente difficile / costoso), E il cliente è a conoscenza di tutti gli avvertimenti ...
Quindi potrebbe essere appropriato consentire semplicemente la crittografia reversibile, senza che siano presenti cerchi speciali.
Mi sto fermando poco prima di dire di non disturbare affatto con la crittografia, perché è molto semplice / economico da implementare (anche considerando la gestione di chiavi passabili) e fornisce QUALCHE protezione (oltre al costo di implementazione). Inoltre, vale la pena guardare a come fornire all'utente la password originale, sia via e-mail, visualizzazione sullo schermo, ecc.
Poiché il presupposto qui è che il valore della password rubata (anche in aggregato) è piuttosto basso, nessuno dei queste soluzioni possono essere valide.

Dato che è in corso una vivace discussione, in realtà TANTE discussioni vivaci, nei diversi post e thread di commenti separati, aggiungerò alcuni chiarimenti e risponderò ad alcuni degli ottimi punti che sono stati sollevati altrove qui.

Per iniziare, penso che sia chiaro a tutti qui che consentire il recupero della password originale dell'utente, è una cattiva pratica e generalmente non è una buona idea. Questo non è affatto in discussione ...
Inoltre, sottolineo che in molte, anzi MOLTO, situazioni - è davvero sbagliato, persino disgustoso, cattivo e brutto .

Tuttavia, il nocciolo della questione è attorno al principio , esiste una situazione in cui potrebbe non essere necessario vietarlo e, in tal caso, come farlo nel modo più corretto appropriato alla situazione .

Ora, come hanno menzionato @Thomas, @sfussenegger e pochi altri, l'unico modo corretto per rispondere a questa domanda è fare un'analisi approfondita del rischio di qualsiasi situazione (o ipotetica) data, per capire cosa è in gioco, quanto vale proteggere e quali altre mitigazioni sono in gioco per garantire tale protezione.
No, NON è una parola d'ordine, questo è uno degli strumenti di base e più importanti per un professionista della sicurezza reale. Le migliori pratiche sono buone fino a un certo punto (di solito come linee guida per gli inesperti e gli hack), dopo che ha preso il sopravvento un'analisi ponderata del rischio.

Sai, è divertente - mi sono sempre considerato uno dei fanatici della sicurezza, e in qualche modo sono dalla parte opposta di quei cosiddetti "Esperti di sicurezza" ... Beh, la verità è - perché sono un fanatico, e un vero esperto di sicurezza nella vita reale - Non credo nel gettare dogma "Best Practice" (o CWE) SENZA quell'importantissima analisi del rischio .
"Attenti al fanatico della sicurezza che è rapido ad applicare tutto nella propria cintura degli strumenti senza sapere quale sia il vero problema contro cui stanno difendendo. Più sicurezza non equivale necessariamente a una buona sicurezza."
L'analisi del rischio e i veri fanatici della sicurezza indicherebbero un compromesso più intelligente, basato sul valore / basato sul rischio, basato su rischio, perdita potenziale, possibili minacce, mitigazioni complementari, ecc. Qualsiasi "Esperto della sicurezza" che non può indicare un'analisi del rischio come la base per le loro raccomandazioni o il supporto di compromessi logici, ma preferirebbe invece spargere dogma e CWE senza nemmeno capire come eseguire un'analisi del rischio, non sono altro che Security Hacks e la loro competenza non vale la carta igienica su cui l'hanno stampata.

In effetti, è così che otteniamo il ridicolo che è la sicurezza aeroportuale.

Ma prima di parlare dei compromessi appropriati da effettuare in QUESTA SITUAZIONE, diamo un'occhiata ai rischi apparenti (apparente, perché non abbiamo tutte le informazioni di base su questa situazione, stiamo tutti ipotizzando - poiché la domanda è quale ipotetico potrebbe esserci una situazione ...)
Supponiamo che un sistema a BASSO VALORE, ma non così trivalente da renderlo pubblico - il proprietario del sistema vuole impedire la rappresentazione casuale, ma la sicurezza "alta" non è così semplice come la facilità d'uso. (Sì, è un compromesso legittimo ACCETTARE il rischio che qualsiasi esperto script-kiddie possa hackerare il sito ... Aspetta, APT non è in voga ora ...?)
Ad esempio, supponiamo che sto organizzando un sito semplice per una riunione di famiglia numerosa, consentendo a tutti di fare brainstorming su dove vogliamo andare in campeggio quest'anno. Sono meno preoccupato per un hacker anonimo, o anche per il cugino Fred che spinge in ripetuti suggerimenti per tornare al lago Wantanamanabikiliki, poiché sono zia Erma che non è in grado di accedere quando è necessario. Ora, la zia Erma, essendo un fisico nucleare, non è molto brava a ricordare le password, o persino a usare i computer ... Quindi voglio rimuovere ogni attrito possibile per lei. Ancora una volta, NON sono preoccupato per gli hack, non voglio solo sciocchi errori di accesso errato - voglio sapere chi sta arrivando e cosa vogliono.

Comunque.
Quindi quali sono i nostri principali rischi qui, se crittografiamo simmetricamente le password, invece di utilizzare un hash unidirezionale?

• Impersonare gli utenti? No, ho già accettato quel rischio, non interessante.
• Amministratore malvagio? Beh, forse ... Ma ancora una volta, non mi interessa se qualcuno può impersonare un altro utente, INTERNO o no ... e comunque un amministratore malintenzionato otterrà la tua password, qualunque cosa accada - se il tuo amministratore è andato male, il suo gioco comunque.
• Un altro problema che è stato sollevato è che l'identità è effettivamente condivisa tra diversi sistemi. Ah! Questo è un rischio molto interessante, che richiede uno sguardo più attento.
  Vorrei iniziare affermando che non è l' identità reale condivisa, piuttosto la prova o le credenziali di autenticazione. Va bene, poiché una password condivisa mi consentirà di accedere a un altro sistema (ad esempio, il mio conto bancario o Gmail), questa è effettivamente la stessa identità, quindi è solo una semantica ... Tranne che non lo è . L'identità è gestita separatamente da ciascun sistema, in questo scenario (anche se potrebbero esserci sistemi ID di terze parti, come OAuth - ancora, è separato dall'identità in questo sistema - ne parleremo più avanti).
  Pertanto, il punto centrale del rischio qui è che l'utente inserirà volentieri la sua (stessa) password in diversi sistemi - e ora io (l'amministratore) o qualsiasi altro hacker del mio sito avremo accesso alle password di zia Erma per il sito missilistico nucleare.

Hmmm.

Ti sembra qualcosa qui?

Dovrebbe.

Cominciamo dal fatto che proteggere il sistema missilistico nucleare non è una mia responsabilità , sto solo costruendo un sito di uscite per la famiglia di frakkin (per la MIA famiglia). Quindi di chi è la responsabilità? Umm ... E il sistema missilistico nucleare? Duh.
In secondo luogo, se volessi rubare la password di qualcuno (qualcuno che è noto per utilizzare ripetutamente la stessa password tra siti sicuri e siti non così sicuri), perché dovrei preoccuparmi di hackerare il tuo sito? O alle prese con la tua crittografia simmetrica? Accidenti, posso semplicemente creare il mio semplice sito Web , fare iscrivere gli utenti per ricevere NOTIZIE MOLTO IMPORTANTI su tutto ciò che vogliono ... Puffo Presto, ho "rubato" le loro password.

Sì, l'educazione degli utenti torna sempre a morderci nella hienie, vero?
E non c'è niente che tu possa fare al riguardo ... Anche se FAREI inserire le loro password sul tuo sito e fare tutto il resto che la TSA può pensare, hai aggiunto protezione alla loro password NON UNO , se vogliono inserire le loro password in modo promiscuo in ogni sito in cui si imbattono. Non preoccuparti ANCHE di provare.

In altre parole , non possiedi le loro password , quindi smetti di provare ad agire come fai tu.

Quindi, miei cari esperti di sicurezza, come una vecchia signora era solita chiedere a Wendy, "Dov'è il rischio?"

Altri pochi punti, in risposta ad alcune questioni sollevate sopra:

• Il CWE non è una legge, un regolamento o uno standard. È una raccolta di debolezze comuni , vale a dire l'inverso delle "Best Practices".
• Il problema dell'identità condivisa è un problema reale, ma frainteso (o travisato) dai negligenti qui. Si tratta di condividere l'identità in sé e per sé (!), NON di decifrare le password su sistemi di basso valore. Se stai condividendo una password tra un sistema di basso valore e un valore elevato, il problema è già lì!
• A proposito, il punto precedente indicherebbe effettivamente CONTRO l' utilizzo di OAuth e simili sia per questi sistemi di basso valore, sia per i sistemi bancari di alto valore.
• So che era solo un esempio, ma (purtroppo) i sistemi dell'FBI non sono davvero i più sicuri in circolazione. Non proprio come i server del tuo gatto, ma non superano alcune delle banche più sicure.
• La conoscenza divisa, o il doppio controllo, delle chiavi di crittografia NON avviene solo nell'esercito, infatti PCI-DSS ora lo richiede praticamente da tutti i commercianti, quindi non è più così lontano (se il valore lo giustifica).
• A tutti coloro che si lamentano del fatto che domande come queste sono ciò che rende la professione degli sviluppatori così brutta: sono le risposte come quelle che rendono la professione della sicurezza ancora peggiore. Ancora una volta, l'analisi del rischio incentrata sul business è ciò che è richiesto, altrimenti ti rendi inutile. Oltre ad avere torto.
• Immagino che questo sia il motivo per cui non è una buona idea assumere semplicemente uno sviluppatore regolare e lasciargli più responsabilità sulla sicurezza, senza formazione per pensare in modo diverso e cercare i giusti compromessi. Senza offesa, per quelli di voi qui, sono tutto per questo - ma è necessario un maggiore addestramento.

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

• Spiegare al cliente il modo corretto di fare le cose.
• Se insiste ancora, spiegane ancora un po ', insisti, discuti. Fai un capriccio, se necessario.
• Spiegagli il RISCHIO DI AFFARI per lui. I dettagli sono buoni, le cifre sono migliori, una demo live è di solito la migliore.
• SE ANCORA insiste E presenta valide ragioni commerciali - è tempo che tu faccia una chiamata di giudizio:
  questo sito è basso o senza valore? È davvero un caso aziendale valido? È abbastanza buono per te? Non ci sono altri rischi che puoi prendere in considerazione e che supererebbero validi motivi commerciali? (E ovviamente, il client NON è un sito dannoso, ma questo è duh).
  Se è così, vai avanti. Non vale la pena, l'attrito e l'uso perduto (in questa ipotetica situazione) per mettere in atto il processo necessario. Qualsiasi altra decisione (di nuovo, in questa situazione) è un cattivo compromesso.

Quindi, linea di fondo e una risposta effettiva: crittografala con un semplice algoritmo simmetrico, proteggi la chiave di crittografia con ACL forti e preferibilmente DPAPI o simili, documentala e fai firmare il client (qualcuno abbastanza esperto da prendere quella decisione) esso.

Che ne dici di una casa a metà strada?

Archivia le password con una crittografia avanzata e non abilitare i ripristini.

Invece di reimpostare le password, consentire l'invio di una password singola (che deve essere modificata non appena si verifica il primo accesso). Consentire quindi all'utente di cambiare la password desiderata (la precedente, se lo desidera).

Puoi "venderlo" come meccanismo sicuro per reimpostare le password.

L'unico modo per consentire a un utente di recuperare la propria password originale è crittografarlo con la chiave pubblica dell'utente. Solo quell'utente può quindi decodificare la propria password.

Quindi i passaggi sarebbero:

1. L'utente si registra sul tuo sito (ovviamente su SSL) senza ancora impostare una password. Accedere automaticamente o fornire una password temporanea.
2. Offri di memorizzare la loro chiave PGP pubblica per il futuro recupero della password.
3. Caricano la loro chiave PGP pubblica.
4. Chiedi loro di impostare una nuova password.
5. Presentano la loro password.
6. È possibile eseguire l'hashing della password utilizzando il miglior algoritmo di hashing della password disponibile (ad es. Bcrypt). Usalo per convalidare il prossimo accesso.
7. Si crittografa la password con la chiave pubblica e la si memorizza separatamente.

Se l'utente chiede la propria password, l'utente risponde con la password crittografata (non con hash). Se l'utente non desidera essere in grado di recuperare la propria password in futuro (sarebbe solo in grado di reimpostarla su una generata dal servizio), i passaggi 3 e 7 possono essere saltati.

Penso che la vera domanda da porsi sia: "Come posso essere migliore nel convincere le persone?"

Ho lo stesso problema. E allo stesso modo penso sempre che qualcuno abbia hackerato il mio sistema non è una questione di "se" ma di "quando".

Quindi, quando devo fare un sito Web che deve archiviare informazioni riservate recuperabili, come una carta di credito o una password, quello che faccio è:

• crittografare con: openssl_encrypt (string $ data, string $ method, string $ password)
  • Manuale PHP .
• dati arg :
  • le informazioni sensibili (ad es. la password dell'utente)
  • serializzare se necessario, ad esempio se l'informazione è una matrice di dati come più informazioni sensibili
• password arg : usa un'informazione che solo l'utente conosce come:
  • la targa dell'utente
  • numero di Social Security
  • numero di telefono dell'utente
  • il nome della madre dell'utente
  • una stringa casuale inviata via e-mail e / o sms al momento della registrazione
• metodo arg :
  • scegli un metodo di cifratura, come "aes-256-cbc"
• Non memorizzare MAI le informazioni utilizzate nell'argomento "password" nel database (o in qualsiasi altra posizione nel sistema)

Se necessario per recuperare questi dati, basta usare la funzione "openssl_decrypt ()" e chiedere la risposta all'utente. Ad esempio: "Per ricevere la password rispondi alla domanda: qual è il tuo numero di cellulare?"

PS 1 : non utilizzare mai come password i dati memorizzati nel database. Se è necessario memorizzare il numero di cellulare dell'utente, non utilizzare mai queste informazioni per codificare i dati. Usa sempre un'informazione che solo l'utente conosce o che è difficile per qualcuno che non conosce.

PS 2 : per informazioni sulla carta di credito, ad esempio "acquisto con un clic", utilizzo la password di accesso. Questa password è sottoposta a hash nel database (sha1, md5, ecc.), Ma al momento del login memorizzo la password di testo normale in sessione o in un cookie sicuro non persistente (cioè in memoria). Questa semplice password non rimane mai nel database, anzi rimane sempre nella memoria, distrutta alla fine della sezione. Quando l'utente fa clic sul pulsante "acquisto con un clic", il sistema utilizza questa password. Se l'utente ha effettuato l'accesso con un servizio come Facebook, Twitter, ecc., Al momento dell'acquisto richiedo nuovamente la password (ok, non è un "clic" completo) oppure uso alcuni dati del servizio utilizzato dall'utente per accedere (come l'id di Facebook).

La protezione delle credenziali non è un'operazione binaria: sicura / non sicura. La sicurezza si basa sulla valutazione del rischio ed è misurata su un continuum. I fanatici della sicurezza odiano pensare in questo modo, ma la brutta verità è che nulla è perfettamente sicuro. Le password tratteggiate con requisiti rigorosi di password, campioni di DNA e scansioni della retina sono più sicure ma a costo di sviluppo ed esperienza dell'utente. Le password in testo normale sono molto meno sicure ma sono più economiche da implementare (ma dovrebbero essere evitate). Alla fine, si tratta di un'analisi costi / benefici di una violazione. L'implementazione della sicurezza si basa sul valore dei dati da proteggere e sul suo valore temporale.

Qual è il costo della password di qualcuno che esce in libertà? Qual è il costo della rappresentazione in un determinato sistema? Per i computer dell'FBI, il costo potrebbe essere enorme. Per il sito Web unico di cinque pagine di Bob, il costo potrebbe essere trascurabile. Un professionista offre opzioni ai propri clienti e, quando si tratta di sicurezza, espone i vantaggi e i rischi di qualsiasi implementazione. Questo è doppiamente così se il cliente richiede qualcosa che potrebbe metterli a rischio a causa del mancato rispetto degli standard del settore. Se un cliente richiede specificamente la crittografia bidirezionale, ti assicurerei di documentare le tue obiezioni, ma ciò non dovrebbe impedirti di implementare nel miglior modo che conosci. Alla fine della giornata, sono i soldi del cliente. Sì,

Se si memorizzano le password con la crittografia bidirezionale, la sicurezza dipende dalla gestione delle chiavi. Windows fornisce meccanismi per limitare l'accesso alle chiavi private dei certificati agli account amministrativi e con password. Se stai ospitando su altre piattaforme, dovresti vedere quali opzioni hai disponibili su quelle. Come altri hanno suggerito, è possibile utilizzare la crittografia asimmetrica.

Non esiste una legge (né il Data Protection Act nel Regno Unito) di cui sono consapevole che afferma in particolare che le password devono essere archiviate utilizzando hash unidirezionali. L'unico requisito in una di queste leggi è semplicemente che vengano prese misure ragionevoli per la sicurezza. Se l'accesso al database è limitato, anche le password in chiaro possono qualificarsi legalmente in base a tale limitazione.

Tuttavia, questo mette in luce un altro aspetto: la precedenza legale. Se la precedenza legale suggerisce che è necessario utilizzare gli hash unidirezionali in base al settore in cui viene costruito il sistema, questo è completamente diverso. Queste sono le munizioni che usi per convincere il tuo cliente. A parte questo, il miglior suggerimento per fornire una ragionevole valutazione del rischio, documentare le obiezioni e implementare il sistema nel modo più sicuro possibile per soddisfare le esigenze del cliente.

Rendi la risposta alla domanda di sicurezza dell'utente una parte della chiave di crittografia e non archiviare la risposta alla domanda di sicurezza come testo normale (l'hash invece)

Implemento sistemi di autenticazione a più fattori per vivere, quindi per me è naturale pensare che sia possibile ripristinare o ricostruire la password, utilizzando temporaneamente un fattore in meno per autenticare l'utente solo per il flusso di lavoro di ripristino / ricreazione. In particolare l'uso di OTP (password monouso) come alcuni dei fattori aggiuntivi, mitiga gran parte del rischio se la finestra temporale è breve per il flusso di lavoro suggerito. Abbiamo implementato generatori software OTP per smartphone (che la maggior parte degli utenti porta già con sé tutto il giorno) con grande successo. Prima che compaiano le lamentele di una spina commerciale, ciò che sto dicendo è che possiamo ridurre i rischi insiti nel mantenere le password facilmente recuperabili o ripristinabili quando non sono l'unico fattore utilizzato per autenticare un utente.

Siamo spiacenti, ma finché hai qualche modo per decodificare la loro password, non c'è modo che sia sicuro. Combatti amaramente, e se perdi, CYA.

Ho appena incontrato questa discussione interessante e accesa. Ciò che mi ha sorpreso di più è stato, quanto poca attenzione è stata prestata alla seguente domanda di base:

• Q1. Quali sono i motivi reali per cui l'utente insiste sull'accesso alla password memorizzata in testo normale? Perché ha così tanto valore?

Le informazioni secondo cui gli utenti sono anziani o giovani non rispondono realmente a questa domanda. Ma come si può prendere una decisione aziendale senza comprendere adeguatamente l'interesse del cliente?

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

Dato che non ho queste informazioni e non posso parlare con quei clienti, posso solo immaginare: si tratta di usabilità, vedi sopra.

Un'altra domanda che ho visto è stata posta:

• Q2. Se l'utente non ricorda la password al primo posto, perché è importante la vecchia password?

E qui è possibile la risposta. Se hai un gatto chiamato "miaumiau" e hai usato il suo nome come password ma hai dimenticato di farlo, preferiresti che ti venisse ricordato di cosa si trattava o piuttosto che ti venisse inviato qualcosa come "# zy * RW (ew"?

Un altro possibile motivo è che l'utente considera difficile elaborare una nuova password! Quindi avere la vecchia password restituita dà l'illusione di salvarla di nuovo da quel lavoro doloroso.

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

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

Se accedo a un sito di notizie per leggere i giornali, voglio digitare 1111 come password e passare attraverso !!!

So che è insicuro, ma cosa mi importa di qualcuno che accede al mio "account"? Sì, può leggere anche le notizie!

Il sito memorizza le mie informazioni "private"? Le notizie che ho letto oggi? Quindi è il problema del sito, non mio! Il sito mostra informazioni private all'utente autenticato? Quindi non mostrarlo al primo posto!

Questo è solo per dimostrare l'atteggiamento dell'utente nei confronti del problema.

Quindi, per riassumere, non credo che sia un problema di come archiviare "in modo sicuro" password di testo semplice (che sappiamo essere impossibile), ma piuttosto come affrontare le preoccupazioni reali dei clienti.

Gestione delle password perse / dimenticate:

Nessuno dovrebbe mai essere in grado di recuperare le password.

Se gli utenti hanno dimenticato le loro password, devono almeno conoscere i loro nomi utente o indirizzi e-mail. Su richiesta, generare un GUID nella tabella Users e inviare un messaggio di posta elettronica contenente un collegamento contenente il guid come parametro all'indirizzo di posta elettronica dell'utente.

La pagina dietro il collegamento verifica l'esistenza del parametro guid (probabilmente con una logica di timeout) e chiede all'utente una nuova password.

Se è necessario che gli utenti della hotline aiutino gli utenti, aggiungere alcuni ruoli al modello delle sovvenzioni e consentire al ruolo della hotline di accedere temporaneamente come utente identificato. Accedi a tutti questi accessi alla hotline. Ad esempio, Bugzilla offre agli amministratori una tale funzione di rappresentazione.

Che ne dici di inviare via e-mail la password in chiaro al momento della registrazione, prima che venga crittografata e persa? Ho visto molti siti Web farlo e ottenere quella password dall'email dell'utente è più sicuro che lasciarla in giro sul tuo server / comp.

Se non puoi semplicemente rifiutare l'obbligo di archiviare le password recuperabili, che ne dici di questo come argomento contrario.

Possiamo eseguire correttamente l'hash delle password e creare un meccanismo di reimpostazione per gli utenti oppure rimuovere dal sistema tutte le informazioni di identificazione personale. È possibile utilizzare un indirizzo e-mail per impostare le preferenze dell'utente, ma questo è tutto. Utilizzare un cookie per estrarre automaticamente le preferenze nelle visite future e eliminare i dati dopo un periodo ragionevole.

L'unica opzione che viene spesso trascurata dalla politica delle password è se una password è davvero necessaria. Se l'unica cosa che fa la tua politica di password è causare chiamate al servizio clienti, forse puoi liberartene.

Gli utenti hanno davvero bisogno di recuperare (ad esempio, dire) la password che hanno dimenticato o devono semplicemente essere in grado di accedere al sistema? Se ciò che vogliono veramente è una password per accedere, perché non avere una routine che cambia semplicemente la vecchia password (qualunque essa sia) in una nuova password che la persona di supporto può dare alla persona che ha perso la password?

Ho lavorato con sistemi che fanno esattamente questo. La persona di supporto non ha modo di sapere quale sia la password corrente, ma può reimpostarla su un nuovo valore. Ovviamente tutti questi ripristini dovrebbero essere registrati da qualche parte e la buona pratica sarebbe quella di generare una e-mail per l'utente che gli dice che la password è stata ripristinata.

Un'altra possibilità è avere due password simultanee che consentano l'accesso a un account. Una è la password "normale" gestita dall'utente e l'altra è come una chiave scheletro / master che è nota solo al personale di supporto ed è la stessa per tutti gli utenti. In questo modo, quando un utente ha un problema, la persona di supporto può accedere all'account con la chiave master e aiutare l'utente a cambiare la propria password in qualunque cosa. Inutile dire che anche tutti gli accessi con la chiave master devono essere registrati dal sistema. Come misura aggiuntiva, ogni volta che viene utilizzata la chiave master è possibile convalidare anche le credenziali delle persone di supporto.

-EDIT- In risposta ai commenti sul fatto di non avere una chiave master: sono d'accordo che è un male, così come credo che sia male consentire a chiunque altro che l'utente di avere accesso all'account dell'utente. Se si guarda alla domanda, l'intera premessa è che il cliente ha imposto un ambiente di sicurezza altamente compromesso.

Una chiave master non deve essere così male come sembrerebbe inizialmente. Lavoravo in un impianto di difesa in cui percepivano la necessità per l'operatore di computer mainframe di avere "accesso speciale" in determinate occasioni. Hanno semplicemente messo la password speciale in una busta sigillata e l'hanno registrata sulla scrivania dell'operatore. Per usare la password (che l'operatore non conosceva) ha dovuto aprire la busta. Ad ogni cambio di turno uno dei compiti del supervisore del turno era vedere se la busta era stata aperta e in tal caso immediatamente la password veniva cambiata (da un altro dipartimento) e la nuova password veniva inserita in una nuova busta e il processo iniziava tutto di nuovo. L'operatore sarebbe stato interrogato sul perché lo avesse aperto e l'incidente sarebbe stato documentato per la cronaca.

Sebbene questa non sia una procedura che vorrei progettare, ha funzionato e fornito un'eccellente responsabilità. Tutto è stato registrato e rivisto, inoltre tutti gli operatori disponevano di autorizzazioni segrete DOD e non abbiamo mai avuto abusi.

A causa della revisione e della supervisione, tutti gli operatori sapevano che se avessero abusato del privilegio di aprire la busta sarebbero stati immediatamente licenziati e avrebbero potuto essere perseguiti penalmente.

Quindi immagino che la vera risposta sia se si vogliono fare le cose nel modo giusto si assumono persone di cui si possono fidare, fare controlli di fondo ed esercitare un'adeguata supervisione e responsabilità della direzione.

Ma poi di nuovo se il cliente di questo poveretto avesse una buona gestione, non avrebbe mai richiesto una soluzione così comprensiva di sicurezza, adesso?

Dal poco che capisco su questo argomento, credo che se stai costruendo un sito Web con un accesso / password, non dovresti nemmeno vedere la password in chiaro sul tuo server. La password deve essere sottoposta a hash, e probabilmente salata, prima ancora di lasciare il client.

Se non vedi mai la password in chiaro, non sorge la domanda di recupero.

Inoltre, ritengo (dal web) che (presumibilmente) alcuni algoritmi come MD5 non siano più considerati sicuri. Non ho modo di giudicarlo da solo, ma è qualcosa da considerare.

aprire un DB su un server autonomo e fornire una connessione remota crittografata a ciascun server Web che richiede questa funzionalità.
non deve essere un DB relazionale, può essere un file system con accesso FTP, utilizzando cartelle e file anziché tabelle e righe.
concedere ai server Web autorizzazioni di sola scrittura, se possibile.

Memorizza la crittografia non recuperabile della password nel DB del sito (chiamiamola "pass-a") come fanno le persone normali :)
su ogni nuovo utente (o modifica della password) archivia una copia semplice della password nel DB remoto. usa l'id del server, l'ID dell'utente e "pass-a" come chiave composita per questa password. puoi persino usare una crittografia bidirezionale sulla password per dormire meglio di notte.

ora, affinché qualcuno ottenga sia la password sia il suo contesto (ID sito + ID utente + "pass-a"), deve:

1. hackerare il DB del sito Web per ottenere una coppia o coppie ("pass-a", id utente).
2. ottenere l'ID del sito Web da un file di configurazione
3. trovare e hackerare il database delle password remote.

puoi controllare l'accessibilità del servizio di recupero password (esponilo solo come servizio Web sicuro, consenti solo un certo numero di recuperi di password al giorno, eseguilo manualmente, ecc.) e persino addebitare un costo aggiuntivo per questo "speciale accordo di sicurezza".
Il server DB per il recupero delle password è piuttosto nascosto in quanto non svolge molte funzioni e può essere meglio protetto (è possibile personalizzare le autorizzazioni, i processi e i servizi).

tutto sommato, rendi il lavoro più difficile per l'hacker. la possibilità di una violazione della sicurezza su un singolo server è sempre la stessa, ma i dati significativi (una corrispondenza di account e password) saranno difficili da assemblare.

Un'altra opzione che potresti non aver considerato è quella di consentire le azioni via e-mail. È un po 'complicato, ma l'ho implementato per un client che necessitava di utenti "esterni" al proprio sistema per visualizzare (solo lettura) determinate parti del sistema. Per esempio:

1. Una volta che un utente è registrato, ha pieno accesso (come un normale sito Web). La registrazione deve includere un'e-mail.
2. Se sono necessari dati o un'azione e l'utente non ricorda la propria password, possono ancora eseguire l'azione cliccando su un apposito " email me per il permesso pulsante", proprio accanto al regolare " submit pulsante".
3. La richiesta viene quindi inviata al messaggio di posta elettronica con un collegamento ipertestuale che chiede se si desidera che l'azione venga eseguita. Questo è simile a un collegamento e-mail per reimpostare la password, ma invece di reimpostare la password esegue l' azione singola .
4. L'utente quindi fa clic su "Sì" e conferma che i dati devono essere mostrati o l'azione deve essere eseguita, i dati rivelati, ecc.

Come menzionato nei commenti, questo non funzionerà se l'e-mail è compromessa, ma risolve il commento di @joachim sul non voler reimpostare la password. Alla fine, dovrebbero utilizzare la reimpostazione della password, ma potrebbero farlo in un momento più conveniente o con l'assistenza di un amministratore o di un amico, se necessario.

Una svolta a questa soluzione sarebbe quella di inviare la richiesta di azione a un amministratore fidato di terze parti. Funzionerebbe meglio nei casi con utenti anziani, con problemi mentali, molto giovani o altrimenti confusi. Naturalmente questo richiede un amministratore di fiducia per queste persone per supportare le loro azioni.

Saltare e hash la password dell'utente normalmente. Quando si accede l'utente, consentire sia la password dell'utente (dopo la salatura / hashing), ma consentire anche ciò che l'utente ha letteralmente inserito per corrispondere.

Ciò consente all'utente di immettere la propria password segreta, ma consente anche di immettere la versione salata / con hash della propria password, che è ciò che qualcuno leggerebbe dal database.

Fondamentalmente, rendere la password salata / hash anche una password "in chiaro".