Quanti giri dovrebbero essere usati per i numeri delle carte hash?

3

Vogliamo che la possibilità di effettuare pagamenti senza effettuare l'accesso utilizzando uno dei metodi di pagamento salvati sia associata al metodo di pagamento salvato. Per esempio. se acquistano un abbonamento ricorrente alla rivista 1 utilizzando la carta di credito 1, quindi acquistano un altro abbonamento alla rivista 2 con carta di credito 1 (ancora una volta), quando accedono al proprio account dovrebbe mostrare che entrambe le riviste sono state acquistate con lo stesso metodo di pagamento . (Non che entrambi siano stati acquistati usando due carte separate che si concludono così nelle stesse ultime 4 cifre).

Poiché non sono connessi durante questi due checkout, non c'è modo per loro di scegliere il loro metodo di pagamento esistente da utilizzare. Internamente, dobbiamo renderci conto che questo metodo di pagamento è stato utilizzato prima e "deduplicarli".

La mia soluzione a questo problema è usare Blowfish per cancellare i dettagli della carta:

private static String hashSalt(Long userId) {
    final Long rounds = 10
    String userHash = sha1("$userId" + GLOBAL_SALT).substring(0, 16)
    return "\a\$$rounds\$$userHash"
}
private static String mergeCardDetails(String number, String cvv, String expirationMonth, String expirationYear) {
    return "card:$number:$cvv:$expirationMonth:$expirationYear"
}

hash = BCrypt.hashpw(mergeCardDetails("4111111111111111", "123", "05", "22"), hashSalt(userId))

Attualmente il conteggio del round è impostato su 10. Tuttavia, mi rendo conto che questo è un numero molto basso come lo spazio di ricerca per i numeri delle carte è molto basso .

La mia domanda è: quanti round sono appropriati per i numeri delle carte hashing, oggi?

So che in futuro il conteggio del round dovrà essere aumentato, con conseguente duplicazione dei metodi di pagamento ...

    
posta Chris Smith 03.07.2018 - 17:37
fonte

2 risposte

38

Sembra che tu abbia i dettagli delle carte di hashing insieme al CVV. È brutto, molto cattivo. Non farlo. Mai. E non c'è modo di fare la cosa sbagliata nel modo giusto.

"A man may do a right thing in a wrong way; but he cannot do a wrong thing in a right way. For there is no right way of doing wrong."src

Ci sono piattaforme di cracking di hash molto economici in tutto il mondo che possono provare milioni di hash al secondo. Rompere gli hash può essere fatto molto velocemente, se si tiene conto che si dispone di una manciata di banche o emittenti validi, quindi le prime 6 cifre sono prese da una tabella, non lo spazio di ricerca completo. Una perdita di database e tutti i dati finanziari sono disponibili nei forum sotterranei.

Non compromettere la sicurezza per un piccolo aumento di convenienza. Non è difficile per il cliente digitare di nuovo la carta, o effettuare il login su Paypal per pagarti, ma sarà terribile se riceverà una mail da te che informa che tutti i dati della carta sono trapelati e devono cancellare e riemettere le loro carte, e mantenere un occhio sul loro account per trovare qualsiasi acquisto fraudolento.

Non memorizzare le informazioni di pagamento. Lascia che il gateway di pagamento lo elabori. Se maltrattano i dati delle carte, sono su di loro, non su di te.

Non memorizzare i dati della carta. Non archiviare mai il CVV, l'hash o no, crittografati o in chiaro, in chiaro o base64 o in qualsiasi altro modo.

Solo un po 'di matematica per il tempo di cracking.

Le prime 6 cifre sono l'identificatore dell'emittente. Ce ne sono meno di un milione, quindi puoi cercare su un tavolo e prendere tutti quelli possibili, e scegliere il più comune. Bank of America, Citibank, HSBC, Chase. Avrai circa cento per le prime 6 cifre.

Per una MasterCard, i successivi 9 numeri sono il numero di conto e l'ultimo cifra è la cifra di verifica. Puoi calcolare l'ultimo modo più veloce di gettarlo nella funzione hash, così avrai 1.000.000.000 di numeri di conto possibili e circa 100 possibili emittenti, per un totale di 10 11 numeri di carte possibili.

Con un strumento di hashing con 8x Nvidia GTX 1080s, hanno crackato 105 cento OpenBSD bcrypt hash al secondo, con un fattore di lavoro di 5. Non conosco i parametri che hai usato nel calcolo di bcrypt, ma consideriamo lo hai fatto buono come gli sviluppatori di OpenBSD (e sono abbastanza bravi)

Usando questi numeri, un singolo rig può rompere questo spazio di ricerca pertinente in:

100,000,000,000 numbers at 105,000 per second = 950k seconds
950k seconds = 264 hours = around 11 days

