Cibersegurança do operador: 2FA, phishing, levantamentos e proteção do dispositivo

A segurança de uma conta de negociação começa pela conta de email, uma palavra-passe única e um método de autenticação adequado. Também importam os dispositivos, as sessões de acesso, as regras de levantamento e os mecanismos de recuperação se perder o telemóvel. Este artigo explica essas salvaguardas passo a passo, os seus limites e como reagir se suspeitar de uma tomada de controlo da conta. Os utilizadores de VPS e robôs de negociação encontram ainda orientações sobre proteção do acesso remoto, das chaves API e das posições abertas. Abordamos separadamente as burlas que imitam empresas no artigo sobre corretoras falsas.

Email, autenticação, dispositivos e recuperação formam em conjunto um sistema de segurança. Nenhuma camada elimina todas as ameaças.
Pontos essenciais em 60 segundos
  • O email é a camada 1, não extra opcional. O comprometimento do email pode permitir repor a palavra-passe do corretor e intercetar confirmações de alterações, dependendo dos controlos de recuperação do corretor. Defina uma palavra-passe única para o email e ative a MFA antes de configurar outras camadas.
  • Uma única palavra-passe reutilizada pode bastar para tomar o controlo da conta, sobretudo sem MFA eficaz. O credential stuffing, o teste automatizado de pares de nome de utilizador/palavra-passe provenientes de outras violações, visa qualquer palavra-passe reutilizada que tenha sido exposta. Uma palavra-passe única mais 2FA, preferencialmente TOTP em vez de SMS, é o mínimo operacional.
  • SMS 2FA supera nenhuma 2FA, mas é inferior a TOTP ou chave física. O SIM swapping pode ser rápido e barato; o tempo, o custo e a taxa de sucesso dependem do operador móvel e do país. TOTP numa aplicação sem cópias das sementes na nuvem, ou uma chave de segurança física como a YubiKey, é um padrão prático.
  • O phishing FX pode ser dirigido. Emails falsos de um «corretor», chamadas de um «departamento de segurança» e ligações para páginas de acesso falsas do MT4 podem ser dirigidos especificamente a traders, em vez de enviados inteiramente ao acaso.
  • Ative a lista de destinos de levantamento autorizados depois de proteger o email. Se o corretor oferecer uma lista de contas bancárias autorizadas, ative-a: um atacante terá de alterar os dados e passar uma verificação adicional. Essa verificação utiliza frequentemente o email, pelo que oferece proteção limitada se a camada 1 estiver comprometida.
  • Um dispositivo para tudo amplia a superfície de ataque. Um dispositivo ou perfil de utilizador separado para negociação é uma questão de disciplina operacional, não uma precaução excessiva.

1. Palavras-passe repetidas: uma fuga ameaça a conta

Comecemos por um cenário muito comum, cuja normalidade é precisamente o que o torna perigoso. Não envolve um pirata informático encapuçado nem a quebra de encriptação. Trata-se de credential stuffing: testar automaticamente, em vários serviços, pares de nome de utilizador/palavra-passe obtidos de violações de bases de dados[1].

O mecanismo é simples. Em 22 de janeiro de 2024, a equipa de investigação da Cybernews descreveu uma coleção acessível ao público com mais de 26 mil milhões de registos e 12 terabytes de dados, apelidada «Mother of All Breaches»[5]. É necessário precisar a sua condição e natureza, porque alteram o significado desse número: não se tratava de uma única violação nova, mas de uma compilação de registos de milhares de violações anteriores e bases de dados transacionadas em privado. O próprio relatório considera os duplicados muito prováveis e trata a presença de informação anteriormente inédita como uma probabilidade, não como uma conclusão demonstrada. O seu relato da exposição posterior é também uma declaração de uma organização, não uma conclusão estabelecida de forma independente: o serviço de pesquisa de violações Leak-Lookup afirmou ser proprietário da coleção e atribuiu a exposição a uma configuração incorreta da firewall que tinha corrigido[5]. Não temos confirmação independente de que as cópias deixaram de circular. Para um trader, a conclusão prática não depende dessa incerteza: se reutilizar uma palavra-passe num fórum de negociação, no Gmail e na conta do corretor, uma dessas milhares de coleções poderá dar a um atacante as credenciais dos três serviços.

Credential stuffing: risco de reutilizar palavras-passe
Credential stuffing: risco de reutilizar palavras-passe. Uma violação num serviço não demonstra o comprometimento de todas as contas. Diagrama educativo; as condições detalhadas e as fontes são explicadas no artigo.
Cenário: credential stuffing após fuga de fórum. Um padrão recorrente é que, após a fuga da base de dados de um fórum de negociação ou criptomoedas, os atacantes testam os mesmos pares de nome de utilizador/palavra-passe em contas de corretagem. Um trader que tenha reutilizado a palavra-passe pode perder o acesso em horas. Neste cenário, o atacante pode alterar os contactos e pedir um levantamento antes de o corretor bloquear a conta. TOTP dificulta significativamente a tomada de controlo: as contas que o utilizam estão menos expostas a este vetor específico.

A cadeia de ataque possível é: email comprometido → reposição da palavra-passe do corretor → alteração dos contactos → pedido de levantamento para a conta do atacante. O intervalo entre comprometer o email e pedir o levantamento pode ser curto, mas não indicamos uma duração concreta: depende dos procedimentos do corretor para alterar dados e do canal de pagamento, e não encontrámos medições que sustentem um número preciso. O corretor envia a confirmação por email, mas o atacante já controla essa conta.

Modelo por camadas: identifique o que protege

Antes de configurar, defina um modelo de ameaças: o que protege, contra quem e o que acontece se uma determinada camada falhar. Sem esse modelo, pode comprar uma chave física para uma conta cuja recuperação da palavra-passe continua dependente de uma conta antiga de Gmail.

Numa conta de negociação, a cadeia de dependências tem sete elos. Percorra-os por esta ordem:

  1. Email: a conta a montante. Comprometê-la ameaça a recuperação das outras contas.
  2. Identidade: o seu número de telefone, códigos de recuperação e documentos que comprovam a sua identidade perante o corretor.
  3. Dispositivo: o computador e o telemóvel onde introduz segredos e recebe códigos.
  4. Corretora: a palavra-passe, a MFA, as sessões ativas e as definições do portal do cliente.
  5. API: chaves programáticas que podem autenticar independentemente de palavra-passe e MFA do portal.
  6. Pagamentos: os métodos de depósito e levantamento e as listas de contas de destino autorizadas.
  7. Recuperação: os canais para restaurar o acesso, frequentemente a via alternativa preferida de um atacante.

Regra prática: uma camada depende da que a sustenta. Não se pode confiar na lista de destinos autorizados se o atacante controlar o email que recebe as confirmações das alterações de destino. Por isso, o artigo segue uma ordem deliberada: as secções 1 e 2 abordam email, identidade e corretor; as secções 5 e 6, dispositivos e API; e a secção 4, pagamentos. A recuperação surge ao longo do texto porque oferece uma via alternativa para as outras camadas.

Responsabilidades da corretora: DORA como contexto, não escudo. Desde 17 de janeiro de 2025, as entidades financeiras da UE abrangidas aplicam o Regulamento (UE) 2022/2554 de 14 de dezembro de 2022 relativo à resiliência operacional digital do setor financeiro, conhecido como DORA (JO UE L 333, 27.12.2022; entrou em vigor em 16 de janeiro de 2023)[11]. Inclui empresas de investimento nos termos do artigo 2.º, n.º 1, alínea e). Impõe deveres de gestão do risco de TIC e de comunicação de incidentes graves relacionados com TIC à autoridade de supervisão, sujeitos às isenções do artigo 2.º, n.º 3, incluindo pessoas isentas nos termos dos artigos 2.º e 3.º da Diretiva 2014/65/UE. A palavra «corretor», por si só, nada demonstra: a aplicação depende da entidade jurídica e do estatuto do prestador, não da marca. O Reino Unido tem um regime FCA separado, em mudança. Em 18 de março de 2026, a FCA publicou a declaração PS26/2 sobre comunicação de incidentes operacionais e mecanismos de comunicação de acordos com terceiros relevantes; está prevista a entrada em vigor das regras resultantes em 18 de março de 2027[3]. Isto não significa que DORA garanta um corretor sem incidentes ou transfira para a empresa a responsabilidade pela sua palavra-passe ou dispositivo. Oferece um quadro para perguntar, após um incidente, que controlos o corretor tinha implementado para acesso, alterações de dados e levantamentos.
A MFA protege o acesso, mas não impede necessariamente o malware. A 2FA protege a fase de início de sessão, mas pode não impedir que malware roube tokens de sessão ou cookies após a autenticação. Num dispositivo infetado, um atacante pode capturar uma sessão válida sem conhecer a palavra-passe nem o código de 2FA. A segurança do dispositivo e do navegador importa, por isso, tanto como uma palavra-passe forte.

