Beranda/Regulasi & keamanan/Cybersecurity

Keamanan siber trader — 2FA, phishing, penarikan dan perlindungan perangkat

Oleh Jarosław Wasiński (EN) • Diterbitkan: • Diperbarui: • sekitar 35 menit

Keamanan akun trading dimulai dari akun email, kata sandi unik dan metode autentikasi yang sesuai. Perangkat, sesi login, aturan penarikan dan pengaturan pemulihan jika ponsel hilang juga penting. Artikel ini memandu Anda langkah demi langkah melalui perlindungan tersebut, menjelaskan keterbatasannya dan menunjukkan cara merespons dugaan pengambilalihan akun. Pengguna VPS dan robot trading juga akan menemukan panduan untuk melindungi akses jarak jauh, kunci API dan posisi terbuka. Penipuan yang menyamar sebagai perusahaan kami bahas secara terpisah dalam artikel tentang broker palsu.

Email, autentikasi, perangkat, dan pemulihan bersama-sama membentuk sistem keamanan. Tidak ada satu lapisan yang menghapus semua ancaman.
Buka gambar dalam ukuran penuh
Poin utama dalam 60 detik
  • Akun email Anda adalah lapisan 1, bukan tambahan opsional. Penyusupan email dapat memungkinkan orang lain mengatur ulang kata sandi broker dan mencegat konfirmasi perubahan, bergantung pada kontrol pemulihan broker. Tetapkan kata sandi email unik dan aktifkan MFA sebelum mengonfigurasi lapisan lainnya.
  • Satu kata sandi yang digunakan ulang dapat cukup untuk mengambil alih akun, terutama jika tidak ada MFA yang efektif. Credential stuffing, yaitu pengujian otomatis pasangan nama pengguna/kata sandi dari kebocoran lain, menyasar setiap kata sandi yang pernah terungkap dan digunakan ulang. Kata sandi unik ditambah 2FA, sebaiknya TOTP daripada SMS, adalah minimum operasional.
  • 2FA SMS lebih baik daripada tanpa 2FA, tetapi lebih lemah daripada TOTP atau kunci keamanan perangkat keras. SIM swapping dapat berlangsung cepat dan murah; waktu, biaya dan tingkat keberhasilannya bergantung pada operator seluler dan negara. TOTP di aplikasi tanpa cadangan seed di awan, atau kunci keamanan perangkat keras seperti YubiKey, adalah standar praktis.
  • Phishing FX dapat menyasar individu tertentu. Email palsu dari “broker”, telepon dari “departemen keamanan” dan tautan ke halaman login MT4 tiruan dapat disesuaikan untuk trader, bukan dikirim sepenuhnya secara acak.
  • Masukkan tujuan penarikan ke daftar yang diizinkan setelah mengamankan email. Jika broker menawarkan daftar rekening bank yang diizinkan, aktifkan: penyerang harus mengubah detail dan lolos verifikasi tambahan. Namun, verifikasi itu sering menggunakan email, sehingga perlindungannya terbatas bila lapisan 1 disusupi.
  • Memakai satu perangkat untuk semua hal memperluas permukaan serangan. Perangkat atau profil pengguna terpisah untuk trading adalah soal disiplin, bukan tindakan pencegahan berlebihan.

1. Penggunaan ulang kata sandi — ketika satu kebocoran mengancam akun trading

Mulailah dengan skenario yang sangat biasa, dan justru kebiasaannya itulah yang membuatnya berbahaya. Tidak ada peretas bertudung ataupun pembobolan enkripsi. Ini adalah credential stuffing: pengujian otomatis di berbagai layanan terhadap pasangan nama pengguna/kata sandi yang diperoleh dari kebocoran basis data[1].

Mekanismenya sederhana. Pada 22 Januari 2024, tim riset Cybernews menjelaskan kumpulan data yang dapat diakses publik, berisi lebih dari 26 miliar catatan dan 12 terabita data, yang dijuluki “Mother of All Breaches”[5]. Status dan sifatnya perlu dinyatakan secara tepat karena keduanya mengubah makna angka tersebut: ini bukan satu kebocoran baru, melainkan kompilasi catatan dari ribuan kebocoran terdahulu dan basis data yang diperdagangkan secara privat. Laporan itu sendiri menyebut duplikasi sangat mungkin terjadi dan memperlakukan keberadaan informasi yang belum pernah dipublikasikan sebagai probabilitas, bukan temuan yang telah dipastikan. Uraiannya tentang keterbukaan data berikutnya juga merupakan pernyataan suatu organisasi, bukan kesimpulan yang dibuktikan secara independen: layanan pencarian kebocoran Leak-Lookup mengaku memiliki kumpulan tersebut dan menyatakan keterbukaannya disebabkan kesalahan konfigurasi firewall yang telah diperbaikinya[5]. Kami tidak memiliki konfirmasi independen bahwa salinannya berhenti beredar. Bagi trader, kesimpulan praktisnya tidak bergantung pada ketidakpastian itu: jika kata sandi dipakai ulang untuk forum trading, Gmail dan akun broker, salah satu dari ribuan kumpulan tersebut dapat memberi penyerang kredensial ketiganya.

Penjejalan kredensial: risiko penggunaan ulang kata sandi
Penjejalan kredensial: risiko penggunaan ulang kata sandi. Kebocoran di satu layanan tidak membuktikan semua akun diretas. Diagram edukasi; syarat terperinci dan sumber dijelaskan dalam artikel.
Buka diagram dalam ukuran penuh
Skenario ilustratif: credential stuffing setelah kebocoran forum. Pola yang berulang adalah setelah basis data forum trading atau kripto bocor, penyerang menguji pasangan nama pengguna/kata sandi yang sama pada akun broker. Trader yang memakai ulang kata sandi dapat kehilangan akses dalam hitungan jam. Dalam skenario ini, penyerang dapat mengubah detail kontak dan mengajukan penarikan sebelum broker memblokir akun. TOTP sangat mempersulit pengambilalihan: akun yang menggunakannya lebih sedikit terpapar vektor serangan khusus ini.

Rantai serangan yang mungkin terjadi: email disusupi → kata sandi broker diatur ulang → detail kontak diubah → permintaan penarikan ke rekening penyerang. Jeda dari penyusupan email hingga pengajuan penarikan dapat singkat, tetapi kami tidak memberi durasi tertentu: hal itu bergantung pada prosedur perubahan detail broker dan saluran pembayaran, dan kami tidak menemukan pengukuran yang mendukung angka presisi. Broker mengirim konfirmasi penarikan melalui email, tetapi penyerang sudah mengendalikan akun email itu.

Model berlapis — tentukan apa yang Anda lindungi

Sebelum mengonfigurasi apa pun, tetapkan model ancaman: apa yang Anda lindungi, dari siapa, dan apa yang terjadi jika suatu lapisan gagal. Tanpanya, Anda bisa membeli kunci perangkat keras untuk akun yang pemulihan kata sandinya masih bergantung pada akun Gmail lama.

Untuk akun trading, rantai ketergantungannya memiliki tujuh mata rantai. Kerjakan dengan urutan ini:

  1. Email — akun hulu. Penyusupannya mengancam pemulihan akun lain.
  2. Identitas — nomor telepon, kode pemulihan dan dokumen yang membuktikan identitas Anda kepada broker.
  3. Perangkat — komputer dan ponsel tempat Anda memasukkan rahasia dan menerima kode.
  4. Broker — kata sandi, MFA, sesi aktif dan pengaturan portal klien.
  5. API — kunci programatik yang dapat mengautentikasi akses secara independen dari kata sandi dan MFA portal klien.
  6. Pembayaran — metode setoran dan penarikan serta daftar rekening tujuan yang diizinkan.
  7. Pemulihan — saluran untuk memulihkan akses, sering menjadi jalur alternatif pilihan penyerang.

Aturan praktisnya adalah suatu lapisan bergantung pada lapisan yang menopangnya. Daftar penarikan yang diizinkan tidak dapat diandalkan jika penyerang mengendalikan akun email penerima konfirmasi perubahan tujuan. Itulah sebabnya artikel ini mengikuti urutan yang disengaja: bagian 1 dan 2 membahas email, identitas dan broker; bagian 5 dan 6 membahas perangkat dan API; dan bagian 4 membahas pembayaran. Pemulihan muncul di sepanjang artikel karena menyediakan jalur alternatif ke lapisan lain.

