in Web Security

Memahami Cara Kerja Token Internet Banking

photo by:hendriadi.wordpress.com

photo:hendriadi.wordpress.com

Penggunaan token berupa alat kecil semacam kalkulator untuk mengamankan transaksi internet banking kini sudah menjadi hal yang wajib. Token ini menjadi faktor tambahan dalam otentikasi yaitu untuk membuktikan bahwa anda adalah benar-benar pengguna yang sah. Mungkin ada yang bertanya-tanya bagaimana cara kerja token seperti yang dipakai situs internet banking? Bagaimana alat kecil seperti kalkulator itu bisa menghasilkan angka yang juga diketahui oleh server internet banking, padahal alat itu tidak terbubung dengan server. Dalam artikel ini saya akan menjelaskan cara kerja token internet banking, dan dalam artikel berikutnya saya akan membuat token berbasis software dan website sederhana yang akan mensimulasikan internet banking.

Authentication Method

Otentikasi bertujuan untuk membuktikan siapa anda sebenarnya, apakah anda benar-benar orang yang anda klaim sebagai dia (who you claim to be). Ada banyak cara untuk membuktikan siapa anda. Metode otentikasi bisa dilihat dalam 3 kategori metode:

  1. Something You Know
  2. Ini adalah metode otentikasi yang paling umum. Cara ini mengandalkan kerahasiaan informasi, contohnya adalah password dan PIN. Cara ini berasumsi bahwa tidak ada seorangpun yang mengetahui rahasia itu kecuali anda seorang.

  3. Something You Have
  4. Cara ini biasanya merupakan faktor tambahan untuk membuat otentikasi menjadi lebih aman. Cara ini mengandalkan barang yang sifatnya unik contohnya adalah kartu magnetik/smartcard, hardware token, USB token dan sebagainya. Cara ini berasumsi bahwa tidak ada seorangpun yang memiliki barang tersebut kecuali anda seorang.

  5. Something You Are
  6. Ini adalah metode yang paling jarang diapakai karena faktor teknologi dan manusia juga. Cara ini mengandalkan keunikan bagian-bagian tubuh anda yang tidak mungkin ada pada orang lain seperti sidik jari, suara atau sidik retina. Cara ini berasumsi bahwa bagian tubuh anda seperti sidik jari dan sidik retina, tidak mungkin sama dengan orang lain.

Lalu bagaimana dengan metode otentikasi tradisional seperti tanda tangan di atas materai? Masuk ke kategori manakah cara itu dari ketiga metode di atas? Saya pikir tidak ada yang cocok, karena itu saya tambahkan satu lagi yaitu “Something You Can“.Β  Cara ini berasumsi bahwa tidak ada orang lain di dunia ini yang bisa melakukan itu selain anda. Memang otentikasi dengan tanda tangan dibangun di atas asumsi itu, tidak ada yang bisa menuliskan tanda tangan anda kecuali anda. Walaupun pada kenyataannya ada saja orang yang bisa meniru tanda tangan anda dengan sangat baik, namun walaupun menyadari fakta tersebut tanda tangan di atas kertas tetap diakui sebagai bukti otentik atas siapa anda.

Two Factor Authentication

Pada aplikasi yang kritis dan sensitif seperti transaksi keuangan, satu metode otentikasi saja tidak cukup. Oleh karena itu muncul istilah 2FA (Two Factor Authentication) yang merupakan sistem otentikasi yang menggunakan 2 faktor (metode) yang berbeda. Empat metode otentikasi yang sudah saya jelaskan sebelunya dapat dikombinasikan untuk meningkatkan keamanan, salah satu contohnya adalah dengan kombinasi “something you have” berupa kartu ATM dengan “something you know” berupa PIN. Kombinasi ini merupakan kombinasi yang paling banyak dipakai.

Contoh kasus lain adalah ketika anda berbelanja di pasar modern dan membayar dengan kartu, tanpa disadari anda telah memakai lebih dari satu faktor otentikasi. Faktor yang pertama adalah “Something You Have” yaitu kartu debit/kredit anda. Faktor kedua adalah “Something You Know”, ketika anda diminta memasukkan PIN ke dalam mesin EDC. Bahkan mungkin ada faktor ketiga yaitu “Something You Can”, ketika anda diminta menanda-tangani nota pembayaran yang dicetak mesin EDC.