Ações práticas

Use palavra-passe única para a corretora. Não a reutilize noutro local. Utilize um gestor de palavras-passe como Bitwarden, 1Password ou KeePass. Gere uma palavra-passe aleatória com pelo menos 16 caracteres, com margem acima do limiar de 15 caracteres das atuais orientações NIST para palavras-passe usadas como único fator de autenticação[2]. Evite inventar palavras-passe: as pessoas não são boas a gerar aleatoriedade.

Use email separado de trading. Crie uma conta exclusivamente para comunicar com corretores e plataformas de negociação. Não a utilize para registo em fóruns, redes sociais ou outros serviços. Se o seu endereço principal for divulgado, o endereço associado à conta de negociação não ficará exposto através dos mesmos registos. Isso reduz o risco, embora não proteja a conta por si só.

Verifique dados expostos. Introduza o seu email em haveibeenpwned.com e examine que dados foram divulgados. Altere imediatamente uma palavra-passe se foi divulgada, reutilizada ou existirem motivos para suspeitar de comprometimento. Um endereço surgir na violação de outro serviço não demonstra, por si só, que uma palavra-passe diferente e única do corretor tenha sido comprometida.

Um gestor é requisito operacional. Sem um gestor, as alternativas habituais são palavras-passe simples que consegue memorizar, mais fáceis de decifrar, ou a reutilização entre serviços, que o expõe a credential stuffing. Na prática, memorizar mais de trinta palavras-passe aleatórias e únicas não é uma alternativa realista.

2. 2FA: mínimo, não opção

A autenticação de dois fatores (2FA) acrescenta uma segunda camada após a palavra-passe. Uma 2FA bem implementada dificulta o início de sessão com uma palavra-passe roubada, mas o phishing pode intercetar códigos, enquanto a recuperação da conta ou o roubo de sessão podem contornar o ecrã normal de acesso. A dificuldade é que os métodos de 2FA não são equivalentes. SMS e TOTP têm fraquezas substancialmente diferentes, tal como tipos distintos de fechadura oferecem proteção diferente.

Método 2FA Como funciona Segurança Fraqueza principal
SMS Código único ao telefone Baixa SIM swapping: controla o número pelo operador
Email Código ao email A mais baixa Se comprometem email, 2FA por email não é independente
TOTP (aplicação autenticadora) Código gerado localmente a cada 30 segundos (Google Authenticator, Authy); prefira uma configuração sem cópias das sementes na nuvem Alta Uma página de phishing pode intercetar um código de utilização única; separadamente, perder o telemóvel sem códigos de recuperação pode deixá-lo sem acesso
Chave de segurança física Dispositivo USB físico (YubiKey, Titan Key) A mais alta Exemplo polaco: centenas de PLN conforme modelo e vendedor; suporte limitado
Os métodos MFA resistem a ataques diferentes
Os métodos MFA resistem a ataques diferentes. Comparação de mecanismos, sem prometer segurança completa. Diagrama educativo; as condições detalhadas e as fontes são explicadas no artigo.

Porque SMS 2FA não basta

A 2FA por SMS é melhor do que não ter 2FA, mas mais fraca do que TOTP ou uma chave de segurança física. Num SIM swap, um burlão contacta o operador móvel, faz-se passar pelo titular e pede a transferência do número para uma SIM de substituição. Estes ataques podem ser rápidos e baratos, mas o tempo, custo e taxa de sucesso dependem do operador, país e qualidade da informação sobre a vítima. Cada operador define os seus procedimentos de verificação para emitir uma substituição, e os dados utilizados podem estar disponíveis em violações de dados. A escala está documentada nos EUA: a FCC regista no seu Consumer Complaint Center cerca de 300 queixas de SIM swapping e portabilidade em 2020, 400 em 2021 e 500 em 2022[4].

TOTP: padrão prático

TOTP (Time-based One-Time Password) gera códigos localmente no dispositivo a cada 30 segundos. Não utiliza a rede móvel, pelo que o SIM swapping não interceta o código, e a sua geração não exige internet. A ordem de preferência do NCSC britânico coloca os códigos gerados por aplicações bastante acima dos enviados por mensagem[7], embora não sejam a primeira opção. A parte passkeys explica o que supera.

Para configurar TOTP, descarregue uma aplicação autenticadora e escolha a utilização sem conta ou desative a sincronização na nuvem. O Google Authenticator sincroniza códigos com uma conta Google se iniciar sessão e também permite utilização sem conta; o Authy oferece cópias na nuvem. É cómodo, mas o incidente confirmado da LastPass de dezembro de 2022, descrito abaixo, ilustra o ponto de falha adicional criado por guardar material de autenticação na nuvem. Prefira geradores offline com uma cópia física dos códigos de recuperação. Nas definições da conta do corretor, procure «Segurança» → «Autenticação de dois fatores» e leia o QR com a aplicação. O acesso passa a exigir a palavra-passe e o código de 6 dígitos da aplicação.

Crucial: guarde códigos de recuperação. Se o corretor emitir códigos de reserva de utilização única para perda do telemóvel, guarde-os durante a configuração. Caso contrário, verifique e registe o procedimento oficial documentado de recuperação antes de precisar dele. Imprima os códigos e guarde-os em segurança, separados do telemóvel, da conta na nuvem e do gestor de palavras-passe: perder o acesso ao gestor não deve significar perder também os códigos. Uma folha num cofre ou numa gaveta fechada à chave é uma opção.

Exemplo: LastPass, dezembro de 2022. Em dezembro de 2022, a LastPass confirmou que um incidente tinha levado à cópia de cópias de segurança de dados dos clientes, incluindo cofres de palavras-passe encriptados[9]. Trata-se de um incidente confirmado pela empresa no aviso de dezembro de 2022. Não determinamos as consequências para clientes individuais, pois não temos uma fonte que sustente essa conclusão. A lição prática é independente dessas consequências: guardar palavras-passe e códigos de recuperação TOTP num único gestor na nuvem coloca ambos os componentes de autenticação no mesmo local. Uma base de dados torna-se um potencial ponto de falha. Guarde os códigos offline e impressos, não apenas noutro gestor de palavras-passe na nuvem.
Camadas MFA: resistência a ameaças concretasUm método mais forte não substitui sessões, dispositivo e recuperação segurosCamadas MFA: resistência a ameaças concretasUm método mais forte não substitui sessões, dispositivo e recuperação segurosEmailDepende de segurança e recuperação da caixa.SMSIntercetáveis por SIM swapping ou phishing.TOTPSem SIM; vulnerável a phishinge retransmissão.FIDO2 / passkeyVincular origem resiste phishing. Reveja sincronização erecuperação.As passkeys vinculadas ao hardware e as sincronizadas diferem; nem todas as implementações cumprem AAL3.

Passkeys e FIDO2: para onde avançar

A chave é implementação física do padrão mais amplo FIDO2/WebAuthn. Em vez de um código que pode ser ditado a alguém ou copiado numa página falsa, o navegador e o autenticador trocam uma assinatura criptográfica vinculada ao domínio adequado. Outro domínio não consegue obter autenticação para a credencial registada. Essa vinculação ao domínio é a distinção essencial em relação a TOTP.

