security pbkdf2 - Come dovrei approcciarmi in modo etico all'archiviazione delle password degli utenti per il successivo recupero dei testi in chiaro?





hash salted (23)


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 semplice (hash che invece)

Mentre continuo a costruire sempre più siti Web e applicazioni web, mi viene spesso chiesto di archiviare le password degli utenti in modo che possano essere recuperate se / quando l'utente ha un problema (o per inviare tramite e-mail un link di password dimenticata, passandole sopra telefono, ecc.) Quando posso, combatto amaramente contro questa pratica e faccio molte programmazioni "extra" per rendere possibili il ripristino della password e l'assistenza amministrativa senza memorizzare la password effettiva.

Quando non riesco a combatterlo (o non posso vincere), codifico sempre la password in qualche modo in modo che, almeno, non venga memorizzata come testo in chiaro nel database, anche se sono consapevole che se il mio DB viene hackerato non ci vorrà molto per il colpevole per rompere le password, quindi questo mi mette a disagio.

In un mondo perfetto le persone aggiornerebbero frequentemente le password e non le duplicherebbero su molti siti diversi - sfortunatamente conosco MOLTE persone che hanno lo stesso lavoro / casa / email / password di banca, e me l'hanno anche dato liberamente quando hanno bisogno di assistenza. Non voglio essere il responsabile della loro scomparsa finanziaria se le mie procedure di sicurezza 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 trattano con molto meno rispetto. Sono certo che ci sono molte strade da percorrere e argomenti da fare per salare gli hash e diverse opzioni di codifica, ma c'è una singola "best practice" quando devi memorizzarli? In quasi tutti i casi sto usando PHP e MySQL se questo fa alcuna differenza nel modo in cui dovrei gestire le specifiche.

Ulteriori informazioni per Bounty

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

In una nota di seguito ho sottolineato che i siti web rivolti in gran parte agli anziani, ai malati mentali o molto giovani possono diventare confusi per le persone quando viene loro richiesto di eseguire una procedura di recupero sicuro della password. Anche se in questi casi potremmo trovarlo semplice e banale, alcuni utenti necessitano dell'assistenza extra di avere una tecnologia di assistenza che li aiuti nel sistema o che li abbiano inviati via email / visualizzati direttamente a loro.

In tali sistemi, il tasso di abbandono di questi dati demografici potrebbe ostacolare l'applicazione se agli utenti non fosse fornito questo livello di assistenza per l'accesso, pertanto è necessario rispondere con tale impostazione.

Grazie a tutti

Questa è stata una domanda divertente con un sacco di discussioni e mi sono divertito. Alla fine ho selezionato una risposta che conserva sia la sicurezza della password (non dovrò mantenere il testo normale o le password recuperabili), ma rende anche possibile che la base di utenti che ho specificato acceda a un sistema senza i maggiori inconvenienti che ho trovato da normale recupero della password.

Come sempre ci sono state circa 5 risposte che mi piacerebbe avere contrassegnate come corrette per diversi motivi, ma ho dovuto scegliere la migliore - tutto il resto ha un +1. Grazie a tutti!

Inoltre, grazie a tutti i membri della community Stack che hanno votato per questa domanda e / o contrassegnato come preferito. Prendo a colpire 100 voti come un complimento e spero che questa discussione abbia aiutato qualcun altro con la stessa preoccupazione che ho avuto.




Un'altra opzione che potresti non aver considerato è consentire azioni via email. È un po 'ingombrante, ma l'ho implementato per un client che aveva bisogno di utenti "esterni" al proprio sistema per visualizzare (sola lettura) alcune parti del sistema. Per esempio:

  1. Una volta che un utente è registrato, ha pieno accesso (come un normale sito Web). La registrazione deve includere una e-mail.
  2. Se sono necessari dati o un'azione e l'utente non ricorda la propria password, può comunque eseguire l'azione facendo clic su un pulsante speciale " inviami un'e-mail per autorizzazione ", proprio accanto al normale pulsante " invia ".
  3. La richiesta viene quindi inviata all'e-mail con un collegamento ipertestuale che chiede se desidera che l'azione venga eseguita. Questo è simile a un collegamento email di reimpostazione della password, ma invece di reimpostare la password esegue l' azione una tantum .
  4. L'utente fa quindi clic su "Sì" e conferma che i dati devono essere mostrati, o che l'azione deve essere eseguita, i dati rivelati, ecc.

Come hai menzionato nei commenti, questo non funzionerà se l'e-mail è compromessa, ma indirizza il commento di @joachim sul fatto di non voler reimpostare la password. Alla fine, avrebbero dovuto usare la reimpostazione della password, ma potevano 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. Ciò funzionerebbe meglio in caso di utenti anziani, con problemi mentali, giovanissimi o in altro modo confusi. Ovviamente ciò richiede un amministratore fidato affinché queste persone supportino le loro azioni.




