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:
- Something You Know
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.
- Something You Have
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.
- Something You Are
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:
- Mode Challenge/Response (C/R)
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.
- Mode Self Generated (Response Only)
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:
- Hanya boleh dipakai 1 kali
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.
- Hanya boleh dipakai dalam rentang waktu yang terbatas
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.
- Hanya boleh dipakai dalam konteks sempit
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:
- Selalu berubah-ubah secara periodik
- Memiliki umur yang singkat
- Hanya bisa dipakai 1 kali
- 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"
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:
- Mengambil waktu saat ini dalam detik berformat EPOCH (jumlah detik
sejak 1 Januari 1970), biasanya dalam granularity 10 detik, sehingga
nilai EPOCH dibagi 10.
- Menggabungkan init-secret dengan waktu saat ini dari langkah 1.
- 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:
- Detik ketika server meminta password (OTP) dari user
- Detik ketika token membangkitkan OTP
- 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.
Dalam
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.
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.
Halo
![[Image: hs.png]](http://i1133.photobucket.com/albums/m599/tsdt7wetew/hs.png)
![[Image: bayu1.jpg]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJGcu8_tcKDjQh9WHWOBgATdy4DC1HZYmLGZdgFCgRy8-auC1wtN5ksbw7FcT57x_62Re1JBj3Mcec9ieKnRpvLhxKzkY2nJeCPTOrioH7MltF4L8iTBArQZs8c4IW-mdyiAe78-TS5vTS/s400/bayu1.jpg)
![[Image: bayu2.jpg]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8pdO0849hPma7aU9InQJ55mtgxhrhuN-dOaulYa7ckSCUbnHlPK9NoyIKhaQyQldbW07ryzuCEjrZPOfkJhnJHbfr6ddMH9jREuMlSymSUEmd6_p1ZTOegi5vhun7PO361YsK3aNJBkDg/s400/bayu2.jpg)
![[Image: bayu3.jpg]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsjpOG2Fy32uo9QZl5DjtfCj_RZjN4CK_WXe4_bUR_plbS3R7PQh2HitVkJ4FiDfk4rnzP3WwvueuNPfR8h-rGcymkhylrf44YEZceRvj58zF4MmRwa-iqPTO3aiOFYCiCBxrDQG8kOUGm/s400/bayu3.jpg)
versi besar