Internet banking juga menggunakan two factor authentication dengan mengombinasikan “something you know” berupa password dan “something you have” berupa hardware token (keyBCA atau Token Mandiri).

Password yang Dikeluarkan Token Internet Banking

Pada umumnya ada dua mode pemakaian token internet banking:

  1. Mode Challenge/Response (C/R)
  2. Ini adalah mode yang paling sering dipakai ketika bertransaksi. Dalam mode ini server memberikan challenge berupa sederetan angka. Angka tersebut harus dimasukkan kedalam mesin token untuk mendapatkan jawaban (response). Kemudian pengguna memasukkan angka yang muncul pada tokennya ke dalam form di situs internet banking. Token akan mengeluarkan kode yang berbeda-beda walaupun dengan challenge code yang sama secara periodik tergantung waktu ketika challenge dimasukkan ke dalam token.

  3. Mode Self Generated (Response Only)
  4. Dalam mode ini server tidak memberikan tantangan (challenge) apapun. Token pengguna bisa langsung mengeluarkan sederetan angka tanpa harus memasukkan challenge. Seperti mode C/R, token juga mengeluarkan kode yang berbeda-beda secara periodik tergantung waktu ketika token diminta untuk menghasilkan kode self generated.

Sebenarnya jawaban yang diberikan oleh token baik dalam mode C/R maupun Self Generated(resopnse only) tidak lain adalah password juga. Namun berbeda dengan password yang anda pakai untuk login, password yang dihasilkan token ini memiliki keterbatasan untuk alasan keamanan, yaitu:

  1. Hanya boleh dipakai 1 kali
  2. Ini disebut dengan OTP (One Time Password). Setelah suatu password dipakai, maka password yang sama tidak bisa lagi dipakai untuk kedua kalinya. Dengan cara ini tidak ada gunanya menyadap password yang dihasilkan token karena password tersebut tidak bisa dipakai lagi. Namun bila password tersebut di-intercept sehingga tidak pernah sampai ke server, maka password tersebut masih berharga karena di mata server, password itu belum pernah dipakai.

  3. Hanya boleh dipakai dalam rentang waktu yang terbatas
  4. Password yang dihasilkan token memiliki umur yang sangat terbatas, mungkin antara 3-6 menit bila umurnya habis maka password itu tidak bisa dipakai, walaupun belum pernah dipakai. Nanti akan saya jelaskan mengapa password token memerlukan umur, waktu merupakan unsur yang sangat kritikal dalam sistem ini.

  5. Hanya boleh dipakai dalam konteks sempit
  6. Bila password/PIN yang dipakai untuk login adalah password yang bebas konteks, dalam arti dengan berbekal password itu, anda bisa melakukan banyak hal, mulai dari melihat saldo, mengecek transaksi dan sebagainya. Namun password yang dihasilkan token, hanya bisa dipakai dalam konteks sempit, contohnya password yang dipakai untuk mengisi pulsa ke nomor 08123456789, tidak bisa dipakai untuk melakukan transfer dana.

    Terbatasnya konteks ini disebabkan karena untuk melakukan transaksi dibutuhkan password yang diikat oleh challenge dari server, sehingga password tersebut tidak bisa dipakai untuk transaksi lain yang membutuhkan challenge code yang berbeda. Contohnya bila challenge yang diberikan server adalah 3 digit terakhir dari nomor handphone (untuk transaksi isi pulsa), atau 3 digit terakhir nomor rekening tujuan (untuk transaksi transfer). Maka password yang dihasilkan token untuk transaksi isi pulsa ke nomor 0812555111222, akan valid juga untuk transaksi transfer uang ke rekening 155887723120222. Sebab kebetulan kedua transaksi tersebut membutuhkan password yang diikat oleh challenge code yang sama, yaitu 222 (diambil dari 3 digit terakhir).

    Konteks ini hanya berlaku bila password dihasilkan dalam mode C/R. Password yang dihasilkan dalam mode Self Generated, bisa dipakai dalam transaksi apa saja yang tidak meminta password dengan challenge code.

Jadi bisa disimpulkan bahwa password yang dikeluarkan token bersifat:

  1. Selalu berubah-ubah secara periodik
  2. Memiliki umur yang singkat
  3. Hanya bisa dipakai 1 kali
  4. Terbagi dalam ada dua jenis, yaitu:
  • Password kontekstual yang terikat oleh challenge code dalam mode challenge/response.
  • Password bebas konteks yang dihasilkan dalam mode self generated.