Ci dispiace, ma finché hai un modo per decodificare la loro password, non c'è modo di essere sicuro. Combattilo amaramente e se perdi, CYA.




C'è stata molta discussione sui problemi di sicurezza per l'utente in risposta a questa domanda, ma vorrei aggiungere una menzione dei benefici. Finora, non ho visto un beneficio legittimo menzionato per avere una password recuperabile memorizzata sul sistema. Considera questo:

  • L'utente beneficia di avere la sua password inviata via email? No. Ricevono più vantaggi da un collegamento per la reimpostazione della password utilizzabile una sola volta, che si spera possa consentire loro di scegliere una password che ricorderanno.
  • L'utente beneficia di avere la propria password visualizzata sullo schermo? No, per lo stesso motivo di cui sopra; dovrebbero scegliere una nuova password.
  • L'utente beneficia del fatto che una persona dell'assistenza parli la password per l'utente? No; ancora una volta, se la persona di supporto ritiene che la richiesta dell'utente per la propria password sia autenticata correttamente, è più utile per il cliente ricevere una nuova password e l'opportunità di cambiarla. Inoltre, l'assistenza telefonica è più costosa rispetto alle reimpostazioni automatiche delle password, quindi anche l'azienda non ne beneficia.

Sembra che gli unici che possono trarre vantaggio dalle password recuperabili siano quelli con intenti malevoli o sostenitori di API scadenti che richiedono lo scambio di password di terze parti (non utilizzare mai dette API mai!). Forse puoi vincere la tua argomentazione affermando sinceramente ai tuoi clienti che l'azienda non guadagna nessun beneficio e solo passività memorizzando password recuperabili .

Leggendo tra le righe di questi tipi di richieste, vedrai che probabilmente i tuoi clienti non capiscono o addirittura non si preoccupano affatto di come 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 non vogliono realmente password recuperabili, dovresti offrire loro dei modi per rendere meno doloroso il processo di autenticazione, specialmente se non hai bisogno dei pesanti livelli di sicurezza di, ad esempio, una banca:

  • Consenti all'utente di utilizzare il proprio indirizzo email per il proprio nome utente. Ho visto innumerevoli casi in cui l'utente dimentica il proprio nome utente, ma pochi dimenticano il loro indirizzo email.
  • Offri OpenID e consenti a una terza parte di pagare i costi dell'oblio dell'utente.
  • Basta con 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 più grande della forza della password, si potrebbero allentare anche i requisiti non stupidi consentendo password più brevi o non richiedendo un mix di classi di caratteri. Con restrizioni allentate, gli utenti saranno più propensi a 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 ragione (e per favore ci spieghi la ragione) davvero, davvero, davvero bisogno di essere in grado di avere una password recuperabile, potresti proteggere l'utente dal compromettere potenzialmente gli altri account online dando loro una password non- sistema di autenticazione basato. Poiché le persone hanno già familiarità con i sistemi username / password e sono una soluzione ben esercitata, questa sarebbe l'ultima risorsa, ma ci sono sicuramente molte alternative creative alle password:

  • Lascia che l'utente scelga un pin numerico, preferibilmente non a 4 cifre, e preferibilmente solo se i tentativi di forza bruta sono protetti contro.
  • Fai scegliere all'utente una domanda con una risposta breve che solo loro conoscono la risposta, non cambieranno mai, si ricorderanno sempre e non gli dispiacerà che altre persone lo scoprano.
  • Chiedere all'utente di inserire un nome utente e quindi tracciare una forma facile da ricordare con permute sufficienti per evitare di indovinare (vedere questa bella foto di come G1 lo fa per sbloccare il telefono).
  • Per il sito Web di un bambino, è possibile generare automaticamente una creatura fuzzy in base al nome utente (una specie di simile a un identificatore) e chiedere all'utente di dare alla creatura un nome segreto. A questo punto può essere richiesto di inserire il nome segreto della creatura per accedere.



In base al commento che ho fatto sulla domanda:
Un punto importante è stato sorvolato da quasi tutti ... La mia reazione iniziale è stata molto simile a @ Michael Brooks, fino a quando ho capito, come @stefanw, che il problema qui è che i requisiti sono rotti, ma questi sono ciò che sono.
Ma poi, mi è venuto in mente che potrebbe non essere nemmeno il caso! Il punto mancante qui è il valore non scritto delle risorse dell'applicazione. In parole povere, per un sistema a 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 a basso valore dove non ne vale la pena (ma una semplice password è ancora richiesta).

