800 file in 30 minuti, con le mie credenziali

Mi servivano dei documenti miei, su una piattaforma dove ho un account.

Non li ho scaricati io. Ho delegato al mio agente personale. Gli ho passato mail e password, che era tutto quello che la piattaforma chiedeva per entrare.

Trenta minuti dopo avevo più di 800 file sul disco.

Circa 27 file al minuto, per mezz'ora di fila, da un account che fino a quel momento aveva scaricato roba a una velocità umana: apri, cerchi, clicchi, aspetti, ripeti.

Niente di illecito. Account mio, documenti miei, agente mio. E proprio per questo il numero è interessante: è quello che il sistema lascia fare a chiunque abbia due stringhe di testo, senza che nessun controllo si accorga di niente.

La password l'ho cambiata subito dopo. Ma la password non era il problema.

Il modello presumeva un umano alla tastiera

Il punto non è che manchi un rate limit. È che il rate limit c'era, ed era implicito.

Da quando esistono le sessioni web — vent'anni buoni — la velocità di un client autenticato è stata la velocità di una persona che clicca. Nessuno ha scritto un limite di 40 download al minuto perché nessun utente reale ci arrivava. Il limite lo metteva il corpo umano: leggere il nome del file, decidere, spostare il mouse, aspettare il refresh.

Quel limite non è mai stato un controllo. Era un effetto collaterale, e ha lavorato come se fosse un controllo per tutto il tempo in cui nessuno lo ha messo alla prova.

E qui va tolta subito la scusa comoda, perché è la parte che mi ha convinto a scriverne: non è un sistema vecchio.

La piattaforma da cui sono usciti quegli 800 file non è un residuo degli anni Duemila in attesa di pensione. È un prodotto di questo decennio, di un operatore che nel proprio materiale commerciale mette l'intelligenza artificiale in prima riga.

Il prodotto è nuovo. Il modello di autenticazione che lo protegge no. Ereditare un default del 2005 non richiede di avere vent'anni: richiede solo che nessuno, nel rifare tutto il resto, sia tornato a guardare quello.

Un agente lo cancella in un pomeriggio. Non serve un exploit, non serve bucare niente: serve automatizzare un percorso che il sistema considera già legittimo, e percorrerlo alla velocità della rete invece che a quella di una mano.

Tutto ciò che nel tuo sistema è protetto dalla lentezza dell'utente, oggi non è più protetto.

Dopo il login la password non conta più

L'altra cosa che ho visto da vicino: la password è la credenziale di cui tutti parlano, e non è quella che conta.

Dopo l'autenticazione, quello che tiene aperto l'accesso è un token di sessione. Nel mio caso valido 48 ore. È una stringa, sta nel browser, e da lì è portabile: qualsiasi client che la presenti è "me", per due giorni, senza mai ripassare dal login.

Questo è il motivo per cui cambiare la password è una reazione istintiva e spesso inutile.

Un cambio password che non invalida le sessioni attive non chiude niente. Chiude la porta di ingresso mentre le persone già dentro restano dentro, e restano dentro per tutta la durata del token.

Non so quale delle due cose sia successa lì. Ed è già di per sé il problema: dal mio profilo non c'era modo di saperlo. Nessuna lista delle sessioni attive, nessun "disconnetti da tutti i dispositivi", nessun log degli accessi. Ho cambiato una stringa e ho sperato.

Un sistema che non ti fa vedere le tue sessioni ti sta chiedendo di fidarti di una cosa che non puoi verificare.

2FA non è "un passaggio in più"

Qui va detta una cosa onesta, perché il discorso "metti la 2FA e sei a posto" è sbagliato quanto non metterla.

La 2FA non avrebbe fermato il mio agente. Il codice glielo avrei dato io.

Quello che fa è un'altra cosa, e più importante: cambia la natura della credenziale.

  • Una password è una stringa portatore. La scrivi una volta, vale finché non la cambi, e chiunque la possieda è te.
  • Un secondo fattore è un atto, legato a un dispositivo, valido per un tentativo solo. Non lo puoi consegnare una volta e dimenticartene.

La differenza pratica: con la sola password, chi ottiene quelle due stringhe ottiene la stessa velocità che ho avuto io. Con un secondo fattore, non gli bastano — gli serve anche un dispositivo che non hanno.

E in più c'è un punto di decisione umano per sessione. Uno solo, ma c'è. Un agente che apre una sessione nuova deve chiedere. Quel "deve chiedere" è l'unico posto in cui una persona può accorgersi che sta succedendo qualcosa che non aveva chiesto.

La 2FA non è attrito. È il punto in cui il sistema smette di dare per scontato chi sta dall'altra parte.