Tanggung jawab broker — DORA sebagai konteks, bukan perisai. Sejak 17 Januari 2025, entitas keuangan UE yang tercakup telah menerapkan Peraturan (UE) 2022/2554 tanggal 14 Desember 2022 tentang ketahanan operasional digital sektor keuangan, yang dikenal sebagai DORA (OJ EU L 333, 27.12.2022; mulai berlaku 16 Januari 2023)[11]. Cakupannya meliputi perusahaan investasi menurut Pasal 2(1)(e). Peraturan ini menetapkan kewajiban pengelolaan risiko TIK dan persyaratan pelaporan insiden besar terkait TIK kepada otoritas pengawas, dengan pengecualian Pasal 2(3), termasuk orang yang dikecualikan menurut Pasal 2 dan 3 Direktif 2014/65/UE. Kata “broker” saja tidak membuktikan apa pun: cakupannya bergantung pada entitas hukum dan status penyedia, bukan mereknya. Inggris memiliki rezim FCA tersendiri yang sedang berubah. Pada 18 Maret 2026, FCA menerbitkan pernyataan kebijakan PS26/2 tentang pelaporan insiden operasional dan pengaturan pelaporan dengan penyedia pihak ketiga material; aturan yang dihasilkan dijadwalkan berlaku pada 18 Maret 2027[3]. Hal ini tidak boleh berarti DORA menjamin broker bebas insiden atau memindahkan tanggung jawab atas kata sandi atau perangkat Anda kepada perusahaan. DORA memberi kerangka untuk menanyakan setelah insiden tentang kontrol yang telah diterapkan broker untuk login, perubahan detail dan penarikan.
MFA melindungi login, tetapi belum tentu menghentikan malware. 2FA melindungi tahap login, tetapi mungkin tidak mencegah malware mencuri token sesi atau cookie setelah autentikasi. Pada perangkat terinfeksi, penyerang dapat menangkap sesi valid tanpa mengetahui kata sandi atau kode 2FA. Karena itu, keamanan perangkat dan browser sama pentingnya dengan kata sandi kuat.

Tindakan praktis

Gunakan kata sandi broker yang unik. Jangan gunakan ulang di tempat lain. Gunakan pengelola kata sandi seperti Bitwarden, 1Password atau KeePass. Buat kata sandi acak minimal 16 karakter, memberi margin di atas ambang 15 karakter dalam panduan NIST terkini untuk kata sandi yang menjadi satu-satunya faktor autentikasi[2]. Hindari merancang kata sandi sendiri: manusia buruk dalam menghasilkan keacakan.

Gunakan alamat email terpisah untuk trading. Buat akun khusus untuk komunikasi dengan broker dan platform trading. Jangan gunakan untuk mendaftar forum, media sosial atau layanan lain. Jika alamat email utama bocor, alamat yang terkait dengan akun trading tidak akan terungkap melalui catatan pendaftaran yang sama. Ini mengurangi risiko, meskipun tidak mengamankan akun dengan sendirinya.

Periksa apakah informasi Anda telah terungkap. Masukkan alamat email di haveibeenpwned.com dan periksa data apa yang terungkap. Segera ganti kata sandi jika bocor, digunakan ulang atau ada alasan mencurigai penyusupan. Munculnya alamat email dalam kebocoran layanan lain tidak dengan sendirinya membuktikan bahwa kata sandi broker lain yang unik telah disusupi.

Pengelola kata sandi adalah kebutuhan operasional. Tanpanya, alternatif yang lazim adalah kata sandi sederhana yang dapat diingat, tetapi lebih mudah dibobol, atau penggunaan ulang lintas layanan yang membuat Anda rentan credential stuffing. Dalam praktiknya, menghafal lebih dari tiga puluh kata sandi acak yang unik bukan alternatif realistis.

2. 2FA — kebutuhan minimum, bukan pilihan

Autentikasi dua faktor (2FA) menambahkan lapisan kedua setelah kata sandi. Jika diterapkan dengan benar, 2FA mempersulit login memakai kata sandi curian, tetapi phishing dapat mencegat kode, sedangkan pemulihan akun atau pencurian sesi dapat melewati layar login normal. Masalahnya, metode 2FA tidak setara. SMS dan TOTP memiliki kelemahan yang berbeda secara material, sebagaimana jenis kunci berbeda menawarkan perlindungan berbeda.

Metode 2FA Cara kerja Keamanan Kelemahan utama
SMS Kode sekali pakai yang dikirim ke nomor telepon Anda Rendah SIM swapping: penyerang menguasai nomor melalui operator seluler
Email Kode yang dikirim ke alamat email Anda Paling rendah Jika akun email disusupi, 2FA email tidak lagi memberi perlindungan independen
TOTP (aplikasi autentikator) Kode yang dibuat secara lokal setiap 30 detik (Google Authenticator, Authy); utamakan pengaturan tanpa cadangan seed di awan Tinggi Kode sekali pakai dapat dicegat halaman phishing; secara terpisah, kehilangan ponsel tanpa kode pemulihan dapat membuat Anda kehilangan akses
Kunci keamanan perangkat keras Perangkat USB fisik (YubiKey, Titan Key) Paling tinggi Dalam contoh biaya Polandia, beberapa ratus PLN bergantung pada model dan penjual; dukungan broker terbatas
Metode MFA menahan serangan berbeda
Metode MFA menahan serangan berbeda. Perbandingan mekanisme, bukan janji keamanan penuh. Diagram edukasi; syarat terperinci dan sumber dijelaskan dalam artikel.
Buka diagram dalam ukuran penuh

Mengapa 2FA SMS tidak cukup

2FA SMS lebih baik daripada tanpa 2FA, tetapi lebih lemah daripada TOTP atau kunci keamanan perangkat keras. Dalam SIM swap, penipu menghubungi operator seluler, menyamar sebagai pemilik nomor dan meminta pemindahan nomor ke SIM pengganti. Serangan ini dapat cepat dan murah, tetapi waktu, biaya dan tingkat keberhasilannya bergantung pada operator, negara dan kualitas informasi korban. Setiap operator menetapkan prosedur verifikasi sendiri untuk penggantian, dan informasi yang dipakai dapat tersedia dalam kebocoran. Skalanya didokumentasikan di AS: FCC melaporkan sekitar 300 pengaduan SIM swap dan pemindahan nomor melalui Consumer Complaint Center pada 2020, 400 pada 2021 dan 500 pada 2022[4].

TOTP — standar praktis

TOTP (Time-based One-Time Password) menghasilkan kode secara lokal di perangkat setiap 30 detik. Metode ini tidak memakai jaringan seluler, sehingga SIM swapping tidak mencegat kodenya, dan pembuatan kode tidak memerlukan internet. Urutan preferensi NCSC Inggris menempatkan kode yang dibuat aplikasi jauh di atas kode yang dikirim melalui pesan[7], tetapi bukan metode peringkat teratasnya. Subbagian passkey menjelaskan metode yang lebih tinggi.

Untuk mengonfigurasi TOTP, unduh aplikasi autentikator dan pilih operasi tanpa akun atau nonaktifkan sinkronisasi awan. Google Authenticator menyinkronkan kode dengan akun Google jika Anda masuk dan juga menawarkan penggunaan tanpa akun; Authy menawarkan cadangan awan. Ini memudahkan, tetapi insiden LastPass Desember 2022 yang terkonfirmasi, dijelaskan di bawah, menunjukkan titik kegagalan tambahan akibat penyimpanan materi autentikasi di awan. Utamakan generator luring dengan cadangan fisik kode pemulihan. Di pengaturan akun broker, cari “Keamanan” → “Autentikasi Dua Faktor” dan pindai kode QR dengan aplikasi. Login kemudian memerlukan kata sandi dan kode 6 digit aplikasi.

Langkah penting: simpan kode pemulihan. Jika broker menerbitkan kode cadangan sekali pakai untuk kehilangan ponsel, simpan saat pengaturan. Jika tidak, periksa prosedur pemulihan resmi yang didokumentasikan dan catat sebelum dibutuhkan. Cetak kode pemulihan dan simpan dengan aman, terpisah dari ponsel, akun awan dan pengelola kata sandi: hilangnya akses ke pengelola tidak boleh sekaligus menghilangkan kode. Kertas fisik dalam brankas atau laci terkunci adalah salah satu opsi.

Contoh industri: insiden LastPass, Desember 2022. Pada Desember 2022, LastPass mengonfirmasi bahwa suatu insiden menyebabkan penyalinan cadangan data pelanggan, termasuk brankas kata sandi terenkripsi[9]. Statusnya adalah insiden yang dikonfirmasi perusahaan dalam pemberitahuan Desember 2022. Kami tidak menentukan dampaknya bagi pelanggan individual karena tidak memiliki sumber yang mendukung kesimpulan itu. Poin praktisnya terlepas dari dampak tersebut: menyimpan kata sandi dan kode pemulihan TOTP dalam satu pengelola awan menempatkan kedua komponen autentikasi di lokasi yang sama. Satu basis data menjadi satu titik kegagalan potensial. Simpan kode pemulihan secara luring dan tercetak, bukan sekadar di pengelola kata sandi awan lain.
Lapisan MFA: ketahanan terhadap ancaman tertentuMetode lebih kuat tidak menggantikan perlindungan sesi, perangkat, dan pemulihanLapisan MFA: ketahanan terhadap ancaman tertentuMetode lebih kuat tidak menggantikan perlindungan sesi, perangkat, dan pemulihanEmailBergantung keamanan kotak masuk dan proses pemulihannya.SMSKode dapat dicegat melalui pengambilalihan SIM atau phishing.TOTPTidak bergantung SIM; kode tetap rentan phishingdan penerusan kode.FIDO2 / kunci aksesPengikatan asal tahan phishing. Periksa sinkronisasi danpemulihan.Kunci akses terikat perangkat dan tersinkronisasi berbeda; tidak setiap implementasi memenuhi AAL3.
Buka diagram dalam ukuran penuh

