Generazione e protezione dei codici delle carte regalo

10

Sto lavorando per un'azienda che sta generando codici di carte regalo che possono essere utilizzati per pagare beni nei negozi online.

Mi chiedo quale sia il modo più sicuro per generare questi codici di carte regalo. La lunghezza deve essere di 16 caratteri (anche se è negoziabile) e può essere alfanumerica (anche se numerica sarebbe più adatta al cliente).

Da quello che posso vedere, il modo più sicuro per farlo è generare un codice di gift card di una lunghezza specifica con il seguente codice Java:

static final String AB = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
static SecureRandom rnd = new SecureRandom();

String randomString( int len ){
   StringBuilder sb = new StringBuilder( len );
   for( int i = 0; i < len; i++ ) 
      sb.append( AB.charAt( rnd.nextInt(AB.length()) ) );
   return sb.toString();
}

Viene preso dalla risposta Overflow dello stack qui . Ho rimosso le lettere minuscole dalla stringa per renderlo più facile da usare. Quindi questo produce combinazioni 36 ^ 16 . Solo numeri sarebbero combinazioni 10 ^ 16 . Credo che il solo numerico sarebbe sufficiente, ma è spesso sottolineato che, data la crescente diffusione della frode delle carte regalo, la stringa dovrebbe essere alfanumerica. Questa è la domanda 1: numerica o alfanumerica?

Quando gli utenti utilizzano le carte regalo in un negozio online per pagare i beni, viene effettuata una chiamata alla nostra API che restituisce il saldo e la valuta per quella carta regalo. Dato che i codici delle carte regalo sono inseriti su server di terze parti, queste carte regalo sono ora disponibili per le persone con accesso a quei server. Questo è ovviamente un problema nel caso in cui vi sia ancora un saldo residuo dopo che un utente ne ha parzialmente rimborsato uno.

Un'opzione sarebbe, quando la chiamata alla nostra API viene effettuata (con il codice della carta regalo) per ottenere il saldo, restituiamo e salviamo sul loro negozio una stringa casuale che può essere utilizzata solo dal negozio online quando ci stanno fatturando - lo abbineremo al codice della carta regalo sul nostro sistema. Il problema con questo è presumibilmente il codice della carta regalo che l'utente inserisce nel checkout viene registrato da qualche parte nei propri registri ed è accessibile a chiunque abbia accesso a tali registri.

Un'altra opzione è che aggiorniamo il codice della carta regalo dopo che è stato parzialmente riscattato. Quindi l'utente viene essenzialmente rilasciato con un nuovo codice della carta regalo per il saldo e il precedente viene annullato. Questo è probabilmente il più sicuro, ma non così facile da usare. Questa è la seconda domanda: in che modo vengono protetti i codici delle carte regalo che vengono riscattati solo in parte e hanno ancora un valore residuo?

Modifica

Abbiamo anche una pagina Verifica saldo in cui un utente inserisce un codice di carta regalo e la valuta e il saldo vengono restituiti. Ciò presumibilmente crea alcuni problemi di sicurezza aggiuntivi.

    
posta Mark 03.04.2018 - 12:49
fonte

5 risposte

7

Per prevenire le frodi, hai bisogno di una probabilità sufficientemente bassa che l'autore dell'attacco possa indovinare qualsiasi codice valido. Per 1 milione di carte, un codice 10 ^ 16 sarà calcolato in media ogni 10 ^ 10 tentativi. Se il tuo sito è completamente sicuro e la tua API è resistente alla forza bruta, il valore numerico dovrebbe essere sufficiente a mantenere quell'approccio alle frodi non conveniente.

Ma è una sicurezza molto fragile, e la protezione di hashing di seguito sarà facile da decifrare in una perdita di database con uno spazio delle chiavi così piccolo. IOW, un utente malintenzionato con accesso al tuo DB sarà in grado di forzare bruscamente molti codici validi. Un codice alfanumerico fornirà una sicurezza più robusta. Puoi anche scendere a compromessi usando un pattern per la facilità d'uso.

Dal momento che nel tuo sistema il codice è effettivamente sia un login che una password, per ridurre le perdite devi modificare il protocollo di comunicazione per eliminare la trasmissione e l'archiviazione dei codici in chiaro.

Il protocollo più semplice sarebbe quello di memorizzare Salt1 e Sash1 = hash (Code + Salt1), quindi generare hash (hash (Code + Salt1) + Salt2) lato client e controllarlo. Ma ciò rimane banalmente vulnerabile se il tuo database è compromesso, in quanto l'hacker ha solo bisogno di un elenco di Hash1 valido per effettuare acquisti tramite la tua API. È anche lento perché devi cancellare tutti i codici validi per controllarne uno.