Uma passkey utiliza este mecanismo com uma credencial FIDO2 guardada num telemóvel, computador ou gestor de palavras-passe e desbloqueada por impressão digital ou PIN do dispositivo, pelo que pode dispensar uma chave separada. O NCSC coloca as credenciais FIDO2 em primeiro lugar na resistência a adivinhação, phishing e roubo de segredos de autenticação. Os códigos gerados por aplicações ocupam o terceiro lugar, e o documento identifica expressamente a sua suscetibilidade a interceção[7]. O NIST permite autenticadores criptográficos multifator nos seus níveis de garantia mais altos quando são cumpridos os requisitos do nível específico; uma passkey sincronizada não se torna automaticamente uma credencial AAL3. A autenticação pela rede telefónica, incluindo SMS, tem estatuto restrito[2].

O que fazer hoje. O suporte a passkeys varia entre corretores de retalho: alguns portais oferecem apenas TOTP e SMS. Procure «chave de segurança», «passkey» ou «WebAuthn» nas definições de segurança. Se suportado, ative-o como método principal e mantenha TOTP como reserva. Se indisponível, TOTP com códigos de recuperação offline continua a ser um mínimo razoável. Ative uma passkey no email independentemente do corretor, pois o email é a camada 1 do modelo acima.

3. Phishing: email, telefone e engenharia social FX

O phishing no forex pode ser dirigido: os atacantes sabem que os traders têm fundos nas contas e reagem a «margin call» e «alerta de segurança». Também pode ser spam comum com o logótipo de um corretor e um domínio registado a baixo custo. Um ataque não precisa de ser sofisticado para funcionar.

Emails falsos de «corretora»

É um vetor de ataque barato e, por isso, comum. Um email imita as cores, o logótipo e o rodapé do corretor. O assunto pode ser «Urgente: verifique a sua conta», «Alerta de segurança: detetado acesso invulgar» ou «Ação necessária: atualize o método de pagamento». A ligação abre uma imitação da página de acesso do corretor noutro domínio. Introduzir as credenciais entrega-as ao atacante. A orientação do NCSC para organizações aborda dois elementos: a falsificação do remetente, combatida por DMARC, SPF e DKIM, e a necessidade de uma via simples e rápida para comunicar mensagens suspeitas[6]. Não trata domínios parecidos; o seguinte é explicação nossa, não atribuída ao NCSC.

Email de phishing exemplificativo: urgência, domínio diferente do portal guardado e verificação do destino da ligação.
Neste exemplo, portal.broker.example e broker-login.example são domínios diferentes. Abra o portal conhecido de forma independente; linguagem fluente e encriptação não demonstram autenticidade.
Cenário: phishing que imita corretora. A primeira fase, imitar remetente, é coberta pela orientação[6]: os clientes recebem o que parece ser uma «atualização urgente de segurança» oficial. O resto do cenário é uma ilustração nossa. A ligação abre um domínio de aspeto semelhante, como brokername-security[.]com em vez de brokername.com. A página copia o portal de acesso, incluindo um certificado SSL válido, pelo que o cadeado do navegador não demonstra autenticidade. Os endereços provêm frequentemente da violação de um serviço externo, não do corretor; por isso, também não clientes podem receber a mesma mensagem. Não nomeamos uma empresa nem indicamos a dimensão da campanha: é um modelo, não o relato de um evento documentado.
Avançado: registos de transparência de certificados. O cadeado do navegador não basta: o portal falso do exemplo também tem um certificado válido. crt.sh permite examinar o histórico de certificados de um domínio. A idade do certificado não demonstra nada por si só: serviços legítimos renovam-nos regularmente e um domínio de phishing pode existir há muito tempo. Certificate Transparency regista a emissão e fornece sinais complementares, como certificados novos para nomes semelhantes ao domínio do corretor. Compare-os com o domínio, a inscrição da entidade jurídica no registo de supervisão e o seu canal oficial de contacto. O histórico não substitui essas verificações nem determina se um sítio é legítimo ou fraudulento.

Chamadas da «segurança»

Um método mais elaborado é o vishing, ou phishing por voz. Alguém liga afirmando trabalhar na segurança do corretor, diz ter detetado atividade suspeita e pede uma verificação de identidade: «Diga-me o número da conta e o código de 2FA que acabámos de enviar». Facultá-lo pode autorizar o acesso do atacante.

Uma corretora correta não deve pedir 2FA de acesso pelo telefone. Quem o pede pode estar a comprometer a conta em vez de a proteger. Desligue e ligue para o número oficial do sítio do corretor, não o do email. A pressão para agir depressa pode ser mais eficaz do que malware.

Descargas MT4/MT5 falsas

Os traders procuram no Google «MT4 download» ou «MT5 download». Os atacantes podem comprar anúncios para instaladores modificados: parecem familiares e podem funcionar normalmente enquanto enviam credenciais para um servidor controlado pelo atacante. Uma página falsa de descargas distribui malware eficazmente porque o utilizador executa o instalador e lhe concede permissões.

Onde descarregar plataforma? Utilize o sítio verificado do corretor, o sítio oficial do fabricante da plataforma ou uma loja de aplicações identificada na documentação do fabricante. Evite ligações de emails não solicitados, grupos Telegram e resultados de pesquisa não verificados. O mais simples é escrever o endereço do corretor e utilizar «Descargas» ou «Plataformas». Na loja, verifique o editor, não apenas o nome e o ícone, fáceis de copiar.
Cenário: venda agressiva para entidade offshore. Um email do seu corretor atual oferece: «Aumente a alavancagem para 1:500 e receba um bónus!». Supostamente, um clique transfere a conta de uma jurisdição supervisionada pela FCApara Seicheles ou Vanuatu. Ganha alavancagem, mas as proteções do regime anterior podem deixar de se aplicar. Quais mudam depende da nova entidade jurídica, jurisdição e contrato. Artigos separados abordam limites de alavancagem e proteção de saldo negativo e sistemas de indemnização; verifique aí o que se aplica à nova entidade. Também não presumimos que a transferência seja legal: depende de como o cliente foi angariado e das autorizações da entidade recetora; os supervisores podem contestar mecanismos que encaminham clientes não profissionais para empresas afiliadas de países terceiros. Aqui importa a pressão para decidir: oferta urgente, um clique e aceitação antes de verificar, como na engenharia social.

Engenharia social em grupos

Os grupos de negociação no Telegram, Discord e Facebook oferecem oportunidades de engenharia social. Um suposto administrador envia uma mensagem privada: «Tenho uma oferta especial do corretor X, mas tem de se registar pela minha ligação». Ou: «Publique uma captura da conta e ajudo a configurar o seu EA». Uma captura pode revelar o número da conta do corretor, ajudando um atacante a manipular verificações telefónicas de identidade fracas. Compreenda essa exposição antes de publicar o «lucro do dia» num grupo.

4. Levantamentos seguros: métodos, listas e documentos KYC

Um atacante que tome o controlo da conta pode fechar posições e prejudicar o capital, mas desviar fundos torna-se mais difícil com uma lista eficaz de destinos autorizados. O controlo visa enviar fundos para uma conta já aprovada em seu nome. Configurar levantamentos é uma questão de segurança, além de comodidade.

Lista de contas autorizadas

Se o corretor oferecer «Destinos de levantamento aprovados» ou uma «Lista de levantamentos autorizados», verifique as regras exatas. Ativá-la restringe os levantamentos a contas bancárias previamente aprovadas. Adicionar uma conta pode exigir verificação adicional e espera; o corretor determina a disponibilidade e duração desses controlos. Dificulta o desvio, mas não garante parar um levantamento após a tomada de controlo.

Verifique se o corretor suporta listas de destinos autorizados e ative-as se disponíveis. Procure «Lista de levantamentos autorizados», «Destinos aprovados» ou «Contas de confiança» no portal do cliente. Verifique o contrato e as definições de segurança: a disponibilidade muda e pode diferir entre entidades do mesmo grupo. Considere a ausência uma desvantagem ao comparar controlos, não uma prova conclusiva de desonestidade.

Levantamentos: beneficiários de confiança e controlos de alterações
Levantamentos: beneficiários de confiança e controlos de alterações. Mecanismo ilustrativo: disponibilidade e condições dependem do corretor. Diagrama educativo; as condições detalhadas e as fontes são explicadas no artigo.