Passkey dan FIDO2 — arah perkembangan

Kunci perangkat keras dalam tabel adalah implementasi fisik standar yang lebih luas: FIDO2/WebAuthn. Alih-alih kode yang dapat didiktekan kepada orang lain atau disalin ke halaman palsu, browser dan autentikator bertukar tanda tangan kriptografis yang terikat pada domain yang sesuai. Domain berbeda tidak dapat memperoleh autentikasi untuk kredensial terdaftar itu. Ikatan domain itulah perbedaan mendasar dari TOTP.

Sebuah passkey menggunakan mekanisme ini dengan kredensial FIDO2 yang disimpan di ponsel, komputer atau pengelola kata sandi dan dibuka dengan sidik jari atau PIN perangkat, sehingga kunci terpisah mungkin tidak diperlukan. NCSC menempatkan kredensial FIDO2 di peringkat pertama untuk ketahanan terhadap tebakan, phishing dan pencurian rahasia autentikasi. Kode buatan aplikasi berada di peringkat ketiga; dokumen itu secara eksplisit mengidentifikasi kerentanannya terhadap pencegatan[7]. NIST mengizinkan autentikator kriptografis multifaktor pada tingkat jaminan tertingginya jika persyaratan tingkat tersebut dipenuhi; passkey tersinkronisasi tidak otomatis menjadi kredensial AAL3. Autentikasi jaringan telepon, termasuk SMS, berstatus dibatasi[2].

Apa yang perlu dilakukan hari ini. Dukungan passkey pada broker ritel bervariasi: sebagian portal klien hanya menawarkan TOTP dan SMS. Periksa pengaturan keamanan untuk “security key”, “passkey” atau “WebAuthn”. Jika didukung, aktifkan sebagai metode utama dan pertahankan TOTP sebagai cadangan. Jika tidak tersedia, TOTP dengan kode pemulihan luring tetap menjadi minimum yang wajar. Aktifkan passkey pada akun email secara terpisah dari broker karena email adalah lapisan 1 dalam model di atas.

3. Phishing — email, telepon dan rekayasa sosial dalam FX

Phishing forex dapat tertarget: penyerang tahu trader menyimpan dana dalam akun dan merespons “margin call” dan “peringatan keamanan”. Bisa pula berupa spam biasa dengan logo broker dan domain yang didaftarkan murah. Serangan tidak perlu canggih untuk berhasil.

Email palsu dari “broker”

Ini vektor serangan yang murah sehingga umum. Email meniru warna, logo dan bagian bawah pesan broker. Subjeknya bisa “Mendesak: Verifikasi Akun Anda”, “Peringatan Keamanan: Login Tidak Biasa Terdeteksi” atau “Tindakan Diperlukan: Perbarui Metode Pembayaran Anda”. Tautan membuka halaman login tiruan di domain berbeda. Memasukkan kredensial memberikannya kepada penyerang. Panduan organisasi NCSC mencakup dua unsur: penyamaran pengirim, yang ditangani kontrol antispofing DMARC, SPF dan DKIM, serta perlunya cara sederhana dan cepat untuk melaporkan pesan mencurigakan[6]. Dokumen itu tidak membahas domain mirip; penjelasan di bawah adalah penjelasan kami, bukan klaim yang diatribusikan kepada NCSC.

Contoh email phishing: urgensi, domain berbeda dari portal tersimpan, dan pemeriksaan tujuan tautan.
Dalam contoh ini, portal.broker.example dan broker-login.example adalah domain berbeda. Buka portal yang dikenal secara independen; bahasa yang fasih dan enkripsi tidak membuktikan keaslian.
Buka gambar dalam ukuran penuh
Skenario ilustratif: kampanye phishing yang menyamar sebagai broker. Tahap pertama yang berulang, penyamaran pengirim, dibahas dalam panduan phishing[6]: klien menerima sesuatu yang tampak seperti “pembaruan keamanan mendesak” resmi. Sisa skenario ini adalah ilustrasi kami. Tautan membuka domain mirip, seperti brokername-security[.]com bukan brokername.com. Halaman menyalin portal login klien, termasuk sertifikat SSL valid, sehingga gembok browser tidak membuktikan keaslian. Alamat email sering berasal dari kebocoran layanan eksternal, bukan broker, sehingga nonklien dapat menerima pesan yang sama. Kami tidak menyebut perusahaan tertentu atau ukuran kampanye: ini model, bukan laporan satu peristiwa terdokumentasi.
Untuk pengguna mahir: log Certificate Transparency. Gembok browser tidak cukup: portal palsu dalam skenario di atas juga memiliki sertifikat valid. Alat crt.sh memungkinkan pemeriksaan riwayat sertifikat domain. Usia sertifikat saja tidak membuktikan apa pun: layanan sah rutin memperbarui sertifikat, dan domain phishing dapat berumur panjang. Certificate Transparency mencatat penerbitan sertifikat dan memberi sinyal pendukung, seperti sertifikat baru untuk nama yang menyerupai domain broker. Bandingkan sinyal itu dengan domainnya sendiri, entri badan hukum dalam register pengawas dan saluran kontak resminya. Riwayat sertifikat tidak menggantikan pemeriksaan ini dan tidak menentukan apakah situs sah atau menipu.

Telepon dari “departemen keamanan”

Metode lebih rumit adalah vishing, atau phishing suara. Seseorang menelepon mengaku bekerja di departemen keamanan broker, menyatakan ada aktivitas akun mencurigakan dan meminta verifikasi identitas: “Berikan nomor akun dan kode 2FA yang baru kami kirim.” Memberikan kode itu dapat mengizinkan login penyerang.

Broker yang beroperasi dengan semestinya tidak seharusnya meminta kode login 2FA melalui telepon. Penelepon yang memintanya mungkin sedang menyusupi akun, bukan melindunginya. Tutup telepon dan hubungi nomor resmi broker dari situs webnya, bukan email. Tekanan agar bertindak cepat dapat lebih efektif daripada malware.

Tautan unduhan MT4/MT5 palsu

Trader mencari “MT4 download” atau “MT5 download” di Google. Penyerang dapat membeli iklan yang menuju pemasang platform modifikasi: tampilannya familier dan mungkin berfungsi normal sambil mengirim kredensial ke server penyerang. Halaman unduhan palsu efektif menyebarkan malware karena pengguna menjalankan pemasang dan memberinya izin.

Dari mana seharusnya mengunduh platform trading? Gunakan situs broker terverifikasi, situs resmi produsen platform atau toko aplikasi yang disebut dalam dokumentasi produsen. Hindari tautan email tak diminta, grup Telegram dan hasil pencarian tak terverifikasi. Cara sederhana adalah mengetik sendiri alamat broker dan memakai bagian “Unduhan” atau “Platform”. Di toko aplikasi, periksa penerbitnya, bukan mengandalkan nama dan ikon yang mudah disalin.
Skenario ilustratif: penjualan silang agresif ke entitas offshore. Email dari broker saat ini menawarkan: “Naikkan leverage menjadi 1:500 dan dapatkan bonus!” Satu klik konon memindahkan akun dari yurisdiksi yang diawasi FCAke Seychelles atau Vanuatu. Anda memperoleh leverage, tetapi perlindungan rezim sebelumnya mungkin tidak lagi berlaku. Perlindungan yang berubah persisnya bergantung pada entitas hukum baru, yurisdiksi dan perjanjian. Artikel terpisah membahas batas leverage dan perlindungan saldo negatif dan skema kompensasi; periksa di sana apa yang berlaku bagi entitas baru. Kami juga tidak menganggap pemindahan itu sah: hal tersebut bergantung pada cara klien ditawari dan izin entitas penerima, dan pengawas dapat mempersoalkan pengaturan yang mengarahkan klien ritel ke perusahaan negara ketiga terafiliasi. Mekanisme relevan di sini adalah tekanan memutuskan: penawaran mendesak, satu klik dan persetujuan sebelum verifikasi, sebagaimana rekayasa sosial.

Rekayasa sosial dalam grup trading

Grup trading Telegram, Discord dan Facebook memberi peluang rekayasa sosial. Seseorang yang mengaku administrator mengirim pesan pribadi: “Saya punya penawaran khusus dari broker X, tetapi Anda harus mendaftar lewat tautan saya.” Atau: “Kirim tangkapan layar akun dan saya bantu mengonfigurasi EA Anda.” Tangkapan layar akun dapat mengungkap nomor akun broker, yang mungkin membantu penyerang memanipulasi pemeriksaan identitas telepon yang lemah. Pahami paparan ini sebelum memposting “profit hari ini” ke grup.

4. Penarikan aman — metode, daftar yang diizinkan dan dokumen KYC

Penyerang yang mengambil alih akun dapat menutup posisi dan merusak modal, tetapi pengalihan dana lebih sulit jika daftar tujuan yang diizinkan efektif. Kontrol yang dimaksud adalah dana menuju rekening atas nama Anda yang telah disetujui. Konfigurasi penarikan merupakan masalah keamanan sekaligus kenyamanan.

Daftar rekening bank yang diizinkan