Proses Otentikasi

Seperti password pada umumnya, syarat agar otentikasi berhasil adalah:

password yang dikirimkan client = password yang disimpan di server

Dengan alasan keamanan jarang sekali server menyimpan password user dalam bentuk plain-text. Biasanya server menyimpan password user dalam bentuk hash sehingga tidak bisa dikembalikan dalam bentuk plain-text. Jadi syarat otentikasi berhasil di atas bisa diartikan sebagai hasil penghitungan hash dari password yang dikirim klien harus sama dengan nilai hash yang disimpan dalam server. Perhatikan gambar di bawah ini untuk lebih memahami.

courtesy of "www.unixwiz.net/techtips/iguide-crypto-hashes.html"

courtesy of "www.unixwiz.net/techtips/iguide-crypto-hashes.html"

Penggunaan Salt

Untuk menghindari brute-force attack terhadap hash yang disimpan di server, maka sebelum password user dihitung nilai hashnya, terlebih dahulu ditambahkan string acak yang disebut dengan salt. Perhatikan contoh berikut, bila password user adalah “secret”, maka sebelum dihitung nilai hashnya, password ditambahkan dulu salt berupa string acak “81090273” sehingga yang dihitung nilai hashnya adalah “secret81090273” bukan “secret”.

Perhatikan bahwa nilai MD5(“secret81090273”) adalah 894240dbe3d2b546c05a1a8e9e0df1bc sedangkan nilai MD5(“secret”) adalah 5ebe2294ecd0e0f08eab7690d2a6ee69. Bila tanpa menggunakan salt, maka attacker yang mendapatkan nilai hash 5ebe2294ecd0e0f08eab7690d2a6ee69 bisa menggunakan teknik brute force attack atau rainbow table untuk mendapatkan nilai password dalam plain-text. Salah satu contoh database MD5 online yang bisa dipakai untuk crack md5 adalah http://gdataonline.com/seekhash.php . Dalam situs tersebut coba masukkan nilai 5ebe2294ecd0e0f08eab7690d2a6ee69, maka situs tersebut akan memberikan hasil “secret”. Hal ini disebabkan karena situs tersebut telah menyimpan pemetaan informasi secret<=>5ebe2294ecd0e0f08eab7690d2a6ee69.

Penambahan salt “81090273” membuat nilai hash menjadi 894240dbe3d2b546c05a1a8e9e0df1bc. Bila nilai ini dimasukkan dalam situs tersebut, dijamin tidak akan ada dalam databasenya bahwa nilai hash tersebut adalah “secret81090273”. Dan karena nilai salt ini dibangkitkan secara random, maka tiap user memiliki nilai salt yang berbeda sehingga tidak mungkin attacker bisa membangun database pemetaan antara plaintext dan hash secara lengkap.

Dengan penggunaan salt, maka database pengguna dalam server akan tampak seperti ini:

Username Salt Password Hash
budi 81090273 894240dbe3d2b546c05a1a8e9e0df1bc

Field salt diperlukan ketika melakukan otentikasi. Password yang dikirimkan user akan ditambahkan dulu dengan nilai salt ini baru kemudian dihitung nilai hashnya. Nilai hash hasil perhitungan tersebut akan dibandingkan dengan field Password Hash yang ada di kolom sebelahnya. Bila sama, maka otentikasi berhasil, bila tidak sama, berarti otentikasi gagal. Secara prinsip sama saja dengan gambar di atas, hanya ditambahkan satu langkah yaitu penambahan salt sebelum dihitung nilai hashnya.

Pembangkitan One Time Password (OTP) Token Internet Banking

Apa yang saya jelaskan sebelumnya menjadi dasar dari apa yang akan saya jelaskan berikut ini. Bagaimana cara token menghasilkan sederetan angka sebagai OTP yang bisa diotentikasi oleh server? Ingat bahwa syarat agar otentikasi berhasil adalah password yang dikirim klien harus sama dengan yang disimpan di server. Ingat juga bahwa password yang dihasilkan token selalu berubah-ubah secara periodik. Bagaimana apa yang dihasilkan alat itu bisa sinkron dengan server? Padahal alat tersebut tidak terhubung dengan server, bagaimana server bisa tahu berapa nilai yang dihasilkan token? Jawabannya adalah denganΒ waktu. Sebelumnya sudah saya sebutkan bahwa waktu adalah elemen yang sangat penting dalam sistem ini. Server dan token dapat sinkron dengan menggunakan waktu sebagai nilai acuan.