Una soluzione più robusta è eseguire il codice attraverso un PBKDF, che è una funzione lenta e irreversibile, producendo un valore che è possibile memorizzare. In questo modo una perdita di database non fornirà dati pronti per simulare un utente legittimo. Ma devi fidarti dei negozi per non memorizzare il codice e imporre le connessioni https-only.

È impossibile rendere questo sistema sicuro contro un archivio canaglia che registra l'input dell'utente - se hanno il codice completo, per definizione possiedono la carta. L'unica difesa è consentire solo il rimborso del codice attraverso un modulo caricato direttamente dal tuo server. Se lo fai, nessuno tranne l'utente e il tuo PBKDF vedranno mai il codice; il negozio riceve solo la tua risposta di convalida.

    
risposta data 03.04.2018 - 15:17
fonte
1

Given that the gift card codes are entered on 3rd party servers, these gift cards are now available to people with access to those servers.

È vero che gli amministratori del server possono accedere alle carte regalo, ma possono anche accedere ai numeri delle carte di credito che gli utenti inseriscono nei negozi online. Se puoi fidarti di un negozio online per raccogliere un numero di carta di credito senza fare nulla di nefasto, perché non puoi fidarti anche di loro per ritirare un ID della carta regalo? (O forse stai pensando che quando un amministratore ruba i numeri CC, non è un tuo problema, ma se rubano i codici delle carte regalo, è il tuo problema ...) Forse controllare correttamente i tuoi commercianti deve essere parte del tuo modello di business.

La tua idea di cambiare il codice della carta regalo dopo ogni acquisto dovrebbe funzionare, ma come fai a dire all'utente quale è il loro nuovo codice? Forse potresti inviarli tramite e-mail notificandoli della transazione, includere il saldo residuo e fornire loro un link per accedere e ottenere il loro nuovo ID carta regalo. Sono d'accordo però, che potrebbe essere un po 'fastidioso per alcuni utenti. Dipenderà davvero da quanto il commerciante sembra affidabile e l'utente potrebbe saperlo meglio. Forse potresti consentire all'utente di decidere se abilitare l'opzione di ripristino e magari anche consentire loro di impostare una soglia oltre la quale si verifica (ad esempio $ 50).

    
risposta data 11.04.2018 - 00:32
fonte
1

Credo che ci sia un problema fondamentale che non puoi affrontare tecnicamente. Le misure antifrode più consolidate riducono il rischio, ma è necessario accettare che si verifichi una frode.

Questo è fondamentalmente un problema di fiducia. Ti stai fidando dei negozi per addebitare l'importo corretto dalla carta regalo per ogni transazione e solo per registrare transazioni autorizzate dall'utente. Ti stai anche fidando che l'utente manterrà la carta segreta.

I problemi di affidabilità richiedono un controllo. Come con le carte di credito, esiste un potenziale abuso da parte di terze parti. Molte delle regole PCI DSS relative alle carte di credito sono progettate per ridurre al minimo il rischio di frode, ma anche con tali regole il settore delle carte di credito deve affrontare un rischio sostanziale di frode. Per far fronte a tale rischio, la banca monitora i segni di frode e le dichiarazioni sono disponibili per i titolari delle carte in modo che possano riesaminare l'attività dell'account per le transazioni non autorizzate. Non è possibile eliminare il rischio di frode, quindi è necessario monitorare e riferire sull'attività --- e consentire agli utenti di fare lo stesso.

La vigilanza e la reattività sono le uniche soluzioni a lungo termine. Nonostante le ragionevoli misure di sicurezza, non è possibile evitare completamente le frodi. Se ciò fosse possibile, l'industria delle carte di credito risparmierebbe miliardi di dollari all'anno. Non potevano farlo, e probabilmente anche la tua compagnia non lo farebbe. La tua azienda e gli utenti devono prestare attenzione agli abusi e intraprendere azioni correttive secondo necessità. Se la tua azienda emette buoni regalo, devono impegnarsi a utilizzare personale anti-frode per tutta la vita del programma. Anche se non insegui un caso legale, dovrai fornire un rimedio ai tuoi utenti . Qualcuno deve avere il potere di indagare e giudicare le richieste di frode.

Esistono misure di sicurezza stabilite che puoi implementare. La maggior parte delle carte regalo iniziano con un saldo zero e / o sono inattive fino a che non vengono vendute. Il numero di conto o CVV dovrebbe essere nascosto fino a quando non viene venduto (sigillato in un pacco anti-manomissione o dietro un gratta e vinci). Al punto di vendita, l'attivazione è basata su un numero di serie anziché sull'ID della carta regalo --- e l'ID della carta regalo non è derivato da quel numero di serie in alcun modo visibile, o viceversa.

