Cybersicurezza del trader: 2FA, phishing, prelievi e protezione dei dispositivi
La sicurezza di un conto di trading inizia dall'account email, da una password unica e da un metodo di autenticazione adeguato. Contano anche dispositivi, sessioni di accesso, regole sui prelievi e procedure di recupero in caso di perdita del telefono. Questo articolo illustra passo dopo passo tali misure, ne spiega i limiti e mostra come rispondere se sospetti una compromissione del conto. Gli utenti di VPS e robot di trading trovano anche indicazioni per proteggere accesso remoto, chiavi API e posizioni aperte. Trattiamo separatamente le truffe che si spacciano per imprese nel nostro articolo sui falsi broker.
- L'email è il livello 1, non un extra opzionale. La compromissione dell'email può consentire di reimpostare la password del broker e intercettare le conferme delle modifiche, a seconda dei controlli di recupero del broker. Imposta una password unica per l'email e attiva l'MFA prima di configurare altri livelli.
- Una sola password riutilizzata può bastare per compromettere un conto, soprattutto in assenza di MFA efficace. Il credential stuffing, la verifica automatizzata di coppie nome utente/password provenienti da altre violazioni, prende di mira qualsiasi password riutilizzata che sia stata esposta. Una password unica più 2FA, preferibilmente TOTP anziché SMS, è il minimo operativo.
- SMS 2FA è meglio di nessuna 2FA, ma inferiore a TOTP o chiave hardware. Il SIM swapping può essere rapido ed economico; tempi, costi e tasso di successo dipendono dall'operatore mobile e dal paese. TOTP in un'app senza backup cloud dei seed, oppure una chiave di sicurezza hardware come YubiKey, costituisce uno standard pratico.
- Il phishing FX può essere mirato. Le email false di un «broker», le chiamate di un «reparto sicurezza» e i link a pagine di accesso contraffatte di MT4 possono essere mirati ai trader, anziché inviati del tutto a caso.
- Attiva la lista dei destinatari di prelievo autorizzati dopo aver protetto l'email. Se il broker offre una lista di conti bancari autorizzati, attivala: un attaccante deve allora modificare i dati e superare un'ulteriore verifica. Questa però usa spesso l'email, quindi offre una protezione limitata se il livello 1 è compromesso.
- Un dispositivo per tutto amplia la superficie d'attacco. Un dispositivo o profilo utente separato per il trading è una questione di disciplina operativa, non una precauzione eccessiva.
1. Password riutilizzate: una violazione minaccia il conto
Partiamo da uno scenario molto ordinario, pericoloso proprio per la sua normalità. Non coinvolge hacker incappucciati né la violazione della cifratura. È il credential stuffing: la verifica automatizzata su più servizi di coppie nome utente/password ottenute da violazioni di database[1].
Il meccanismo è semplice. Il 22 gennaio 2024, il gruppo di ricerca di Cybernews ha descritto una raccolta pubblicamente accessibile con oltre 26 miliardi di record e 12 terabyte di dati, soprannominata «Mother of All Breaches»[5]. È necessario precisarne la natura e lo stato, perché cambiano il significato di quella cifra: non si trattava di una singola nuova violazione, ma di una raccolta di record da migliaia di violazioni precedenti e database scambiati privatamente. Il rapporto stesso considera altamente probabili i duplicati e tratta la presenza di informazioni prima inedite come una probabilità, non come un risultato accertato. Anche il resoconto dell'esposizione successiva è una dichiarazione di un'organizzazione, non una conclusione accertata in modo indipendente: il servizio di ricerca delle violazioni Leak-Lookup ha rivendicato la proprietà della raccolta, attribuendo l'esposizione a una configurazione errata del firewall che aveva corretto[5]. Non abbiamo conferme indipendenti che le copie abbiano smesso di circolare. Per un trader, la conclusione pratica non dipende da questa incertezza: se riutilizzi la stessa password su un forum di trading, Gmail e il conto del broker, una di quelle migliaia di raccolte potrebbe fornire all'attaccante le credenziali per tutti e tre.
La possibile catena di attacco è: email compromessa → ripristino della password del broker → modifica dei contatti → richiesta di prelievo sul conto dell'attaccante. L'intervallo fra compromissione dell'email e richiesta può essere breve, ma non indichiamo una durata specifica: dipende dalle procedure del broker per modificare i dati e dal canale di pagamento, e non abbiamo trovato misurazioni a sostegno di una cifra precisa. Il broker invia la conferma del prelievo via email, ma quell'account è già controllato dall'attaccante.
Modello a livelli: identificare cosa si protegge
Prima di configurare, definire un modello di minaccia: cosa proteggi, da chi e cosa accade se un determinato livello fallisce. Senza questo modello, potresti comprare una chiave hardware per un conto il cui recupero della password dipende ancora da un vecchio account Gmail.
Per un conto di trading, la catena delle dipendenze ha sette anelli. Esaminali in quest'ordine:
- Email — l'account a monte. Comprometterlo mette a rischio il recupero degli altri conti.
- Identità — il tuo numero di telefono, i codici di recupero e i documenti che attestano la tua identità presso il broker.
- Dispositivo — il computer e il telefono sui quali inserisci segreti e ricevi codici.
- Broker — password, MFA, sessioni attive e impostazioni del portale clienti.
- API — chiavi programmatiche che possono autenticare indipendentemente da password e MFA del portale.
- Pagamenti — i metodi di deposito e prelievo e le liste dei conti destinatari autorizzati.
- Recupero — i canali per ripristinare l'accesso, spesso la via alternativa preferita di un attaccante.
Regola pratica: un livello dipende da quello che lo sostiene. Non si può fare affidamento sulla lista dei destinatari autorizzati se l'attaccante controlla l'email che riceve le conferme delle modifiche dei destinatari. Per questo l'articolo segue un ordine preciso: le sezioni 1 e 2 trattano email, identità e broker; le sezioni 5 e 6 dispositivi e API; la sezione 4 i pagamenti. Il recupero ricorre in tutto il testo perché offre una via alternativa verso gli altri livelli.
Azioni pratiche
Usare password unica per il broker. Non riutilizzarla altrove. Usa un gestore di password come Bitwarden, 1Password o KeePass. Genera una password casuale di almeno 16 caratteri, con un margine rispetto alla soglia di 15 caratteri delle attuali indicazioni NIST per le password usate come unico fattore di autenticazione[2]. Evita di inventare le password: le persone non sono brave a generare casualità.
Usare email separata per trading. Crea un account esclusivamente per comunicare con broker e piattaforme di trading. Non usarlo per registrarti a forum, social media o altri servizi. Se il tuo indirizzo principale viene esposto, quello associato al conto di trading non lo sarà attraverso gli stessi dati di registrazione. Ciò riduce il rischio, pur non proteggendo da solo il conto.
Verificare dati esposti. Inserisci il tuo indirizzo email su haveibeenpwned.com ed esamina quali dati siano stati divulgati. Cambia subito una password se è trapelata, è stata riutilizzata o esistono motivi per sospettarne la compromissione. La presenza dell'email nella violazione di un altro servizio non dimostra di per sé che una password diversa e unica del broker sia stata compromessa.
2. 2FA: minimo, non opzione
L'autenticazione a due fattori (2FA) aggiunge un secondo livello dopo la password. Una 2FA correttamente implementata rende più difficile accedere con una password rubata, ma il phishing può intercettare i codici, mentre il recupero del conto o il furto di sessione possono aggirare la normale schermata di accesso. La difficoltà è che i metodi 2FA non sono equivalenti. SMS e TOTP hanno debolezze sostanzialmente diverse, come tipi diversi di serratura offrono protezioni differenti.
| Metodo 2FA | Come funziona | Sicurezza | Debolezza principale |
|---|---|---|---|
| SMS | Codice monouso al telefono | Bassa | SIM swapping: controlla il numero tramite operatore |
| Codice all'email | La più bassa | Se compromettono email, 2FA email non è indipendente | |
| TOTP (app autenticatrice) | Codice generato localmente ogni 30 secondi (Google Authenticator, Authy); preferisci una configurazione senza backup cloud dei seed | Alta | Una pagina di phishing può intercettare un codice monouso; separatamente, perdere il telefono senza codici di recupero può impedirti l'accesso |
| Chiave di sicurezza hardware | Dispositivo USB fisico (YubiKey, Titan Key) | La più alta | Esempio polacco: centinaia di PLN secondo modello e rivenditore; supporto limitato |
Perché SMS 2FA non basta
La 2FA via SMS è meglio dell'assenza di 2FA, ma più debole di TOTP o di una chiave di sicurezza hardware. Nel SIM swap, un truffatore contatta l'operatore mobile, si spaccia per il titolare del numero e chiede di trasferirlo su una SIM sostitutiva. Questi attacchi possono essere rapidi ed economici, ma tempi, costi e tasso di successo dipendono da operatore, paese e qualità delle informazioni sulla vittima. Ogni operatore stabilisce proprie verifiche per emettere una SIM sostitutiva e le informazioni usate possono essere disponibili in fughe di dati. La scala è documentata negli Stati Uniti: la FCC riporta presso il suo Consumer Complaint Center circa 300 reclami per SIM swap e portabilità nel 2020, 400 nel 2021 e 500 nel 2022[4].
TOTP: standard pratico
TOTP (Time-based One-Time Password) genera codici localmente sul dispositivo ogni 30 secondi. Non usa la rete mobile, quindi il SIM swapping non intercetta il codice e per generarlo non serve internet. L'ordine di preferenza del NCSC britannico colloca i codici generati dalle app molto al di sopra di quelli inviati nei messaggi[7], ma non al primo posto. La sezione passkey spiega cosa supera.
Per configurare TOTP, scarica un'app autenticatrice e scegli l'uso senza account o disattiva la sincronizzazione cloud. Google Authenticator sincronizza i codici con un account Google se effettui l'accesso e offre anche l'uso senza account; Authy propone il backup cloud. È comodo, ma il confermato incidente LastPass del dicembre 2022, descritto sotto, illustra il punto di vulnerabilità aggiunto dall'archiviazione nel cloud di materiale di autenticazione. Preferisci generatori offline con una copia fisica dei codici di recupero. Nelle impostazioni del conto del broker, cerca «Sicurezza» → «Autenticazione a due fattori» e scansiona il QR con l'app. L'accesso richiederà la password e il codice di 6 cifre dell'app.
Cruciale: salvare i codici di recupero. Se il broker emette codici di riserva monouso per la perdita del telefono, salvali durante la configurazione. In caso contrario, verifica la procedura ufficiale documentata di recupero e annotala prima di averne bisogno. Stampa i codici e conservali al sicuro, separati da telefono, account cloud e gestore di password: perdere l'accesso al gestore non deve significare perdere anche i codici. Un foglio in cassaforte o in un cassetto chiuso a chiave è un'opzione.
Passkey e FIDO2: la direzione
La chiave è implementazione fisica del più ampio standard FIDO2/WebAuthn. Al posto di un codice che si può dettare a qualcuno o copiare in una pagina falsa, browser e autenticatore scambiano una firma crittografica legata al dominio corretto. Un dominio diverso non può ottenere l'autenticazione per la credenziale registrata. Questo legame al dominio è la distinzione essenziale rispetto a TOTP.
Una passkey usa questo meccanismo con una credenziale FIDO2 archiviata su telefono, computer o gestore di password e sbloccata tramite impronta o PIN del dispositivo, perciò una chiave separata può essere superflua. Il NCSC colloca le credenziali FIDO2 al primo posto per resistenza a tentativi di indovinare, phishing e furto di segreti di autenticazione. I codici generati dalle app sono terzi e il documento ne indica esplicitamente la suscettibilità all'intercettazione[7]. Il NIST consente autenticatori crittografici multifattore ai livelli di garanzia più elevati quando sono soddisfatti i requisiti del livello specifico; una passkey sincronizzata non diventa automaticamente una credenziale AAL3. L'autenticazione tramite rete telefonica, inclusi gli SMS, ha lo status di limitata[2].
Cosa fare oggi. Il supporto alle passkey varia fra i broker al dettaglio: alcuni portali offrono solo TOTP e SMS. Cerca «chiave di sicurezza», «passkey» o «WebAuthn» nelle impostazioni di sicurezza. Se supportato, attivalo come metodo principale e conserva TOTP come riserva. Se non disponibile, TOTP con codici di recupero offline resta un minimo ragionevole. Attiva una passkey sull'email indipendentemente dal broker, perché l'email è il livello 1 del modello sopra.
3. Phishing: email, telefono e ingegneria sociale FX
Il phishing nel forex può essere mirato: gli attaccanti sanno che i trader detengono fondi sui conti e reagiscono a «margin call» e «avviso di sicurezza». Può anche trattarsi di comune spam con il logo di un broker e un dominio registrato a basso costo. Un attacco non deve essere sofisticato per funzionare.
Email false del «broker»
È un vettore di attacco economico e quindi comune. Un'email imita colori, logo e piè di pagina del broker. L'oggetto può essere «Urgente: verifica il tuo conto», «Avviso di sicurezza: rilevato accesso insolito» o «Azione richiesta: aggiorna il metodo di pagamento». Il link apre un'imitazione della pagina di accesso del broker su un altro dominio. Inserire le credenziali le consegna all'attaccante. La guida organizzativa del NCSC tratta due elementi: la falsificazione del mittente, contrastata da DMARC, SPF e DKIM, e la necessità di un percorso semplice e rapido per segnalare messaggi sospetti[6]. Non tratta domini simili; la spiegazione seguente è nostra, non attribuita a NCSC.
Chiamate della «sicurezza»
Un metodo più articolato è il vishing, o phishing vocale. Qualcuno chiama fingendo di lavorare per la sicurezza del broker, segnala attività sospette sul conto e chiede una verifica dell'identità: «Mi dia il numero del conto e il codice 2FA appena inviato». Fornire quel codice potrebbe autorizzare l'accesso dell'attaccante.
Un broker corretto non dovrebbe chiedere 2FA d'accesso al telefono. Chi lo richiede potrebbe compromettere il conto anziché proteggerlo. Riaggancia e chiama il numero ufficiale sul sito del broker, non quello nell'email. La pressione ad agire in fretta può essere più efficace del malware.
Download MT4/MT5 falsi
I trader cercano su Google «MT4 download» o «MT5 download». Gli attaccanti possono comprare annunci che portano a installer modificati: sembrano familiari e possono funzionare normalmente mentre inviano credenziali a un server controllato dall'attaccante. Una falsa pagina di download distribuisce malware efficacemente perché l'utente esegue l'installer e gli concede permessi.
Ingegneria sociale nei gruppi
I gruppi di trading su Telegram, Discord e Facebook offrono occasioni di ingegneria sociale. Un presunto amministratore invia un messaggio privato: «Ho un'offerta speciale del broker X, ma devi registrarti dal mio link». Oppure: «Pubblica una schermata del conto e ti aiuterò a configurare il tuo EA». Una schermata del conto può rivelarne il numero presso il broker, aiutando un attaccante a manipolare verifiche telefoniche dell'identità deboli. Comprendi questa esposizione prima di pubblicare il tuo «profitto del giorno» in un gruppo.
4. Prelievi sicuri: metodi, liste e documenti KYC
Un attaccante che prende il controllo del conto può chiudere posizioni e danneggiarne il capitale, ma dirottare fondi diventa più difficile con una lista efficace di destinatari autorizzati. Il controllo mira a inviare i fondi a un conto già approvato e intestato a te. Configurare i prelievi è una questione di sicurezza oltre che di comodità.
Lista di conti autorizzati
Se il broker offre «Destinatari di prelievo approvati» o una «Lista dei destinatari autorizzati», verifica le regole precise. Attivarla limita i prelievi a conti bancari già approvati. Aggiungere un conto può richiedere ulteriori verifiche e un'attesa; il broker decide disponibilità e durata dei controlli. Ciò ostacola il dirottamento, ma non garantisce il blocco di un prelievo dopo la compromissione del conto.
Verifica se il broker supporta la lista dei destinatari autorizzati e attivala se disponibile. Cerca «Lista dei destinatari di prelievo», «Destinatari approvati» o «Conti fidati» nel portale clienti. Verifica contratto e impostazioni di sicurezza: la disponibilità cambia nel tempo e può differire fra entità dello stesso gruppo. Considera l'assenza uno svantaggio nel confronto dei controlli, non una prova conclusiva di disonestà.
Notifiche di prelievo
Attiva email e notifiche push per ogni richiesta di prelievo. Se ne vedi una che non hai presentato, chiama subito il broker: l'email potrebbe essere già compromessa. Fra richiesta ed esecuzione da parte di broker e banca c'è solitamente un tempo di elaborazione, stabilito però dalle condizioni dell'entità specifica. Verificalo prima, non durante l'incidente. Questa finestra offre spesso la migliore opportunità di fermare il trasferimento, ma non è l'unico intervento possibile: dopo l'invio, banca o prestatore di pagamento possono avviare un richiamo, come spiegato sotto.
Modifiche dei dati: punto critico
L'evento critico è spesso la modifica di email, telefono, conto bancario o beneficiario del prelievo, più che l'accesso stesso. Cambiare metodo ogni settimana può attivare controlli manuali di conformità e, talvolta, una restrizione temporanea proprio quando vuoi prelevare i profitti. Scegli un metodo adatto, verificalo e usalo con continuità.
Documenti KYC: possono aprire un altro conto
Per aprire un conto, invii al broker una scansione della carta d'identità o del passaporto, una prova dell'indirizzo e talvolta un estratto conto bancario. Insieme, questi documenti possono facilitare l'apertura o il recupero di un altro conto. Trattali come informazioni sensibili sull'identità, non come un normale allegato.
In pratica, caricare documenti nel portale, anziché via email o app di messaggistica. Se un'email li richiede, chiama il numero sul sito verificato per confermare la richiesta. Non lasciare copie in download o galleria; se conservate, usare contenitore cifrato o gestore con allegati. Rimuovere copie di lavoro dopo la verifica, anche da messaggi inviati e chat. Un documento trapelato può sostenere un tentativo di recupero con «ho dimenticato la password e perso la 2FA». Se disponibile, imposta prima una password per i contatti telefonici. Domande come il cognome da nubile della madre o la prima scuola sono un tema separato: le risposte si possono ricostruire da fughe di dati e social media. Se il broker le usa, considerale un controllo di supporto insieme a MFA robusta e recupero verificato, non un sostituto.
5. Dispositivi: VPN, Wi-Fi pubblico, aggiornamenti e separazione
Computer e telefono sono porte d'accesso al conto di trading. Se un dispositivo è compromesso, password, 2FA e lista autorizzata insieme potrebbero comunque non bastare: l'attaccante potrebbe osservare ciò che fai sullo schermo.
Wi-Fi pubblico: cosa risolve VPN e cosa no
Distingui le misure essenziali dai controlli aggiuntivi, perché sul Wi-Fi pubblico circolano molte esagerazioni. Le basi sono HTTPS correttamente verificato, indirizzo del portale inserito manualmente sul dominio giusto, nessuna elusione degli avvisi sui certificati, dispositivo aggiornato e MFA resistente al phishing. L'autorità statunitense per i consumatori afferma esplicitamente che la diffusione della cifratura rende solitamente sicura la connessione su Wi-Fi pubblico[13]. Osserva anche che i truffatori possono ottenere certificati per i propri siti, quindi la cifratura da sola non identifica chi riceve le tue informazioni.
Il Wi-Fi pubblico presenta ancora rischi di hotspot falsi, reindirizzamenti verso pagine di accesso contraffatte e phishing. Una VPN o un hotspot proprio è un livello aggiuntivo, non un requisito per la sicurezza. Può ridurre l'esposizione del traffico di supporto e la dipendenza da una rete sconosciuta, ma non riparare un dispositivo infetto né impedirti di inserire una password su un dominio falso.
Se scegli una VPN, seleziona un fornitore con una chiara politica dei log e verifica come si finanzia. Con un servizio gratuito conta più del solo prezzo: alcuni piani sono finanziati dagli abbonamenti a pagamento, altri monetizzano traffico e dati degli utenti. Valuta modello di attività, politica dei log e audit indipendente del fornitore specifico, senza presumere che pagare ne dimostri l'affidabilità. Il tethering LTE/5G dal tuo telefono è spesso più semplice e non aggiunge un altro fornitore di cui fidarsi.
I livelli di sicurezza, come una VPN o le scansioni su un VPS, possono incidere sulla latenza di rete o sul carico del dispositivo. Misura l'effetto nella tua configurazione. L'articolo sull'infrastruttura di esecuzione spiega quando conta, per esempio nel trading sulle notizie o nello scalping e quando no.
Sessioni attive: verifica e revoca
L'accesso crea una sessione che può restare attiva nel browser, nell'app mobile o nel terminale. Un malware che ruba cookie di sessione potrebbe non aver bisogno di password né codice 2FA: una sessione valida può bastare. Cambiare la password dopo un incidente senza revocare le sessioni può quindi lasciare l'attaccante connesso.
Cerca «Sessioni attive», «Dispositivi», «Dispositivi connessi» o «Attività di sicurezza» nel portale. Controlla periodicamente la lista e disconnetti ciò che non riconosci: un altro computer, un vecchio telefono o un luogo sconosciuto. Se esiste «Esci da tutti i dispositivi», impara a trovarlo prima di un incidente. Esegui la stessa verifica sull'email collegata al broker, il livello 1 del modello sopra.
Separazione dei dispositivi
Si gestisce capitale: mantenere pulito l'ambiente. Un dispositivo dedicato è un laptop o tablet su cui eviti navigazione estranea al trading, allegati e software non verificato. Gli strumenti necessari sono piattaforma, browser per il portale clienti del broker e gestore di password.
Nell'esempio di budget polacco, un ThinkPad ricondizionato da circa mille PLN può essere un'opzione per proteggere il conto. Se un dispositivo separato è impraticabile, un profilo utente distinto del sistema operativo aiuta l'organizzazione e riduce parte dell'esposizione, ma non sostituisce un altro dispositivo contro minacce malware più gravi.
Aggiornamenti: normali ma critici
Windows, macOS, Android, iOS, MT5 e cTrader ricevono aggiornamenti, incluse correzioni di sicurezza; MT4 è trattato separatamente sotto. Un'installazione obsoleta può contenere vulnerabilità note sfruttabili dagli attaccanti. Attiva gli aggiornamenti automatici anziché rinviarli indefinitamente.
MetaTrader 4 riceve ancora aggiornamenti del produttore. Non attribuiamo a MetaQuotes una fine formale dello sviluppo di MT4, non avendo trovato un annuncio del produttore che la stabilisca. Se usi MT4, assicurati di avere l'ultima versione dal broker o dal produttore. Vecchie build da siti estranei possono contenere vulnerabilità note.
6. Sicurezza VPS/EA: operazioni orfane e accesso remoto
Eseguire Expert Advisor (EA) su un VPS introduce una superficie di attacco aggiuntiva. Questo computer remoto opera 24/7, resta connesso al broker e può accedere al conto di trading. Comprometterlo può dare a un attaccante il controllo dell'ambiente di trading.
Configurazione RDP sicura
Remote Desktop Protocol (RDP) è un modo standard per collegarsi a un VPS Windows. Esposto direttamente a internet, RDP è un bersaglio persistente: i bot di scansione tentano attacchi alle password continuamente, 24/7.
Cambiare solo porta protegge poco. Dare priorità a nessun RDP pubblico, accesso via tunnel VPN/WireGuard; una lista IP autorizzata se il fornitore dà indirizzo stabile; autenticazione a livello di rete (NLA); MFA presso fornitore VPS e separatamente sul gateway se usato; e snapshot regolari e registri eventi. Applica il principio del minimo privilegio: installa solo ciò che serve all'ambiente di trading.
Gestire password MT4/MT5 su VPS
MT4 e MT5 offrono «Salva password» all'accesso. Disattivalo se non serve al funzionamento previsto: le credenziali salvate facilitano l'accesso dopo la compromissione dell'host o della sessione. Per un EA 24/7, verifica però come il terminale si riconnette dopo un riavvio. Disattivare il salvataggio senza un piano di riautenticazione può fermare l'automazione.
Ciò è diverso dal salvare la password in un gestore. Un gestore cifra il segreto dietro la propria autenticazione e può far parte di una configurazione EA 24/7 se host e percorso di accesso sono protetti con MFA e lista di IP consentiti. L'ordine è proteggere prima host e accesso, poi decidere come fornire le credenziali. Nessuna misura sostituisce l'altra: limita archiviazione e permessi alle esigenze dell'automazione; inserire manualmente la password non giustifica un RDP pubblico con configurazione predefinita.
Operazioni orfane: senza controllore
Un'operazione orfana è stata aperta da un EA, ma non è più gestita dopo un guasto del VPS, una perdita di connessione o un riavvio. Potrebbe non avere stop-loss, perché l'algoritmo doveva gestire dinamicamente l'uscita, né take profit né qualcuno che la sorvegli. La posizione può restare esposta fino a una richiesta di margine o a un altro intervento.
Tutela: un EA dovrebbe impostare uno stop loss accettato lato server anziché affidarsi solo a uno stop virtuale algoritmico. Se l'EA si ferma, lo SL accettato resta sul server, ma non garantisce né il prezzo di esecuzione né una perdita limitata all'importo previsto. Il compromesso conta: con scarsa liquidità e un ampio spread, come durante il rollover del broker, uno stop può scattare in condizioni peggiori del previsto. Per un rollover alle 17:00 di New York, l'esempio polacco è solitamente alle 23:00, oppure alle 22:00 nei periodi di cambio dell'ora legale non coincidenti. Ciò non prova di per sé che il broker abbia mirato al tuo stop. Uno stop virtuale nasconde il livello fisso nel terminale, ma aggiunge dipendenza dall'infrastruttura. Scegli in base alle condizioni di esecuzione del broker e al metodo di trading.
Non condividere VPS
Condividere un VPS per risparmiare può esporre EA e posizioni aperte a un altro utente con potenziale accesso a terminale, file, registri e segreti. Nell'esempio polacco, risparmiare PLN 50 crea questa esposizione. Mantieni il VPS sotto il controllo di un solo trader, anziché condividere l'ambiente del conto con utenti estranei.
I conti di maggiori dimensioni e il trading algoritmico possono utilizzare API FIX o colocation vicino ai server del broker, trattate in infrastruttura di esecuzione. Vale la stessa distinzione di sicurezza delle altre chiavi API: distinguere le credenziali di sola lettura da quelle autorizzate a inserire ordini.
7. Checklist di 10 minuti e risposta agli incidenti
Oggi puoi accedere alle posizioni aperte e domani perdere l'accesso. Quanto segue è pensato come una verifica di 10 minuti: sufficiente per esaminare l'elenco e individuare le voci che non puoi ancora spuntare.
| # | Voce | Requisito minimo | Stato |
|---|---|---|---|
| 1 | Email protetta indipendentemente | Password email unica, MFA (preferibilmente una passkey), regole di inoltro e filtri controllati: livello 1 della sezione 1 | ☐ |
| 2 | Email separata per il trading | Indirizzo dedicato non utilizzato per registrarsi a servizi estranei | ☐ |
| 3 | Password unica del broker | 16+ caratteri casuali da un gestore di password, mai riutilizzati altrove | ☐ |
| 4 | 2FA attiva (TOTP) | App TOTP senza backup cloud, anziché SMS o email | ☐ |
| 5 | Codici di recupero 2FA offline | Stampati e conservati in un luogo sicuro | ☐ |
| 6 | Destinatari di prelievo autorizzati | Se supportato: solo conti bancari approvati, con regole verificate per modificare il destinatario | ☐ |
| 7 | Notifiche di prelievo | Notifiche email e push per ogni richiesta di prelievo | ☐ |
| 8 | Aggiornamenti di sistema e piattaforma | Aggiornamenti automatici attivati; build aggiornate di MT4/MT5 | ☐ |
| 9 | Reti sconosciute: HTTPS verificato, VPN come livello aggiuntivo | Inserire manualmente l'indirizzo del portale; non ignorare mai gli avvisi sui certificati. Una VPN con politica di registrazione verificata o il tethering del telefono sono misure supplementari | ☐ |
| 10 | Dispositivi o profili separati | Computer o profilo utente per il trading separato dalle attività quotidiane | ☐ |
| 11 | VPS: tunnel VPN, lista di IP consentiti e MFA del fornitore | Nessun RDP pubblico; accesso VPN/WireGuard, lista di IP consentiti, MFA del fornitore e MFA separata del gateway, se utilizzato | ☐ |
| 12 | VPS: segreti controllati e limitati | Archiviazione delle credenziali del terminale limitata alle esigenze dell'automazione; accesso dopo riavvio verificato, gestore di password, host e accesso protetti | ☐ |
| 13 | EA: SL lato server in caso di guasto del VPS | SL accettato dal server del broker, anziché soltanto uno stop virtuale dell'EA | ☐ |
| 14 | Verifica delle sessioni attive | Elenchi dei dispositivi di broker ed email controllati; sessioni sconosciute disconnesse | ☐ |
| 15 | Chiavi API inutilizzate revocate | Chiavi inutilizzate revocate; permessi rimanenti ridotti e restrizioni IP applicate ove supportate | ☐ |
| 16 | Canali di contatto verificati del broker salvati | Numero telefonico ufficiale, portale e indirizzo dell'ufficio conformità annotati fuori dall'account email | ☐ |
| 17 | Nessun accesso remoto per persone non verificate | Niente AnyDesk, TeamViewer o condivisione dello schermo su richiesta di un «consulente», «reparto sicurezza» o «società di recupero» che contatti senza essere stato interpellato | ☐ |
Ho cliccato un link, inserito la password e approvato l'MFA: e adesso?
È uno scenario difficile perché tecnicamente il secondo fattore non ha fallito: lo hai approvato. L'attaccante potrebbe ora disporre di una sessione valida e del permesso di modificare i dati. Conta l'ordine delle azioni, non soltanto la velocità di una singola azione. Usa un altro dispositivo affidabile e interrompi ogni interazione con l'email sospetta.
- Revoca le sessioni oltre a cambiare la password. Disconnetti tutti i dispositivi nel portale del broker, poi cambia la password. Modificarla non termina sempre le sessioni. Se manca un comando per farlo, segnalalo esplicitamente all'assistenza telefonica del broker.
- Proteggi l'email. Cambia la password, termina le sessioni e controlla regole di inoltro e filtri. Una regola che sposta nel cestino i messaggi del broker può nascondere la compromissione.
- Chiama il broker al numero salvato in precedenza, anziché a quello indicato nel messaggio. Chiedi di sospendere i prelievi e di segnalare la sospetta compromissione. Domanda se nelle ultime ore siano stati modificati i contatti o i destinatari dei prelievi.
- Reimposta il secondo fattore. Revoca la credenziale compromessa e configura nuovamente l'MFA. Genera nuovi codici di recupero e invalida quelli precedenti.
- Revoca le chiavi API e verifica se ne siano state create di nuove. Una chiave autorizzata a negoziare può restare valida dopo una modifica della password.
- Verifica i dati di prelievo e la lista dei destinatari autorizzati. Segnala un conto sconosciuto come parte dello stesso incidente, non come una questione amministrativa separata.
- Documenta tutto. Conserva schermate datate, l'email con le intestazioni complete, la cronologia degli accessi e il numero di riferimento dell'assistenza telefonica. Sono utili per un reclamo o una successiva controversia con il broker.
- Controlla il dispositivo. Se sospetti anche malware, per esempio finestre o estensioni sconosciute o rallentamenti inspiegabili, usa un dispositivo pulito fino al completamento delle verifiche, come spiegato nella sezione 5.
- Segnala l'accaduto. Segnala un prelievo non autorizzato alla polizia e all'autorità di vigilanza del broker. Nell'esempio polacco, segnala separatamente l'incidente tecnico, compresi phishing, email o dispositivo compromessi, a CERT Polska tramite incydent.cert.pl[14]. Questo canale tecnico non sostituisce né una denuncia penale né il reclamo al broker e non determina il rimborso. Fuori dalla Polonia, usa il canale nazionale competente per segnalare gli incidenti. L'articolo 13.7 spiega la distinzione tra reclamo e intervento di vigilanza e i percorsi procedurali pertinenti.
Cosa non fare: non installare software per «controllare il computer» inviato da chi ti chiama senza essere stato interpellato, non concedere accesso remoto e non versare altro denaro per «sbloccare un prelievo». Ogni richiesta segnala una possibile seconda fase dello stesso attacco.
Questa checklist non protegge dalle perdite di mercato. Mira a ridurre il rischio di perdere il controllo del conto per ragioni estranee al mercato, molte delle quali possono essere affrontate con una configurazione attenta.
FAQ: cybersicurezza del trader forex
La 2FA via SMS basta a proteggere un conto di trading?
Cosa fare se perdo il telefono con l'app 2FA?
Dovrei usare una VPN per il trading?
Come proteggere MT4/MT5 sul telefono?
Cosa fare se sospetto un accesso non autorizzato al conto?
Un EA può rubare le mie credenziali?
Fonti
- OWASP Foundation, «Credential Stuffing Prevention Cheat Sheet», cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html: definisce la verifica di coppie nome utente/password provenienti dalla violazione di un altro servizio e descrive controlli lato servizio, tra cui MFA, restrizioni IP e rilevamento di dispositivi o indirizzi sconosciuti. Non misura la quota di compromissioni di conti di trading attribuibile a questo vettore; qui non le viene attribuita alcuna statistica simile. Consultato il 31 agosto 2026.
- National Institute of Standards and Technology (NIST), «Digital Identity Guidelines — SP 800-63B-4», pages.nist.gov/800-63-4/sp800-63b/authenticators/: sezione 3.1.1.2: almeno 15 caratteri quando la password è l'unico fattore, oppure 8 nell'MFA; sezione 3.1.3.3: l'autenticazione tramite rete telefonica pubblica, inclusi gli SMS, è limitata, con obbligo di offrire un'alternativa; la sezione 3.1.7 riguarda gli autenticatori crittografici multifattore. L'edizione SP 800-63B del 2 marzo 2020 precedentemente citata qui è stata sostituita da SP 800-63B-4, finalizzata il 31 luglio 2025, di cui sopra si applica la numerazione delle sezioni. Non abbreviare l'identificatore in «SP 800-63-4»: quel distinto documento generale ha sostituito SP 800-63-3, non SP 800-63B. Stato del documento verificato su csrc.nist.gov/pubs/sp/800/63/b/4/final. Consultato il 1 settembre 2026.
- Financial Conduct Authority, «PS26/2: Operational incident and third party reporting», fca.org.uk/publications/policy-statements/ps26-2-operational-incident-third-party-reporting: dichiarazione di politica pubblicata il 18 marzo 2026: definizione di incidente operativo, soglie di segnalazione e processo standardizzato; separatamente, segnalazione di accordi rilevanti con terzi e registro annuale. Le regole risultanti dovrebbero applicarsi dal 18 marzo 2027. Sostituisce il riferimento obsoleto dell'articolo precedente a semplici «obblighi annunciati di segnalazione degli incidenti». Consultato il 31 agosto 2026.
- Federal Communications Commission, «Protecting Consumers from SIM Swap and Port-Out Fraud», Report and Order and Further Notice of Proposed Rulemaking, FCC 23-95, WC Docket No. 21-341, docs.fcc.gov/public/attachments/FCC-23-95A1.pdf: adottato il 15 novembre 2023 e pubblicato il 16 novembre 2023. Le circa 300 denunce nel 2020, 400 nel 2021 e 500 nel 2022 relative a SIM swap e portabilità fraudolenta provengono dalla nota 13 e dagli archivi del Consumer Complaint Center della Commissione. Consultato il 31 agosto 2026 (98 pagine; testo estratto localmente nella verifica polacca originale).
- Vilius Petkauskas, Cybernews, «Mother of all breaches reveals 26 billion records: what we know so far», cybernews.com/security/billions-passwords-credentials-leaked-mother-of-all-breaches/: pubblicato il 22 gennaio 2024; materiale aggiornato, con il 15 giugno 2026 registrato come ultimo aggiornamento nella verifica polacca delle fonti. La raccolta di 12 TB conteneva oltre 26 miliardi di record in circa 3.800 directory, descritta come probabilmente la maggiore compilazione di più violazioni (COMB), con duplicati altamente probabili. È una fonte secondaria sulle violazioni sottostanti e viene trattata come tale: sostiene la descrizione della raccolta, non conclusioni su ogni singola violazione inclusa. Consultato il 31 agosto 2026.
- National Cyber Security Centre (NCSC UK), «Phishing attacks: defending your organisation», ncsc.gov.uk/guidance/phishing: controlli DMARC, SPF e DKIM contro la falsificazione del mittente, una politica di quarantena o rifiuto e un percorso semplice per segnalare tempestivamente messaggi sospetti. La verifica originale ne ha controllato separatamente l'ambito: non tratta i domini dall'aspetto simile, quindi questo argomento non le viene attribuito. Consultato il 31 agosto 2026.
- National Cyber Security Centre (NCSC UK), «Recommended types of MFA», in «Multi-factor authentication for your corporate online services», ncsc.gov.uk/collection/mfa-for-your-corporate-online-services/recommended-types-of-mfa: ordine di preferenza: 1) credenziali FIDO2, 2) applicazioni basate su challenge, 3) generatori di codici in app (TOTP), 4) generatori hardware di codici, 5) codici inviati tramite messaggio. Consultato il 31 agosto 2026.
- MetaQuotes, «The checks a trading robot must pass before publication in the Market», mql5.com/en/articles/2555, 1 agosto 2016: controlli obbligatori prima della pubblicazione in MQL5 Market e divieto di importare DLL e file EX4/EX5 compilati nei prodotti del Market. Consultato il 31 agosto 2026.
- LastPass, «Notice of Security Incident», blog.lastpass.com/posts/notice-of-recent-security-incident: avviso del 22 dicembre 2022 che conferma la copia di backup dei dati dei clienti, comprese le casseforti di password. I campi sensibili, come nomi utente, password e note, erano cifrati; alcuni metadati, inclusi gli URL dei siti, non erano cifrati. Consultato il 31 agosto 2026; l'avviso storico originale è stato verificato nuovamente il 9 ottobre 2026.
- Banca nazionale svizzera, «Swiss National Bank discontinues minimum exchange rate and lowers interest rate to -0.75%», snb.ch/en/publications/communication/press-releases/2015/pre_20150115, 15 gennaio 2015: fonte della decisione e della sua data. La pagina non specifica l'ora di pubblicazione; il comunicato completo è disponibile come PDF scaricabile. Consultato il 31 agosto 2026.
- Regolamento (UE) 2022/2554 del Parlamento europeo e del Consiglio del 14 dicembre 2022 sulla resilienza operativa digitale per il settore finanziario (DORA), CELEX 32022R2554, GU UE L 333, 27.12.2022: gestione dei rischi TIC e segnalazione dei gravi incidenti connessi alle TIC da parte delle entità finanziarie interessate. L'articolo 2(1) è soggetto ai paragrafi 3 e 4 e include le «imprese di investimento» alla lettera (e); l'articolo 2(3)(d) esenta i soggetti coperti dalle esenzioni degli articoli 2 e 3 della direttiva 2014/65/UE. Il testo polacco usato nella verifica originale è stato ottenuto tramite publications.europa.eu/resource/celex/32022R2554; l'intestazione riporta «27.12.2022 PL Official Journal of the European Union L 333/1». Le disposizioni finali fissano espressamente l'applicazione dal 17 gennaio 2025 e l'entrata in vigore il ventesimo giorno successivo alla pubblicazione nella Gazzetta ufficiale. La pubblicazione il 27 dicembre 2022 dà quindi il 16 gennaio 2023; l'atto non indica numericamente quest'ultima data. Consultato il 1 settembre 2026.
- MetaQuotes, documentazione di riferimento MQL5, «FileOpen» (mql5.com/en/docs/files/fileopen) e «WebRequest» (mql5.com/en/docs/network/webrequest): le operazioni sui file sono limitate alla sandbox e WebRequest richiede l'inserimento dell'URL del server nell'elenco degli URL consentiti sotto «Expert Advisors» in «Options». La documentazione afferma: «I file sui quali si effettuano operazioni mediante MQL5 non possono trovarsi fuori dalla sandbox dei file». Consultato il 31 agosto 2026. Il contesto di esecuzione delle DLL è stato inoltre verificato in «About Dynamic-Link Libraries» di Microsoft, learn.microsoft.com/en-us/windows/win32/dlls/about-dynamic-link-libraries, il 9 ottobre 2026.
- Federal Trade Commission, «Are Public Wi-Fi Networks Safe? What You Need To Know», consumer.ftc.gov/articles/are-public-wi-fi-networks-safe-what-you-need-know, febbraio 2023: la diffusione della cifratura rende solitamente sicure le connessioni Wi-Fi pubbliche, mentre anche i truffatori possono cifrare siti falsi. La cifratura da sola non stabilisce chi riceve le informazioni. Consultato il 31 agosto 2026.
- Esempio pratico polacco: CERT Polska opera all'interno di NASK, l'istituto nazionale di ricerca, e svolge i compiti di CSIRT NASK come uno dei tre gruppi polacchi di risposta a livello nazionale (cert.pl/o-nas). Il modulo è su incydent.cert.pl, intitolato «Zgłoś incydent | CERT.PL». È citato esclusivamente come canale di segnalazione degli incidenti tecnici: questa fonte non stabilisce né una procedura di reclamo finanziario né una decisione sul rimborso. Fuori dalla Polonia, usa il canale nazionale competente. Consultato il 1 settembre 2026.
