È una sicurezza se nel database è memorizzata un'alternativa del numero completo della carta di credito

Question

È una sicurezza se nel database è memorizzata un'alternativa del numero completo della carta di credito

#1 da (10 voti)
#2 da (10 voti)

0

Breve descrizione

Mi chiedo se esiste un modo per memorizzare in modo sicuro un'alternativa del numero totale della carta di credito, che non richiede il numero di carta da recuperare dall'altra alternativa.

Descrizione lunga

Il mio obiettivo qui è quello di archiviare in qualche modo un'alternativa del numero totale di carte di credito dei clienti nel database, in modo da poter identificare lo stesso cliente al momento dell'acquisto successivo. Tuttavia dovrebbe essere un enorme problema di sicurezza se abbiamo hash / criptare il numero completo nel database. Quindi mi riferisco all'idea della crittografia one-time pad in cui è stato usato il CC come chiave privata (Key) e la chiave verrà utilizzata per crittografare una stringa casuale che seguirà un pattern (testo normale). Pertanto Key non verrà memorizzato nel database e ci sono milioni di possibilità di Plain Text .

Flusso esatto dell'idea iniziale

Numero della carta di prova: 4539112781735373 (fonte: link )

A) Cripta il numero totale della carta di credito da bcrypt con il costo 14 ( $2y$14$g161t43Dcu7beXbIn2a55.LvH.Cpn7pwu05MPCz1PbAzbFEr0SqZS )

B) Converti l'output bcrypt in byte ( 00100100 00110010 01111001 00100100 00110001 00110100 00100100 01100111 00110001 00110110 00110001 01110100 00110100 00110011 01000100 01100011 01110101 00110111 01100010 01100101 01011000 01100010 01001001 01101110 00110010 01100001 00110101 00110101 00101110 01001100 01110110 01001000 00101110 01000011 01110000 01101110 00110111 01110000 01110111 01110101 00110000 00110101 01001101 01010000 01000011 01111010 00110001 01010000 01100010 01000001 01111010 01100010 01000110 01000101 01110010 00110000 01010011 01110001 01011010 01010011 )

C) Genera 6 numeri casuali di 10 cifre segui uno schema come testo normale (il modello dovrebbe essere abbastanza semplice da lasciare più possibilità aperte e complicare abbastanza da essere identificabile, diciamo che tutti possono essere divisi per 2 e 7 ) ( 1410065398 1410065384 1410065370 1410065356 1410065328 1410065342 ) e converti i numeri in byte ( 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00111001 00111000 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00111000 00110100 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00110111 00110000 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00110101 00110110 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00110010 00111000 00110001 00110100 00110001 00110000 00110000 00110110 00110101 00110011 00110100 00110010 )

D) Esegui XOR con byte dal passaggio B) e C), output 101010000011001001000000101000000000100000010000100010101010000001000000011100000000001000000000001010000001101110100010101010100000000000100010110100101000101101001010101100111100001011110000000100101011100000000000001100001100101111100010001110111110000011111011100110100000001011000000000100100001101000010010000110000000100000001011111000110000001110011010011000000010001100011010100000111100101001011010101100111011101110101010000100000011001100110010000100110111001100001

E) Quando c'è un altro acquisto effettuato dalla stessa carta di credito, il passaggio B verrà eseguito nuovamente e l'output dei byte verrà utilizzato per tutti i record del passaggio D) (indipendentemente dalle prestazioni)

F) Tutti i byte recuperati verranno quindi riconvertiti in numeri e verificati quali possono essere divisi per 2 e 7, i record corrispondenti verranno trattati come "cliente di ritorno"

Quello che mi chiedo davvero è ...

Il flusso sopra è sufficientemente sicuro per proteggere la carta dei clienti numero?
C'è qualche ulteriore passo che potrei prendere per renderlo più sicuro?
Potrebbero essere applicati algoritmi o pattern migliori per la fase C)?
Il costo 14 è abbastanza buono per il passaggio A)? O è il costo / sicurezza importa quando si ottengono i byte dalla carta di credito?
È possibile decifrare il numero completo della carta con il metodo sopra? se sì, quanto ci vuole?
Qual è la possibilità che 2 diverse carte di credito siano in conflitto con il metodo sopra riportato? (stesso risultato)

Scusa se non sono bravo in matematica, crittografia o sicurezza, qualsiasi idea è ben accetta.

Osservazione