Jika broker menawarkan “Approved Withdrawal Destinations” atau “Withdrawal Whitelist”, periksa aturan pastinya. Fitur ini membatasi penarikan ke rekening bank yang telah disetujui. Penambahan rekening dapat memerlukan verifikasi tambahan dan masa tunggu; broker menentukan ketersediaan serta durasinya. Ini mempersulit pengalihan dana, tetapi tidak menjamin penarikan dihentikan setelah akun diambil alih.

Periksa apakah broker mendukung daftar yang diizinkan dan aktifkan jika tersedia. Cari “withdrawal whitelist”, “approved withdrawal destinations” atau “trusted accounts” dalam portal klien. Periksa perjanjian dan pengaturan keamanan: ketersediaannya berubah dari waktu ke waktu dan dapat berbeda antarbadan hukum dalam satu grup. Anggap ketiadaan fitur sebagai kelemahan saat membandingkan kontrol, bukan bukti pasti ketidakjujuran.

Penarikan: rincian penerima tepercaya dan kontrol perubahan
Penarikan: rincian penerima tepercaya dan kontrol perubahan. Mekanisme ilustratif — ketersediaan dan syarat bergantung broker. Diagram edukasi; syarat terperinci dan sumber dijelaskan dalam artikel.
Buka diagram dalam ukuran penuh

Notifikasi penarikan

Aktifkan notifikasi email dan push untuk setiap permintaan penarikan. Jika ada permintaan yang tidak Anda ajukan, segera telepon broker: email mungkin sudah disusupi. Biasanya ada waktu pemrosesan antara pengajuan dan pelaksanaan oleh broker serta bank, tetapi ketentuan entitas tertentu yang menentukannya. Periksa sebelumnya, bukan saat insiden. Jendela ini sering menjadi kesempatan terbaik menghentikan transfer, meskipun bukan satu-satunya titik intervensi: setelah dikirim, bank atau penyedia pembayaran masih dapat memulai prosedur penarikan kembali, seperti dijelaskan di bawah.

Perubahan detail — titik keamanan kritis

Peristiwa kritis sering berupa perubahan alamat email, nomor telepon, rekening bank atau penerima penarikan, bukan login itu sendiri. Mengganti metode penarikan setiap minggu dapat memicu pemeriksaan kepatuhan manual dan kadang pembatasan sementara tepat saat Anda ingin menarik profit. Tetapkan metode yang sesuai, verifikasi dan gunakan secara konsisten.

Kebijakan sebagian broker: dana kembali melalui rute yang sama dengan setoran. Dalam “same method withdrawal”, setoran Visa dikembalikan ke kartu Visa itu. Ini bukan aturan seluruh pasar: sebagian perusahaan mengembalikan ke sumber dengan pengecualian, yang lain menerapkan urutan metode, dan profit dapat ditangani terpisah. Periksa ketentuan broker untuk cakupan, pengecualian dan urutannya. Jika berlaku, ini satu kontrol penarikan bersama daftar yang diizinkan, penundaan dan tinjauan manual.
Apa yang benar-benar bisa dibatalkan setelah insiden? Hasil penarikan tanpa izin bergantung pada apakah dana telah keluar, metode pembayaran, apakah tujuan masuk daftar yang diizinkan dan apakah broker mendeteksi insiden sebelum penyelesaian. Transfer bank: pemulihan setelah penyelesaian tidak pasti, tetapi masalahnya tidak otomatis tertutup. Bank atau penyedia pembayaran dapat meminta bank penerima mengembalikan transfer, termasuk dalam kasus penipuan. Ini tidak menjamin pengembalian, dan tidak ada satu batas jam universal yang membuat semua transfer tak dapat dibatalkan; poin praktisnya, penundaan mengurangi peluang pemulihan. Transfer kripto: setelah tercatat on-chain, pembayar tidak memiliki mekanisme pembalikan. Kartu: pengaduan atau chargeback bergantung pada jenis transaksi, dasar, jaringan kartu, penerbit dan tenggat; ini bukan mekanisme umum membatalkan penarikan broker. Segera laporkan insiden kepada broker dan bank agar opsi yang tersedia tetap terbuka.

Dokumen KYC — informasi yang dapat membuka akun broker lain

Untuk membuka akun, Anda mengirim salinan KTP atau paspor, bukti alamat dan kadang rekening koran. Bersama-sama, dokumen itu dapat mendukung pembukaan atau pemulihan akun lain. Perlakukan sebagai informasi identitas sensitif, bukan lampiran biasa.

Dalam praktik, unggah dokumen melalui portal klien, bukan email atau aplikasi pesan. Jika ada email meminta dokumen, telepon nomor di situs terverifikasi untuk memastikan permintaannya. Jangan tinggalkan salinan di folder unduhan atau galeri ponsel; jika disimpan, gunakan wadah terenkripsi atau pengelola kata sandi yang mendukung lampiran. Hapus salinan kerja setelah verifikasi, termasuk dari pesan terkirim dan percakapan. Dokumen bocor dapat mendukung percobaan pemulihan akun dengan alasan “Saya lupa kata sandi dan kehilangan 2FA”. Jika tersedia, atur kata sandi kontak telepon sebelumnya. Pertanyaan seperti nama gadis ibu atau sekolah pertama merupakan masalah terpisah: jawabannya dapat direkonstruksi dari kebocoran dan media sosial. Jika broker menggunakannya, perlakukan sebagai pemeriksaan pendukung bersama MFA kuat dan proses pemulihan terverifikasi, bukan penggantinya.

Catat saluran kontak aman sebelum dibutuhkan. Simpan nomor telepon di situs broker, alamat portal klien yang diketik manual, alamat kepatuhan dan nomor akun di luar akun email. Saat insiden, mungkin tidak ada waktu menentukan saluran asli; pencarian hotline dapat menghadapkan Anda pada iklan hotline palsu.

5. Perlindungan perangkat — VPN, Wi-Fi publik, pembaruan dan pemisahan

Komputer dan ponsel Anda adalah gerbang ke akun trading. Jika perangkat disusupi, kata sandi, 2FA dan daftar yang diizinkan sekaligus pun dapat tidak cukup: penyerang berpotensi mengamati aktivitas di layar.

Wi-Fi publik — apa yang diselesaikan dan tidak diselesaikan VPN

Bedakan dasar dari kontrol tambahan, karena Wi-Fi publik kerap dibahas secara berlebihan. Dasarnya adalah HTTPS yang diverifikasi dengan benar, alamat portal pada domain benar yang diketik manual, tidak melewati peringatan sertifikat, perangkat diperbarui dan MFA tahan phishing. Otoritas perlindungan konsumen AS secara eksplisit menyatakan bahwa enkripsi yang tersebar luas biasanya membuat koneksi melalui Wi-Fi publik aman[13]. Otoritas itu juga menyatakan penipu dapat memperoleh sertifikat untuk situs sendiri, sehingga enkripsi saja tidak mengidentifikasi penerima informasi Anda.

Wi-Fi publik tetap mengandung risiko hotspot palsu, pengalihan ke halaman login tiruan dan phishing. VPN atau hotspot pribadi adalah lapisan tambahan, bukan prasyarat keamanan. Ini dapat mengurangi paparan lalu lintas pendukung dan ketergantungan pada jaringan asing, tetapi tidak memperbaiki perangkat terinfeksi atau mencegah Anda memasukkan kata sandi di domain palsu.

Skenario ilustratif: hotspot palsu. Penyerang membuat hotspot bernama sama dengan jaringan hotel. Masalahnya bukan browser tidak memiliki certificate pinning: HTTPS yang diverifikasi dengan benar juga melindungi isi koneksi di jaringan asing. Risikonya adalah pengalihan ke halaman login tiruan dan godaan mengabaikan peringatan sertifikat. Di acara dan hotel, hotspot ponsel sendiri mungkin lebih sederhana. Peringatan sertifikat adalah alasan berhenti, bukan mengeklik “lanjutkan”.

Jika memilih VPN, pilih penyedia dengan kebijakan pencatatan jelas dan periksa sumber pendanaan layanan. Pada layanan gratis, pertanyaan itu lebih penting daripada harga semata: sebagian paket gratis dibiayai langganan berbayar, sementara yang lain memonetisasi lalu lintas serta data pengguna. Nilai model bisnis, kebijakan pencatatan dan audit independen penyedia tertentu, bukan menganggap pembayaran membuktikan keterpercayaan. Tethering LTE/5G ponsel sendiri sering lebih sederhana dan tidak memperkenalkan penyedia kepercayaan tambahan.

Lapisan keamanan seperti VPN atau pemindaian pada VPS, dapat memengaruhi latensi jaringan atau beban perangkat. Ukur efeknya dalam konfigurasi Anda. Artikel tentang infrastruktur eksekusi menjelaskan kapan hal itu penting, misalnya trading berita atau scalping, dan kapan tidak.

Penggunaan VPN dan kepatuhan broker. Perubahan alamat IP, login dari beberapa negara dan geolokasi tidak biasa dapat memicu pembatasan atau tinjauan manual. Jika rutin memakai VPN, pertimbangkan titik akhir stabil di negara Anda dan pahami kebijakan broker. Sebagian portal mendukung daftar IP tepercaya, dengan verifikasi tambahan untuk alamat lain. Periksa apakah pengaturan itu tersedia dan cara kerjanya secara tepat.