È importante ricordare che la vera competenza in materia di sicurezza consiste nel trovare i compromessi appropriati, NON nel formulare 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 appropriato basso senza risorse "costose" (l'identità stessa inclusa), E ci sono requisiti aziendali validi che rendono impossibile il processo corretto (o sufficientemente difficile / costoso) , E il cliente è reso consapevole di tutti gli avvertimenti ...
Quindi potrebbe essere opportuno semplicemente consentire la crittografia reversibile, senza che cerchi speciali possano passare.
Sto semplicemente smettendo di dire di non preoccuparmi affatto della crittografia, perché è molto semplice / economico da implementare (anche considerando una gestione delle chiavi passibile), e fornisce una protezione SOME (più del costo di implementazione). Inoltre, vale la pena guardare come fornire all'utente la password originale, tramite e-mail, visualizzazione sullo schermo, ecc.
Poiché qui si assume che il valore della password rubata (anche in aggregato) è piuttosto basso, qualsiasi di queste soluzioni può essere valida.

Dal momento che c'è una vivace discussione in corso, in realtà SEVERAL discussioni vivaci, nei diversi post e discussioni separate, aggiungerò alcuni chiarimenti e risponderò ad alcuni dei punti molto positivi che sono stati sollevati altrove qui.

Per iniziare, penso che sia chiaro a tutti qui che è possibile recuperare la password originale dell'utente, è una cattiva pratica e generalmente non è una buona idea. Questo non è affatto in discussione ...
Inoltre, sottolineo che in molti, anzi MOST, situazioni - è davvero sbagliato, anche fallo, cattivo, E brutto .

Tuttavia, il punto cruciale della domanda è intorno al principio , c'è qualche situazione in cui potrebbe non essere necessario vietarlo, e in tal caso, come farlo nel modo più corretto appropriato alla situazione .

Ora, come @Thomas, @sfussenegger e pochi altri menzionati, l'unico modo corretto per rispondere a questa domanda è di 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 permettersi quella protezione.
No, NON è una parola d'ordine, questo è uno degli strumenti di base e più importanti per un professionista della sicurezza in tempo reale. Le migliori pratiche sono valide fino ad un certo punto (di solito come linee guida per gli inesperti e gli hack), dopo di che prende il sopravvento l'analisi dei rischi.

Sai, è divertente - mi sono sempre considerato uno dei fanatici della sicurezza, e in qualche modo sono dalla parte opposta dei cosiddetti "esperti di sicurezza" ... Beh, la verità è - perché sono un fanatico, e un vero esperto di sicurezza nella vita reale - Non credo nel lanciare dogmi (o CWE) di "Best Practice" SENZA quell'importante analisi del rischio .
"Fai attenzione al fanatico della sicurezza che è veloce nell'applicare tutto nella cintura degli attrezzi senza sapere quale sia il vero problema con cui si stanno difendendo. Una maggiore sicurezza non equivale necessariamente a una buona sicurezza".
L'analisi del rischio e i veri fanatici della sicurezza farebbero riferimento a un compromesso più intelligente, basato su rischio / rischio, potenziale perdita, possibili minacce, mitigazioni complementari, ecc. Qualsiasi "esperto di sicurezza" che non può puntare a un'analisi del rischio solida come Basandosi sulle loro raccomandazioni, o supportando i compromessi logici, ma preferirebbero piuttosto sputare 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 fare in QUESTA SITUAZIONE, diamo un'occhiata ai rischi apparenti (evidente, perché non abbiamo tutte le informazioni di base su questa situazione, stiamo tutti ipotizzando - poiché la domanda è quale ipotetica situazione potrebbe esserci ...)
Assumiamo un sistema LOW-VALUE, ma non così trival che è un accesso pubblico - il proprietario del sistema vuole evitare la rappresentazione casuale, tuttavia la sicurezza "alta" non è fondamentale quanto la facilità d'uso. (Sì, è un compromesso legittimo accettare il rischio che qualsiasi abile script-kiddie possa hackerare il sito ... Aspetta, non è APT in voga ora ...?)
Per esempio, diciamo che sto organizzando un sito semplice per una grande riunione di famiglia, consentendo a tutti di fare un brainstorming su dove vogliamo andare nel nostro campeggio quest'anno. Sono meno preoccupato per un hacker anonimo, o anche per il cugino Fred che mi spreme in ripetuti suggerimenti per tornare al lago Wantanamanabikiliki, dato che sono a conoscenza di 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 il computer ... Quindi voglio rimuovere tutto l'attrito possibile per lei. Ancora una volta, NON sono preoccupato per gli hack, semplicemente non voglio errori stupidi di login errati - Voglio sapere chi sta arrivando e cosa vogliono.

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

  • Impersonare gli utenti? No, ho già accettato questo 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 malvagio otterrà la tua password non importa cosa - 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.
    Permettetemi di iniziare affermando che non è l' identità reale che è condivisa, piuttosto la prova o le credenziali di autenticazione. Ok, dal momento che una password condivisa mi consentirà effettivamente l'accesso a un altro sistema (ad esempio, il mio conto bancario o gmail), questa è effettivamente la stessa identità, quindi è solo semantica ... Tranne che non lo è . L'identità è gestita separatamente da ciascun sistema, in questo scenario (anche se potrebbero esserci sistemi di id di terze parti, come OAuth - ancora, è separato dall'identità in questo sistema - ne parleremo più avanti).
    Come tale, il punto di rischio principale 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 avrò accesso alle password di zia Erma per il sito dei missili nucleari.

