Problemi di sicurezza con il sistema di pagamento anticipato

6

Sto cercando di creare un sistema di pagamento anticipato per l'industria alimentare al dettaglio. I rivenditori saranno in grado di generare codici casuali a 10 cifre e fornirli ai clienti per accedere a un'app per ottenere il valore assegnato al codice. Il mio database è simile al seguente

  +----+-----------+-------------+-----------+-------+
  | ID | code      | activated   | user      | value |
  +----+-----------+-------------+-----------+-------+
  |  1 | iijwd923j |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  2 | aidwd923j |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  3 | jksjwdijk |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  4 | jiejdedow |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  5 | iwqjdwdqd |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+

Molte colonne omesse poiché non sono richieste qui. Quando il rivenditore genera il codice, viene sottoposto a hash e salato prima di entrare nel database. Quando il codice viene inserito nell'app, il proprio ID viene assegnato al codice e viene attivato. Il rivenditore può anche attivare o disattivare il codice se i codici vanno 'mancanti'. Questo è fatto dall'indice.

Prevedi problemi di sicurezza qui?

    
posta maxum 26.10.2012 - 07:45
fonte

2 risposte

6

Il principio di base sembra piuttosto buono.

Alcuni pensieri:

  • Quando viene utilizzato un token, non cancellarlo. Contrassegnalo come usato, memorizza una data "usata" e cancella i vecchi token dopo 6 mesi. In caso contrario, lo stesso numero di serie del token potrebbe essere ricreato per errore, poiché il sistema non ha alcuna registrazione di esso mai esistente.
  • È possibile che una singola istanza di questo sistema di pagamento anticipato venga eseguita su più siti fisici? In tal caso, dovrai tenere in considerazione la sincronizzazione dei dati, altrimenti un utente potrebbe riutilizzare il proprio token su un altro computer.
  • Se ogni sistema di vendita deve comunicare con una qualche tipo di stazione base, avrà bisogno di un modo sicuro per farlo. La sicurezza fisica di un cavo ethernet è OK nei piccoli negozi, ma vale la pena essere sicuri: assicurati di implementare SSL per tale traffico, con i certificati client e server installati sulle macchine appropriate.
  • Probabilmente vorrai legare ogni codice a un fornitore specifico, il cui ID è generato casualmente. In caso contrario, l'addetto al negozio potrebbe stampare una serie di codici e fare acquisti presso un altro fornitore che utilizza il proprio sistema. Assicurati che la generazione dell'ID utilizzi un generatore di numeri casuali di alta qualità!
  • Assicurarsi che siano state prese le opportune misure di sicurezza per il sistema che esegue il database. Blocca la macchina con criteri di gruppo, attiva e configura correttamente Windows Firewall, installa un pacchetto anti-malware (Microsoft Security Essentials è utile se non ti piace l'idea di eseguire soluzioni di terze parti), ecc.
  • Configurare correttamente il software del server del database. Ciò include il fatto di essere in ascolto solo localmente (non eseguire il binding a 0.0.0.0) o solo se possibile utilizza pipe locali. Dovresti inoltre utilizzare credenziali forti per il server e privilegi minimi. Se possibile, riduci tutte le query nelle stored procedure e consenti solo all'account di accedere a tali procedure: non concedere alcun privilegio su alcuna tabella.
  • Assicurati di implementare un sistema di controllo che registra il cassiere che ha effettuato la transazione, l'ora, l'ID ordine a cui apparteneva, il prezzo totale della transazione al momento (i prezzi dei prodotti cambiano!), l'ID del negozio, e il codice in chiaro che è stato usato. Non è necessario proteggere il codice a questo punto, è inutile.
  • In caso di rimborso in cui il cliente deve restituire il proprio token, generare un nuovo token. Non riutilizzare mai il vecchio numero di token.
risposta data 26.10.2012 - 08:02
fonte
1

Sembra un buon approccio per me.

Potresti considerare se prevedi la necessità di risoluzione delle controversie. A seconda dell'applicazione, forse non è necessario, ma ritengo che la risoluzione delle controversie e la fatturazione rappresentino una parte considerevole della complessità e della sfida di molti sistemi di pagamento.

Penso che potresti voler associare ciascun codice a un rivenditore specifico, in modo che possa essere riscattato solo presso quel rivenditore e quindi puoi eseguire rapporti su base per-rivenditore (ad esempio, numero di codici creati, numero riscattato, valore totale in circolazione, ecc.).

    
risposta data 26.10.2012 - 07:54
fonte

Leggi altre domande sui tag