Memorizzazione di password in chiaro per rilevare la frode

In questo caso, al momento della registrazione, è possibile generare un hash della password inserita per ogni sale utilizzato fino a quel momento, quindi controllare queste password salate e hash con tutte le password già memorizzate.

Potresti persino memorizzare nella cache tutti i sali utilizzati fino ad ora, questa è potenzialmente una lista più piccola di quella di dover eseguire il ciclo di tutte le password ogni volta per raccoglierle.

Se questo è troppo costoso da calcolare su ogni registrazione, limita il numero di sali che generi (scegli a caso da una lista limitata) per ridurre il tempo di calcolo. Ciò sarà comunque più sicuro (di gran lunga) rispetto alla memorizzazione di password in testo semplice.

Nota che se questo è solo per il rilevamento delle frodi, una violazione della sicurezza e una pubblicità negativa (enorme) ti costeranno molto di più, cancellando in questo modo tutti i vantaggi che hai ottenuto nel catturare alcuni frodi.

Rendere le password accessibili in testo normale in un modo o nell'altro è già un enorme difetto di sicurezza. Questo è uno dei componenti di sicurezza più importanti su qualsiasi sito ovunque. Credo che tu lo sappia già.

La mia raccomandazione è di trovare un altro modo per gestire tali frodi. Esporre le password degli utenti in questo modo non vale la pena. Vinci un po 'e perdi molto. Se lo fai, te ne pentirai più tardi.

EDIT: Credo che dipenda molto da ciò che le persone possono acquistare su quel sito. Puoi controllare le stesse password, lo stesso IP, lo stesso browser ecc. Ma se qualcuno vuole fare 2 o più acquisti, può farlo. Se i beni di cui stiamo parlando sono oggetti reali, a mio parere il modo migliore per rilevare tali "frodi" è confrontare gli indirizzi di spedizione. Qualcuno potrebbe usare un account / password / browser diverso (è facile), ma cambierà raramente il loro indirizzo per ottenere qualcosa di simile.

Il rischio di una cattiva PR se le tue password perdono la pena per il leggero guadagno che hai ottenuto? Personalmente, non lo farei.

Se proprio devi "avere un sistema che deve limitare gli acquisti a 1 (o un piccolo numero) a persona" (che sembra un compito impossibile) non c'è qualcos'altro che puoi usare?

• Lo stesso indirizzo IP?
• stesso browser?

presupponendo che la "stessa password" sia un buon modo per verificare la presenza di frodi e considerando che dare il modo di ripristinare la password memorizzata nel testo in chiaro è solo una pessima idea, ecco come consentirei il rilevamento dei duplicati: Continuerò comunque con lo schema "per utente unico salt" per identificare i miei utenti.

Oltre a questo, avrei anche un salt unico che viene utilizzato prima di eseguire un altro hash sulla password. Tutte le password passano attraverso l'hashing e vengono archiviate in un DB (non nella stessa tabella della tabella utente), insieme al numero di volte in cui è stato utilizzato. Ciò consentirebbe comunque un attacco arcobaleno su questa tabella specifica, ma non avresti il link utente < - > password.

In altre parole, il tuo aggressore verrebbe ridotto a utilizzare un attacco al dizionario bruteforce (che eseguirà comunque e che probabilmente gli darà accesso a un numero elevato di account). Se la tua base di utenti è piccola, nulla ti impedisce di inserire righe fittizie in quella tabella, solo per aumentare le dimensioni del dizionario che l'utente malintenzionato dovrebbe utilizzare.

La chiave qui è che non ti importa di quale utente ha la nuova password digitata. L'unica cosa a cui potrai accedere è "quanti utenti hanno questa password", che ti permetterà di rifiutare gli ultimi abbonamenti (non importa cosa, non puoi rifiutare le sottoscrizioni prima che un certo numero di utenti abbia usato lo stesso password).

Probabilmente non è una buona idea archiviare le password in chiaro, ma se si volesse utilizzare la "stessa password" come indicatore di frode, ecco come farei io:

• Quando un utente si iscrive, genera un hash utilizzando un sale diverso da quello che altrimenti usi.
• Tronca al primo n bit.

Quindi per ogni utente si dovrebbero avere due hash distinti, uno con, diciamo, 64 byte. L'altro con 2 byte, per esempio. In teoria, ciò renderà il tuo hashing 65.536 volte più debole (non del tutto sicuro di ciò, forse qualcuno potrebbe supportare / refutare).

Saresti quindi in grado di utilizzare questo valore come un debole indicatore di frode.

L'unico modo in cui prenderei in considerazione l'idea di fare qualcosa di simile è se metti una macchina stand-alone in una stanza chiusa con solo una connessione RS232 tra questa e il server web. Nessuna scheda di rete, nessuna connessione wi-fi, nessuna chiavetta USB consentita.

Eseguire un hash non salato sul server Web, inviare solo l'hash e un ID utente sulla porta seriale e ottenere un conteggio del numero di utenti con hash corrispondenti dal computer bloccato. Non memorizzare nella cache il risultato sul server web!

Il computer bloccato può avere un database di tutti gli hash memorizzati dall'ID utente e può fare il confronto per dire quanti risultati corrispondono.

Anche in questo caso, tutto dipende dalla disciplina della società coinvolta. Qui non vuoi fare buchi nel vuoto d'aria.

Se si è pronti a farlo, la soluzione ideale mi sembra di utilizzare un filtro Bloom delle "password errate" conosciute.