Hmmm.

Ti sembra qualcosa qui?

Dovrebbe.

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

Sì, la formazione degli utenti torna sempre a morderci nel ciao, vero?
E non c'è nulla che tu possa fare a riguardo ... Anche se TU STAVI l'hash delle loro password sul tuo sito, e fai tutto il resto a cui la TSA può pensare, hai aggiunto la protezione alla loro password NON UNO WHIT , se hanno intenzione di mantenere attaccare promiscuamente le loro password in ogni sito in cui si imbattono. Non preoccuparti di provare.

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

Quindi, miei cari esperti di sicurezza, come una vecchia signora chiedeva per Wendy, "DOVE è il rischio?"

Altri punti, in risposta ad alcune questioni sollevate sopra:

  • CWE non è una legge, o regolamento, o addirittura uno standard. È una raccolta di punti deboli comuni , ovvero l'inverso delle "Best Practices".
  • Il problema dell'identità condivisa è un problema reale, ma frainteso (o travisato) dagli oppositori qui. È un problema di condivisione dell'identità in sé e per sé (!), NON di cracking delle password su sistemi di basso valore. Se stai condividendo una password tra un sistema a basso valore e un valore elevato, il problema è già lì!
  • In base al punto, il punto precedente potrebbe effettivamente puntare contro l'uso di OAuth e simili per entrambi questi sistemi a basso valore e per i sistemi bancari ad alto valore.
  • So che è stato solo un esempio, ma (purtroppo) i sistemi dell'FBI non sono davvero i più sicuri in circolazione. Non proprio come i server del blog del tuo gatto, ma nemmeno superano alcune delle banche più sicure.
  • Dividere le conoscenze, o il doppio controllo, delle chiavi di crittografia NON si verifica solo nelle forze armate, infatti PCI-DSS ora richiede questo praticamente da tutti i commercianti, quindi non è così tanto lontano là fuori (SE il valore lo giustifica).
  • A tutti coloro che si lamentano del fatto che domande come queste siano ciò che rende la professione degli sviluppatori un aspetto così negativo: sono risposte come quelle che rendono la professione della sicurezza ancora peggiore. Ancora una volta, l'analisi del rischio focalizzata sul business è ciò che è richiesto, altrimenti ti rendi inutile. Oltre ad essere sbagliato.
  • Immagino che questo sia il motivo per cui non è una buona idea assumere solo uno sviluppatore abituale e far cadere più responsabilità di sicurezza su di lui, senza allenarsi a pensare in modo diverso, e cercare i compromessi giusti. Senza offesa, per quelli di voi qui, sono tutto per questo - ma più allenamento è in ordine.

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

  • Spiega al cliente il modo corretto di fare le cose.
  • Se insiste ancora, spiegane qualcos'altro, insisti, discuti. Fai un capriccio, se necessario.
  • Spiega a lui il RISCHIO AZIENDALE. I dettagli sono buoni, le cifre sono migliori, una demo dal vivo è solitamente la migliore.
  • SE ANCORA insiste, E presenta validi motivi di lavoro - è tempo che tu faccia una chiamata di giudizio:
    Questo sito è di basso valore? È davvero un caso aziendale valido? È abbastanza buono per te? Non ci sono altri rischi che puoi prendere in considerazione, che superano i validi motivi commerciali? (E ovviamente, il client NON è un sito malevolo, ma è così).
    Se è così, vai avanti. Non vale la pena, l'attrito e l'uso perso (in questa situazione ipotetica) per mettere in atto il processo necessario. Qualsiasi altra decisione (di nuovo, in questa situazione) è un compromesso negativo.

Quindi, bottom line e una risposta reale: crittografalo con un semplice algoritmo simmetrico, proteggi la chiave di crittografia con ACL forti e preferibilmente DPAPI o simili, documentalo e chiedi al client (qualcuno abbastanza anziano per prendere quella decisione) di firmare esso.




Penso che la vera domanda che dovresti porci è: "Come posso essere migliore nel convincere le persone?"




Se non puoi semplicemente rifiutare il requisito per archiviare le password recuperabili, che ne dici di come tuo contro-argomento.