Notificações de levantamento

Ative email e notificações push para cada pedido de levantamento. Se vir um que não apresentou, ligue imediatamente ao corretor: o email pode estar comprometido. Costuma existir tempo de processamento entre pedido e execução pelo corretor e pelo banco, mas a duração depende dos termos da entidade concreta. Verifique-os antes, não durante o incidente. Essa janela oferece frequentemente a melhor oportunidade de parar uma transferência, mas não é a única: após o envio, o banco ou prestador de pagamentos pode iniciar uma recuperação, como explicado abaixo.

Alterações de dados: ponto crítico

O evento crítico é frequentemente alterar o email, telefone, conta bancária ou beneficiário do levantamento, não o acesso em si. Mudar os métodos semanalmente pode desencadear uma revisão manual de conformidade e, por vezes, uma restrição temporária precisamente quando quer levantar lucros. Escolha um método adequado, verifique-o e utilize-o de forma consistente.

Algumas devolvem pela mesma via. No «levantamento pelo mesmo método», um depósito Visa é devolvido a esse cartão Visa. Não é uma regra geral do mercado: algumas empresas devolvem à origem com exceções, outras aplicam uma hierarquia de métodos, e os lucros podem ser tratados separadamente. Verifique âmbito, exceções e ordem nos termos do corretor. Quando aplicável, é um controlo a par de listas autorizadas, atrasos e revisão manual.
O que pode reverter após incidente? O resultado de um levantamento não autorizado depende de os fundos já terem saído, do método de pagamento, de o destino estar autorizado e de o corretor ter detetado o incidente antes da liquidação. Transferência: a recuperação após a liquidação é incerta, mas o assunto não fica automaticamente encerrado. Um banco ou prestador de pagamentos pode pedir ao banco recetor a recuperação de uma transferência, incluindo em casos de fraude. Não garante reembolso e não há uma hora universal após a qual toda a transferência se torna irreversível: na prática, atrasar reduz as hipóteses de recuperação. Cripto: registada na cadeia, o pagador não tem mecanismo de reversão. Cartão: uma reclamação ou chargeback depende do tipo de transação, fundamentos, rede de cartões, emissor e prazos; não é um mecanismo geral para reverter um levantamento de corretagem. Comunique prontamente o incidente ao corretor e ao banco para preservar as opções disponíveis.

Documentos KYC: podem abrir outra conta

Para abrir uma conta, envia ao corretor uma digitalização do cartão de identidade ou passaporte, um comprovativo de morada e, por vezes, um extrato bancário. Em conjunto, esses documentos podem facilitar a abertura ou recuperação de outra conta. Trate-os como informação sensível de identidade, não como um anexo corrente.

Na prática, carregue documentos pelo portal, em vez de email ou aplicações de mensagens. Se um email os pedir, ligue para o número do sítio verificado para confirmar o pedido. Não deixe cópias em descargas ou galeria; se guardar use contentor cifrado ou gestor com anexos. Elimine cópias de trabalho após verificar, incluindo mensagens enviadas e conversas. Um documento divulgado pode facilitar uma tentativa de recuperação com «esqueci a palavra-passe e perdi a 2FA». Se disponível, defina previamente uma palavra-passe para contacto telefónico. Perguntas como o apelido de solteira da mãe ou a primeira escola são outra questão: as respostas podem ser reconstruídas a partir de violações de dados e redes sociais. Se o corretor as utilizar, trate-as como verificação complementar a MFA forte e recuperação verificada, não como substituto.

Guarde canais seguros antes. Guarde o telefone do sítio do corretor, o endereço do portal introduzido manualmente, o endereço de conformidade e o número da conta fora do email. Durante um incidente pode não ter tempo para apurar que canal é autêntico; procurar uma linha de apoio pode expô-lo a um anúncio de uma falsa.

5. Dispositivos: VPN, Wi-Fi público, atualizações e separação

O computador e o telemóvel são portas de acesso à conta de negociação. Se um dispositivo estiver comprometido, palavra-passe, 2FA e lista autorizada em conjunto podem continuar a ser insuficientes: o atacante pode potencialmente observar o que faz no ecrã.

Wi-Fi público: o que resolve VPN e o que não

Distinga as medidas essenciais dos controlos adicionais, porque o Wi-Fi público suscita muitos exageros. O essencial é HTTPS corretamente verificado, endereço do portal introduzido manualmente no domínio certo, não ignorar avisos de certificado, dispositivo atualizado e MFA resistente ao phishing. A autoridade de proteção do consumidor dos EUA afirma expressamente que a encriptação generalizada costuma tornar seguras as ligações por Wi-Fi público[13]. Também refere que burlões podem obter certificados para os seus sítios, pelo que a encriptação, por si só, não identifica o destinatário da informação.

O Wi-Fi público continua a apresentar riscos de hotspots falsos, redirecionamento para páginas de acesso imitadas e phishing. Uma VPN ou um hotspot próprio é camada adicional, não um pré-requisito de segurança. Pode reduzir a exposição do tráfego auxiliar e a dependência de uma rede desconhecida, mas não reparar um dispositivo infetado nem impedir que introduza uma palavra-passe num domínio falso.

Cenário: hotspot falso. Um atacante cria um hotspot com o mesmo nome da rede do hotel. O problema não é a falta de certificate pinning no navegador: HTTPS corretamente verificado também protege o conteúdo em redes desconhecidas. O risco é o redirecionamento para um acesso falso e a tentação de ignorar um aviso de certificado. Em eventos e hotéis, o hotspot do telemóvel pode ser mais simples. Um aviso de certificado é motivo para parar, não para clicar em «Continuar».

Se escolher uma VPN, selecione um fornecedor com política clara de registos e verifique como se financia. Num serviço gratuito, isso importa mais do que o preço: alguns planos gratuitos são financiados por subscrições pagas, outros monetizam tráfego e dados dos utilizadores. Avalie o modelo de negócio, política de registos e auditoria independente do fornecedor específico, sem pressupor que pagar demonstra fiabilidade. A partilha LTE/5G do seu telemóvel é frequentemente mais simples e evita acrescentar outro fornecedor em quem confiar.

Camadas de segurança, como uma VPN ou análises num VPS, podem afetar a latência de rede ou a carga do dispositivo. Meça o efeito na sua configuração. O artigo sobre infraestrutura de execução explica quando isso importa, por exemplo na negociação de notícias ou no scalping e quando não.

VPN e conformidade. Alterar IP, aceder de vários países e geolocalizações invulgares pode desencadear restrições ou revisão manual. Se usar VPN regularmente, considere um ponto de saída estável no seu país e conheça a política do corretor. Alguns portais suportam listas de IP de confiança, com verificação adicional para outros endereços. Confirme se o corretor oferece essa definição e como funciona exatamente.

Sessões ativas: revisão e revogação

O acesso cria uma sessão que pode permanecer ativa no navegador, aplicação móvel ou terminal. Malware que roube cookies de sessão pode não precisar da palavra-passe nem do código de 2FA: uma sessão válida pode bastar. Alterar a palavra-passe após um incidente sem revogar sessões pode, por isso, deixar o atacante ligado.

Procure «Sessões ativas», «Dispositivos», «Dispositivos ligados» ou «Atividade de segurança» no portal. Reveja a lista periodicamente e termine o que não reconhece: outro computador, um telemóvel antigo ou um local desconhecido. Se existir «Terminar sessão em todos os dispositivos», saiba onde está antes de um incidente. Faça o mesmo no email associado ao corretor, a camada 1 do modelo acima.

Separação de dispositivos

Gere capital: mantenha limpo o ambiente. Um dispositivo dedicado é um portátil ou tablet no qual evita navegação alheia à negociação, anexos e software não verificado. As ferramentas necessárias são a plataforma, um navegador para o portal do corretor e um gestor de palavras-passe.

No exemplo orçamental polaco, um ThinkPad recondicionado de cerca de mil PLN pode ser uma opção para proteger a conta. Se outro dispositivo for impraticável, um perfil de utilizador separado no sistema operativo ajuda a organizar e reduz alguma exposição, mas não substitui um dispositivo separado perante malware mais grave.