Sesi aktif — tinjauan dan pencabutan

Login menciptakan sesi yang dapat tetap aktif di browser, aplikasi seluler atau terminal. Malware pencuri cookie sesi mungkin tidak memerlukan kata sandi maupun kode 2FA: sesi valid bisa cukup. Karena itu, mengganti kata sandi setelah insiden tanpa mencabut sesi dapat membiarkan penyerang tetap terhubung.

Cari “active sessions”, “devices”, “logged-in devices” atau “security activity” di portal. Tinjau daftar berkala dan keluarkan yang tidak dikenal: komputer lain, ponsel lama atau lokasi asing. Jika ada “sign out all devices”, ketahui letaknya sebelum insiden. Lakukan tinjauan sama pada email terkait broker, lapisan 1 model di atas.

Pemisahan perangkat

Anda mengelola modal, jadi jaga lingkungan trading tetap bersih. Sebuah perangkat khusus trading adalah laptop atau tablet yang tidak dipakai untuk penelusuran tak terkait, lampiran dan perangkat lunak tak terverifikasi. Alat yang diperlukan adalah platform trading, browser untuk portal broker dan pengelola kata sandi.

Dalam contoh anggaran Polandia, ThinkPad rekondisi seharga sekitar seribu PLN dapat menjadi pilihan melindungi akun. Jika perangkat terpisah tidak praktis, profil pengguna sistem operasi terpisah membantu pengaturan dan mengurangi sebagian paparan, tetapi tidak menggantikan perangkat terpisah terhadap ancaman malware lebih serius.

Pemisahan perangkat: kurangi permukaan serangan
Pemisahan perangkat: kurangi permukaan serangan. Profil terpisah adalah batas yang lebih lemah daripada perangkat terpisah. Diagram edukasi; syarat terperinci dan sumber dijelaskan dalam artikel.
Buka diagram dalam ukuran penuh

Pembaruan — rutin tetapi kritis

Windows, macOS, Android, iOS, MT5 dan cTrader menerima pembaruan, termasuk perbaikan keamanan; MT4 dibahas terpisah di bawah. Instalasi usang dapat memiliki kerentanan dikenal yang bisa dieksploitasi penyerang. Aktifkan pembaruan otomatis, jangan menundanya tanpa batas.

MetaTrader 4 masih menerima pembaruan produsen. Kami tidak mengatribusikan akhir formal pengembangan MT4 kepada MetaQuotes karena tidak menemukan pengumuman produsen yang menetapkannya. Jika memakai MT4, pastikan versi terbaru dari broker atau produsen. Build lama dari situs tak terkait dapat memiliki kerentanan dikenal.

Antivirus hanya satu lapisan, tetapi harus tetap aktif. Windows Defender bawaan Windows 10/11 yang diperbarui dan aktif memberi lapisan dasar untuk workstation trading biasa. macOS memiliki kontrol sendiri, termasuk Gatekeeper dan XProtect. Jangan menonaktifkannya hanya karena merasa perangkat melambat.

6. Keamanan VPS dan EA — transaksi tanpa pengelolaan dan akses jarak jauh

Menjalankan Expert Advisor (EA) pada VPS menambahkan permukaan serangan. Komputer jarak jauh ini beroperasi 24/7, tetap terhubung ke broker dan dapat mengakses akun trading. Penyusupannya dapat memberi penyerang kendali atas lingkungan trading.

Konfigurasi RDP yang aman

Remote Desktop Protocol (RDP) adalah cara standar terhubung ke VPS Windows. RDP yang langsung terbuka ke internet menjadi sasaran terus-menerus: bot pemindai mencoba serangan kata sandi terus-menerus, 24/7.

Mengubah porta RDP saja memberi sedikit perlindungan. Utamakan tidak ada RDP publik, dengan akses melalui terowongan VPN/WireGuard; daftar IP yang diizinkan jika penyedia internet memberi alamat stabil; Network Level Authentication (NLA); MFA pada penyedia VPS dan secara terpisah pada gerbang akses jika digunakan; serta snapshot berkala dan pencatatan peristiwa. Terapkan hak akses minimum: pasang hanya yang diperlukan lingkungan trading.

Skenario ilustratif: VPS disusupi dengan kredensial tersimpan. VPS murah mempertahankan kata sandi bawaan dan porta RDP publik. Bot pemindai membobol kata sandi, masuk, membuka terminal dengan kredensial tersimpan dan menempatkan posisi bervolume maksimum. Trader menemukan saldo negatif pada pagi hari. Broker menolak kompensasi dengan alasan sesi terautentikasi valid. Tanggung jawab tidak dapat ditentukan dari skenario saja: bergantung pada perjanjian, hukum berlaku dan log kedua pihak. Unsur yang dapat diidentifikasi sebagai kendali langsung trader adalah konfigurasi VPS.

Kendalikan penyimpanan kata sandi MT4/MT5 di VPS

MT4 dan MT5 menawarkan “Simpan Kata Sandi” saat login. Nonaktifkan jika tidak dibutuhkan operasi yang dimaksud: kredensial tersimpan memudahkan akses setelah host atau sesi disusupi. Namun, untuk EA 24/7, periksa cara terminal menyambung kembali setelah restart. Menonaktifkan penyimpanan tanpa rencana autentikasi ulang dapat menghentikan otomatisasi.

Ini berbeda dari penyimpanan dalam pengelola kata sandi. Pengelola mengenkripsi rahasia di balik autentikasinya sendiri dan dapat menjadi bagian pengaturan EA 24/7 jika host dan jalur akses diamankan dengan MFA serta daftar IP yang diizinkan. Urutannya adalah amankan host dan akses dahulu, lalu tentukan cara memasok kredensial. Keduanya tidak saling menggantikan: batasi penyimpanan dan izin kredensial sesuai kebutuhan otomatisasi, sedangkan memasukkan kata sandi manual tidak membenarkan RDP publik dengan konfigurasi bawaan.

Transaksi tanpa pengelolaan — posisi yang kehilangan pengendalinya

Transaksi ini dibuka EA tetapi tak lagi dikelola setelah VPS gagal, koneksi putus atau restart. Posisi mungkin tidak memiliki stop loss karena algoritme seharusnya mengelola keluar secara dinamis, tanpa take profit dan tanpa pemantauan. Posisi dapat tetap terpapar hingga margin call atau intervensi lain.

Pengamanan: EA seharusnya memasang stop loss sisi server yang diterima, bukan semata stop virtual algoritmik. Jika EA berhenti, SL yang diterima tetap ada di server, tetapi tidak menjamin harga eksekusi atau kerugian terbatas sesuai rencana. Pertimbangannya penting: saat likuiditas rendah dan spread lebar, seperti jendela rollover broker, stop dapat terpicu dalam kondisi lebih buruk dari perkiraan. Untuk rollover pukul 17:00 New York, contoh Polandia biasanya 23:00, atau 22:00 saat periode pergantian waktu musim panas tidak selaras. Pemicu demikian tidak dengan sendirinya membuktikan broker mengincar stop Anda. Stop virtual menyembunyikan level stop tetap dalam terminal tetapi menambah ketergantungan infrastruktur. Pilih sesuai kondisi eksekusi broker dan metode trading.

VPS: keamanan akses versus kinerja eksekusi
VPS: keamanan akses versus kinerja eksekusi. Dua lapisan berbeda — terowongan tidak menjamin hasil atau harga eksekusi. Diagram edukasi; syarat terperinci dan sumber dijelaskan dalam artikel.
Buka diagram dalam ukuran penuh

Jangan berbagi VPS

Berbagi VPS untuk menghemat dapat mengekspos EA dan posisi terbuka kepada pengguna lain yang berpotensi mengakses terminal, berkas, log dan rahasia. Dalam ilustrasi Polandia, penghematan PLN 50 menciptakan paparan itu. Pertahankan VPS trading di bawah kendali satu trader, jangan berbagi lingkungan akun dengan pengguna tak terkait.

