La scelta di un'unica piattaforma: il punto di vista di un ingegnere sull'unificazione di Verify, Fraud e Auth

Dietro le quinte dell'Ingegneria · Il primo capitolo di una nuova serie con gli ingegneri di Prelude su come viene effettivamente costruito il prodotto

In un'intervista con Loïc Madiès, Senior Backend Engineer presso Prelude.

Prima di Prelude, facevo parte del team di autenticazione di un sito di e-commerce in Francia. La prevenzione delle frodi era comunque una parte fondamentale del mio lavoro.

Sulla carta, lo stack era sensato. Email e password, OTP per l'autenticazione a più fattori e una manciata di provider per il login social. Dietro le quinte: DataDome per il traffico bot, Vonage per la gestione dell'invio degli OTP e un sistema di autenticazione sviluppato internamente. Tre strumenti, un solo obiettivo — consentire a un utente di accedere alla piattaforma — e nessuno di loro comunicava con gli altri. Alla fine gli account fraudolenti venivano segnalati, grazie a modelli che analizzavano i pattern a posteriori, ma a quel punto l'accesso era già stato effettuato. 

Non avevo una reale visibilità su cosa stesse accadendo in quel preciso istante. Questo divario, unito al fatto che una piattaforma creata per condividere segnali tra questi diversi elementi mi sembrava davvero interessante, è uno dei motivi per cui ho deciso di entrare in Prelude.

Tre strumenti, un solo obiettivo, nessun contesto condiviso

Questo è l'aspetto che va definito con precisione: ognuno di questi tre strumenti svolgeva correttamente il proprio lavoro individuale, ma mancava comunque l'elemento fondamentale.

L'autenticazione da sola copre già un'ampia superficie d'attacco, ma non è propriamente pensata per il rilevamento delle frodi; si limita principalmente a verificare se la password è corretta, quanti tentativi sono stati effettuati, insomma questo tipo di limitazione della frequenza. Uno strumento anti-bot può rilevare che il volume di tentativi da uno specifico IP o paese appare leggermente elevato, ma non è in grado di stabilire se sia effettivamente sospetto o se si tratti di traffico normale, non senza i dati del numero di telefono provenienti dalla verifica.

Senza un contesto condiviso, un sistema può rilevare che qualcosa somiglia a un bot e comunque lasciarlo passare come un normale login non segnalato. 

Una volta che si riesce a inserire le informazioni provenienti dal lato anti-bot o di verifica all'interno del flusso di autenticazione, è possibile distinguere pattern che nessuno dei due lati riuscirebbe a intercettare da solo. Una password pericolosa, un'email insolita, un numero insolitamente alto di tentativi da un singolo paese in un breve intervallo di tempo: nessuno di questi elementi, preso singolarmente, è determinante.

Insieme, con l'aggiunta del numero di telefono e della cronologia dei dispositivi, offrono un segnale molto più chiaro. E se il pattern di aggiornamento di una sessione mostra un IP diverso a ogni tentativo, questo è un forte indicatore di un proxy residenziale; anche in questo caso, è qualcosa che emerge solo quando si analizzano insieme i segnali di autenticazione e di frode.

Condividere questo contesto fa bene alla sicurezza e, altrettanto direttamente, all'esperienza utente: consente di saltare una re-autenticazione ridondante perché il sistema sa già cosa è già stato verificato.

Questo non è stato aggiunto in un secondo momento. Era il piano fin dal primo giorno

A volte si pensa che un'unificazione del genere venga integrata a posteriori, partendo da tre prodotti nati separatamente e poi collegati insieme. 

Ma non è andata così. 

Condividere i segnali tra questi prodotti era la vision aziendale fin dall'inizio: delegare l'onboarding e la fiducia a un unico attore piuttosto che a diversi, proprio per consentire alle informazioni di circolare tra loro.

L'obiettivo era consentire ai clienti di concentrarsi sul proprio business invece di gestire direttamente gli utenti malintenzionati; un unico attore che gestisce l'intero processo è in grado di rilevare di più, con meno falsi positivi, rispetto a quanto potrebbero mai fare tre sistemi scollegati.

Ho iniziato occupandomi nello specifico di autenticazione, senza concentrarmi troppo sulle frodi, semplicemente perché c'era molto da costruire.