Separar dispositivos: reduzir a superfície de ataque
Separar dispositivos: reduzir a superfície de ataque. Um perfil separado isola menos do que um dispositivo separado. Diagrama educativo; as condições detalhadas e as fontes são explicadas no artigo.

Atualizações: rotineiras e críticas

Windows, macOS, Android, iOS, MT5 e cTrader recebem atualizações, incluindo correções de segurança; MT4 é abordado separadamente abaixo. Uma instalação desatualizada pode conter vulnerabilidades conhecidas exploráveis. Ative atualizações automáticas em vez de as adiar indefinidamente.

MetaTrader 4 continua a receber atualizações do fabricante. Não atribuímos à MetaQuotes um fim formal do desenvolvimento de MT4, pois não encontrámos um anúncio do fabricante que o estabeleça. Se usar MT4, confirme que tem a versão mais recente do corretor ou fabricante. Versões antigas de sítios alheios podem conter vulnerabilidades conhecidas.

Antivírus é uma camada, mantenha ativo. O Windows Defender atualizado e ativo, integrado no Windows 10/11, fornece uma camada básica para uma estação de negociação típica. macOS tem controlos próprios, incluindo Gatekeeper e XProtect. Evite desativá-los apenas por acreditar que tornam o dispositivo lento.

6. Segurança VPS/EA: operações órfãs e acesso remoto

Executar Expert Advisors (EA) num VPS introduz uma superfície de ataque adicional. Esse computador remoto opera 24/7, permanece ligado ao corretor e pode aceder à conta de negociação. Comprometê-lo pode dar ao atacante o controlo do ambiente de negociação.

Configuração RDP segura

Remote Desktop Protocol (RDP) é uma forma habitual de ligação a um VPS Windows. RDP exposto diretamente à internet é um alvo persistente: bots de pesquisa tentam ataques às palavras-passe continuamente, 24/7.

Mudar porta só protege pouco. Priorize não expor RDP publicamente, acesso por túnel VPN/WireGuard; uma lista IP autorizada se o prestador dá endereço estável; autenticação de nível de rede (NLA); MFA no prestador VPS e à parte no gateway se usado; e instantâneos regulares e registo de eventos. Aplique o princípio do privilégio mínimo: instale apenas o que o ambiente de negociação necessita.

Cenário: VPS comprometido com credenciais guardadas. Um VPS barato conserva a palavra-passe predefinida e uma porta RDP pública. Bots decifram a palavra-passe, entram, abrem o terminal com credenciais guardadas e colocam posições com o volume máximo. O trader descobre um saldo negativo de manhã. O corretor recusa compensar, invocando uma sessão autenticada válida. A responsabilidade não se determina apenas pelo cenário: depende do contrato, lei aplicável e registos de ambas as partes. Identifica-se o que o trader controlava diretamente: a configuração do VPS.

Controle palavras-passe MT4/MT5 no VPS

MT4 e MT5 oferecem «Guardar palavra-passe» ao iniciar sessão. Desative se desnecessário ao funcionamento previsto: credenciais guardadas facilitam o acesso após comprometer o anfitrião ou a sessão. Para um EA 24/7, verifique como o terminal volta a ligar após reiniciar. Desativar o armazenamento sem plano de reautenticação pode parar a automatização.

Isto difere de guardar a palavra-passe num gestor. Um gestor encripta o segredo com a sua própria autenticação e pode integrar uma configuração EA 24/7 quando o anfitrião e a via de acesso estão protegidos por MFA e lista de IP autorizados. A ordem é proteger primeiro o anfitrião e o acesso e depois decidir como fornecer as credenciais. Nenhuma medida substitui a outra: limite armazenamento e permissões às necessidades da automatização; introduzir manualmente a palavra-passe não justifica RDP público com configuração predefinida.

Operações órfãs: sem controlador

Uma operação órfã foi aberta por um EA, mas deixa de ser gerida após falha do VPS, perda de ligação ou reinício. Pode não ter stop-loss, porque o algoritmo devia gerir a saída dinamicamente, nem take profit nem alguém a vigiá-la. A posição pode permanecer exposta até uma chamada de margem ou outra intervenção.

Salvaguarda: um EA deve definir um stop loss aceite no servidor em vez de depender apenas de um stop virtual algorítmico. Se o EA parar, o SL aceite permanece no servidor, mas não garante o preço de execução nem uma perda limitada ao montante previsto. O compromisso importa: com pouca liquidez e um amplo spread, como na janela de rollover do corretor, um stop pode ser acionado em condições piores do que o esperado. Para um rollover às 17:00 de Nova Iorque, o exemplo polaco é geralmente às 23:00, ou às 22:00 quando as mudanças de hora de verão não coincidem. Isso não prova, por si só, que o corretor visou o seu stop. Um stop virtual oculta o nível fixo no terminal, mas acrescenta dependência de infraestrutura. Escolha de acordo com as condições de execução do corretor e o método de negociação.

VPS: segurança de acesso e desempenho de execução
VPS: segurança de acesso e desempenho de execução. Duas camadas distintas: um túnel não garante resultados nem preços de execução. Diagrama educativo; as condições detalhadas e as fontes são explicadas no artigo.

Não partilhe VPS

Partilhar um VPS para poupar pode expor EA e posições abertas a outro utilizador com potencial acesso ao terminal, ficheiros, registos e segredos. No exemplo polaco, poupar PLN 50 cria essa exposição. Mantenha o VPS sob controlo de um único trader, em vez de partilhar o ambiente da conta com utilizadores alheios.

História e cenário: 15 de janeiro de 2015, BNS e EA sem SL servidor. Em 15 de janeiro de 2015, o Banco Nacional Suíço eliminou a taxa de câmbio mínima de 1,20 francos por euro e reduziu a taxa de juro para −0,75%, como anunciou no comunicado desse dia[10]. A decisão foi anunciada e aplicada; não repetimos estimativas contraditórias da imprensa especializada sobre o movimento em pips. O que se segue é um cenário ilustrativo, não um relato documentado: um VPS executa um EA de scalping EURCHF com stop virtual algorítmico e sem SL no servidor. VPS e EA continuam operacionais, mas os fornecedores de liquidez deixam de cotar. Sem preços executáveis, o stop virtual não pode fechar a posição. A lição de infraestrutura é que um SL aceite no servidor pode operar sem EA, mas exige mercado disponível e continua sujeito às condições de execução: um gap pode produzir um preço pior do que o nível do stop. Um SL virtual depende também de EA funcional e ligação ao corretor.
Chaves API: palavras-passe com permissões definidas Os modelos de acesso programático diferem. Um fornecedor pode emitir um token pessoal que abranja todas as subcontas; outro utiliza uma biblioteca ligada a uma sessão do terminal já autenticada, inicialmente apenas de leitura. Não existe um nome universal para a permissão de colocar ordens nem uma restrição obrigatória de IP disponível em todo o mercado. Antes de emitir credenciais, esclareça cinco aspetos com o corretor: tipo de credencial, âmbito das permissões, duração, se permite negociar ou levantar e como revogá-la. Verifique separadamente se o acesso pode ser restringido a IP específicos. Seja qual for o modelo, uma credencial autorizada a colocar ordens pode contornar o acesso normal ao portal: trate-a como um segredo poderoso. Guarde-a em variáveis de ambiente, não incorporada no código-fonte do script. Além disso rever as chaves emitidas e revogar as que não são utilizadas: uma chave gerada há dois anos para testar um bot pode continuar a funcionar se não expirar e ninguém a tiver revogado. Menos credenciais ativas com permissões mais restritas reduzem a superfície de ataque.
DLL: permissão adicional, risco adicional
DLL: permissão adicional, risco adicional. O código da biblioteca executa no contexto do processo do terminal. Diagrama educativo; as condições detalhadas e as fontes são explicadas no artigo.
Allow DLL imports: conceder acesso ao sistema a código externo. Ativar «Allow DLL imports» para um EA de origem desconhecida permite executar código externo. Uma DLL funciona fora das restrições de ficheiros do MQL, mas com os privilégios do processo do terminal: selecionar a opção não confere direitos de administrador. Código malicioso pode abusar dos ficheiros, da memória e do acesso à rede disponíveis para esse processo para roubar informação. Um EA que exija DLL requer um programador verificado e código auditado. A MetaQuotes proíbe importações de DLL e de ficheiros EX4/EX5 compilados nos produtos do MQL5 Market, pelo que um EA que exija uma DLL está fora desse canal de distribuição[8].