Peristiwa historis dan skenario ilustratif: 15 Januari 2015 — keputusan SNB dan EA tanpa SL sisi server. Pada 15 Januari 2015, Swiss National Bank menghentikan kurs minimum 1.20 franc per euro dan menurunkan suku bunga menjadi -0.75%, sebagaimana siaran pers hari itu[10]. Keputusan diumumkan dan dilaksanakan; kami tidak mengulang perkiraan pergerakan pip yang saling bertentangan dari pers industri. Berikut adalah skenario ilustratif, bukan laporan terdokumentasi: VPS menjalankan EA scalping EURCHF dengan stop virtual algoritmik tanpa SL server. VPS dan EA tetap berjalan, tetapi penyedia likuiditas berhenti mengutip. Tanpa harga yang dapat dieksekusi, stop virtual tidak dapat menutup posisi. Pelajaran infrastrukturnya: SL server yang diterima dapat beroperasi tanpa EA, tetapi tetap memerlukan pasar tersedia dan tunduk pada kondisi eksekusi; gap dapat menghasilkan fill lebih buruk daripada level stop. SL virtual juga bergantung pada EA aktif dan koneksi broker.
Kunci API — perlakukan sebagai kata sandi dengan izin terdefinisi. Model akses programatik berbeda-beda. Satu penyedia dapat menerbitkan token pribadi untuk semua subakun; yang lain memakai pustaka terhubung ke sesi terminal terautentikasi, awalnya hanya baca. Tidak ada nama izin penempatan order yang berlaku seluruh pasar maupun pembatasan IP wajib yang tersedia universal. Sebelum menerbitkan kredensial, tetapkan lima hal dengan broker: jenis kredensial, cakupan izin, masa berlaku, apakah trading atau penarikan diizinkan, dan cara mencabutnya. Periksa terpisah apakah akses dapat dibatasi ke IP tertentu. Apa pun modelnya, kredensial berizin order dapat melewati login portal biasa, jadi perlakukan sebagai rahasia kuat. Simpan dalam variabel lingkungan, bukan ditanam dalam kode sumber skrip. Juga tinjau kunci terbitan dan cabut yang tidak dipakai: kunci yang dibuat dua tahun lalu untuk menguji bot mungkin masih berfungsi tanpa kedaluwarsa atau pencabutan. Lebih sedikit kredensial aktif dengan izin lebih sempit mengurangi permukaan serangan.
DLL: izin tambahan, risiko tambahan
DLL: izin tambahan, risiko tambahan. Kode pustaka berjalan dalam konteks proses terminal. Diagram edukasi; syarat terperinci dan sumber dijelaskan dalam artikel.
Buka diagram dalam ukuran penuh
Allow DLL imports — memberi kode eksternal akses ke sistem. Mengaktifkan “Allow DLL imports” untuk EA tak dikenal memungkinkan eksekusi kode eksternal. DLL berjalan di luar batasan berkas MQL, tetapi dengan hak proses terminal: mencentang opsi tidak memberi hak administrator. Kode jahat dapat menyalahgunakan berkas, memori dan akses jaringan proses itu untuk mencuri informasi. EA yang memerlukan DLL membutuhkan pengembang terverifikasi dan kode diaudit. MetaQuotes melarang impor DLL dan EX4/EX5 terkompilasi dalam produk MQL5 Market, sehingga EA yang memerlukan DLL berada di luar saluran distribusi itu[8].

Akun lebih besar dan trading algoritmik dapat memakai API FIX atau kolokasi dekat server broker, dibahas dalam infrastruktur eksekusi. Pembedaan keamanannya sama seperti kunci API lain: pisahkan kredensial hanya baca dari yang berizin order.

Copy trading sebagai vektor serangan. Pengguna ZuluTrade, MQL5 Signals atau eToro Copy Trading mengizinkan layanan menyalin transaksi penyedia pilihan. Modelnya berbeda, jadi jangan menganggap penyedia sinyal menerima akses akun: izin dan entitas penempat order bervariasi, dan sebagian penyedia tak dapat mengakses akun atau detail pelanggan. Jika akun penyedia disusupi, transaksi jahat dapat disalin dalam batas pelanggan, seperti porsi modal, ambang ekuitas penghenti penyalinan dan batas ukuran posisi. Periksa terpisah izin yang diterima layanan penyalin dan tempat mengatur batasnya. Baca dokumentasi penyedia tertentu, jangan menganggap pengaturan setara antarlayanan.
Skenario ilustratif: penyedia sinyal diretas. Penyedia dengan ratusan akun pelanggan disusupi. Pada malam hari, penyerang membuka posisi besar tanpa stop loss pada pasangan tak likuid. Akun pelanggan menyalin dalam pengaturan masing-masing. Alokasi modal lebih besar dan batas posisi lebih longgar mendekatkan mereka ke margin call. Mengikuti sinyal orang lain tanpa batas tegas tingkat akun menyerahkan sebagian risiko ke lingkungan yang keamanannya tak Anda kendalikan.

7. Daftar periksa 10 menit dan respons insiden

Anda bisa mengakses posisi terbuka hari ini dan kehilangan akses besok. Berikut ditujukan sebagai tinjauan 10 menit: cukup untuk memeriksa daftar dan mengenali hal yang belum dapat dicentang.

Mulai dengan tiga hal. Utamakan (1) kata sandi unik dan MFA pada email tertaut, (2) kata sandi broker unik buatan pengelola kata sandi dan (3) TOTP luring dengan kode pemulihan tersimpan aman. Ini menangani serangan murah berskala besar yang memakai email disusupi dan kata sandi bocor yang dipakai ulang. Yang pertama mendukung lainnya karena pemulihan dan konfirmasi perubahan dapat memakai email. Jika tersedia, daftar tujuan penarikan yang diizinkan menjadi keempat, karena perubahan tujuan juga dapat dikonfirmasi lewat email. Jadwalkan konfigurasi sisanya, jangan dibiarkan belum selesai selamanya.
# Hal Standar minimum Status
1 Email diamankan secara independen Kata sandi email unik, MFA (sebaiknya passkey), aturan penerusan dan filter ditinjau — lapisan 1 pada bagian 1 ☐
2 Email trading terpisah Alamat khusus yang tidak dipakai mendaftar layanan tak terkait ☐
3 Kata sandi broker unik 16+ karakter acak dari pengelola kata sandi, tidak pernah dipakai ulang ☐
4 2FA aktif (TOTP) Aplikasi TOTP tanpa cadangan awan, bukan SMS atau email ☐
5 Kode pemulihan 2FA luring Dicetak dan disimpan di tempat aman ☐
6 Tujuan penarikan dalam daftar yang diizinkan Jika didukung: hanya rekening disetujui, dengan aturan perubahan penerima terverifikasi ☐
7 Notifikasi penarikan Notifikasi email dan push untuk setiap permintaan penarikan ☐
8 Pembaruan sistem dan platform Pembaruan otomatis aktif; build MT4/MT5 terkini ☐
9 Jaringan asing: HTTPS terverifikasi, VPN sebagai lapisan tambahan Ketik alamat portal manual; jangan melewati peringatan sertifikat. VPN dengan kebijakan pencatatan terverifikasi atau tethering ponsel bersifat tambahan ☐
10 Perangkat atau profil terpisah Komputer atau profil pengguna trading dipisahkan dari kegiatan harian ☐
11 VPS: terowongan VPN, daftar IP yang diizinkan dan MFA penyedia Tanpa RDP publik; akses VPN/WireGuard, daftar IP yang diizinkan, MFA penyedia dan MFA gerbang terpisah jika digunakan ☐
12 VPS: rahasia dikendalikan dan dibatasi Penyimpanan kredensial terminal dibatasi sesuai kebutuhan otomatisasi; login setelah restart diuji, pengelola kata sandi, host dan akses aman ☐
13 EA: SL server untuk kegagalan VPS SL yang diterima server broker, bukan hanya stop virtual EA ☐
14 Tinjauan sesi aktif Daftar perangkat broker dan email ditinjau; sesi tidak dikenal dikeluarkan ☐
15 Kunci API tak terpakai dicabut Kunci tak terpakai dicabut; izin tersisa dipersempit dan batas IP diterapkan jika didukung ☐
16 Saluran kontak broker terverifikasi disimpan Nomor resmi, portal dan alamat kepatuhan dicatat di luar email ☐
17 Tidak ada akses desktop jarak jauh bagi orang tak terverifikasi Tanpa AnyDesk, TeamViewer atau berbagi layar atas permintaan “penasihat”, “departemen keamanan” atau “perusahaan pemulihan” yang menghubungi tanpa diminta ☐

Saya mengeklik tautan, memasukkan kata sandi dan menyetujui MFA — sekarang bagaimana?

Ini skenario sulit karena faktor kedua secara teknis tidak gagal: Anda menyetujuinya. Penyerang kini mungkin memiliki sesi valid dan izin mengubah detail. Urutan tindakan penting, bukan hanya kecepatan satu tindakan. Gunakan perangkat tepercaya lain dan hentikan interaksi dengan email mencurigakan.