OTP dalam Mode Self Generated (Response Only)

Saya akan jelaskan mulai dari pembangkitan OTP dalam mode self generated atau response only. Sebelumnya tentu saja, server dan token harus menyepakati sebuah nilai awal rahasia (init-secret atau secret key). Nilai awal ini disimpan (ditanam) dalam token device dan disimpan juga dalam database di sisi server.

Ketika pada suatu waktu tertentu token diminta menghasilkan OTP tanpa challenge code, inilah yang dilakukan token:

  1. Mengambil waktu saat ini dalam detik berformat EPOCH (jumlah detik sejak 1 Januari 1970), biasanya dalam granularity 10 detik, sehingga nilai EPOCH dibagi 10.
  2. Menggabungkan init-secret dengan waktu saat ini dari langkah 1.
  3. Menghitung nilai hash gabungan init-secret dan waktu dari langkah 2.

Nilai hash dari langkah 3 inilah yang menjadi OTP. Namun biasanya OTP diambil dari beberapa karakter/digit di awal hash.

Sebenarnya yang saya jelaskan di atas hanyalah penyederhanaan saja, proses sebenarnya lebih kompleks dari yang di atas. Prosedur di atas adalah penyederhanaan dari keyed-hash atau HMAC (hash-based message authentication code), fungsi hash dengan tambahan masukan berupa secret key.

Bagaimana cara server melakukan otentikasi? Caranya mirip dengan yang dilakukan token, yaitu dengan menghitung nilai hash gabungan init-secret dengan waktu saat ini dan mengambil beberapa digit di awal sebagai OTP. Bila OTP yang dikirim user sama dengan OTP yang didapatkan server dari perhitungan hash, maka otentikasi berhasil.

Namun ada sedikit catatan yang harus diperhatikan terkait waktu. Untuk memberikan toleransi perbedaan waktu antara token dan server, dan juga jeda waktu dari sejak server meminta password sampai user meminta token membangkitkan token, maka server harus memberikan toleransi waktu.

Ada tiga kejadian yang perlu diperhatikan waktunya, yaitu:

  1. Detik ketika server meminta password (OTP) dari user
  2. Detik ketika token membangkitkan OTP
  3. Detik ketika server menerima OTP dari user

Perhatikan contoh di bawah ini:

Bila diasumsikan waktu di server sama persis dengan waktu di token (jam internal token), maka kita harus perhatikan bahwa pasti akan ada jeda antara kejadian 1, 2 dan 3. Bila pada detik ke-0 server meminta password dari user, karena lambatnya akses internet, bisa jadi baru pada detik ke-30 user melihat pada browsernya bahwa dia harus memasukkan OTP dari token. Kemudian baru pada detik ke-60 token menghasilkan OTP. Pada detik ke-65 user mensubmit nilai OTP tersebut ke server dan baru tiba di server pada detik ke-90.

Karena pembangkitan OTP tergantung waktu pada saat OTP dibangkitkan, maka OTP yang dihasilkan token, adalah OTP pada detik ke-60. Sedangkan server meminta password dari user sejak detik ke-0. Bagaimana cara server melakukan otentikasi? Caranya adalah dengan memeriksa seluruh kemungkinan OTP dalam rentang waktu yang dipandang memadai, misalkan 180 detik.

Bila sistem menggunakan granularity 10 detik maka server harus menghitung nilai OTP sejak dari detik ke-0, 10, 20, 30, 40, s/d ke 180 dalam kelipatan 10 detik. Perhatikan contoh pada gambar di bawah ini. Dalam sistem ini diasumsikan OTP adalah 6 karakter awal dari MD5 gabungan. Dalam melakukan otentikasi, server harus membandingkan semua nilai OTP sejak detik ke-0 (dalam contoh ini EPOCH/10 = 124868042) hingga waktu toleransi maksimum.

otptoken1Dalam contoh di atas bila user mengirimkan OTP “b1cdb9” maka otentikasi akan berhasil ketika server menghitung nilai OTP pada detik ke-60 sejak server meminta OTP dari user.