Il vantaggio è che, anche in caso di compromissione, si perdono solo informazioni sulle password di attori cattivi noti / sospetti e non si perdono mai direttamente gli hash delle password. Inoltre, un filtro Bloom denso è molto veloce da cercare e può essere dimensionato per avere un basso tasso di falsi positivi. Inoltre, se il filtro Bloom è dimensionato per una percentuale di falsi positivi pari a 1 su un milione, anche un utente malintenzionato che è stato in grado di rubare il tuo filtro Bloom troverà tutte le vere "password errate" più una su un milione del suo / la sua password casuale indovina.

Supponiamo che tu abbia un filtro Bloom 65.536 con 8 diverse funzioni hash. Ciò richiederà solo 8 kilobyte da archiviare e manterrà più di exp (ln (1e-6) / 8) * 65536/8 = 1.457 "cattive" password prima di raggiungere una velocità falsa positiva di 1 su un milione.

Lo svantaggio è che dopo aver contrassegnato un account come non valido, dovrai attendere il prossimo accesso a quell'account per aggiungere la password al filtro Bloom (solo in questo caso vedi le password in chiaro) e dopo aver aggiunto una "password errata" per il filtro Bloom, non scoprirai altri account che condividono la "password errata" fino al prossimo accesso.

Il primo problema può essere facilmente superato espirando i token di crittografia / i cookie di accesso di un account non valido, ingannando immediatamente l'attaccante. I token di crittografia / i cookie di accesso devono sempre contenere un timestamp di creazione messaggio-autenticazione-codice-protetto. Ciò ti consente di forzare l'accesso periodico e inoltre di mantenere un timestamp earliestValidToken per utente che puoi risalire all'orario corrente quando cambiano la password (o se hai bisogno di scadere dei loro token esistenti per qualche altro motivo).

Il secondo problema può essere risolto utilizzando una combinazione di diversi metodi. (1) È bene fare in modo che gli utenti facciano il login ogni 2 settimane per impedire loro di dimenticare le loro password (2) probabilmente ti interessa principalmente la creazione di nuovi account usando "password errate" (3) presumendo che la maggior parte degli account diventi spam poco dopo la creazione, quando scopri un account spam, puoi scartare i token crittografici / i cookie di accesso di tutti gli account creati negli ultimi N giorni (o forse tutti gli account creati dopo l'account spam).

Per quanto riguarda come ottenere le 8 funzioni di hash, sono necessari 8 hash a 16 bit o 128 bit di output hash da tagliare in blocchi da 16 bit. Dovrai utilizzare le tue funzioni hash per utilizzare chiavi specifiche del sito, in modo da ridurre al minimo la possibilità di utilizzare cross-site di un filtro Bloom rubato. Due invocazioni di Siphash-2-4 utilizzando due chiavi diverse è probabilmente il modo più veloce per ottenere i 128 bit di valori hash. Anche SHA-1 HMAC (troncato da MAC a 128 bit) o AES CMAC sono perfettamente accettabili.

Se capisco che intendi utilizzare queste informazioni solo internamente all'interno della tua organizzazione per individuare possibili frodi?

Ora non so se si cripta e si salda la password sul lato client usando JavaScript o qualcosa di simile prima di inviarla al server. Ma se no, allora potresti memorizzare una password non criptata su un altro server db in una rete isolata non accessibile dall'esterno ed eseguirne i controlli?

Per quanto riguarda il controllo dell'IP e del browser, suppongo che la maggior parte delle persone che fanno questi tipi di frodi lavorano attraverso diversi proxy per cambiare il proprio ip in giro e utilizzare le funzioni di navigazione in incognito per "nascondere" il proprio browser.

Aggiornamento: Alcune persone sembrano mancare il fatto che sia stata sollevata una domanda. Non ha nulla a che fare con le nostre personali convinzioni sul trattamento delle password e le migliori pratiche di sicurezza.

Se uno è d'accordo su ciò che la persona che fa la domanda vuole fare o no non è il punto. La domanda era semplice e semplice:

Domanda: se viene stabilito che è necessaria la capacità di rilevamento delle frodi di recuperare le password, quali sono le migliori pratiche per archiviare le password in modo sicuro ma in un modo accessibile al testo semplice?

Non chiede SE è sicuro al 100%. Chiede pratiche per renderlo il più sicuro possibile.

Sì, molto probabilmente succhierà e sarà impossibile da proteggere con un tasso di successo del 100%. Ma SE DEVE ESSERE FATTO, come potrebbe farlo nel modo più sicuro possibile. Ci sarà SEMPRE un modo per aggirare qualsiasi cosa non criptata con un algoritmo hash, come ancora, non interrotto. Potrebbe essere più o meno drammatico e potrebbe richiedere che un C4 entri in una stanza del server a 100 metri sotto la superficie e uccida 10 guardie armate cablate su un sistema che le uccide se provano a lasciare la stanza (in modo che non possano rubare le informazioni e andarsene).

Ma non è ancora il punto della domanda. Vuole sapere come memorizzare le password del TESTO PLAIN nel modo più sicuro possibile. Da chi non è molto specificato e se è l'unico a gestire questo sistema (e assumiamo che possa fidarsi di se stesso), gli unici che deve proteggere dai dati sono esterni. In caso contrario, sarà necessario prendere in considerazione anche le parti interne.

Fa schifo per memorizzare dati sensibili come testo in chiaro? DIAVOLO SÌ! La persona che fa la domanda merita di saperlo? Sì!

Rispondiamo alla sua domanda affermando solo questo? NO!