I segreti sono condivisi e questo infrange la maggior parte della sicurezza. Con le carte regalo e le tradizionali carte di credito, gli utenti forniscono venditori di terze parti con tutto il necessario per impersonarli. Questo è in netto contrasto con i sistemi basati su blockchain che consentono agli utenti di mantenere riservati i propri segreti. Quando si ha a che fare con un sistema fondamentalmente insicuro, è necessario implementare controlli compensativi o attenuazioni per tali rischi. Quindi accetti qualsiasi rischio rimanga e soldato.

    
risposta data 11.04.2018 - 01:36
fonte
1

Nel mondo delle carte di credito, ogni transazione online in cui un cliente digita i numeri delle carte in un browser, richiede il numero della carta E il codice CVV2. Questo è in genere un codice a 3 cifre stampato sul retro della carta. I commercianti sono invitati a MAI memorizzare questo numero, ma possono conservare il numero della carta (con restrizioni molto rigide).

L'analogia è che il numero della carta è come un Username, mentre il CVV2 è come la password (sorta di, forse!). Il tuo problema sembra essere che ti stai solo affidando ai numeri delle carte, il che equivale a fare affidamento solo sui nomi utente per motivi di sicurezza. Questo è un problema, ci dovrebbe essere in qualche modo per autenticare la carta, il numero della carta è semplicemente un identificatore.

Il mio suggerimento è di aggiungere una sorta di PIN alla transazione. Il cliente deve fornire il PIN nella chiamata API prima che possa essere approvato. Il PIN non deve mai essere memorizzato nei registri dei commercianti. Se sei preoccupato di questo, prova a creare un PIN One Time (OTP) che invii al cliente quando viene effettuata una transazione, ma questo aggiunge un carico di complessità, ma rimuove anche il rischio di riutilizzo dei commercianti la carta per un'altra transazione, poiché non avranno mai l'OTP.

Cambiare il numero della carta è una cosa ancora più difficile da fare, e probabilmente non è il miglior viaggio per il cliente, non lo consiglierei.

    
risposta data 11.04.2018 - 05:51
fonte
0

Ho esaminato tutte le risposte e ho trovato una soluzione, tenendo conto dei suggerimenti:

  • Generiamo un link da inviare all'utente. La chiave inviata nel collegamento è una stringa alfanumerica casuale ed è hash (MD5 o qualcosa di simile) quindi non può essere revocata prima di essere salvata nel DB.

  • Quando l'utente fa clic sul link, viene reindirizzato alla nostra pagina di destinazione, usiamo la chiave per ottenere l'ordine, controllare lo stato dell'ordine e se c'è credito su di esso, e se è ok generiamo un Codice alfanumerico di 16 caratteri e inviato all'interfaccia utente. Il codice di 16 caratteri viene sottoposto a hashing (sempre MD5) e salvato nel nostro database. Ogni volta che un utente fa clic sul link, vedono un nuovo codice della carta regalo che viene generato al volo ogni volta.

  • Nel contratto con il negozio online, specifichiamo che non possono registrare o salvare il codice della carta regalo da nessuna parte (i nostri 2 clienti sono grandi rivenditori online noti)

  • Nella pagina di pagamento del negozio online del nostro cliente, per pagare con il nostro codice della carta regalo, l'utente fornisce il codice della carta regalo da 16 caratteri. Viene inviato ai nostri server e il saldo e un I.D. a pagamento casuale. viene restituito al negozio online. Questo pagamento I.D viene salvato nel negozio online come parte dell'ordine. Al completamento dell'ordine, il negozio online invia una richiesta API (con l'ID di pagamento) ai nostri server per riscattare l'importo dalla carta regalo (questa funzionalità è stata creata da noi e viene fornita al negozio online tramite un plug-in che installano).

  • la comunicazione tra lo store online e la nostra API è autenticata usando OAuth 2.0

  • Se sulla carta regalo è rimasto un saldo, viene generato un nuovo codice della carta regalo (all'utente viene inviato un nuovo collegamento per ottenere il nuovo codice della carta regalo per il saldo)

  • Quando il negozio online ci sta fatturando, ci fornisce un elenco di ID di pagamento, che poi corrispondono ai codici delle carte regalo nel nostro back-end (quindi abbinati al nostro emittente).

Protegge:

  • Il codice della carta regalo non viene inviato ad una email - solo il link (nel nostro backend possiamo fare alcuni controlli - come vedere l'ordine è scaduto, il credito è già stato utilizzato, prima di visualizzare il codice della carta regalo)

  • Chiunque abbia accesso al DB del negozio online non vedrà i nostri codici carta regalo

  • Qualcuno che ha violato il nostro database non può vedere i codici delle carte regalo (come sono hash), né generare il link per vedere i codici delle carte regalo (come la chiave per il collegamento è hash)

Fammi sapere se ci sono commenti.

    
risposta data 30.04.2018 - 16:20
fonte

Leggi altre domande sui tag