CVV spiegato: a cosa serve il codice di sicurezza della carta

Il breve codice stampato su una carta di pagamento è il campo sul quale le persone esitano quando leggono una carta ad alta voce, e quell’esitazione è esattamente il punto. Un CVV è un segreto separato che vive solo sulla plastica, non nel numero, non nella data di scadenza e non in qualcosa che un ladro potrebbe ricostruire da una ricevuta. Fu aggiunto perché i pagamenti senza carta presente avevano bisogno di qualche prova che la persona che digitava i dettagli avesse davvero la carta in mano.

Questo articolo spiega cos’è il codice, perché la sua lunghezza cambia tra le reti, perché le regole dei pagamenti ne vietano la conservazione e a cosa fare attenzione quando costruisci o testi un modulo che lo richiede.

Cos’è il codice di sicurezza e dove è stampato

Per la maggior parte delle reti il codice è di tre cifre stampato sul retro della carta, all’interno della striscia per la firma o immediatamente accanto. American Express mette quattro cifre sul fronte, sopra l’ultimo gruppo del numero di carta.

Il valore è generato dall’emittente quando la carta viene prodotta. Non è derivato dal numero di carta, non è una somma di controllo e non può essere calcolato da qualsiasi altra cosa stampata sulla carta. Se perdi il codice non puoi recuperarlo con l’aritmetica; l’emittente deve riemettere la carta.

La documentazione usa diversi nomi per indicarlo, e la numerazione in quei nomi è significativa e non decorativa. Il termine semplice descrive i dati codificati nella banda magnetica o nel chip, mentre la versione numerata due è il valore stampato che un cliente legge. Un test di un terminale con carta presente e un test di una pagina di pagamento toccano quindi campi diversi, anche se i nomi suonano intercambiabili.

Perché su alcune carte il codice ha tre cifre e su altre quattro?

La differenza deriva dal piano di numerazione che ogni rete ha scelto, non da una distinzione di sicurezza. Un codice a quattro cifre non è più forte di uno a tre in alcun senso significativo; entrambi sono abbastanza brevi che indovinare non è il modello di minaccia. La lunghezza è semplicemente parte della specifica della rete, allo stesso modo in cui i suoi numeri di carta usano un numero diverso di cifre.

Per chi costruisce un modulo, questo singolo fatto genera la maggior parte dei bug in quest’area. Un campo codificato per tre caratteri tronca un codice American Express senza dirlo all’utente, e un validatore che pretende tre cifre rifiuta una carta legittima. L’approccio pragmatico è chiedere prima all’utente la marca, oppure rilevarla dal numero, e dimensionare il campo di conseguenza — con un limite massimo che rifiuti comunque input assurdi.

Cosa prova il codice e cosa non prova?

In una transazione senza carta presente il commerciante non può vedere la carta, quindi il sistema di pagamento chiede qualcosa che chi la tiene in mano può leggere. Il numero e la scadenza potrebbero essere stati copiati da una vecchia fattura o da un database violato; il codice stampato no, perché non è mai stato trascritto da nessun’altra parte.

Questo lo rende un ostacolo modesto ma reale alla frode occasionale, ed è per questo che il campo non è decorativo. Le reti trattano il codice come prova che una transazione ha soddisfatto un livello di verifica più alto, e i commercianti che lo raccolgono correttamente vengono gestiti diversamente da quelli che non lo fanno quando sorge una contestazione per frode. I termini precisi di quello spostamento di responsabilità appartengono alle reti; il messaggio pratico per chi costruisce un modulo è semplicemente che il campo deve essere raccolto, non simulato.

Ciò che il codice non prova è che la carta sia autentica o che il conto sia in regola. Un valore indovinato della forma giusta supera all’istante qualsiasi controllo lato client, perché un modulo non ha modo di verificare un segreto che non può vedere. Solo una richiesta di autorizzazione all’emittente può rispondere a quella domanda.

Perché le regole delle carte vietano di conservare il codice?

Questa è la regola che sorprende di più i team di ingegneria. Secondo lo standard di sicurezza dei dati del settore delle carte, il codice di sicurezza è classificato come dato di autenticazione sensibile. Può essere usato per autorizzare una transazione e non deve essere conservato dopo l’autorizzazione — non in una colonna di database, non in un file di log, non in un foglio di calcolo, non in un messaggio su una coda che un worker consuma dieci secondi dopo.

