Azioni critiche: perché alcune operazioni richiedono di nuovo entrambi i dispositivi

Hai fatto l'accesso. Hai un ruolo di admin. Clicchi su «rimuovi membro» — e SSP ti chiede di firmare con entrambi i dispositivi, esattamente come se stessi entrando da zero.

Non è attrito fine a sé stesso. È una linea tracciata di proposito tra le operazioni che un token di sessione dovrebbe poter autorizzare e quelle che non dovrebbe, e il ragionamento dietro quella linea vale la pena capirlo, che tu usi SSP o no.

Le sessioni servono alla comodità, non alle conseguenze

Un token di sessione è una credenziale al portatore. Chiunque lo detenga sei tu, per quanto ne sa il server. È esattamente ciò che rende comode le sessioni — ti autentichi una volta e poi agisci liberamente — ed esattamente ciò che le rende una base scadente per decisioni irreversibili.

Le sessioni vengono rubate. Per un bug di cross-site scripting, un portatile non bloccato, del malware, un backup trapelato, o semplicemente un browser lasciato aperto in un ufficio condiviso. La guida alla gestione delle sessioni di OWASP tratta il furto di sessione come una condizione attesa e non come un caso limite, e qualunque progetto che presuma il contrario è ottimista.

Per la maggior parte delle azioni questo è un rischio accettabile, perché la maggior parte delle azioni è reversibile. Rinominare un vault, aggiungere un viewer, modificare un'impostazione di notifica: se un aggressore con una sessione rubata fa questo, tu lo disfi.

Alcune azioni non sono così. Trasferire la proprietà di un'organizzazione consegna il controllo a qualcun altro. Rimuovere un membro gli taglia l'accesso. Eliminare un'organizzazione è definitivo. Per queste, SSP pretende la prova che chi agisce detiene ancora entrambi i dispositivi proprio adesso, non che li deteneva in qualche momento della giornata.

Le tredici azioni

Tredici operazioni richiedono di firmare di nuovo. Si dividono in quattro gruppi.

Controllo dell'organizzazione

• Trasferire la proprietà
• Eliminare l'organizzazione

Appartenenza e ruoli

• Rimuovere un membro
• Promuovere un membro ad admin
• Retrocedere un admin

Identità dell'account

• Cambiare l'e-mail aziendale
• Rimuovere l'e-mail aziendale

Ciclo di vita e amministrazione dei vault

• Archiviare un vault e ripristinarlo dall'archivio
• Congelare un vault e scongelarlo
• Promuovere un admin di vault e retrocederlo

Ciò che le unisce non è che muovano denaro — nessuna lo fa, e nessuna lo può, perché solo i firmatari possono muovere fondi. Ciò che le unisce è che cambiano chi potrà fare cose in seguito. Sono le operazioni che un aggressore vorrebbe per consolidare l'accesso, chiudere fuori i veri proprietari o preparare in silenzio un furto successivo.

Da notare: le azioni legate all'e-mail sono nell'elenco. Cambiare l'e-mail aziendale di un account sembra amministrativo, ma è la classica mossa d'apertura in un dirottamento di account: reindirizzare il canale di recupero e poi lavorare con calma. Richiedere entrambi i dispositivi per farlo chiude quella strada.

Perché la sfida la scrive il server

Il meccanismo conta quanto il requisito, e una decisione di progetto fa quasi tutto il lavoro.

Il server genera il messaggio che firmi. Il client mai.

Se il client componesse la propria sfida, un client compromesso potrebbe comporne una comoda: un messaggio che descrive un'azione innocua, firmato da un utente convinto di fare qualcosa di innocuo, e poi riprodotto contro un endpoint pericoloso. Che sia il server a redigere il messaggio significa che ciò che firmi è ciò che verrà eseguito, perché il server verifica la firma contro il messaggio che ha emesso e nessun altro.

È lo stesso schema che SSP usa per l'accesso, e lo stesso schema che rende sicura in generale l'autenticazione basata su firme: non firmare mai qualcosa che non hai ricevuto dalla parte che lo verificherà.

A che cosa è legata la sfida

Il messaggio non è un «sì» generico. È una stringa specifica che contiene quattro cose che, insieme, rendono inutile altrove una firma intercettata.

L'azione esatta. remove_member e transfer_ownership producono messaggi diversi. Una firma per una non può autorizzare l'altra.

Il bersaglio esatto. L'organizzazione, il vault dove pertinente e la persona coinvolta sono nominati nel messaggio. Le azioni con ambito di vault includono esplicitamente l'ID del vault, così che una firma per congelare un vault non possa essere riprodotta per congelarne un altro.

Una marca temporale. Occupa i primi tredici caratteri del messaggio — una posizione fissa, perché SSP Wallet valida quel formato prima di mostrare qualsiasi cosa. Le sfide scadono dopo quindici minuti.

Un nonce casuale. Dodici byte di casualità crittografica, che rendono unica ogni sfida anche per un'azione identica contro un bersaglio identico nello stesso secondo.

E la sfida è monouso. Quando viene riscattata, il server la contrassegna come usata nella stessa operazione atomica che la valida, così una firma riprodotta viene rifiutata con «già usata» invece di riuscire in silenzio due volte. Le sfide scadute vengono ripulite automaticamente da un indice TTL.

Ogni tentativo viene registrato, compresi i fallimenti

Le azioni critiche vengono scritte in un registro permanente, e qui c'è un dettaglio facile da saltare: la voce di registro viene scritta quando la sfida viene richiesta, non soltanto quando l'azione si completa.

Ciò significa che il registro include tentativi abbandonati, tentativi in cui la firma è fallita e tentativi rifiutati. Una singola azione critica fallita di solito è qualcuno che ha cambiato idea. Un grappolo di esse alle 3 di notte è una storia.

Come il resto della traccia di audit di SSP, questi record non hanno scadenza né processo di pulizia. Il valore di un registro di audit vive interamente nelle parti di cui nessuno aveva previsto il bisogno.

Che aspetto ha nella pratica

Abbi entrambi i dispositivi con te prima di iniziare. Le azioni critiche non si completano con un solo dispositivo, e la sfida scade in quindici minuti. Se il telefono è in un'altra stanza, vallo a prendere prima.

Leggi l'azione sul telefono, non solo sulla dashboard. Il messaggio che i tuoi dispositivi mostrano nomina l'azione e il bersaglio. È la tua occasione per accorgerti che il bersaglio non è quello che ti aspettavi — la stessa abitudine che ti protegge quando controlli una transazione. Attacchi di phishing contro gli utenti cripto spiega perché quella seconda occhiata sul secondo dispositivo vale i secondi che costa.

Non raggrupparle. Ogni azione critica riceve la propria sfida e la propria firma. Se stai rimuovendo tre dipendenti in uscita, sono tre firme. È deliberato: raggruppare significherebbe una firma che autorizza più modifiche, che è esattamente la proprietà che vogliamo evitare.

Aspettatele nei momenti peggiori. Le azioni critiche si addensano proprio quando qualcuno se ne va, un account è compromesso o un vault va congelato: cioè nei momenti in cui le persone sono sotto stress e vogliono muoversi in fretta. Sapere in anticipo che queste richiedono entrambi i dispositivi trasforma una sorpresa in un passaggio.

Il quadro più ampio di che cosa impone che cosa — e perché la firma ripetuta sta nel livello intermedio e non in quello più forte — è in che cosa ferma davvero una transazione. Per come si incastrano l'organizzazione e i suoi vault, parti da SSP Enterprise: vault multisig per i team.