Dugaan kompromi: rencana responsPrioritas tindakan — waktu adalah target rencana, bukan jaminanDugaan kompromi: rencana responsPrioritas tindakan — waktu adalah target rencana, bukan jaminan1. Batasi aksesPerangkat tepercayaCabut sesiMinta pembekuanpenarikanAmankan emailT+0–5 menit2. Dapatkan kembali kendaliKata sandi unikAtur ulang MFA / kodeCabut kunci APIPeriksa penerima danaT+5–15 menit3. SimpanbuktiSaldo danposisiRiwayat loginTangkapan bertanda waktuNomor referensikasusT+15–60 menit4. Laporkan insidenBroker dan bankCERT terkait /polisiPenilaian perangkatPemulihan amanTarget: dalam 24 jamMengganti kata sandi belum tentu mencabut akses API. Gunakan saluran resmi broker dari perangkat tepercaya.
Buka diagram dalam ukuran penuh
Respons insiden trader: empat fase dalam 24 jam pertama setelah kredensial disusupi, dari permintaan segera memblokir penarikan sampai laporan resmi.
  1. Cabut sesi selain mengganti kata sandi. Keluarkan semua perangkat di portal broker, lalu ganti kata sandi. Mengganti kata sandi tidak selalu menghentikan sesi. Jika tak ada kontrolnya, sampaikan tegas kepada hotline broker.
  2. Amankan email Anda. Ganti kata sandi, hentikan sesi dan periksa aturan penerusan serta filter. Aturan yang memindahkan pesan broker ke tempat sampah dapat menyembunyikan pengambilalihan.
  3. Telepon broker memakai nomor yang disimpan sebelumnya, bukan nomor dalam pesan. Minta penghentian penarikan dan penandaan dugaan penyusupan. Tanyakan apakah detail kontak atau tujuan penarikan berubah dalam beberapa jam terakhir.
  4. Atur ulang faktor kedua. Cabut kredensial terdampak dan konfigurasi ulang MFA. Buat kode pemulihan baru dan batalkan yang lama.
  5. Cabut kunci API dan periksa apakah ada kunci baru dibuat. Kunci berizin trading dapat tetap valid setelah perubahan kata sandi.
  6. Periksa detail penarikan dan daftar yang diizinkan. Laporkan rekening tidak dikenal sebagai bagian insiden yang sama, bukan urusan administratif terpisah.
  7. Dokumentasikan semuanya. Simpan tangkapan layar bertanggal, email dengan header lengkap, riwayat login dan nomor referensi hotline. Ini mendukung pengaduan atau sengketa broker berikutnya.
  8. Periksa perangkat. Jika juga mencurigai malware, misalnya jendela atau ekstensi asing maupun perlambatan tanpa sebab, gunakan perangkat bersih sampai diperiksa, seperti bagian 5.
  9. Laporkan masalahnya. Laporkan penarikan tanpa izin kepada polisi dan pengawas broker. Dalam contoh Polandia, laporkan insiden teknis, termasuk phishing, email atau perangkat disusupi, secara terpisah kepada CERT Polska melalui incydent.cert.pl[14]. Saluran teknis ini tidak menggantikan laporan kejahatan atau pengaduan broker dan tidak menentukan pengembalian dana. Di luar Polandia, gunakan saluran pelaporan insiden nasional yang sesuai. Artikel 13.7 menjelaskan perbedaan pengaduan dan tindakan pengawas serta jalur prosedural terkait.

Yang tidak boleh dilakukan: jangan pasang perangkat lunak “pemeriksaan komputer” dari penelepon tak diminta, beri akses desktop jarak jauh atau setor uang lagi untuk “membuka penarikan”. Setiap permintaan menandakan kemungkinan tahap kedua serangan yang sama.

Daftar ini tidak melindungi dari kerugian pasar. Tujuannya mengurangi risiko kehilangan kendali akun karena sebab di luar pasar, yang banyak dapat ditangani dengan konfigurasi teliti.

Tinjauan triwulanan. Tinjau semua hal setiap tiga bulan. Izin akses dan konfigurasi VPS dapat berubah, dan perbaikan keamanan harus dipasang. Jangan mengganti kata sandi kuat yang unik hanya karena waktu berlalu; ganti setelah penyusupan atau kecurigaan beralasan. Jadwalkan tinjauan keamanan trading berulang dalam kalender dan perlakukan sebagai pemeliharaan wajib.

Tanya jawab — Keamanan siber trader forex

Apakah 2FA SMS cukup untuk mengamankan akun broker?
2FA SMS lebih baik daripada tanpa 2FA, tetapi lebih lemah daripada TOTP atau kunci keamanan perangkat keras. SIM swapping memindahkan nomor telepon melalui operator seluler; waktu dan biayanya bergantung pada negara serta informasi korban yang tersedia. Setelah nomor diambil alih, penyerang menerima kode SMS. Minimum yang dianjurkan adalah generator TOTP luring, seperti Google Authenticator tanpa sinkronisasi awan, atau kunci keamanan perangkat keras seperti YubiKey. Cadangan seed di awan menambah titik kegagalan sebagai imbalan atas kemudahan. Untuk akun trading, utamakan pengaturan yang mengandalkan operasi luring dan kode pemulihan yang disimpan secara fisik. Jika broker hanya menyediakan SMS tanpa TOTP, anggap hal itu sebagai keterbatasan signifikan infrastruktur keamanannya.
Apa yang harus saya lakukan jika kehilangan ponsel yang berisi aplikasi 2FA?
Gunakan kode pemulihan yang disimpan saat pengaturan, jika broker menerbitkannya. Simpan dalam bentuk cetak dan amankan secara fisik, bukan di ponsel. Tanpa kode, hubungi broker untuk mengikuti prosedur verifikasi identitas dan pengaturan ulang 2FA, yang dapat mencakup dokumen identitas, verifikasi video atau pemeriksaan lain. Kehilangan akses saat volatilitas tinggi merupakan risiko keuangan. Salah satu pengaturan praktis adalah kode pemulihan tercetak di brankas ditambah ponsel lama berisi seed TOTP, yang disimpan dengan aman, Wi-Fi terputus dan SIM dilepas. Ini dapat menjadi cadangan bagi trader aktif yang tidak mampu menanggung hilangnya akses akun saat pasar bergejolak.
Haruskah saya menggunakan VPN untuk trading?
VPN adalah lapisan tambahan, termasuk saat memakai Wi-Fi publik, bukan prasyarat. Dasarnya tetap HTTPS yang valid tanpa peringatan sertifikat, domain benar yang diketik manual, perangkat yang diperbarui dan MFA tahan phishing. FTC menyatakan bahwa enkripsi yang tersebar luas biasanya membuat Wi-Fi publik aman[13]. Pertimbangkan VPN atau tethering ponsel bila Anda tidak memercayai jaringan atau ingin mengurangi paparan lalu lintas pendukung. Di rumah, nilai model ancaman dan konfigurasi router Anda; firmware usang atau kredensial bawaan yang tidak aman dapat membuka paparan. Untuk penggunaan VPN rutin, pertimbangkan titik akhir yang stabil: alamat IP yang sering berubah dan negara yang tidak biasa dapat memicu verifikasi broker, bergantung pada kontrol entitasnya. Nilai model pendanaan, kebijakan pencatatan dan audit independen VPN gratis, bukan harganya saja; sebagian paket gratis ditopang langganan berbayar dan sebagian lainnya memonetisasi lalu lintas pengguna.
Bagaimana cara mengamankan MT4/MT5 di ponsel?
Aktifkan kunci layar dengan PIN, sidik jari atau Face ID. Hindari menyimpan kredensial yang tidak diperlukan di MT4/MT5; masukkan kata sandi secara manual atau melalui isi otomatis pengelola kata sandi. Perbarui aplikasi. Jangan masuk melalui ponsel orang lain. Nonaktifkan pratinjau notifikasi di layar terkunci agar kode 2FA dan peringatan broker tidak terlihat orang sekitar. Jika ponsel hilang, segera gunakan perangkat tepercaya lain untuk mengganti kata sandi broker.
Apa yang harus saya lakukan jika mencurigai akses akun tanpa izin?
Segera: (1) gunakan perangkat tepercaya untuk mencabut sesi broker, lalu ganti kata sandi; (2) lakukan hal yang sama pada akun email tertaut, lapisan hulu; (3) telepon hotline resmi broker, bukan mengandalkan email yang mungkin telah disusupi, dan minta pembekuan sementara; (4) tinjau riwayat login untuk alamat IP, perangkat atau lokasi yang tidak dikenal; (5) periksa permintaan penarikan dan minta broker membatalkan yang tidak sah; (6) aktifkan atau atur ulang 2FA. Simpan tangkapan layar, tanggal dan waktu. Laporkan penarikan tanpa izin kepada polisi dan pengawas broker; di Polandia, laporkan insiden teknis secara terpisah kepada CERT Polska di incydent.cert.pl, dan gunakan saluran nasional yang relevan di negara lain. Bagian 7 memberikan respons lebih lengkap untuk halaman phishing tempat Anda sendiri menyetujui MFA.
Bisakah EA mencuri kredensial saya?
EA berbahaya dapat melakukan trading di akun Anda: Anda mungkin memasangnya setelah klaim Telegram bahwa EA itu “menghasilkan 300 pip seminggu”. Bedakan dua tingkat izin. Kode MQL biasa tidak memiliki akses sistem tanpa batas: MetaQuotes mendokumentasikan sandbox berkas, dan WebRequest mengharuskan server tujuan ditambahkan ke daftar URL yang diizinkan terminal[12]. Mengizinkan impor DLL memberikan izin terpisah yang membawa kode eksternal keluar dari pembatasan tersebut, sebagaimana dibahas pada bagian 6. Jangan aktifkan impor DLL untuk EA dari sumber tidak dikenal. Permintaan menonaktifkan antivirus “agar berfungsi” merupakan peringatan malware serius. Gunakan MQL5 Market atau pengembang dengan reputasi terverifikasi, sambil memahami bahwa saluran distribusi tidak menjamin profitabilitas ataupun keamanan penuh.
Artikel 13.8 · Regulasi & Keamanan · April 2026