Ilustrasi di atas hanyalah contoh, pada kenyataannya ada kemungkinan waktu antara server dan token tidak sama persis 100%, sehingga server terpaksa harus memberikan toleransi waktu tidak hanya ke depan, namun juga ke belakang. Sebab bisa jadi waktu di server lebih cepat daripada waktu di token. Sebagai contoh ketika waktu di server menunjukkan EPOCH/10=124868219, bisa jadi waktu di token baru menunjukkan EPOCH/10=1248682121 (waktu token terlambat 80 detik).

Misalkan waktu toleransi adalah 3 menit, maka server harus memberikan toleransi 3 menit ke depan dan 3 menit ke belakang relatif terhadap waktu ketika server menerima OTP dari user dan melakukan otentikasi. Ingat, waktu toleransi ini relatif terhadap waktu server melakukan otentikasi. Jadi jika server melakukan otentikasi pada EPOCH/10=600, maka server harus menghitung seluruh nilai OTP sejak EPOCH/10=420Β  hingga EPOCH/10=780.

Ingat penjelasan saya tentang salt sebelumnya. Kalau dibandingkan dengan OTP ini, maka nilai init-secret adalah sejenis dengan password plain-text pengguna, sedangkan salt atau tambahannya adalah waktu (EPOCH/10).

Umur OTP

Sebelumnya sudah saya sebutkan bahwa sifat dari OTP adalah memiliki umur yang terbatas. Umur ini terkait dengan waktu toleransi yang diberikan server sebesar X detik ke depan dan X detik ke belakang relatif terhadap saat server melakukan otentikasi. Bila waktu toleransi adalah 3 menit (180 detik), maka umur sebuah OTP adalah 3 menit, dalam arti bila server melakukan otentikasi tidak lebih dari 3 menit sejak OTP dibangkitkan token, maka OTP tersebut akan dianggap valid oleh server.

OTP dalam Mode Challenge/Response

Pembangkitan dan otentikasi OTP dalam mode C/R sebenarnya mirip dengan mode self-generated. Bila dalam mode self generated tambahan (salt) dari init-secret adalah waktu (EPOCH/10), dalam mode C/R ini salt/tambahannya lebih banyak. Init-secret tidak hanya ditambah dengan waktu, namun juga ditambah lagi dengan challenge.

Perhatikan gambar di bawah ini. Server melakukan penghitungan OTP untuk semua detik dalam waktu toleransinya.

otptoken2

Dalam mode C/R ada field tambahan yang harus digabungkan sebelum dihitung nilai hashnya, yaitu challenge. Nilai challenge ini diketahui oleh server dan juga oleh token (ketika user mengetikkan challenge ke token), sehingga baik token maupun server akan dapat menghitung OTP yang sama sehingga proses otentikasi dapat berlangsung.

Untuk menghindari brute-force attack terhadap hash yang disimpan di server, maka sebelum password user dihitung nilai hashnya, terlebih dahulu ditambahkan string acak yang disebut dengan salt. Perhatikan contoh berikut, bila password user adalah “rahasia”, maka sebelum dihitung nilai hashnya, password ditambahkan dulu salt berupa string acak “81090273” sehingga yang dihitung nilai hashnya adalah “rahasia81090273” bukan “rahasia”.

Write a Comment

Comment