Possiamo utilizzare correttamente le password di hash e creare un meccanismo di ripristino per gli utenti, oppure possiamo rimuovere tutte le informazioni di identificazione personale dal sistema. È possibile utilizzare un indirizzo e-mail per impostare le preferenze dell'utente, ma questo è tutto. Usa un cookie per richiamare automaticamente le preferenze sulle visite future e buttare via i dati dopo un periodo ragionevole.

L'unica opzione che viene spesso trascurata con la politica della password è se una password sia davvero necessaria. Se l'unica cosa che fa la tua politica sulle password è causare chiamate al servizio clienti, forse puoi sbarazzartene.




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

Quindi, quando devo fare un sito web che ha bisogno di memorizzare informazioni confidenziali recuperabili, come una carta di credito o una password, quello che faccio è:

  • criptare con: openssl_encrypt (stringa $ data, stringa $ metodo, stringa $ password)
  • dati arg :
    • le informazioni sensibili (ad esempio 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 da 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 posizione nel sistema)

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

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

PS 2 : per informazioni sulla carta di credito, come "acquisto con un clic", quello che faccio è usare la password di accesso. Questa password è hash nel database (sha1, md5, ecc.), Ma al momento del login memorizzo la password in testo semplice in sessione o in un cookie sicuro non persistente (cioè in memoria). Questa semplice password non rimane mai nel database, anzi rimane sempre in 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., Richiedo nuovamente la password al momento dell'acquisto (ok, non è completamente "on-click") o utilizza 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 è tutta una questione di 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 con hash con requisiti di password rigorosi, campioni di DNA e scansioni di retina sono più sicure ma a un costo di sviluppo e di esperienza utente. Le password in chiaro sono molto meno sicure ma sono meno costose da implementare (ma dovrebbero essere evitate). Alla fine della giornata, si tratta di un'analisi costi / benefici di una violazione. Implementa la sicurezza in base al valore dei dati protetti e al suo valore temporale.

Qual è il costo della password di qualcuno per uscire allo stato selvatico? Qual è il costo della rappresentazione nel sistema specificato? Per i computer dell'FBI, il costo potrebbe essere enorme. Per il sito Web di cinque pagine unico 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, mi assicurerei di documentare le sue obiezioni ma ciò non dovrebbe impedirti di implementare nel modo migliore che tu conosca. Alla fine della giornata, sono i soldi del cliente. Sì, dovresti spingere per usare gli hash a senso unico, ma dire che è assolutamente l'unica scelta e qualsiasi altra cosa non è etica è un'assurdità totale.

Se si memorizzano le password con la crittografia bidirezionale, la sicurezza si riduce alla gestione delle chiavi. Windows fornisce meccanismi per limitare l'accesso alle chiavi private dei certificati agli account amministrativi e alle password. Se stai ospitando su un'altra piattaforma, dovresti vedere quali opzioni hai a disposizione 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 a conoscenza che afferma specificamente che le password devono essere memorizzate utilizzando gli hash unidirezionali. L'unico requisito in una qualsiasi di queste leggi è semplicemente che vengono prese misure ragionevoli per la sicurezza. Se l'accesso al database è limitato, anche le password in chiaro possono qualificarsi legalmente in base a tale restrizione.

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, è completamente diverso. Queste sono le munizioni che usi per convincere il tuo cliente. Salvo che, il miglior suggerimento per fornire una valutazione del rischio ragionevole, documentare le obiezioni e implementare il sistema nel modo più sicuro che si può dare ai requisiti del cliente.




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




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

Ciò consente all'utente di inserire la propria password segreta, ma consente anche loro di inserire la versione salata / hash della propria password, che è ciò che qualcuno avrebbe letto dal database.

Fondamentalmente, rendere la password salata / hash anche una password di "testo normale".




Non è possibile memorizzare in modo etico le password per il successivo richiamo di testo in chiaro. E 'così semplice. Persino Jon Skeet non può memorizzare in modo etico le password per il successivo recupero di testo in chiaro. Se gli utenti possono recuperare le password in testo normale in un modo o nell'altro, allora potenzialmente anche un hacker che trova una vulnerabilità di sicurezza nel codice. E non si tratta solo della password di un utente compromessa, ma di tutte.

Se i tuoi clienti hanno un problema con questo, digli che archiviare le password in modo recuperabile è contro la legge. In ogni caso, nel Regno Unito, il Data Protection Act 1998 (in particolare, Schedule 1, Part II, Paragraph 9) richiede ai responsabili del trattamento di adottare le misure tecniche appropriate per proteggere i dati personali, tenendo conto, tra le altre cose, del danno che potrebbe essere causato se i dati sono stati compromessi - che potrebbe essere considerevole per gli utenti che condividono le password tra i siti. Se hanno ancora difficoltà a fare i groove sul fatto che sia un problema, indirizzali ad alcuni esempi del mondo reale, come questo .

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

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

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