Contas maiores e negociação algorítmica podem utilizar API FIX ou colocation perto dos servidores do corretor, abordadas em infraestrutura de execução. Aplica-se a mesma distinção de segurança das outras chaves API: distinguir credenciais apenas de leitura das autorizadas a colocar ordens.

Copy trading como vetor de ataque. Os utilizadores de ZuluTrade, MQL5 Signals ou eToro Copy Trading autorizam um serviço a replicar as operações de um fornecedor selecionado. Os modelos diferem: não pressuponha que o fornecedor de sinais recebe acesso à sua conta. As permissões e a entidade que coloca as ordens variam, e alguns fornecedores não conseguem aceder às contas nem aos dados dos subscritores. Se a conta de um fornecedor for comprometida, podem ser copiadas operações maliciosas dentro dos limites definidos pelo subscritor, como a parcela de capital atribuída, o limiar de capital próprio que interrompe a cópia e os limites de dimensão das posições. Verifique separadamente que permissões recebe o serviço de cópia e onde configurar esses limites. Leia a documentação do fornecedor específico, em vez de pressupor definições equivalentes entre serviços.
Cenário ilustrativo: um fornecedor de sinais pirateado. Um fornecedor com centenas de contas subscritoras é comprometido. Durante a noite, o atacante abre posições grandes sem stop loss em pares ilíquidos. As contas dos subscritores copiam as operações dentro das suas próprias definições. Uma maior atribuição de capital e limites de posição mais permissivos aproximam-nas de uma chamada de margem. Seguir sinais de terceiros sem limites firmes ao nível da conta delega parte do risco a um ambiente cuja segurança não controla.

7. Lista de verificação de 10 minutos e resposta a incidentes

Hoje pode aceder às posições abertas e amanhã perder esse acesso. O que se segue destina-se a uma revisão de 10 minutos: suficiente para percorrer a lista e identificar os pontos que ainda não pode assinalar como concluídos.

Comece por três pontos. Dê prioridade a (1) uma palavra-passe única e MFA no email associado, (2) uma palavra-passe única do corretor gerada por um gestor e (3) TOTP offline com códigos de recuperação guardados em segurança. Estas medidas combatem ataques baratos e escaláveis que utilizam emails comprometidos e palavras-passe reutilizadas divulgadas. A primeira sustenta as restantes porque a recuperação e as confirmações de alterações podem utilizar o email. Se disponível, a lista de destinos de levantamento autorizados ocupa o quarto lugar, pois as alterações de destino também podem ser confirmadas por email. Agende o restante trabalho de configuração, em vez de o deixar indefinidamente por concluir.
# Elemento Padrão mínimo Estado
1 Email protegido de forma independente Palavra-passe única do email, MFA (preferencialmente uma passkey), regras de reencaminhamento e filtros revistos: camada 1 da secção 1 ☐
2 Email separado para negociação Endereço dedicado não utilizado para registo noutros serviços ☐
3 Palavra-passe única do corretor 16+ caracteres aleatórios de um gestor de palavras-passe, nunca reutilizados noutro local ☐
4 2FA ativada (TOTP) Aplicação TOTP sem cópia na nuvem, em vez de SMS ou email ☐
5 Códigos de recuperação de 2FA offline Impressos e guardados num local seguro ☐
6 Destinos de levantamento autorizados Se suportado: apenas contas bancárias aprovadas, com regras verificadas para alterar o destinatário ☐
7 Notificações de levantamento Notificações por email e push para cada pedido de levantamento ☐
8 Atualizações do sistema e da plataforma Atualizações automáticas ativadas; versões atuais do MT4/MT5 ☐
9 Redes desconhecidas: HTTPS verificado, VPN como camada adicional Introduzir manualmente o endereço do portal; nunca ignorar avisos de certificado. Uma VPN com política de registos verificada ou a partilha de ligação do telemóvel são medidas complementares ☐
10 Dispositivos ou perfis separados Computador ou perfil de utilizador para negociação separado da atividade quotidiana ☐
11 VPS: túnel VPN, lista de IP autorizados e MFA do fornecedor Sem RDP público; acesso por VPN/WireGuard, lista de IP autorizados, MFA do fornecedor e MFA independente do gateway, se utilizado ☐
12 VPS: segredos controlados e restritos Armazenamento de credenciais do terminal limitado às necessidades de automatização; início de sessão após reinício testado, gestor de palavras-passe e anfitrião e acesso protegidos ☐
13 EA: SL no servidor em caso de falha do VPS SL aceite pelo servidor do corretor, em vez de apenas um stop virtual do EA ☐
14 Revisão das sessões ativas Listas de dispositivos do corretor e do email revistas; sessões desconhecidas terminadas ☐
15 Chaves API não utilizadas revogadas Chaves não utilizadas revogadas; permissões restantes reduzidas e restrições de IP aplicadas quando suportadas ☐
16 Canais de contacto verificados do corretor guardados Número de telefone oficial, portal e endereço de conformidade registados fora da conta de email ☐
17 Sem acesso remoto para pessoas não verificadas Sem AnyDesk, TeamViewer nem partilha de ecrã a pedido de um «consultor», «departamento de segurança» ou «empresa de recuperação» que contacte sem solicitação prévia ☐

Cliquei numa ligação, introduzi a palavra-passe e aprovei a MFA: e agora?

É um cenário difícil porque o segundo fator não falhou tecnicamente: foi aprovado por si. O atacante pode ter agora uma sessão válida e permissão para alterar dados. A ordem das ações importa, não apenas a rapidez de uma ação isolada. Utilize outro dispositivo de confiança e deixe de interagir com o email suspeito.

Suspeita de comprometimento: plano de respostaPrioridades de ação: os tempos são metas de planeamento, não garantiasSuspeita de comprometimento: plano de respostaPrioridades de ação: os tempos são metas de planeamento, não garantias1. Conter o acessoDispositivo de confiançaRevogar sessõesPedir bloqueiode levantamentosProteger o emailT+0–5 min2. Recuperar o controloPalavra-passe únicaRepor MFA / códigosRevogar chaves APIVerificar beneficiáriosT+5–15 min3. PreservarprovasSaldo eposiçõesHistórico de acessosCapturas com data e horaNúmeros dereferência do casoT+15–60 min4. Comunicar o incidenteCorretor e bancoCERT competente /políciaAvaliação do dispositivoRecuperação seguraObjetivo: em 24 hAlterar a palavra-passe pode não revogar o acesso API. Utilize o canal oficial do corretor a partir de um dispositivo de confiança.
Resposta do trader a incidentes: quatro fases nas primeiras 24 horas após o comprometimento das credenciais, do pedido imediato de bloqueio dos levantamentos às participações formais.
  1. Revogue as sessões além de alterar a palavra-passe. Termine as sessões de todos os dispositivos no portal do corretor e depois altere a palavra-passe. Alterá-la nem sempre encerra as sessões. Se não existir um controlo para o fazer, informe expressamente a linha de apoio do corretor.
  2. Proteja o email. Altere a palavra-passe, termine as sessões e examine as regras de reencaminhamento e os filtros. Uma regra que mova mensagens do corretor para o lixo pode ocultar a tomada de controlo.
  3. Ligue ao corretor para o número guardado previamente, em vez de utilizar um número da mensagem. Peça a suspensão dos levantamentos e a sinalização da suspeita de comprometimento. Pergunte se os contactos ou destinos de levantamento foram alterados nas últimas horas.
  4. Reponha o segundo fator. Revogue a credencial afetada e configure novamente a MFA. Gere novos códigos de recuperação e invalide o conjunto antigo.
  5. Revogue as chaves API e verifique se foram criadas novas chaves. Uma chave autorizada a negociar pode continuar válida após alterar a palavra-passe.
  6. Verifique os dados de levantamento e a lista de destinos autorizados. Comunique uma conta desconhecida como parte do mesmo incidente, não como uma questão administrativa separada.
  7. Documente tudo. Guarde capturas datadas, o email com os cabeçalhos completos, o histórico de acessos e o número de referência da linha de apoio. Estes elementos apoiam uma reclamação ou um posterior litígio com o corretor.
  8. Verifique o dispositivo. Se também suspeitar de malware, por exemplo devido a janelas ou extensões desconhecidas ou lentidão inexplicável, utilize um dispositivo limpo até a situação ser investigada, como explicado na secção 5.
  9. Comunique a ocorrência. Participe um levantamento não autorizado à polícia e ao supervisor do corretor. No exemplo polaco, comunique separadamente o incidente técnico, incluindo phishing, email comprometido ou dispositivo comprometido, ao CERT Polska através de incydent.cert.pl[14]. Este canal técnico não substitui a participação criminal nem a reclamação ao corretor e não determina o reembolso. Fora da Polónia, utilize o canal nacional adequado para comunicar incidentes. O artigo 13.7 explica a distinção entre reclamação e atuação de supervisão, bem como as vias processuais pertinentes.