Le prime 6 e le ultime 4 cifre del numero della carta sono memorizzate nel database da qualche altra parte.

encryption brute-force credit-card hash bcrypt

posta Zay Lau 15.01.2018 - 07:33

fonte

2 risposte

10

Francamente, questa idea non è molto intelligente. È massicciamente complicato, e non è chiaro cosa stai cercando di ottenere.

La tua offuscazione XOR è davvero inutile perché sei il prefisso di bcrypt di XOR con la tua serie numerica. Poiché il prefisso ($ 2y $ 14 $) è quasi sempre costante e noto all'attaccante, puoi usarlo per decodificare i primi 7 caratteri della serie di numeri casuali: "$ 2y $ 14 $" xor output_of_step_D [: 7]="1410065". Questo restringe la serie di numeri effettiva solo alle ultime tre cifre. Inoltre, sapendo che le serie di numeri devono essere divisibili per 2 e 7 e restringono l'inizio dei numeri a tre cifre a circa 71 possibilità (1000/14 = 71), e poiché la serie di numeri sarà in ordine decrescente, puoi eliminare la maggior parte del resto controllando quale delle 71 possibilità possono essere prodotte dal set di caratteri base64 di xor-ing bcrypt e dalle cifre ASCII.

Dato che la parte XOR e la parte di numeri non-casuali generati qui sono effettivamente inutili, in effetti non sei migliore della semplice memorizzazione della carta di credito in bcrypt qui.

La cosa peggiore di questo schema è questa:

the outputting bytes will be used to against all of the records from step

A causa di questa parte, sarà estremamente costoso per la propria applicazione controllare i clienti di ritorno, le prestazioni subiranno un aumento del numero di clienti e sarà necessario ripetere su ogni richiesta memorizzando nella cache tali assegni. sconfigge lo scopo. Non sarei sorpreso se questo controllo diventasse facilmente il collo di bottiglia principale della CPU.

risposta data 15.01.2018 - 13:05

fonte

Leggi altre domande sui tag encryption brute-force credit-card hash bcrypt

Perché dovrei proteggere il mio computer? Invio del nome del database nelle intestazioni delle richieste

score 10 · Accepted Answer

Disclaimer: Depending on your location there might be local laws and regulations regarding how to store credit card numbers (like PCI-DSS, for example). Look them up and when they are at odds with what I am proposing here, do what they say, not what I am saying.

Stai inventando un proprio algoritmo crittografico. Questo è qualcosa che non dovresti mai fare , a meno che tu non faccia parte della ristretta élite di esperti di crittografia di fama mondiale che hanno le conoscenze necessarie in matematica e informatica per farlo. E visto che ti descrivi come "non bravo in matematica, crittografia o sicurezza", non sembri esserlo. Quando cerchi di inventare la tua crittografia senza avere competenze sufficienti, farai cose che sono inutili nel migliore dei casi e feriscono attivamente la sicurezza nel peggiore dei casi.

In questo caso, usa solo una funzione di hashing unidirezionale e chiamala un giorno. bcrypt non è un'opzione appropriata qui, perché vuoi essere in grado di rilevare le collisioni con i dati che hai già. Ma bcrypt aggiunge un salt casuale a ogni hash generato, il che significa che più hash di bcrypt dagli stessi dati non assomigliano affatto. Questo è utile per lo scopo bcrypt è stato progettato per (password di hashing per l'autenticazione dell'utente) ma non adatto allo scopo (dati di impronte digitali per rilevare duplicati). Quello che vuoi è un algoritmo di hash crittografico che ti dà lo stesso output per lo stesso input. Gli attuali algoritmi all'avanguardia con questa proprietà sono SHA-3 (che presenta piccole somiglianze tecniche con algoritmi obsoleti SHA-1 e SHA-2 ) e BLAKE2 , ad esempio.

Se vuoi minimizzare il danno in caso di furto dell'intero database:

Aggiungi un pepe (aggiungi una stringa a ciascun numero di carta di credito uguale per tutti i numeri) alla tua generazione di hash. In questo modo non è possibile eseguire il rimando incrociato del database con un altro database che utilizza lo stesso algoritmo di crittografia.
Utilizza più round del tuo algoritmo hash alimentando ripetutamente l'output come input per il round successivo. Ciò moltiplica il tempo necessario a un cracker per forzare i tuoi numeri CC, ma anche il tempo necessario per elaborare nuovi numeri.