Il ragionamento è semplice. Un codice memorizzato è una credenziale di pagamento memorizzata. Se una violazione espone i numeri di carta, l’attaccante ha comunque bisogno di qualcosa in più per usarli online; se espone anche i codici, i numeri diventano immediatamente utilizzabili.

In revisione, i fallimenti raramente sembrano scelte deliberate:

• Una colonna aggiunta alla tabella degli ordini per una singola sessione di debug e mai rimossa.
• Un middleware di logging delle richieste che registra l’intero corpo inviato, codice incluso, in un aggregatore con controlli di accesso più deboli del sistema di pagamento.
• Un segnalatore di errori che allega il payload del modulo fallito a ogni eccezione.
• Una coda di retry che mantiene intatta la richiesta di addebito originale per poterla rieseguire.

Ognuno è un fallimento di conformità, e nessuno di essi somiglia a tale nel momento in cui viene scritto.

Compilare un campo codice di sicurezza senza errori

Qui la maggior parte della difficoltà è di digitazione più che di sicurezza, e i casi scomodi sono abbastanza prevedibili da progettarli in anticipo:

1. Un codice più lungo del campo. Qualcuno incolla quattro cifre in una casella da tre caratteri. O tronca in silenzio o mostra un messaggio, ma scegli un comportamento e applicalo coerentemente.
2. Input non numerico. Lettere, uno spazio, un trattino da un blocco copiato. Il campo dovrebbe rifiutarli senza cancellare ciò che l’utente ha già digitato.
3. Zeri iniziali. Un codice che inizia con zero è legale e non deve essere normalizzato via analizzando il valore come numero.
4. Mascheramento. Nascondere le cifre mentre vengono digitate sembra rassicurante, ma verifica che non rompa l’autofill o non faccia trattare al browser l’intero pagamento come una schermata di login.
5. Tastiere mobili. Un tastierino numerico è più veloce da usare, il che conta su un campo che le persone digitano tenendo una carta nell’altra mano.

Per gli sviluppatori: tenere il codice fuori da log e archiviazione

La disciplina ingegneristica qui è la sottrazione. La gestione più sicura dei dati di autenticazione sensibili è non averli in un sistema in nessun momento diverso da quello dell’autorizzazione.

Inizia rivedendo ciò che il tuo livello di logging cattura davvero. Un framework che registra i corpi delle richieste per impostazione predefinita registrerà il codice, e la destinazione del log è spesso un servizio di terze parti con regole di accesso diverse. Se il codice non raggiunge mai il tuo server — perché un campo di pagamento ospitato lo raccoglie direttamente — il problema scompare, e questa è l’opzione più forte disponibile.

Dove gestisci il valore, trattalo come transitorio. Non aggiungerlo a un oggetto modello che viene serializzato in una riga di audit, non includerlo in un payload di retry e non lasciare che un gestore di eccezioni lo alleghi a un report. Scrivi un test che cerca nell’output dei log dopo un’esecuzione e fallisce se compare un valore a forma di codice; quel singolo controllo intercetta la maggior parte della conservazione accidentale.

Poi guarda i tuoi dati di test. Qualsiasi cosa riempia automaticamente il campo dovrebbe provenire da valori sintetici, rivisti con la stessa cura di qualsiasi altra fixture di pagamento. Le note PCI DSS coprono le regole più ampie su ciò che può risiedere in un ambiente di test, e la checklist del modulo di pagamento colloca questo campo nella sequenza di flussi che vale la pena esercitare prima del lancio.

Carte di test e i loro codici segnaposto

Una carta generata ha bisogno di un codice per riempire il campo, e quel valore è un segnaposto allo stesso modo del resto della carta. Ha la lunghezza giusta e il set di caratteri giusto, e non corrisponde ad alcun segreto detenuto da un emittente.

Questo è il modo accurato di descrivere tutto ciò che restituisce il generatore di questo sito: dati strutturalmente validi che non sono mai stati emessi. Un codice segnaposto fa sembrare completo una demo o un test di preproduzione, e non autorizzerà nulla da nessuna parte.

Passi successivi

Controlla un modulo che possiedi per tre cose, in ordine: se il campo si adatta alla lunghezza del codice della rete, se il valore finisce in qualche log o tabella e se i messaggi di errore distinguono una lunghezza errata da un carattere non supportato. Per un numero da abbinare al campo, usa il generatore di numeri di carta, e per la data che gli sta accanto, la guida alla data di scadenza copre le regole di confine.