È possibile crittografare la password + un sale con una chiave pubblica. Per i login basta controllare se il valore memorizzato è uguale al valore calcolato dall'ingresso utente + sale. Se arriva un momento, quando la password deve essere ripristinata in chiaro, è possibile decifrare manualmente o semi-automaticamente con la chiave privata. La chiave privata può essere memorizzata altrove e può inoltre essere crittografata simmetricamente (che richiederà quindi un'interazione umana per decrittografare la password).

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

  • Le password vengono archiviate crittografate
  • Le persone possono accedere senza decifrare in chiaro
  • Le password possono essere ripristinate in testo semplice, ma solo con una chiave privata, che può essere archiviata all'esterno del sistema (in una cassaforte della banca, se lo si desidera).



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

Quindi i passaggi sarebbero:

  1. Registri utente sul tuo sito (su SSL ovviamente) senza ancora impostare una password. Registrali in automatico o fornisci una password temporanea.
  2. Si offre di memorizzare la propria chiave PGP pubblica per il recupero futuro della password.
  3. Caricano la loro chiave PGP pubblica.
  4. Chiedi loro di impostare una nuova password.
  5. Presentano la loro password.
  6. Hai cancellato la password utilizzando l'algoritmo di hashing della password migliore disponibile (ad esempio bcrypt). Usalo quando convalidi il prossimo log-in.
  7. Cripti la password con la chiave pubblica e la memorizzi separatamente.

Se l'utente chiede la propria password, si risponde con la password crittografata (non con hash). Se l'utente non desidera essere in grado di recuperare la propria password in futuro (sarà solo in grado di reimpostarlo su uno generato dal servizio), i passaggi 3 e 7 possono essere saltati.




Gestione delle password perse / dimenticate:

Nessuno dovrebbe mai essere in grado di recuperare le password.

Se gli utenti dimenticano le loro password, devono almeno conoscere i loro nomi utente o indirizzi email. Su richiesta, generare un GUID nella tabella Utenti e inviare una e-mail contenente un collegamento contenente il guid come parametro all'indirizzo e-mail dell'utente.

La pagina dietro il link verifica che il parametro guid esiste realmente (probabilmente con una logica di timeout) e chiede all'utente una nuova password.

Se è necessario disporre della hotline per aiutare gli utenti, aggiungere alcuni ruoli al modello di concessione e consentire al ruolo di hotline di accedere temporaneamente come utente identificato. Registra tutti questi accessi hotline. Ad esempio, Bugzilla offre una tale funzione di impersonificazione agli amministratori.




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

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 di sicurezza non sono opzionali, sono richieste in base al codice antincendio della città.
Cliente: non ti sto pagando per discutere. Fai solo quello che ho chiesto.

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

Nel settore dell'edilizia e dell'ingegneria, la conversazione ha più probabilità di finire così:

Architetto: questo edificio non può essere costruito senza uscite di sicurezza. 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 sembrano spesso chiedersi perché la nostra professione non abbia lo stesso rispetto di un ingegnere civile o meccanico - beh, non guardare oltre. Quelle professioni, quando vengono consegnate le immondizie (o apertamente pericolose), semplicemente si rifiuteranno. Sanno che non è una scusa per dire "bene, ho fatto del mio meglio, ma lui ha insistito, e devo fare quello che dice". Potrebbero perdere la licenza per quella scusa.

Non so se voi oi vostri clienti facciano parte o meno di una società quotata in borsa, ma la memorizzazione di password in qualsiasi forma recuperabile causerebbe il fallimento di diversi tipi di controlli di sicurezza. Il problema non è quanto sarebbe difficile per alcuni "hacker" che hanno accesso al tuo database per recuperare le password. La stragrande maggioranza delle minacce alla sicurezza sono interne. Ciò di cui hai bisogno per proteggersi è un impiegato scontento che si allontana con tutte le password e le vende al miglior offerente. Utilizzare la crittografia asimmetrica e archiviare la chiave privata in un database separato non fa assolutamente nulla per evitare questo scenario; ci sarà sempre qualcuno con accesso al database privato, e questo è un serio rischio per la sicurezza.

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




Dopo aver letto questa parte:

In una nota di seguito ho sottolineato che i siti web rivolti in gran parte agli anziani, ai malati mentali o molto giovani possono diventare confusi per le persone quando viene loro richiesto di eseguire una procedura di recupero sicuro della password. Anche se in questi casi potremmo trovarlo semplice e banale, alcuni utenti necessitano dell'assistenza extra di avere una tecnologia di assistenza che li aiuti nel sistema o che li abbiano inviati via email / visualizzati direttamente a loro.

In tali sistemi, il tasso di abbandono di questi dati demografici potrebbe ostacolare l'applicazione se agli utenti non fosse fornito questo livello di assistenza per l'accesso, pertanto è necessario rispondere con tale impostazione.

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

