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


Answers

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 insoddisfatto 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.

Question

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 in molti siti diversi - sfortunatamente conosco MOLTE persone che hanno lo stesso lavoro / casa / email / password di banca, e me lo 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 complimento e spero che questa discussione abbia aiutato qualcun altro con la stessa preoccupazione che ho avuto.




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.




aprire un DB su un server standalone 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 invece di tabelle e righe.
dare i permessi di sola scrittura ai server Web, 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) memorizza una semplice copia della password nel DB remoto. utilizzare l'id del server, l'ID dell'utente e "pass-a" come chiave composta per questa password. puoi persino usare una crittografia bidirezionale sulla password per dormire meglio la notte.

ora per consentire a qualcuno di ottenere sia la password sia il suo contesto (id sito + ID utente + "pass-a"), egli deve:

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

è possibile controllare l'accessibilità del servizio di recupero della password (esporlo solo come servizio Web protetto, consentire solo un certo numero di recuperi di password al giorno, farlo manualmente, ecc.), e persino addebitare extra per questo "speciale regime di sicurezza".
Il server DB di recupero delle password è nascosto in quanto non offre molte funzioni e può essere protetto meglio (è possibile adattare permessi, processi e servizi strettamente).

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.




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).




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.



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




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.




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.




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 giuste, assume persone di cui si può fidare, 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?




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".




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 da questi dati demografici potrebbe ostacolare l'applicazione se agli utenti non fosse fornito questo livello di assistenza per l'accesso, quindi per favore rispondi con tale impostazione in mente.

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.




Non arrenderti L'arma che puoi usare per convincere i tuoi clienti è la non-ripudiabilità. Se riesci a ricostruire le password degli utenti tramite qualsiasi meccanismo, hai dato ai loro clienti un meccanismo legale di non disconoscimento e possono ripudiare qualsiasi transazione che dipende da tale password, perché non c'è modo in cui il fornitore può dimostrare di non aver ricostruito la password e mettere la transazione da soli. Se le password sono archiviate correttamente come digest invece che come testo cifrato, ciò è impossibile, sia che il cliente finale esegua la transazione da solo o abbia violato il suo dovere di diligenza per la password. In entrambi i casi questo lascia la responsabilità direttamente con lui. Ho lavorato su casi in cui ciò equivale a centinaia di milioni di dollari. Non qualcosa che vuoi sbagliare.




Related