Una volta implementate le funzionalità principali, sono passato anche al lato anti-frode e verifica, ed è lì che per me è avvenuta la contaminazione: i pattern che ho appreso sul fronte frodi (blocco dell'SMS pumping, poi dei bot, infine del furto di account) hanno influenzato direttamente il comportamento dell'autenticazione, perché a quel punto erano la stessa persona e lo stesso segnale a guidare entrambi gli aspetti.

L'esempio concreto più chiaro: i Refresh Token

Se dovessi indicare un singolo dettaglio tecnico che dimostra questo valore meglio di qualsiasi discorso filosofico, sarebbe questo.

In una tipica configurazione interna, se qualcuno ruba un token (ad esempio, intercettandolo su una rete pubblica) e in quel momento viene effettuato il rinnovo del token, si potrebbe riutilizzare quel refresh token rubato; questo era perfettamente possibile nelle mie aziende precedenti. 

Forti di questa esperienza, abbiamo scelto di renderlo impossibile utilizzando chiavi private sul dispositivo dell'utente, in modo da poter capire se un refresh token viene riutilizzato da un dispositivo diverso, grazie a una soluzione che chiamiamo DPoP. Si tratta di un ulteriore livello di sicurezza, a cui si aggiunge la cronologia del fingerprinting che ci aiuta a riconoscere se è un dispositivo diverso a riutilizzare la stessa sessione.

È un problema concreto, perché quando si sviluppa internamente ci si concentra principalmente sul login, dimenticando ciò che viene dopo; gli utenti aggiornano una sessione molto più spesso di quanto non effettuino un vero e proprio login. 

Questo processo diventa più sicuro proprio perché condivide i segnali con il lato frodi: sul front-end raccogliamo già molte informazioni dal dispositivo, il che rende più semplice rilevare questi pattern.

Il compromesso onesto: il rischio di disservizio

L'unico vero svantaggio (e non sarebbe onesto far finta di nulla) è che centralizzare significa che un disservizio può mandare offline tutti e tre i servizi contemporaneamente, poiché si trovano tutti sullo stesso percorso critico.

Non voglio fingere che la nostra soluzione sia una vittoria netta su questo punto, perché non lo è. Scegliendo invece tre provider distinti, ognuno rappresenta comunque il proprio percorso critico per la funzione che svolge; di conseguenza, perdere uno qualsiasi di essi significa comunque che un utente non può accedere, con lo stesso risultato finale che si avrebbe perdendo il nostro unico sistema integrato. 

La vera differenza sta nel numero di punti in cui può verificarsi un guasto: un'unica superficie di disservizio che blocca tutto insieme, contro tre superfici separate, ognuna delle quali è in grado di causare lo stesso identico blocco da sola. Sostanzialmente i due approcci si equivalgono, e preferisco dirlo chiaramente piuttosto che presentarlo come qualcosa che non è.

Dove le cose si fanno davvero difficili: la migrazione

Se c'è un ostacolo reale e concreto per i potenziali clienti, questo è la migrazione, ed è bene spiegare nel dettaglio il perché.

Sostituire un provider che si occupa solo di verifica è quasi banale: basta cambiare una chiamata API, forse due, e il gioco è fatto. 

L'autenticazione è un problema completamente diverso, perché richiede dati: chi è già registrato, come lo è, inclusi elementi come i login Google esistenti che devono essere trasferiti. Tecnicamente si tratta pur sempre di una singola azione, ma richiede diverse settimane e, poiché non si presenta come una nuova funzionalità (come potrebbe essere l'abilitazione di un nuovo metodo di pagamento), spesso non viene considerata prioritaria dai team di prodotto.

Ogni provider di autenticazione si scontra esattamente con questa difficoltà, non solo Prelude.

La parte che richiede maggiore attenzione è non perdere utenti durante il processo. C'è un timore reale, da entrambe le parti, che un errore di migrazione disconnetta gli utenti o che una password o un numero di telefono modificati lascino qualcuno fuori dal proprio account, cosa che né gli utenti né l'azienda che effettua la migrazione desiderano. Per questo motivo, la migrazione a Prelude copre anche le sessioni esistenti, non solo le credenziali di accesso, proprio per garantire che chi è già connesso rimanga tale durante il passaggio.

La semplicità come vero elemento di differenziazione

Il vero elemento di differenziazione rispetto ai concorrenti che hanno iniziato a parlare di unificazione di questi elementi si riduce a due fattori: essere realmente all'avanguardia sul lato fraud (nello specifico, sulla verifica tramite SMS) e una scelta deliberata su quanto controllo la piattaforma tolga al cliente.  

La maggior parte dei provider di login offre una pagina verso cui reindirizzare l'utente per poi farlo tornare indietro, un'esperienza che si rivela poco fluida soprattutto su mobile: una pagina web che si apre all'interno di un'app mobile raramente trasmette una sensazione di natività. 