O que não fazer: não instale software para «verificar o computador» enviado por alguém que ligou sem solicitação prévia, não conceda acesso remoto nem deposite mais dinheiro para «desbloquear um levantamento». Cada pedido indica uma possível segunda fase do mesmo ataque.

Esta lista não protege contra perdas de mercado. Destina-se a reduzir o risco de perder o controlo da conta por razões alheias ao mercado, muitas das quais podem ser tratadas com uma configuração cuidada.

Revisão trimestral. Reveja todos os pontos de três em três meses. As permissões de acesso e a configuração do VPS podem mudar, e é necessário instalar correções de segurança. Não substitua palavras-passe fortes e únicas apenas porque passou tempo; altere-as após um comprometimento ou uma suspeita fundamentada. Marque no calendário uma revisão periódica da segurança da negociação e trate-a como manutenção obrigatória.

Perguntas frequentes: cibersegurança do trader de forex

A 2FA por SMS basta para proteger uma conta de corretagem?
A 2FA por SMS é melhor do que não ter 2FA, mas mais fraca do que TOTP ou uma chave de segurança física. O SIM swapping transfere o número através do operador móvel; o tempo e o custo dependem do país e da informação disponível sobre a vítima. Depois de tomar o número, o atacante recebe os códigos SMS. O mínimo recomendado é um gerador TOTP offline, como o Google Authenticator sem sincronização na nuvem, ou uma chave física como a YubiKey. As cópias das sementes na nuvem acrescentam um ponto de falha em troca de conveniência. Para uma conta de negociação, prefira uma configuração essencialmente offline e códigos de recuperação guardados fisicamente. Se o corretor oferecer apenas SMS sem TOTP, considere isso uma limitação significativa da sua infraestrutura de segurança.
O que fazer se perder o telemóvel com a aplicação de 2FA?
Utilize os códigos de recuperação guardados na configuração, se o corretor os tiver emitido. Guarde-os impressos e fisicamente protegidos, não no telemóvel. Sem códigos, contacte o corretor para seguir o seu procedimento de verificação de identidade e reposição da 2FA, que pode incluir documento de identificação, verificação por vídeo ou outros controlos. Perder o acesso durante a volatilidade é um risco financeiro. Uma solução prática consiste em códigos impressos num cofre e um smartphone antigo com as sementes TOTP, guardado em segurança, com Wi-Fi desligado e sem SIM. Pode servir de reserva a traders ativos que não podem perder o acesso durante a volatilidade.
Devo utilizar uma VPN para negociar?
Uma VPN é uma camada adicional, também no Wi-Fi público, não um pré-requisito. As bases continuam a ser HTTPS válido sem avisos de certificado, o domínio correto introduzido manualmente, dispositivos atualizados e MFA resistente ao phishing. A FTC refere que a encriptação generalizada costuma tornar seguro o Wi-Fi público[13]. Considere uma VPN ou a partilha de ligação do telemóvel se desconfiar da rede ou quiser reduzir a exposição do tráfego auxiliar. Em casa, avalie o modelo de ameaça e a configuração do router: firmware desatualizado ou credenciais predefinidas inseguras podem criar exposição. Para uso regular de VPN, considere um ponto de saída estável: mudanças frequentes de IP e países invulgares podem desencadear verificações do corretor, consoante os controlos da entidade. Avalie o modelo de financiamento, a política de registos e as auditorias independentes de uma VPN gratuita, não apenas o preço; alguns planos gratuitos dependem de subscrições pagas e outros monetizam o tráfego dos utilizadores.
Como proteger o MT4/MT5 no telemóvel?
Ative o bloqueio do ecrã com PIN, impressão digital ou Face ID. Evite guardar credenciais desnecessárias no MT4/MT5; introduza a palavra-passe manualmente ou pelo preenchimento automático de um gestor. Mantenha a aplicação atualizada. Não inicie sessão em telemóveis de terceiros. Desative a pré-visualização de notificações no ecrã bloqueado para que outras pessoas não vejam códigos de 2FA nem alertas do corretor. Se perder o telemóvel, utilize outro dispositivo de confiança para alterar prontamente a palavra-passe do corretor.
O que fazer se suspeitar de acesso não autorizado à conta?
Imediatamente: (1) utilize um dispositivo de confiança para revogar as sessões do corretor e depois altere a palavra-passe; (2) faça o mesmo na conta de email associada, a camada a montante; (3) ligue para a linha oficial do corretor, em vez de confiar num email potencialmente comprometido, e peça um bloqueio temporário; (4) reveja o histórico de acessos à procura de IP, dispositivos ou locais desconhecidos; (5) verifique os pedidos de levantamento e peça ao corretor que cancele os não autorizados; (6) ative ou reponha a 2FA. Guarde capturas, datas e horas. Participe um levantamento não autorizado à polícia e ao supervisor do corretor; na Polónia, comunique separadamente o incidente técnico ao CERT Polska em incydent.cert.pl, utilizando noutros países o canal nacional competente. A secção 7 apresenta a resposta mais completa a uma página de phishing na qual aprovou pessoalmente a MFA.
Um EA pode roubar as minhas credenciais?
Um EA malicioso pode negociar na sua conta: pode instalá-lo após uma afirmação no Telegram de que «ganha 300 pips por semana». Distinga dois níveis de permissões. Código MQL normal não tem acesso irrestrito ao sistema: a MetaQuotes documenta uma sandbox de ficheiros, e WebRequest exige que o servidor de destino seja adicionado à lista de URL permitidos do terminal[12]. Permitir importações DLL concede uma permissão separada que coloca código externo fora dessas restrições, como explicado na secção 6. Não ative importações DLL para um EA de origem desconhecida. Pedir para desativar o antivírus «para funcionar» é um sinal grave de malware. Utilize o MQL5 Market ou programadores com reputação verificada, reconhecendo que um canal de distribuição não garante rentabilidade nem segurança completa.