Sumber

  1. OWASP Foundation, “Credential Stuffing Prevention Cheat Sheet”, cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html — mendefinisikan pengujian pasangan nama pengguna/kata sandi dari kebocoran layanan lain dan menjelaskan kontrol sisi layanan, termasuk MFA, pembatasan IP dan deteksi perangkat atau alamat tak dikenal. Sumber ini tidak mengukur proporsi pengambilalihan akun broker akibat vektor ini; tidak ada statistik demikian yang diatribusikan kepadanya di sini. Diakses 31 Agustus 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/ — bagian 3.1.1.2: minimal 15 karakter jika kata sandi satu-satunya faktor, atau 8 dalam MFA; bagian 3.1.3.3: autentikasi jaringan telepon publik, termasuk SMS, dibatasi, dengan alternatif wajib; bagian 3.1.7 mencakup autentikator kriptografis multifaktor. Edisi SP 800-63B tanggal 2 Maret 2020 yang dahulu dikutip di sini digantikan oleh SP 800-63B-4, difinalkan 31 Juli 2025, yang penomoran bagiannya digunakan di atas. Jangan singkat pengenal ini menjadi “SP 800-63-4”: dokumen payung terpisah itu menggantikan SP 800-63-3, bukan SP 800-63B. Status dokumen diperiksa di csrc.nist.gov/pubs/sp/800/63/b/4/final. Diakses 1 September 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 — pernyataan kebijakan diterbitkan 18 Maret 2026: definisi insiden operasional, ambang pelaporan dan proses terstandar; secara terpisah, pelaporan pengaturan pihak ketiga material dan register tahunan. Aturan hasilnya dijadwalkan berlaku mulai 18 Maret 2027. Ini menggantikan rujukan usang artikel sebelumnya yang hanya menyebut “persyaratan pelaporan insiden yang diumumkan”. Diakses 31 Agustus 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 — ditetapkan 15 November 2023 dan diterbitkan 16 November 2023. Sekitar 300 pengaduan pada 2020, 400 pada 2021 dan 500 pada 2022 tentang SIM swap dan pemindahan nomor berasal dari catatan kaki 13 serta catatan Consumer Complaint Center Komisi. Diakses 31 Agustus 2026 (98 halaman; teks diekstrak lokal dalam audit Polandia asli).
  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/ — diterbitkan 22 Januari 2024; materi diperbarui, dengan 15 Juni 2026 dicatat sebagai pembaruan terakhir dalam audit sumber Polandia. Kumpulan 12 TB berisi lebih dari 26 miliar catatan dalam sekitar 3.800 direktori, disebut mungkin kompilasi terbesar dari banyak kebocoran (COMB), dengan duplikasi sangat mungkin. Ini pelaporan sekunder tentang kebocoran dasar dan diperlakukan demikian: mendukung uraian kompilasi, bukan temuan tiap kebocoran penyusunnya. Diakses 31 Agustus 2026.
  6. National Cyber Security Centre (NCSC UK), “Phishing attacks: defending your organisation”, ncsc.gov.uk/guidance/phishing — kontrol antispofing DMARC, SPF dan DKIM, kebijakan karantina atau penolakan dan jalur pelaporan pesan mencurigakan yang sederhana dan cepat. Audit asli memeriksa cakupannya secara terpisah: sumber ini tidak membahas domain mirip, sehingga topik itu tidak diatribusikan kepadanya. Diakses 31 Agustus 2026.
  7. National Cyber Security Centre (NCSC UK), “Recommended types of MFA”, dalam “Multi-factor authentication for your corporate online services”, ncsc.gov.uk/collection/mfa-for-your-corporate-online-services/recommended-types-of-mfa — urutan preferensi: 1) kredensial FIDO2, 2) aplikasi berbasis tantangan, 3) generator kode aplikasi (TOTP), 4) generator kode perangkat keras, 5) kode lewat pesan. Diakses 31 Agustus 2026.
  8. MetaQuotes, “The checks a trading robot must pass before publication in the Market”, mql5.com/en/articles/2555, 1 Agustus 2016 — pemeriksaan wajib sebelum publikasi di MQL5 Market dan larangan impor DLL serta EX4/EX5 terkompilasi pada produk Market. Diakses 31 Agustus 2026.
  9. LastPass, “Notice of Security Incident”, blog.lastpass.com/posts/notice-of-recent-security-incident — pemberitahuan 22 Desember 2022 yang mengonfirmasi cadangan data pelanggan, termasuk brankas kata sandi, disalin. Bidang sensitif seperti nama pengguna, kata sandi dan catatan dienkripsi; sebagian metadata, termasuk URL situs web, tidak dienkripsi. Diakses 31 Agustus 2026; pemberitahuan historis asli diverifikasi ulang 9 Oktober 2026.
  10. Swiss National Bank, “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 Januari 2015 — sumber keputusan dan tanggalnya. Halaman tidak menyebut waktu publikasi; rilis lengkap tersedia sebagai PDF unduhan. Diakses 31 Agustus 2026.
  11. Peraturan (UE) 2022/2554 Parlemen Eropa dan Dewan tanggal 14 Desember 2022 tentang ketahanan operasional digital sektor keuangan (DORA), CELEX 32022R2554, OJ EU L 333, 27.12.2022 — pengelolaan risiko TIK dan pelaporan insiden besar terkait TIK oleh entitas keuangan tercakup. Pasal 2(1) tunduk pada ayat 3 dan 4 dan mencakup “perusahaan investasi” pada poin (e); Pasal 2(3)(d) mengecualikan orang dalam pengecualian Pasal 2 dan 3 Direktif 2014/65/UE. Teks bahasa Polandia dalam audit asli diperoleh melalui publications.europa.eu/resource/celex/32022R2554; kepala dokumennya menyebut “27.12.2022 PL Official Journal of the European Union L 333/1”. Ketentuan akhir secara eksplisit menetapkan penerapan mulai 17 Januari 2025 dan mulai berlaku pada hari kedua puluh setelah publikasi Jurnal Resmi. Publikasi 27 Desember 2022 dengan demikian menghasilkan 16 Januari 2023; undang-undang tidak menyatakan tanggal terakhir itu secara numerik. Diakses 1 September 2026.
  12. MetaQuotes, dokumentasi MQL5 Reference, “FileOpen” (mql5.com/en/docs/files/fileopen) dan “WebRequest” (mql5.com/en/docs/network/webrequest) — operasi berkas dibatasi pada sandbox berkas, dan WebRequest mengharuskan URL server dimasukkan dalam daftar URL diizinkan pada “Expert Advisors” di “Options”. Dokumentasi menyatakan: “Berkas yang dioperasikan menggunakan sarana MQL5 tidak dapat berada di luar sandbox berkas”. Diakses 31 Agustus 2026. Konteks eksekusi DLL juga diverifikasi dalam Microsoft “About Dynamic-Link Libraries”, learn.microsoft.com/en-us/windows/win32/dlls/about-dynamic-link-libraries, pada 9 Oktober 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, Februari 2023 — enkripsi yang tersebar luas biasanya membuat koneksi Wi-Fi publik aman, sementara penipu juga dapat mengenkripsi situs palsu. Enkripsi saja tidak menentukan siapa penerima informasi. Diakses 31 Agustus 2026.
  14. Contoh penerapan Polandia: CERT Polska berada dalam NASK, lembaga riset nasional, dan menjalankan tugas CSIRT NASK sebagai satu dari tiga tim respons tingkat nasional Polandia (cert.pl/o-nas). Formulir insidennya incydent.cert.pl, berjudul “Zgłoś incydent | CERT.PL”. Sumber ini dikutip semata sebagai saluran pelaporan insiden teknis: sumber ini tidak menetapkan proses pengaduan finansial maupun keputusan pengembalian dana. Di luar Polandia, gunakan saluran pelaporan nasional yang relevan. Diakses 1 September 2026.

Kemajuan belajar Anda

Selesai membaca pelajaran ini? Tandai sendiri. Membuka atau menggulir halaman tidak menandainya sebagai selesai.

Kemajuan memerlukan JavaScript dan penyimpanan browser.

Disimpan hanya di browser ini. Tanpa akun atau sinkronisasi antarperangkat. Menghapus data situs dapat menghapus kemajuan Anda.

Jarosław Wasiński

Pemimpin redaksi, ForexMechanics.com • Analis makro dan FX

Analis independen dan profesional dengan lebih dari 20 tahun pengalaman di pasar keuangan. Aktif di Forex sejak 2004, berfokus pada analisis fundamental, struktur pasar OTC, dan manajemen risiko modal yang disiplin.

  • Pendiri dan pemimpin redaksi MyBank.pl, menyediakan edukasi keuangan tepercaya sejak 2004.
  • Penulis ratusan komentar pasar mendalam, analisis struktural, dan materi edukasi untuk trader dan investor.
  • Pendukung transparansi pasar, mempromosikan edukasi berbasis data konkret dan laporan institusional (BIS, ESMA, CFTC).

Seluruh konten bersifat edukasi dan informasi semata – bukan merupakan saran investasi atau rekomendasi apa pun. Ingat: trading dengan leverage (Forex/CFD) memiliki risiko tinggi kehilangan modal dengan cepat.