La scelta di Prelude Auth è stata quella di non creare affatto quella UI: gestiamo la sicurezza e la logica di backend, esponiamo il login come un metodo che il cliente chiama direttamente e lasciamo che sia il cliente a creare la propria interfaccia. Si tratta di un compromesso reale rispetto a un concorrente che offre una soluzione più "chiavi in mano" basata su pagine esterne, ed è una scelta deliberata.

La stessa filosofia si riflette nei prezzi e nell'ambito di applicazione. L'obiettivo dichiarato è non avere tariffe per singola funzionalità, in modo che una nuova opzione non faccia lievitare silenziosamente la fattura del cliente, come accade con i provider che raggruppano funzionalità mai richieste. 

La vision è creare le funzionalità di cui il 90% delle persone ha bisogno, anche se questo significa perdere il 10% dei potenziali clienti. L'aspetto più importante non è quanti metodi di login si offrono: gli standard documentati sono numerosi, e gran parte di quella documentazione può alimentare un'IA per costruirli al posto tuo.

Il punto principale dell'autenticazione è la prevenzione delle frodi. È qui che possiamo essere davvero determinanti.

Due specifici pattern di frode intercettati

Vale la pena citare direttamente due esempi concreti, perché sono abbastanza specifici da poter essere verificati anziché solo ipotizzati.

Attacchi a dizionario basati su dati trapelati. Una quota significativa di credential attacks non è casuale. Viene costruita a partire da informazioni già trapelate: un indirizzo, il nome di un familiare, il nome di un figlio. Un utente malintenzionato può creare una breve lista di password probabili da questi dati ed effettuare una manciata di tentativi distanziati nel tempo, rimanendo sempre al di sotto delle normali soglie di limitazione della frequenza; ad esempio, pochi tentativi ogni dieci minuti per alcuni giorni, piuttosto che un picco improvviso che farebbe scattare un allarme evidente. Conoscevo questo pattern per esperienza anche prima di Prelude; è uno degli elementi che Watch è stato specificamente progettato per intercettare, utilizzando un segnale condiviso piuttosto che il semplice conteggio dei tentativi.

Proxy residenziali su larga scala. I bot cercano di nascondersi, e uno dei modi in cui lo fanno è ruotare attraverso indirizzi IP residenziali piuttosto che IP palesemente sospetti. L'analisi di rete può identificare questo pattern, ma solo se lo cerca su un volume sufficiente: un singolo tentativo di login lento e accurato ogni venti minuti non sembra nulla di insolito se preso da solo. È il pattern su larga scala, combinato con ciò che accade sul sito in un secondo momento, a rivelarlo. Un sistema che monitora solo l'autenticazione, in modo isolato, non sarà in grado di vederlo.

Il nocciolo della questione

La nostra scommessa è che la condivisione dei segnali tra verifica, autenticazione e protezione dalle frodi, intesa come pacchetto unico anziché come tre acquisti separati e collegati, sia un elemento strutturalmente diverso e più potente rispetto agli stessi tre elementi creati separatamente e uniti a posteriori.

Ciò che ho imparato lavorando su questo progetto, dopo aver sviluppato l'autenticazione in-house per una singola azienda all'inizio della mia carriera rispetto a costruirla come piattaforma condivisa per molti: si tratta di due discipline profondamente diverse. 

L'accesso ai dati di molti clienti, anziché alla sola porzione di un singolo prodotto, rappresenta la vera svolta: un pattern di portata globale si manifesta sull'intera base clienti della piattaforma condivisa prima ancora di raggiungere uno qualsiasi di essi singolarmente. 

Sviluppando internamente vedi solo la tua porzione di dati, ed è esattamente questo il divario che ho iniziato a descrivere all'inizio di questo articolo dall'altra prospettiva, anni fa, quando ancora non sapevo dargli un nome.

Vuoi vedere come funziona per il tuo stack?

Se tutto questo, in particolare il dettaglio sui refresh token, somiglia a un problema che stai attualmente risolvendo con tre fornitori diversi, parla con il team di Auth della tua configurazione specifica.

Loïc Madiès è un ingegnere presso Prelude e si occupa di Auth. È entrato in Prelude provenendo da Leboncoin, dove si è occupato di sistemi di gestione delle sessioni e anti-frode, portando quell'esperienza direttamente nel modo in if cui il prodotto Auth di Prelude condivide oggi i segnali tra le sessioni. Ha studiato ingegneria presso il Polytech Lyon.