Un utente malintenzionato non crackerà ogni singola carta sul tuo database in 11 giorni, ma creerà tutte le carte dei principali emittenti in meno di 2 settimane. Affitta alcune piattaforme minerarie di Ethereum dal tuo criptatore di valuta criptato e un aggressore può rompere tutto questo in un giorno.

    
risposta data 03.07.2018 - 19:45
fonte
13

Sono d'accordo con la risposta di ThoriumBR. Ho qualche altro dettaglio e un suggerimento:

Stai provando a colpire un bersaglio in movimento. "Quanti round sono sufficienti?" è una domanda con una risposta mutevole al variare della disponibilità dell'hardware. Quando si tratta di impostazioni di hashing della password, molti sistemi hanno quindi metodi per aumentare automaticamente i cicli di hashing con il tempo. Qual è il numero minimo di round? Alcuni matematici potrebbero sicuramente rispondere (confrontando l'entropia media di una password complessa con l'entropia media di un numero di carta di credito e aumentando di conseguenza il costo). Tuttavia, sospetto che la risposta sia "un sacco di round". Inoltre, temo che ciò che stai cercando di fare sia fondamentalmente difettoso.

Hai taggato questa domanda come "PCI-DSS", quindi ovviamente questa è una preoccupazione rilevante. Generalmente il modo migliore per ottenere la conformità PCI è semplicemente non avere numeri di carta di credito sul tuo server. Il fatto che tu stia tagliando i dettagli della tua carta di credito significa che hai quei numeri. Non ricordo esattamente quali sono le regole per la conformità PCI quando i numeri delle carte di credito viaggiano effettivamente attraverso il tuo server, ma so che è molto più complicato e può persino essere proibitivo. È molto meglio non farlo.

Inoltre, il modo in cui si utilizzano le password di hashing non è del tutto normale e aumenta i rischi per la sicurezza per i propri clienti. I sali dovrebbero essere una stringa casuale - non c'è bisogno di legare l'id dell'utente (sembra strano anche perché l'intero punto di questo è far corrispondere le carte di credito tra utenti anonimi). Inoltre, includendo non solo il numero della carta di credito ma la scadenza e il CVC nell'hash è solo una pessima idea. Per ottenere ciò che desideri, ti occorrono solo i dettagli della carta di credito: ulteriori informazioni consentono semplicemente a un utente malintenzionato di ottenere i dettagli completi della carta di credito nel caso in cui ottengano e eseguano con successo il blocco dell'hash.

Questo è il tipo in cui entra in gioco l'idea "Non tirare la tua sicurezza". Se mi perdonerai, sembra che potresti essere un po 'al di fuori del tuo livello di esperienza quando si tratta di proteggere un cliente importante dati, quindi trovare il proprio sistema per abbinare le carte di credito dei clienti sembra un buon modo per inavvertitamente perdere un sacco di numeri di carte di credito e causare un sacco di problemi per la tua azienda.

Per ricapitolare, potrebbe essere meglio ascoltare la risposta di ThoriumBR: semplicemente non farlo. Il leggero miglioramento nell'interfaccia utente per i tuoi clienti non vale il rischio aumentato di perdita dei loro numeri di carta di credito. Se vuoi farlo, trova un processore di carte di credito conforme allo standard PCI che possa tradurre il numero della carta di credito in una stringa unica e sicura per te. Puoi quindi memorizzarlo e confrontarlo in modo sicuro nel tuo database. L'esempio immediato in cima alla mia testa è Stripe.

E alcuni numeri

Stamattina stavo anche guardando alcuni numeri. Ho trovato questo articolo pertinente:

link

La persona descrive l'utilizzo di quella che è (probabilmente) una configurazione di hashing di livello medio-basso per decifrare le password dal dump dei dati di Ashley Madison. Hanno usato bcrypt con un fattore di costo di 12 (credo che il numero di cicli di crittografia sia uguale a 2^cost_factor , cioè il fattore di costo di 12 = 2^12 = 4096 cicli di bcrypt (ma verificate assolutamente questo fatto se con questo tipo di cracking ha avuto un hash rate di 156 hash al secondo, ThoriumBR evidenzia abbastanza bene l'entropia di un numero di carta di credito (con circa 1e11 possibili numeri di carte di credito), il che significa che crackare una carta di credito numero con lo stesso setup di hash rig come il ragazzo nel link sopra con un fattore di costo di 12 impiegherà circa 20 anni. Salting farà in modo che ogni hash debba essere forzato brutalmente individualmente.

Naturalmente, questi numeri possono cambiare improvvisamente. La configurazione di hashing che ho citato nel mio esempio non è sicuramente al top della linea. Inoltre, le cose possono cambiare drasticamente se qualcuno crea un ASIC efficiente per bcrypt (non credo che ce ne sia ancora uno, ma potrebbe essere sbagliato).

    
risposta data 03.07.2018 - 21:16
fonte

Leggi altre domande sui tag