Quindi il sistema è configurato per sapere quando è avvenuto un reset della password e visualizzare un messaggio "desideri mantenere la nuova password o sceglierne uno nuovo".

Com'è peggio per chi ha meno familiarità con il PC rispetto alla vecchia password? E mentre la persona del servizio clienti può arrivare fino a guai, il database stesso è molto più sicuro in caso di violazione.

Commenta cosa non va bene sul mio suggerimento e suggerirò una soluzione che effettivamente fa ciò che inizialmente volevi.




Che ne dici di una casa a metà strada?

Archiviare le password con una crittografia avanzata e non abilitare le reimpostazioni.

Invece di reimpostare le password, consentire l'invio di una password monouso (che deve essere modificata non appena si verifica il primo accesso). Consenti all'utente di passare alla password che desidera (la precedente, se lo desidera).

Puoi "vendere" questo come un meccanismo sicuro per reimpostare le password.




Mi sono imbattuto in questa discussione interessante e animata. Ciò che mi ha sorpreso di più è stato, quanta poca attenzione è stata posta alla seguente domanda fondamentale:

  • Q1. Quali sono le reali ragioni per cui l'utente insiste nell'avere accesso alla password memorizzata in testo semplice? Perché ha così tanto valore?

Le informazioni che gli utenti sono anziani o giovani in realtà non rispondono a questa domanda. Ma come può essere presa una decisione aziendale senza una corretta comprensione delle preoccupazioni del cliente?

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

Poiché non ho queste informazioni e non posso parlare con questi clienti, posso solo supporre: si tratta di usabilità, vedi sopra.

Un'altra domanda che ho visto ha chiesto:

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

E qui è possibile una risposta. Se hai un gatto chiamato "miaumiau" e hai usato il suo nome come password ma hai dimenticato di averlo fatto, preferiresti essere ricordato di cosa si trattava o piuttosto di inviare qualcosa come "# zy * RW (ew"?

Un'altra possibile ragione è che l'utente considera un duro lavoro trovare una nuova password! Quindi avere la vecchia password restituita dà l'illusione di salvarla di nuovo da quel doloroso lavoro.

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

Come utente, voglio le 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 se qualcuno accede al mio "account"? Sì, anche lui può leggere le notizie!

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

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

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




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

  1. Cripta la password con la chiave pubblica di qualcun altro - qualche autorità esterna. In questo modo non puoi ricostruirlo personalmente e l'utente dovrà rivolgersi a quell'autorità esterna e chiedere di recuperare la password.
  2. Criptare la password utilizzando una chiave generata da una seconda passphrase. Effettua questa crittografia lato client e non la trasmetti mai in chiaro al server. Quindi, per recuperare, eseguire di nuovo la decifrazione lato client ri-generando la chiave dal loro input. Certo, questo approccio utilizza fondamentalmente una seconda password, ma puoi sempre dire loro di scriverlo, o usare il vecchio approccio domanda-sicurezza.

Penso che 1. sia la scelta migliore, perché ti consente di designare qualcuno all'interno dell'azienda del cliente per tenere la chiave privata. Assicuratevi che generino la chiave da soli e la memorizzino con le istruzioni in una cassaforte, ecc. Potreste persino aggiungere sicurezza scegliendo di crittografare e fornire determinati caratteri dalla password alla terza parte interna in modo che possano craccare la password per indovinare esso. Fornendo questi caratteri all'utente, probabilmente ricorderanno di cosa si trattava!




Gli utenti hanno davvero bisogno di recuperare (ad esempio, viene detto) quale password hanno dimenticato o hanno semplicemente bisogno di essere in grado di accedere al sistema? Se quello che vogliono veramente è una password per l'accesso, perché non avere una routine che semplicemente cambia la vecchia password (qualunque essa sia) in una nuova password che la persona di supporto può dare alla persona che ha perso la sua 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. Naturalmente tutti questi reset dovrebbero essere registrati da qualche parte e una buona pratica sarebbe quella di generare una e-mail all'utente che gli dice che la password è stata ripristinata.

