In che modo la generazione dei token di pagamento è sicura nello sviluppo mobile?

Question

In che modo la generazione dei token di pagamento è sicura nello sviluppo mobile?

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

1

Uso Stripe per i pagamenti delle app nel mio progetto di app per dispositivi mobili e non capisco perfettamente come qualsiasi app sia protetta se l'utente immette le informazioni sulla scheda (con o senza stripe) se non è su HTTPS per tutto il tempo .

Dalla mia comprensione se vuoi fare qualsiasi forma ^{_{(gioco di parole)}} dei pagamenti su un dispositivo mobile devi creare un token e inviare quel token a un back-end server che utilizza HTTPS (e ha la chiave privata) per elaborare il pagamento (con stripe, non sono abbastanza familiare con gli altri).

Come indicato dalla striscia:

It's worth noting that Checkout doesn't actually create charges—it only creates tokens. You can use those tokens to create the actual charge on your server.

Dove il token diventa una carica quando è sul lato server che è su SSL

All submissions of payment info using Checkout are made via a secure HTTPS connection. However, in order to protect yourself from certain forms of man-in-the-middle attacks, we suggest that you also serve the page containing the payment form with HTTPS as well. This means that any page that a Checkout form may exist on should start with https:// rather than just http://.

La mia domanda / preoccupazione (TL; DR):

Quindi puoi creare un token senza averlo sopra HTTPS, dove è solo il pagamento che deve essere su HTTPS. Tuttavia, questo processo di creazione di token è sicuro (la mia prima domanda)? Non posso fare a meno di pensare che chiunque inserisca le proprie informazioni sulle carte in cui le informazioni vengono inviate sul filo per strisciare e tornare indietro per creare un token non è sicuro ed è soggetto agli attacchi degli uomini nel mezzo.

È sicuro che il token venga creato su HTTP e non su HTTPS? È sicuro quindi inviare il token creato tramite il cavo tramite HTTP?
In tal caso, non potrebbero essere compromesse le informazioni sulla carta dell'utente (ad esempio raccolte o raschiate) in questo processo? Quando le informazioni sulla carta sono state inserite, inviate a stripe, inviate indietro e inviate server tutto senza HTTPS ?
Quali sono le migliori pratiche quando si tratta di un dispositivo mobile? Questo caso differisce nello sviluppo nativo o ibrido? Che dire dell'utilizzo nel browser delle app per i pagamenti?

mobile credit-card tls token payment-gateway

posta garrettmac 10.11.2015 - 21:10

fonte

2 risposte

Leggi altre domande sui tag mobile credit-card tls token payment-gateway

Come posso creare una botnet di ricerca all'interno di VMware? Il mio server è stato compromesso? [duplicare]

score 2 · Answer 1

Sembra che tu abbia un malinteso sulla creazione di token, quando dici puoi creare un token senza che sia su HTTPS . La creazione di token è la seguente:

Il titolare della carta invia la carta tramite HTTPS alla striscia
Stripe memorizza il numero della carta e lo associa a un token che genera
Metti le mani sul token al mercante (tu).
Da quel momento in poi, puoi addebitare la carta di credito sottostante comunicando a Stripe di addebitare il token.

Passaggio 1, in cui il numero della carta viene trasmesso attraverso la rete, deve essere protetto da HTTPS . Il token, pur non essendo sensibile come il numero della carta, viene solitamente trasmesso anche su HTTPS.

Quando Stripe dice

we suggest that you also serve the page containing the payment form with HTTPS

Significa che la tua pagina che contiene il modulo (o iframe, link o javascript) che conduce a Stripe. Non stanno parlando di trasmissioni di token successive quando lo dicono (anche se, di nuovo, la pratica standard è di proteggere anche il token).

Per rispondere alle tue domande:

Is it secure for token be created over HTTP and not HTTPS?

No. La creazione di token richiede la trasmissione dei dati delle carte, che richiede HTTPS come da PCI. Ricorda, non crei il token, fa Stripe e si trovano dall'altra parte di Internet sia da te che dai tuoi clienti.

If so, couldn't the user's card info be jeopardized (e.g collected or scraped) in this process?

Poiché # 1 è "no", la clausola "se sì" non si applica. (Sì, se non hai utilizzato HTTPS, le informazioni sulla scheda dell'utente potrebbero essere compromesse, motivo per cui deve essere HTTPS.)

What are the best practices when dealing when mobile?

La cosa migliore è criptare tutto, acceso o spento.

score 1 · Answer 2

I PAN della carta di credito devono MAI essere inviati in chiaro o memorizzati in modo non criptato.

Ciò significa che è necessario recuperare le informazioni della carta di pagamento dall'utente tramite un canale sicuro come HTTPS e ottenere un token di pagamento per tale da Stripe su HTTPS.

Una variante interessante su questo che omette la tua app web da PCI è quella di inviare una chiave pubblica al client, fare in modo che JavaScript crittografi il PAN e poi il server manda tale PAN crittografato a un servizio di tokenizzazione sul tuo backend che ha il privato chiave e parla con Stripe.