BAB I

PENDAHULUAN
1.1 Latar Belakang
Perkembangan teknologi informasi,telekomunikasi, dan internet menyebabkan mulai
munculnya aplikasi bisnis berbasis internet. Salah satu aplikasi yang mulai mendapat
perhatian adalah Internet banking. Internt banking adalah salah satu pelayanan jasa bankyang
memungkinkan nasabah untuk memperoleh informasi, melakukan komunikasi dan
melakukan transaksi perbankan melalui jaringan internet.
Internet banking memberikan keuntungan bagi nasabah maupun bank. Bagi nasabah,
Internet banking menawarkan kemudahan dan kecepatan dalam melakukan transaksi
perbankkan. Keuntungan dari menyediakan layanan internet banking bagi bank adalah :
internet banking bisa menjadi solusi murah pengembangan infrastruktur disbanding
membuka outlet ATM, contohnya klikbca saat ini telah menggantikan fungsi 160 ATM dan
menghemat biaya percetakan formulir yang harus diisi nasabah untuk bertransaksi, brosur,
catalog, dan menggantikannya dengan data elektronik.
Tentunya internet banking belum tentu aman karena internet banking menggunakan
jaringan internet. Sedang kan jaringan internet merupakan jaringan global yang dapat diakses
oleh siapapun. Banyak kejadian negative pada jaringan dunia perbankan seperti webspoofing,
pencurian password dengan sniffing packet, dll. Pada internet banking seperti klikbca, untuk
sekadar transaksi yang bersifat informatif (tidak ada pengurangan saldo) maka cukup
menggunakan sandi lewat (password) untuk masuk, tetapi untuk transaksi yang sifatnya
memindahkan/mengurangi saldo nasabah diminta untuk memasukan pin yang dihasilkan oleh
suatu alat yang biasa disebut token atau pin. Alat ini akan mengeluarkan deretan angka
(biasanya 6 digit) yang hanya identik dengan rekening nasabah tersebut. Jadi token lain tidak
mungkin bisa digunakan pada rekening.
Penggunaan token berupa alat kecil semacam kalkulator digunakan untuk
mengamankan transaksi internet banking, dan kini sudah menjadi hal yang wajib. Token ini
menjadi faktor tambahan dalam otentikasi yaitu untuk membuktikan bahwa anda adalah
benar-benar pengguna yang sah. Token menghasilkan angka yang diketahui oleh server
internet banking tanpa terbubung dengan server.
1.2 Tujuan
Tujuan fungsi otentikasi berbasis token adalah sebagai berikut :
1. Token dapat membuat transaksi internet banking menjadi lebih safety karena
menggunakan beberapa metode Otentikasi.
2. Pengguna token dapat menghasilkan sebuah pin dari token tanpa harus
terhubung dari server klikbca, untuk proses otentifikasi sebagai pengguna yang
sah.
1.3 Metodologi
Penelitian dilakukan dengan mempelajari beberapa otentikasi untuk membuktikan
siapa pengguna sebenarnya, apakah benar-benar orang yang diklaim sebagai dia (who you
claim to be).

BAB 2
LANDASAN TEORI
2.1 Konsep dasar Otentikasi
Ketika suatu sumber data dan informasi elektronik hanya terbatas pada beberapa
individu yang berwenang, pelaku bisnis dan pelanggannya harus memiliki jaminan bahwa
tidak ada orang lain dapat mengakses informasi tersebut. Ada beberapa teknik untuk
mengatur kontrol akses ini, yaitu firewall, hak akses, identifikasi pengguna dan teknik
otentikasi (seperti password dan sertifikat digital), Virtual Private Network (VPN), dan
banyak lagi.
Ada berbagai cara untuk membuktikan siapa pengguna. Metode otentikasi
bisa dilihat dalam 4 kategori metode:
1. Something You Know
Ini adalah metode autentifikasi 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.
2. 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.
3. 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.

4. Something You Can

Metode otentikasi ini menggunakan cara tradisional seperti tanda tangan di atas
materai. Cara ini berasumsi bahwa tidak ada orang lain di dunia ini yang bisa
melakukan itu selain pengguna. Walaupun pada kenyataannya ada saja orang yang
bisa meniru tanda tangan pengguna dengan sangat baik, Namun walaupun menyadari
fakta tersebut tanda tangan di atas kertas tetap diakui sebagai bukti otentik atas siapa
pengguna.

2.1.1 Two Factor Authentication pada Token

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 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.
Internet banking menggunakan two factor authentication dengan mengombinasikan
something you know berupa password dan something you have berupa hardware token
(keyBCA atau Token Mandiri).

2.2 Mode Pemakaian Token Internet Banking

Pada umumnya ada dua mode pemakaian token internet banking:
1. 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 berbedabeda walaupun dengan challenge code yang sama secara periodik tergantung
waktu ketika challenge dimasukkan ke dalam token.
2. 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.

2.3 Keamanan dari Keterbatasan Token

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

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.

2.

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.

3.

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:
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.

BAB 3
PEMBAHASAN
3.1 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.

3.2 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
budi

Salt

Password Hash

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.

3.3 Pembangkitan One Time Password (OTP) Token Internet Banking

Cara token menghasilkan sederetan angka sebagai OTP yang bisa diotentikasi oleh
server dengan syarat agar otentikasi berhasil adalah password yang dikirim klien harus sama
dengan yang disimpan di server. Dan password yang dihasilkan token selalu berubah-ubah
secara periodik. Apa yang dihasilkan token bisa sinkron dengan server padahal alat tersebut
tidak terhubung dengan server, dan bagaimana server bisa tahu berapa nilai yang dihasilkan
token adalah dengan waktu. 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)
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 dijelaskan 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.

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.
Salt jika 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.

BAB 4
KESIMPULAN

Dari pembahasan pada bab-bab sebelumnya maka penulis dapat menarik kesimpulan sebagai
berikut:
1. Pengamanan suatu web merupakan hal yang sangat diperlukan mengingat pentingnya
suatu data pribadi atau data suatu perusahaan.
2. Penggunaan mekanisme otentikasi multi faktor mampu meningkatkan keamanan
sistem jaringan dalam proses otentikasi ke server di banding menggunakan otentikasi
satu faktor saja (username dan password).
3. Dengan multi faktor otentikasi sebuah organisasi dapat menjamin bahwa hanya user
yang berhak dan terdaftar saja yang dapat masuk ke dalam sistem.
4. Hasil Angka dari token dapat diketahui oleh server karena sebelumnya, 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.
5. Cara token menghasilkan sederetan angka sebagai OTP yang bisa diotentikasi oleh
server dengan syarat agar otentikasi berhasil adalah password yang dikirim klien
harus sama dengan yang disimpan di server.

DAFTAR PUSTAKA
http://coretanaba.blogspot.com/2011/10/fungsi-token-dalam-internet-banking.html
http://www.ilmuhacking.com/web-security/memahami-cara-kerja-token-internetbanking/
http://www.ilmuhacking.com/web-security/membuat-web-dengan-otentikasiberbasis-token/
http://banking.blog.gunadarma.ac.id/2012/05/01/sistem-keamanan-yang-baik-padainternet-bangking/