116 Comments

  1. saya lebih tertarik oprek keytoken yang ada di dalam memory ram hardwarenya, nanti saya crosscheck sama pemahaman cara kerja base on aplikasi punyamu.

    klo aku suka belajar bhs mesin daripada bhs tingkat tinggi..maklum orang jadul..

  2. Salam kenal mas Rizki,

    Saya baru menemukan blog ini baru-baru ini, itu pun setelah saya menjadi korban hacker (salah satu blog saya ada yang nge hack) jadi saya ingin belajar tentang ilmu hacking (supaya bisa menjaga diri di dunia maya πŸ™‚ ). Akhirnya saya temukan blog yang sangat bermanfaat ini.

    Blog ini sudah langsung saya bookmark mas :). Dan kalo mas Rizki tidak keberatan, saya ingin bisa berteman di YM, supaya bisa lebih banyak lagi menyerap ilmunya mas Rizki πŸ™‚

    Dan satu lagi, kalo tidak keberatan juga πŸ™‚ mungkin mas Rizki punya literatur-literatur dalam bentuk ebook, kalo berkenan dikirimkan ke email saya πŸ™‚

    sekali lagi terima kasih banyak atas sharenya dan ditunggu selalu updatenya πŸ™‚

  3. Begitu toh cara kerjanya.
    Selama ini sering menggunakan token, tetapi selalu bingung kok bisa ya, kirain tokennya ada cara komunikasi rahasia ke servernya πŸ˜›

  4. Jadi daftar angka (password) yg ada di token sudah di set terlebih dahulu supaya cocok dengan data server?
    Thx

    • idenya sederhana, token dan server sama2 menghitung dengan cara yang sama, karena rumus dan inputannya sama, pasti hasil itungannya akan sama, di token dan di server… bukan daftar angkanya di set di token (nggak akan cukup di memori token), yang ada di token cuma rumus dan inputannya aja, anytime dibutuhkan tinggal jalankan prosedurnya aja

  5. sorry banyak tanya, nah gimana pula token PLN prabayar dimana transaksinya tidak terhubung ke server (internet)?
    Thx

    • intinya dengan prosedur matematika tertentu, dua pihak bisa “agree on something” walaupun tanpa terhubung. sebenarnya ada banyak cara untuk otentikasi nomer voucher sejenis yang dipakai di PLN gitu tanpa harus saling terhubung, bisa dengan cryptographic hash, asimetrik kriptografi dsb (saya belum pernah baca source codenya alat itu, jadi just guessing aja ya, harap maklum).

  6. Pada hardware token yang digunakan pada internet banking menggunakan baterai didalamnya. Saya ingin menanyakan apa akibatnya bila kita melepas baterai tersebut kemudian memasukkanny kembali, apakah token tersebut masih bisa digunakan?? terima kasih atas tanggapannya…

  7. Mau nanya bang tentang cara kerja tokenx . . .
    Bisa ng’ klo 2 rekening menggunakan 1 token . . . ?
    Trus, apa mungkin bisa sj waktu yang ada d token berbeda dengan waktu yang ada d serverx . . . klo mungkin bisa berbeda, gmn solusix . . . ?
    Thank’s . . . πŸ™‚

  8. Hehehehe…………Kalo saya memahaminya simple aja.
    Kalo dibilang Token tidak terhubung dengan server bank saya kira kurang benar. karena untuk membangkitkan password ,token harus mendapat masukan kode yg dikeluarkan server. Artinya ada transfer data server-token dan sebaliknya lewat tangan manusia.
    Jadi menurut saya alat ini tidak terlalu ajaib.

    • kalo menurut saya engga perlu terhubung ke server mas,
      ibaratnya,
      ketika ujian kan murid dapet soal tuh, trus dikerjain
      selain itu guru juga udah ngerjain buat kunci jawabannya,

      trus kalo jawaban murid bener, kok bisa itu murid jawabannya sama ama gurunya? padahal engga ada komunikasi

      *yg ada cuman kesamaan nilai awal, ama algoritma, itu aja udah cukup

      CMIIW (:

  9. bagus.. sangat bermanfaat dan mendetail.
    dari segi bahsanya sangat mudah untuk dimengerti

    Saya repost yah di blog saya heheh

    Terima kasih yaa

  10. Wahhh…
    Mancaaap inponya boussss…

    bedewe, Boleh nanya kan mas ??
    Kgak bolehpun gw tetep nanya πŸ˜›

    Token Bank itu sifatnya Pribadi???
    Maksud saya, 1 Account Bank, hanya bisa generate Angka dari 1Token atau bisa pinjam Token temen???
    Makasih sebelumnya mas,
    Mohon Balas Secepatnya mas, terima kasih πŸ™‚

  11. sangat bermanfaat pak rizki wicaksono, saya peserta di conference hadfex,
    kebetulan saya ingin melakukan penelitian tentang OTP (One Time Password), adakah algoritma khusus pada konsep OTP ini?

    terima kasih sebelumnya….

  12. kalau misal kita pinjam token / key BCA milik teman utk trx internet banking di account kita bisa gak ?

    asumsinya kita udah tahu password / Pin utk menggunakan Token/key BCA milik teman kita tadi….

    • tidak bisa, tiap user punya secret key yang unique dan harus sinkron antara secret key di server dan di token. kalau sampai bisa berbagi token, artinya secret key dua nasabah itu sama, seharusnya itu tidak boleh terjadi

      • asumsinya pada saat pertama kita membuka rekening di bank si mbak teller yang cantik sebelum menyerahkan token ke nasabah maka mbak teller yang cantik dan bahenol terlebih dahulu mendaftarkan nomor register token si nasabah. nah disitu akan terjadi interaksi antara si server dan si token. bahwa token si nasabah akan terdaftar sebagai 1 milik rekening dan tdk lebih sehingga jika dipakai utk melakukan transaksi ke rekening lain akan ditolak karena tdk sinkron. begitu pemahaman saya…apakah benar mas rizki

  13. pembahasan tentang SIM / GSM donk om… ane pengen bajak hape orang….
    soalnya ga semua bank pke token fisik,,, ada juga yg msh pke sms dengan nama Mpin / Mtoken…. jadi yg harus dibajak ya hapenya dulu….. πŸ˜›

  14. mantap mas infonya..
    saya pikir tadinya kerja token itu ada 2 kemungkinan :
    1. pake chip yg bisa terhubung ke server.
    2. nyimpan OTP hingga ribuan/juataan untuk transaksi. (memory ga mungkin cukup)
    ternyata bener2 kayak programmed calkulator,
    jd memory terbatas cuma buat nyimpen pin+secret key+rumus hasilnya OTP

    mantap mas

  15. Nice article & Nice share.

    ane ampe bongkar tuh token nya gara2 penasaran. ternyata kuncinya ada di ” Match Timing ”

    Bisa nih buat nambah2 secure web ane. wekekekeke

    Thank you gan ^:)^

  16. mau tanya nih, saya coba token di luar negeri kok selalu gagal kenapa ya? token keluar angka, saya ketikkan diapprove. berhasil, tp kmudian mbalik lagi, transaksi digagalkan. apa emang ada batas daerah digunakan untuk token tersebut?

  17. wah keren banget nih infonya..
    saya memang penasaran banget sama cara kerja token internet banking
    setelah baca artikel ini, saya benar-benar tercerahkan

    Terima kasih karena udah berbagi ilmu yang sangat bermanfaat πŸ˜€

  18. menarik sekali konsep kerjanya… terutama yang jawaban mas di komentar mengenai token PLN… jika ada kesempatan coba diulas juga mas… meskipun belum diketahui pasti seperti apa yang benarnya dalam penggunaan token PLN tapi kemungkinan cryptographic hash, asimetrik kriptografi bisa juga dibahas πŸ™‚

  19. Mas, saya boleh minta sumber literartur (buku, web, atau sumber apapun) penulisan tentang cara kerja token ini mas? kebetulan saya lagi angkat topik ini untuk makalah, mungkin dari sumber literatur mas saya bisa lebih memahami tentang cara kerja token ini? terima kasih mas πŸ™‚

  20. Mas Rizki, saya pemula mau tanya nih

    antara Token dan server tidak terhubung sama sekali
    yang menghubungkan mereka be2 adalah waktu

    metode perhitungan berarti berada di kedua device (token dan server)?bener ga mas?

    jika benar yang saya tanyakan apakah si Device Token memiliki 2 mode perhitungan (Mode Self Generated (Response Only) dan Mode Challenge/Response (C/R))??

    jika ya
    bagaimana si Device Token tahu bahwa saya sedang dalam mode Mode Self Generated (Response Only) atau dalam mode Mode Challenge/Response (C/R)??

    maaf banyak tanya nih mas maklum pemula :((

    • Hapunten..,saya akan mencoba mencawab pertanyaan dari mas Arif.
      Pertama, benar yang menghubungkan antar server dengan token adalah waktu artinya waktu antara server dan token harus sinkron.
      Kedua, setelah waktu antara server dan token sinkron maka keduanya melakukan perhitungan yang sama dengan rumus yang sama yaitu algoritma Time-Based One Time Password.
      Ketiga, untuk self generate konsepnya seperti saya (server) melakukan perhitungan saat ini, Anda (token) juga melakukan perhitungan saat ini dengan rumus yang sama dengan rumus saya (server) dan hasil perhitungan kita bandingkan antar saya (server) dan Anda (token), jika sama transaksi akan di proses. Dan hasilnya pasti sama dalam rentang waktu tertentu (misalnya 3 menit).
      Keempat, untuk challenge/response konsepnya seperti : Saya (server) mempunyai pertanyaan (challenge) dan saya menjawab pertanyaan itu dengan menggunakan perhitungan algoritma TOTP sehingga saya mendapatkan jawabanya (response). Pertanyaan yang sama saya lemparkan kepada Anda (token) untuk membuktikan bahwa Anda (token) ini benar2 valid, kemudian Anda memasukkan challenge (pertnyaan) yang saya berikan baru anda melakukan perhitungan. Pertnyaan yang sama dalam waktu yang sama menggunakan algoritma yang sama pasti akan menghasilkan jawaban (response) yang sama. Kemudian jawaban dibandingkan antara Saya (server) dengan Anda (token) jika cocok maka transaksi di proses.

  21. berati kuncinya setelah memahami rumus token, kita harus tau timing dan code inti yang di kasi oleh server untuk rekening kita ya baru bisa buat token sendiri ya

  22. saya mau nanya nih. assumsi nya saya punya 2 token dari bank yg sama. Dan bila saya salah menggunakan token saat bertransaksi. misal saya transfer menggunakan bank A tp saya malah menggunakan token bank B waktu diminta challenge codenya. Tentu tidak bisakan? Pertanyaan saya, berapa kali kesalahan yg bisa membuat accont atau pun token saya terblokir ?

Webmentions

  • Cara Mendapatkan Uang Dari Internet Asli - Internet Marketing June 4, 2020

    […] Memahami Cara Kerja Token Internet Banking […]

  • Cara Mendapatkan Uang Dari Kerja Internet - Internet Marketing June 4, 2020

    […] Memahami Cara Kerja Token Internet Banking […]

  • Cara Mendapatkan Uang Dari Internet Ebook - Internet Marketing June 4, 2020

    […] Memahami Cara Kerja Token Internet Banking […]

  • Cara Mendapatkan Uang Dari Internet Hacker - Internet Marketing June 4, 2020

    […] Memahami Cara Kerja Token Internet Banking […]

  • Rahasia Cara Mendapatkan Uang Dari Internet - Internet Marketing June 4, 2020

    […] Memahami Cara Kerja Token Internet Banking […]

  • download hack key bca - trusmovies June 4, 2020

    […] Memahami Cara Kerja Token Internet Banking Ilmu Hacking […]

  • Algoritma Token OTP – Mr.Dzer0 -Blog- June 4, 2020

    […] Dalam mode C/R ada field tambahan yang harus digabungkan sebelum dihitung nilai hashnya, yaitu challenge. Nilai challenge ini diketahui oleh server dan juga oleh token (ketika user mengetikkan challenge ke token), sehingga baik token maupun server akan dapat menghitung OTP yang sama sehingga proses otentikasi dapat berlangsung. *Akhirnya Pusing juga kan setelah baca tulisan ini πŸ˜€ *Makanya saya share biar bisa dibaca dilain waktu *Selamat Menikmati Sumber […]

  • Ternyata, Kode Token Bank BRI Itu Bayar Rp 500 per Biji Lho — FWD Blog! June 4, 2020

    […] didunia memiliki satlit semacam ini, tetapi kok tidak ada token fisik? yang mau pusing, coba baca cara kerja token fisik, tapi bukan berarti tidak akan menggunakan token […]

  • makalah internet banking bca | Contoh Makalah June 4, 2020

    […] transaksi internet banking kini sudah menjadi hal yang wajib. Token ini menjadi faktor … Download Memahami Cara Kerja Token Internet Banking […]

  • E-Banking | sigitpurnomo7680 June 4, 2020

    […] http://www.ilmuhacking.com/web-security/memahami-cara-kerja-token-internet-banking/ […]

  • Membuat Web dengan Otentikasi berbasis Token | Web Security | Ilmu Hacking June 4, 2020

    […] artikel sebelumnya saya sudah menjelaskan cukup detil tentang cara kerja token yang dipakai pada internet banking. Artikel tersebut hanya menjelaskan sebatas teoretis saja, saya […]

  • Inuyasha Manga Inuyasha Hash June 4, 2020

    […] Memahami Cara Kerja Token Internet Banking | Web Security | Ilmu … […]