L'agente non è l'attaccante: è il carico che il sistema prenderà comunque

La tentazione, leggendo una cosa così, è archiviarla come caso limite. "Sì, ma tu hai usato uno strumento strano."

No. Io sono stato il caso migliore.

Ero il titolare dell'account. Avevo diritto a quei file. Non ho aggirato nulla, ho solo percorso più in fretta una strada aperta.

Chiunque rubi quella stessa coppia mail-password ottiene esattamente le stesse prestazioni, e le usa su documenti che non sono suoi. Nel 2026 automatizzare un percorso autenticato non richiede più competenze specialistiche: è un lavoro di venti minuti, e il costo di provarci è sceso a zero.

Il mio agente è stato un test di carico sul modello di autenticazione. Non l'ha rotto: ha misurato quanto valeva davvero. La risposta è che valeva la lentezza dell'utente medio, e quella lentezza non esiste più.

Cosa avrebbe fermato la mia sessione

Niente di esotico. Tutta roba standard, che costa poche giornate di lavoro:

  • Un secondo fattore, anche solo TOTP. Non serve il passkey, serve che la password da sola non basti.
  • Invalidazione di tutte le sessioni al cambio credenziali. Altrimenti il cambio password è un gesto simbolico.
  • Lista delle sessioni attive nel profilo, con revoca. Dispositivo, IP, ultimo accesso. È anche l'unico modo perché l'utente possa accorgersi da solo.
  • Rate limit sul download, non sul login. Quasi tutti mettono il limite sull'endpoint di autenticazione e lasciano libero tutto quello che c'è dopo. L'abuso è dopo.
  • Una soglia di anomalia sul volume. 800 file in 30 minuti da un account che ne scaricava 5 al giorno è un evento che un if intercetta.

Nessuno di questi punti richiede una riprogettazione. Sono controlli che si aggiungono a un sistema esistente senza toccarne l'architettura.

Il trade-off, detto onesto

La 2FA ha un costo reale, e chi la vende come gratis mente.

Il costo non è il login. Sono trenta secondi la prima volta e zero le successive. Il costo è il recovery: l'utente che cambia telefono, perde il seed, non ha più accesso e apre un ticket. Quel flusso va progettato, presidiato da qualcuno e reso a prova di ingegneria sociale, altrimenti hai spostato la vulnerabilità dal login all'assistenza clienti.

Su un prodotto con un funnel di acquisizione fragile, un secondo fattore obbligatorio al primo accesso costa conversioni. È un fatto, non un'opinione.

La via di mezzo che ha senso è lo step-up: login normale con la password, secondo fattore richiesto solo sulle operazioni che contano — export massivo, cambio email, accesso ai documenti in blocco. L'attrito lo paghi dove il rischio è concentrato, non su ogni apertura dell'app.

E se il tuo prodotto è una piattaforma il cui valore sono i documenti che custodisce, quel trade-off non esiste. Lì il documento è l'asset. Proteggerlo con una sola stringa è una scelta di prodotto, non una dimenticanza tecnica.

Quello che ho cambiato sui miei sistemi

Questo pezzo non l'ho scritto per giudicare una piattaforma. L'ho scritto perché ho guardato i miei sistemi con lo stesso metro e non tutti hanno superato l'esame.

Quattro regole che ora do per default:

  • Il client è un agente, finché non dimostra il contrario. Non progetto più assumendo un umano che clicca. Assumo un processo che itera.
  • Ogni endpoint che restituisce una lista è un endpoint di massa. Se torna una pagina di risultati, tornerà tutte le pagine. Il limite va lì, non sulla singola richiesta.
  • La sessione è un oggetto con un ciclo di vita. Si crea, si elenca, si revoca, scade. Non è un effetto collaterale del login che nessuno guarda più.
  • L'attrito umano non è un controllo di sicurezza. Se una difesa regge solo perché "nessuno si metterebbe a farlo a mano", non è una difesa. È una scommessa sul costo del lavoro altrui, e quel costo è appena crollato.

La quarta è quella che mi è costata di più da accettare, perché ci si appoggia senza saperlo. Sta in ogni sistema in cui la protezione non è scritta da nessuna parte: sta nella noia di chi dovrebbe attaccarlo.

Il principio

Gli agenti non hanno introdotto vulnerabilità nuove. Hanno tolto lo sconto sulla fatica.

Ogni difesa che reggeva perché costava tempo a una persona, oggi non regge più. E scoprirlo da un log di 800 download è meglio che scoprirlo da una notifica di data breach.

Progetta per un client che non si stanca. È già dall'altra parte della tua API.