Fontes

  1. OWASP Foundation, «Credential Stuffing Prevention Cheat Sheet», cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html: define o teste de pares de nome de utilizador/palavra-passe provenientes da violação de outro serviço e descreve controlos do serviço, incluindo MFA, restrições de IP e deteção de dispositivos ou endereços desconhecidos. Não mede a proporção de tomadas de controlo de contas de corretagem atribuível a este vetor; não lhe é atribuída aqui tal estatística. Consultado em 31 de agosto de 2026.
  2. National Institute of Standards and Technology (NIST), «Digital Identity Guidelines — SP 800-63B-4», pages.nist.gov/800-63-4/sp800-63b/authenticators/: secção 3.1.1.2: pelo menos 15 caracteres quando a palavra-passe é o único fator, ou 8 no âmbito de MFA; secção 3.1.3.3: a autenticação pela rede telefónica pública, incluindo SMS, é restrita, sendo exigida uma alternativa; a secção 3.1.7 abrange autenticadores criptográficos multifator. A edição SP 800-63B de 2 de março de 2020 anteriormente citada aqui foi substituída pela SP 800-63B-4, finalizada em 31 de julho de 2025, cuja numeração de secções se aplica acima. Não abrevie este identificador para «SP 800-63-4»: esse documento geral separado substituiu a SP 800-63-3, e não a SP 800-63B. Estado do documento verificado em csrc.nist.gov/pubs/sp/800/63/b/4/final. Consultado em 1 de setembro de 2026.
  3. Financial Conduct Authority, «PS26/2: Operational incident and third party reporting», fca.org.uk/publications/policy-statements/ps26-2-operational-incident-third-party-reporting: declaração de política publicada em 18 de março de 2026: definição de incidente operacional, limiares de comunicação e processo normalizado; separadamente, comunicação de acordos relevantes com terceiros e registo anual. Está prevista a aplicação das regras resultantes a partir de 18 de março de 2027. Substitui a referência desatualizada do artigo anterior a meros «requisitos anunciados de comunicação de incidentes». Consultado em 31 de agosto de 2026.
  4. 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: adotado em 15 de novembro de 2023 e publicado em 16 de novembro de 2023. As cerca de 300 queixas em 2020, 400 em 2021 e 500 em 2022 relativas a SIM swapping e portabilidade fraudulenta provêm da nota 13 e dos registos do Consumer Complaint Center da Comissão. Consultado em 31 de agosto de 2026 (98 páginas; texto extraído localmente na auditoria polaca original).
  5. 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/: publicado em 22 de janeiro de 2024; material atualizado, com 15 de junho de 2026 registado como última atualização na auditoria polaca das fontes. A coleção de 12 TB continha mais de 26 mil milhões de registos em cerca de 3.800 diretórios, descrita como provavelmente a maior compilação de múltiplas violações (COMB), com duplicados muito prováveis. Trata-se de informação secundária sobre as violações subjacentes e assim é tratada: sustenta a descrição da compilação, não conclusões sobre cada violação que a integra. Consultado em 31 de agosto de 2026.
  6. National Cyber Security Centre (NCSC UK), «Phishing attacks: defending your organisation», ncsc.gov.uk/guidance/phishing: controlos DMARC, SPF e DKIM contra falsificação do remetente, uma política de quarentena ou rejeição e uma via simples para comunicar prontamente mensagens suspeitas. A auditoria original verificou separadamente o seu âmbito: não aborda domínios de aspeto semelhante, pelo que esse tema não lhe é atribuído. Consultado em 31 de agosto de 2026.
  7. National Cyber Security Centre (NCSC UK), «Recommended types of MFA», em «Multi-factor authentication for your corporate online services», ncsc.gov.uk/collection/mfa-for-your-corporate-online-services/recommended-types-of-mfa: ordem de preferência: 1) credenciais FIDO2, 2) aplicações baseadas em desafios, 3) geradores de códigos em aplicações (TOTP), 4) geradores físicos de códigos, 5) códigos enviados por mensagem. Consultado em 31 de agosto de 2026.
  8. MetaQuotes, «The checks a trading robot must pass before publication in the Market», mql5.com/en/articles/2555, 1 de agosto de 2016: verificações obrigatórias antes da publicação no MQL5 Market e proibição de importações de DLL e de ficheiros EX4/EX5 compilados nos produtos do Market. Consultado em 31 de agosto de 2026.
  9. LastPass, «Notice of Security Incident», blog.lastpass.com/posts/notice-of-recent-security-incident: aviso de 22 de dezembro de 2022 que confirma a cópia de cópias de segurança de dados dos clientes, incluindo cofres de palavras-passe. Os campos sensíveis, como nomes de utilizador, palavras-passe e notas, estavam encriptados; alguns metadados, incluindo URL de sítios, não estavam. Consultado em 31 de agosto de 2026; o aviso histórico original foi verificado novamente em 9 de outubro de 2026.
  10. Banco Nacional Suíço, «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 de janeiro de 2015: fonte da decisão e da respetiva data. A página não especifica a hora de publicação; o comunicado completo está disponível em PDF para descarregar. Consultado em 31 de agosto de 2026.
  11. Regulamento (UE) 2022/2554 do Parlamento Europeu e do Conselho, de 14 de dezembro de 2022, relativo à resiliência operacional digital do setor financeiro (DORA), CELEX 32022R2554, JO UE L 333, 27.12.2022: gestão do risco de TIC e comunicação de incidentes graves relacionados com TIC pelas entidades financeiras abrangidas. O artigo 2(1) está sujeito aos números 3 e 4 e inclui «empresas de investimento» na alínea (e); o artigo 2(3)(d) isenta pessoas abrangidas pelas isenções dos artigos 2 e 3 da Diretiva 2014/65/UE. O texto polaco utilizado na auditoria original foi obtido através de publications.europa.eu/resource/celex/32022R2554; o cabeçalho identifica «27.12.2022 PL Official Journal of the European Union L 333/1». As disposições finais fixam expressamente a aplicação a partir de 17 de janeiro de 2025 e a entrada em vigor no vigésimo dia após a publicação no Jornal Oficial. A publicação em 27 de dezembro de 2022 resulta, portanto, em 16 de janeiro de 2023; o ato não indica numericamente esta última data. Consultado em 1 de setembro de 2026.
  12. MetaQuotes, documentação de referência MQL5, «FileOpen» (mql5.com/en/docs/files/fileopen) e «WebRequest» (mql5.com/en/docs/network/webrequest): as operações de ficheiros estão restritas à sandbox de ficheiros e WebRequest exige inserir o URL do servidor na lista de URL permitidos em «Expert Advisors», dentro de «Options». A documentação afirma: «Os ficheiros sobre os quais são realizadas operações através de MQL5 não podem estar fora da sandbox de ficheiros». Consultado em 31 de agosto de 2026. O contexto de execução de DLL foi adicionalmente verificado em «About Dynamic-Link Libraries» da Microsoft, learn.microsoft.com/en-us/windows/win32/dlls/about-dynamic-link-libraries, em 9 de outubro de 2026.
  13. 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, fevereiro de 2023: a encriptação generalizada costuma tornar seguras as ligações Wi-Fi públicas, mas os burlões também podem encriptar sítios falsos. A encriptação, por si só, não demonstra quem recebe a informação. Consultado em 31 de agosto de 2026.
  14. Exemplo prático polaco: o CERT Polska funciona no NASK, o instituto nacional de investigação, e desempenha funções de CSIRT NASK como uma das três equipas polacas de resposta a nível nacional (cert.pl/o-nas). O formulário de incidentes está em incydent.cert.pl, com o título «Zgłoś incydent | CERT.PL». É citado exclusivamente como canal de comunicação de incidentes técnicos: esta fonte não estabelece um processo de reclamação financeira nem uma decisão de reembolso. Fora da Polónia, utilize o canal nacional pertinente. Consultado em 1 de setembro de 2026.

O seu progresso de aprendizagem

Terminou esta lição? Marque-a você. Abrir ou deslocar uma página nunca a marca como concluída.

O progresso requer JavaScript e armazenamento do navegador.

Guardado apenas neste navegador. Sem conta nem sincronização entre dispositivos. Limpar os dados do site pode apagar o seu progresso.

Jarosław Wasiński

Editor-chefe, ForexMechanics.com • Analista macro e FX

Analista independente e profissional com mais de 20 anos de experiência nos mercados financeiros. Atua no Forex desde 2007, com foco em análise fundamentalista, estrutura do mercado OTC e gestão disciplinada do risco de capital.

  • Criador e editor-chefe do MyBank.pl, oferecendo educação financeira confiável desde 2004.
  • Autor de centenas de comentários de mercado aprofundados, análises estruturais e materiais educacionais para traders e investidores.
  • Defensor da transparência do mercado, promovendo uma educação baseada em dados concretos e relatórios institucionais (BIS, ESMA, CFTC).

Todo o conteúdo tem caráter exclusivamente educacional e informativo – não constitui recomendação de investimento. Lembre-se: operar com alavancagem (Forex/CFD) envolve alto risco de perda rápida de capital.