Un'altra possibilità è quella di avere due password simultanee che consentono l'accesso a un account. Una è la password "normale" che l'utente gestisce e l'altra è simile a una chiave scheletro / principale che è conosciuta solo dal 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 modificare la sua password in qualsiasi modo. Inutile dire che tutti gli accessi con la chiave master dovrebbero essere registrati anche dal sistema. Come misura aggiuntiva, ogni volta che viene utilizzata la chiave principale, è 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 sul fatto che sia sbagliato proprio come credo che sia male consentire a chiunque, a parte l'utente, di accedere 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 prima. Lavoravo in un impianto di difesa dove percepivano la necessità per l'operatore di computer mainframe di avere "accesso speciale" in certe occasioni. Hanno semplicemente inserito 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 di vedere se la busta era stata aperta e in tal caso immediatamente la password è cambiata (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 l'aveva aperto e l'incidente sarebbe stato documentato per la cronaca.

Anche se questa non è una procedura che vorrei progettare, ha funzionato e fornito un'eccellente responsabilità. Tutto è stato registrato e revisionato, inoltre tutti gli operatori disponevano di autorizzazioni 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 oggetto di licenziamento immediato e possibile procedimento penale.

Quindi immagino che la vera risposta sia se uno vuole fare le cose nel modo giusto, assume persone di cui può fidarsi, fare verifiche di background ed esercitare una supervisione e responsabilità di gestione adeguate.

Ma di nuovo, se il cliente di questo povero amico avesse una buona gestione, non avrebbe mai chiesto una soluzione comprimizzata di tale sicurezza, adesso?




Implemento sistemi di autenticazione a più fattori per vivere, quindi per me è naturale pensare che sia possibile resettare o ricostruire la password, usando 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, attenua gran parte del rischio se la finestra temporale è breve per il flusso di lavoro suggerito. Abbiamo implementato generatori OTP di software per smartphone (che la maggior parte degli utenti già porta con sé tutto il giorno) con grande successo. Prima di sporgere denuncia di un plug pubblicitario, quello che sto dicendo è che possiamo ridurre i rischi inerenti al mantenere le password facilmente recuperabili o ripristinabili quando non sono l'unico fattore utilizzato per autenticare un utente. Ammetto che per il riutilizzo della password tra gli scenari dei siti la situazione non è ancora carina, poiché l'utente insisterà per avere la password originale perché vuole aprire anche gli altri siti, ma puoi provare a consegnare la password ricostruita in il modo più sicuro possibile (htpps e aspetto discreto sull'html).




Per quanto posso dire che non è possibile creare facilmente la chiave pubblica prevista direttamente in iOS, è necessario farlo tramite un certificato. Quindi i passaggi necessari sono simili a bloccare il certificato, ma in aggiunta è necessario estrarre la chiave pubblica dal certificato effettivo e da un certificato di riferimento (la chiave pubblica prevista).

Quello che devi fare è:

  1. Utilizzare NSURLConnectionDelegate per recuperare i dati e implementare willSendRequestForAuthenticationChallenge .
  2. Includere un certificato di riferimento in formato DER . Nell'esempio ho usato un semplice file di risorse.
  3. Estrai la chiave pubblica presentata dal server
  4. Estrai la chiave pubblica dal tuo certificato di riferimento
  5. Confronta i due
  6. Se corrispondono, continua con i controlli regolari (nome host, firma del certificato, ecc.)
  7. Se non corrispondono, fallire.

Qualche esempio di codice:

 (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
    // get the public key offered by the server
    SecTrustRef serverTrust = challenge.protectionSpace.serverTrust;
    SecKeyRef actualKey = SecTrustCopyPublicKey(serverTrust);

    // load the reference certificate
    NSString *certFile = [[NSBundle mainBundle] pathForResource:@"ref-cert" ofType:@"der"];
    NSData* certData = [NSData dataWithContentsOfFile:certFile];
    SecCertificateRef expectedCertificate = SecCertificateCreateWithData(NULL, (__bridge CFDataRef)certData);

    // extract the expected public key
    SecKeyRef expectedKey = NULL;
    SecCertificateRef certRefs[1] = { expectedCertificate };
    CFArrayRef certArray = CFArrayCreate(kCFAllocatorDefault, (void *) certRefs, 1, NULL);
    SecPolicyRef policy = SecPolicyCreateBasicX509();
    SecTrustRef expTrust = NULL;
    OSStatus status = SecTrustCreateWithCertificates(certArray, policy, &expTrust);
    if (status == errSecSuccess) {
      expectedKey = SecTrustCopyPublicKey(expTrust);
    }
    CFRelease(expTrust);
    CFRelease(policy);
    CFRelease(certArray);

    // check a match
    if (actualKey != NULL && expectedKey != NULL && [(__bridge id) actualKey isEqual:(__bridge id)expectedKey]) {
      // public keys match, continue with other checks
      [challenge.sender performDefaultHandlingForAuthenticationChallenge:challenge];
    } else {
      // public keys do not match
      [challenge.sender cancelAuthenticationChallenge:challenge];
    }
    if(actualKey) {
      CFRelease(actualKey);
    }
    if(expectedKey) {
      CFRelease(expectedKey);
    }
 }

Dichiarazione di non responsabilità: questo è solo un esempio di codice e non completamente testato. Per un'implementazione completa, iniziare con l' esempio di blocco dei certificati di OWASP .

E ricorda che il blocco dei certificati può sempre essere evitato usando SSL Kill Switch e strumenti simili.





security password-encryption password-storage