Mengenal OpenID

openid logo

Setiap anda akan mengakses bank account, social network, email dan layanan lain, anda memerlukan identitas digital. Dalam artikel ini saya membahas tentang OpenID sebagai bentuk baru identitas digital anda  yang akan memudahkan mengelola identitas anda.

Security pada OpenID akan saya bahas pada artikel saya berikutnya, dalam artikel ini sifatnya hanya konsep dasar dan perkenalan.

Digital Identity

Identitas adalah atribut yang membuat berbeda dengan yang lain.

Identitas adalah kumpulan atribut yang membedakan sesuatu dengan yang lainnya. Nama saja tidak bisa dijadikan identitas seseorang karena kemungkinan banyak orang yang bernama sama. Biasanya identitas seseorang ditunjukkan dengan ID Card yang berisi kumpulan atribut, antara lain: nama, alamat, tanggal lahir. Bila nama saja tidak cukup membedakan seseorang dengan yang lain, maka kumpulan dari nama, alamat, tanggal lahir akan membuatnya unik (berbeda dengan yang lain).

Berbeda dengan di dunia nyata, di internet biasanya nama (username) atau alamat email memang harus unik dari awalnya. Tidak mungkin ada alamat email yang sama untuk dua orang yang berbeda, sehingga umumnya username atau email bisa dijadikan identitas. Khusus untuk username, biasanya keunikannya hanya relatif terhadap satu website/domain saja. Misal, bila kita punya username rizki di detik.com, kita boleh juga membuat username yang sama di facebook.com.

On the Internet, Nobody Knows You‘re a Dog

Di internet, anda bisa menjadi siapa saja yang anda mau. Mau jadi diri sendiri, silakan. Mau menyamar jadi orang lain juga boleh. Sangat sulit bagi orang lain untuk bisa mengetahui siapa anda sebenarnya. Hal ini karena identitas anda di internet diwakilkan dalam bentuk username dan password. Siapapun yang mengetahui username dan password anda, akan bisa memakai identitas anda dan semua orang akan menganggap dia adalah anda.

Identitas digital sangat mudah dibuat, cukup dengan memasukkan beberapa data pada saat signup/register di suatu web, maka anda telah membuat identitas baru untuk anda. Karena mudah dibuat, maka identitas digital kurang bisa dipercaya. Agar identitas digital memiliki kredibilitas yang kuat, maka perlu didukung dengan proses verifikasi manual.

Salah satu contoh digital identitas yang kredibilitasnya kuat adalah SSL certificate. SSL certificate adalah bentuk bukti identitas suatu server. Dalam sertifikat tersebut tertera nama domain, nama perusahaan dan deskripsi lainnya. Data-data tersebut telah melalui proses verifikasi yang ketat oleh Certificate Authority (CA) sehingga dijamin datanya benar, bukan fiktif.

Contoh lain adalah Paypal. Pengguna Paypal harus memasukkan nomor kartu kredit yang akan dipakai untuk bertransaksi. Dalam Paypal account terbagi dalam dua macam, Verified dan non-Verified. Apa bedanya? Bedanya adalah verified account telah melalui verifikasi manual untuk memastikan bahwa anda adalah pemilik kartu kredit yang anda daftarkan tersebut. Caranya adalah dengan memasukkan sebuah kode dalam tagihan kartu kredit anda. Anda harus menunggu sampai tagihan kartu kredit anda bulan berikutnya tiba, kemudian memasukkan kode yang tertera di dalamnya. Bila kode yang anda masukkan benar, berarti anda telah membuktikan bahwa anda memang benar pemilik kartu kredit yang anda daftarkan dalam Paypal. Hal ini karena hanya pemilik kartu kredit yang sah yang bisa membaca lembar tagihan, kecuali bila anda mencuri surat tagihan kartu kredit milik orang lain.

Hal ini berbeda dengan identitas anda di jaringan social seperti Facebook. Dalam facebook anda bisa menjadi siapa saja karena tidak ada verifikasi manual di Facebook. Untuk menjadi seorang selebritas, anda cukup mendaftar dengan nama dan data umum selebritas tersebut, kemudian upload foto-fotonya. Dengan begini, kini anda telah menjadi seorang selebritas di Internet. Tidak akan ada yang bisa membedakan, apakah anda memang benar-benar selebritas, atau orang biasa yang menyamar.

Too Many Identity Problem

how to effectively manage multiple identities at many web sites that a user has to interact with

Kemudahan membuat identitas digital membuat satu orang bisa memiliki banyak identitas. Hal ini menjadi masalah, karena seseorang harus mengelola banyak identitias untuk web yang berbeda-beda. Bila identitas sudah terlalu banyak, orang cenderung untuk melakukan hal yang terlarang, antara lain membuat password yang terlalu lemah, mencatat password di kertas dan membuat password yang sama untuk semua web.

Bila seseorang menggunakan password yang sama untuk semua web, maka bila ada satu saja web yang diikuti korban berhasil ditembus dengan sql injection atau bug lainnya, maka attacker itu bisa mengakses semua account milik korban dengan mudah. Ini sangat berbahaya.

Dari sisi server kita tahu bahwa tidaklah mudah membuat authentication yang tingkat keamanannya tinggi. Banyak kasus hacking yang disebabkan karena authentication yang tidak aman. Salah satu yang cukup sering terjadi adalah sql injection di halaman login. Selain itu halaman authentication yang aman seharusnya menggunakan SSL (https), bukan http biasa karena http tidak mengenkrip paket datanya.

Namun tidak mudah dan murah biayanya untuk membuat halaman authentication yang aman. Sehingga tidak heran bila sebagian besar halaman authentication di web tidak menggunakan https. Bila ada seseorang yang memiliki banyak account dengan password yang sama. Bila ada salah satu web saja yang tidak secure dan membuat passwordnya berhasil di sniff, maka semua account lainnya akan terancam juga.

Jadi baik dari sisi klien maupun dari sisi server, terlalu banyak identitas menimbulkan masalah. Oleh karena itu dibutuhkan identitas digital tunggal yang diterima di banyak tempat.

URL as Single Universal Identity

Kita telah melihat bahwa terlalu banyak identitas membuat masalah yang berbahaya, mempunyai banyak identitas terkadang diperlukan untuk beragam kondisi. Namun memiliki terlalu banyak identitas bisa melukai pemiliknya karena username, password dan data lain milik user bertebaran di banyak tempat menunggu untuk dicuri cracker.

OpenID adalah protokol terbuka yang memungkinkan seseorang menggunakan URL sebagai identitas tunggal yang diterima di banyak tempat. Apa maksudnya, URL kok dijadikan identitas?

URL  bisa dibayangkan sebagai petunjuk untuk mencapai lokasi yang mengandung sesuatu yang berharga

Kembali ke URL sebagai identitas. Bagaimana logikanya? Identitas menunjukkan siapa anda, yang biasanya diwakilkan dengan identifier/nama. Jadi sebenarnya sederhana saja, URL bisa dianggap sebagai identifier/nama, jadi bisa juga dipakai sebagai identitas. Misalkan kalau ada yang bertanya, siapa anda? Saya bisa menjawab dengan “Saya Rizki”, atau bisa juga menjawab dengan “Saya rizkiwicaksono.pip.verisignlabs.com”.

URL sebagai identifier sebenarnya lebih baik dibanding nama orang, karena URL adalah unik, kalau saya sebutkan saya adalah rizki, tentu banyak orang lain yang punya nama yang sama. Tapi kalau saya bilang, “saya rizkiwicaksono.pip.verisignlabs.com” tidak akan ada kembarannya, karena URL menunjukkan satu lokasi yang unik.

Example of URL Authentication

Identitas tentu sangat erat kaitannya dengan authentication yang fungsinya untuk memastikan siapakah anda. Bagaimanakah authentication dari identitas yang berupa URL? Anda tentu ingat bahwa URL adalah petunjuk lokasi.

Bayangkan bila anda menyebutkan identitas anda bahwa “Saya adalah Jl. Sudirman no. 17″, itu adalah klaim identitas anda yang harus dibuktikan dengan authentication. Orang lain akan percaya bahwa anda adalah “Jl Sudirman no. 17″, bila anda bisa membuktikan bahwa anda adalah pemilik properti di lokasi itu. Salah satu cara membuktikannya adalah dengan menunjukkan surat/akta kepemilikan.

Mirip dengan contoh itu, dalam URL. Salah satu bentuk authentication adalah anda harus bisa membuktikan bahwa anda benar pemilik lokasi yang ditunjukkan oleh URL itu. Bila URL itu menunjukkan alamat web, maka anda harus bisa memasukkan sebuah file, atau mengubah teksnya menjadi sesuatu yang lain. Bila anda bisa, maka orang akan yakin anda benar pemilik URL itu.

Bagi yang pernah memakai Google Analytics tentu tahu, cara untuk membuktikan bahwa anda adalah pemilik web, adalah dengan membuat sebuah file kosong yang namanya telah ditentukan google. Kemudian google akan mengakses file tersebut, bila hasilnya 200 OK, maka anda telah lolos verifikasi google analytics. Berarti klaim anda benar, bahwa web itu memang benar milik anda.

Oke, yang saya sebutkan di atas hanyalah contoh sederhana authentication sebuah URL untuk menunjukkan bahwa URL bisa dipakai sebagai identitas yang sah karena bisa diotentikasi. Faktanya OpenID jauh lebih kompleks dari sekedar memasukkan sebuah file seperti verifikasi yang dilakukan oleh google analytics.

Terminologi

Beberapa istilah yang perlu saya jelaskan sebelum saya masuk pembahasan teknis openid adalah:

• End user: pengguna.
• Consumer/Relying Party: website yang mendukung openid, anda bisa login dengan openid di situs ini.
• Identifier: URL openid.
• Identity provider: server yang mengelola account openid pengguna. Server inilah yang menangani authentication openid account anda. Jadi sebelum bisa mengakses consumer website anda harus login dulu di server identity provider.
• User agent: web browser pengguna.

Creating OpenID

Agar lebih memahami openID, saya akan menunjukkan pembuatan dan pemakaian OpenID. Dalam contoh ini saya menggunakan OpenID provider milik Verisign yaitu Personal Identity Portal. Untuk mendaftar klik ke PIP Portal Verisign, di https://pip.verisignlabs.com. Kemudian klik tombol Get Started Now.

sign up button

Setelah itu masukkan username, password dan email anda.Dalam contoh ini saya menggunakan username ilmuhacking.

sign up form

Setelah selesai, anda akan menerima email konfirmasi dan account PIP anda sudah siap digunakan.

openid created

Sangat mudah bukan membuat openID, hanya perlu 3 langkah saja. OpenID yang baru saya buat adalah “ilmuhacking.pip.verisignlabs.com”. URL tersebut adalah identifier identitas saya yang bisa saya pakai untuk login ke web yang mendukung OpenID. Dalam satu account PIP tersebut saya bisa membuat banyak identitas OpenID, jadi sesuai dengan namanya Personal Identity Portal, jadi PIP itu semacam portal/gerbang untuk identitas pribadi saya. Cukup dengan satu account (username+password) PIP, saya bisa membuat dan memakai banyak identitas OpenID.

multiple openID

Dengan punya banyak identitas dalam satu account, saya bisa menggunakannya untuk kondisi yang berbeda. Misalkan di situs yang terkait dengan hacking, saya pakai “ilmuhacking.pip.verisignlabs.com”, namun bila di situs yang sifatnya umum, saya pakai “masrizki.pip.verisignlabs.com”.

Using OpenID in LiveJournal

livejournal openID

Sebagai contoh pemakaian OpenID, saya menggunakan contoh LiveJournal, yang dalam hal ini bertindak sebagai consumer website. Sebelumnya saya akan logout dulu dari PIP. Untuk Login di Livejournal dengan OpenID, klik link “Login w/ OpenID“. Dalam contoh ini saya menggunakan “ilmuhacking.pip.verisignlabs.com” sebagai identitas saya. Setelah saya klik tombol Login, maka LiveJournal akan redirect ke PIP Verisignlabs.

Berhubung saya sudah mengaktifkan setting “Sign in Security”, maka yang muncul bukan halaman login PIP, tapi peringatan bahwa saya harus login dulu ke PIP dengan cara mengetikkan URL: http://pip.verisignlabs.com/login.do.  Bila settings “Sign in Security” tidak diaktifkan, maka saya akan langsung diarahkan ke halaman login PIP.

Setelah saya login ke PIP, kemudian saya harus mengulang lagi memasukkan OpenID URL saya di LiveJournal. Kali ini karena saya sudah login (session PIP masih hidup di browser saya), saya tidak perlu login ke PIP dulu dan saya langsung masuk ke halaman verifikasi berikut:

verifikasi

Di situ saya diminta untuk memverifikasi, apakah benar ilmuhacking adalah OpenID saya. Saya juga diminta menentukan hubungan trust dengan situs LiveJournal, bila saya tetapkan Never Expire maka berikutnya saya  tidak diminta verifikasi situs LiveJournal.com seperti ini. Namun bila saya setting Expire After Sign In, maka saya hanya mengijinkan untuk login kali ini saja, login berikutnya saya akan ditanyakan verifikasi lagi.

welcome back to livejournal

Setelah verifikasi, saya masuk ke halaman pribadi LiveJournal.com karena saya sudah berhasil login dengan OpenID. Saya tidak pernah mendaftar di situs ini, tapi saya mendaftar di PIP sekali saja, dan saya bisa langsung memakai LiveJournal dan banyak situs lainnya, menyenangkan bukan?

Using OpenID in CommonGate

commongate openid login

Pada contoh sebelumnya saya sudah menunjukkan pemakaian OpenID di situs LiveJournal. Biar lebih mantap, saya akan coba lagi untuk consumer website yang lain, yaitu CommonGate.com. Kali ini saya menggunakan identitas “masrizki.pip.verisignlabs.com”, ingat di awal saya sudah ceritakan bahwa identitas masrizki.pip.verisignlabs.com dan ilmuhacking.pip.verisignlabs.com adalah dua OpenID dalam satu account PIP yang sama, yaitu username ilmuhacking.

Dalam keadaan session PIP saya masih hidup (belum logout) dengan account ilmuhacking, saya masukkan URL OpenID saya di commongate.com seperti pada gambar di atas. Sekali lagi, karena session PIP saya masih hidup, maka saya langsung diarahkan pada halaman verifikasi, karena ini adalah situs baru yang belum pernah saya percayai.

confirmation commongate

Berbeda dengan LiveJournal yang hanya meminta expiration date saja, kali ini commongate meminta beberapa data seperti tanggal lahir, negara, bahasa. Data tersebut adalah data yang sudah saya masukkan sebelumnya ketika saya membuat OpenID di PIP. Jadi sekarang saya tidak perlu repot-repot mengisinya lagi, saya tinggal tentukan tanggal expired hubungan trus commongate.com dengan PIP saya. Untuk mudahnya saya pilih Never Expire.

commongate profile page

Setelah melalui verifikasi, saya langsung diarahkan ke halaman home saya di commongate seperti pada gambar di atas. Karena saya memilih Never Expire, jadi berikutnya dengan session PIP yang masih aktif, ketika saya login di commongate dengan OpenID, saya akan langsung masuk ke halaman profile saya di commongate. Perhatikan pada gambar tersebut, username, country dan gender sudah terisi dengan benar karen field tersebut diambil dari data saya di PIP tanpa perlu saya memasukkan secara manual. Field location masih salah karena memang tidak ada field location di PIP.

Using Different URL

Sebelumnya saya selalu menggunakan “masrizki.pip.verisignlabs.com” dan “ilmuhacking.pip.verisignlabs.com” sebagai identifier OpenID saya. Karena saya membuat OpenID di PIP Verisignlabs (Verisignlabs adalah Identity Provider), maka URL saya defaultnya adalah menggunakan URL yang diberikan oleh PIP.

Sebenarnya URL openID tidak harus sama dengan URL identity provider. Fungsi dari URL OpenID adalah sebagai tempat untuk meng-host html dokumen yang mengandung petunjuk di mana alamat Identity Provider yang dipakai. Mari kita lihat source html dari URL http://masrizki.pip.verisignlabs.com/ :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <link rel="openid.server" href="http://pip.verisignlabs.com/server" /> <link rel="openid2.provider" href="http://pip.verisignlabs.com/server" /> <meta http-equiv="X-XRDS-Location" content="http://pip.verisignlabs.com/user/masrizki/yadisxrds" /> <title>Identity Endpoint For masrizki</title> </head> <body>   <p>This is an identity endpoint for&nbsp;masrizki</p> <p>For more information, please visit <a href="http://pip.verisignlabs.com">http://pip.verisignlabs.com</a></p> </body> </html>

Informasi yang penting hanyalah pada baris ke-5,6 dan 7. Pada baris ke-5 dan 6 terlihat bahwa openid server yang dipakai adalah http://pip.verisignlabs.com/server. Sedangkan pada baris-7 menunjukkan lokasi file XRDS (eXtensible Resource Descriptor Sequence) yang merupakan file XML yang mendeskripsikan openID saya.

Isi dari file XRDS tersebut adalah berikut ini:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

<?xml version="1.0" encoding="UTF-8"?> <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD>   <Service priority="0"> <Type>http://specs.openid.net/auth/2.0/signon</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/extensions/sreg/1.1</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/multi-factor</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical</Type> <URI>http://pip.verisignlabs.com/server</URI> <LocalID>http://masrizki.pip.verisignlabs.com/</LocalID> </Service>   <Service priority="1"> <Type>http://openid.net/signon/1.1</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/extensions/sreg/1.1</Type> <URI>http://pip.verisignlabs.com/server</URI> <openid:Delegate>http://masrizki.pip.verisignlabs.com/</openid:Delegate> </Service>   </XRD> </xrds:XRDS>

Sebagai contoh saya akan membuat URL : masrizki.ilmuhacking.com sebagai identifier OpenID saya. Saya harus membuat index.html di url itu berisi:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head>   <link rel="openid.server" href="http://pip.verisignlabs.com/server" /> <link rel="openid.delegate" href="http://masrizki.pip.verisignlabs.com" /> <link rel="openid2.provider" href="http://pip.verisignlabs.com/server" /> <link rel="openid2.local_id" href="http://masrizki.pip.verisignlabs.com" /> <meta http-equiv="X-XRDS-Location" content="http://pip.verisignlabs.com/user/masrizki/yadisxrds" />   <title>OpenID MasRizki</title> </head> <body> <h1>OpenID MasRizki</h1> </body> </html>

masrizki.ilmuhacking.com

Kalau dibuka di browser URL tersebut akan tampak seperti gambar disamping. Setelah file htmlnya dibuat, kini saya siap menggunakan masrizki.ilmuhacking.com sebagai identifier saya, bukan lagi memakai masrizki.pip.verisignlabs.com yang menurut saya terlalu panjang. Mari kita coba identifier baru tersebut dalam sniffo.org.

Setelah saya membuka halaman depan sniffo.org dan login, prosesnya terlihat pada gambar di bawah ini.

sniffo.org login using openid

Terlihat pada gambar di atas saya login di sniffo.org menggunakan OpenID identifier: masrizki.ilmuhacking.com. Karena situs itu masih baru, belum ada trust, maka PIP meminta saya untuk menentukan waktu expired trust. Walaupun identifiernya terletak pada host masrizki.ilmuhacking.com, namun authentication tetap dihandle oleh VerisignLabs sebagai OpenID Provider. Jadi masrizki.ilmuhacking.com hanya sebagai nama (identifier) saja, semua proses authentication selanjutnya dihandle oleh PIP Verisignlabs. Proses ini disebut dengan authentication delegation karena host ilmuhacking.com mendelegasikan otentikasi ke PIP Verisignlabs. Instruksi delegate ini bisa diketahui dari dokumen html yang diambil dari url masrizki.ilmuhacking.com pada baris ke-7 yaitu:

<link rel="openid.delegate" href="http://masrizki.pip.verisignlabs.com" />

Baris di atas menunjukkan bahwa masrizki.ilmuhacking.com mendelegasikan otentikasi kepada masrizki.pip.verisignlabs.com. Sehingga selanjutnya proses otentikasi diarahkan ke Verisignlabs. Dengan begini saya bisa membuat identifier apapun yang saya mau, tanpa perlu repot menjadi OpenID Provider. URL untuk identifier OpenID benar-benar bebas, anda bisa membuat identifier misalkan: www.foobar.or.id/namaku/, yang terpenting pada URL tersebut terdapat file html yang menunjukkan delegasi OpenID provider yang dipakai.

Centralized vs Distributed Session Management

SSO (single sign on) adalah teknologi yang memungkinkan pengguna hanya perlu login sekali saja untuk bisa menikmati banyak layanan. Cara pengelolaan session dalam SSO ada dua macam:

• Centralized: hanya ada satu session saja untuk mengakses semua layanan. Contohnya adalah layanan google dan yahoo.
• Distributed: setiap website memiliki session masing-masing yang saling independent. Openid adalah salah satu contoh SSO yang memakai distributed session.

4 independent session: distributed session

OpenID provider (dalam artikel ini PIP Verisignlabs), hanya mengurus soal authentication, dan tidak bertanggung jawab untuk mengurus session consumer web (livejournal,commongate,sniffo).

Pada gambar di samping terlihat ada 4 session yang terpisah dan satu sama lain saling independent. Bila anda sudah login ke PIP, pada browser anda nanti akan ada session cookie khusus untuk OpenID Provider. Selama session ini masih hidup anda tidak perlu lagi memasukkan password setiap kali memakai openid.

Session untuk masing-masing consumer website dikelola secara mandiri dan tidak ada hubungannya dengan session OpenID provider. Jadi bila anda sudah login ke PIP, kemudian dengan OpenID login ke LiveJournal, CommonGate dan Sniffo, berarti pada browser anda akan ada 4 session cookie yang berbeda, satu untuk openid provider, dan 3 untuk consumer website (livejournal,commongate,sniffo).

Logout dari openid provider, tidak akan membuat anda logout dari consumer website

Bila anda logout dari salah satu consumer website, maka anda tetap bisa memakai layanan di consumer website yang lain. Logout dari satu consumer website hanya mematikan session consumer web itu saja, tidak berpengaruh sama sekali pada session di web lainnya.

single session google network: centralized session

Salah satu contoh implementasi SSO yang terpusat adalah layanan dari yahoo dan google seperti terlihat pada gambar di samping. Pada yahoo/google user cukup sign-on sekali saja, kemudian dia bisa membaca email, chatting dan menggunakan layanan lain tanpa perlu ditanyakan password lagi. Begitu pula sebaliknya, bila user logout dari salah satu layanan, maka user tersebut akan logout dari seluruh network, sehingga tidak bisa mengakses layanan yang lain.

Di Balik Layar

Setelah mencoba berbagai situs yang mendukung OpenID dengan identifier yang dari PIP dan identifier yang dibuat sendiri. Kini tiba saatnya saya untuk menjelaskan apa yang sebenarnya terjadi di balik layar.

Indirect vs Direct Communication between Consumer and Provider

Dalam openid ada 3 entitas yang terlibat, yaitu User Agent (browser yang dipakai user), consumer website (relying party), dan openid provider. Komunikasi yang terjadi di antara ketiganya bisa dilakukan secara langsung atau tidak langsung, semuanya menggunakan protokol HTTP. Pada gambar di samping terlihat gambaran komunikasi secara langsung dan tidak langsung. Komunikasi secara langsung menggunakan HTTP POST, sedangkan komunikasi tidak langsung menggunakan HTTP GET melalui browser Redirect. Pada komunikasi tida langsung, request dikirimkan dalam bentuk http response 302 (redirect), kemudian browser user akan melakukan GET request pada url yang tertera pada header Location. Begitu pula sebaliknya, response juga akan dikirimkan melalui user dengan mengirimkan 302 redirect terlebih dahulu.

Komunikasi yang terjadi di openid ada dua mode:

• Dumb Mode
Pada mode “bodoh” ini, consumer tidak memiliki ingatan, sehingga tidak menyimpan state koneksi antara consumer dan provider. Dalam mode ini percakapan berlangsung lebih banyak karena banyak percakapan yang harus diulang lagi karena “lupa terus”.
• Smart Mode
Pada mode smart, consumer mengingat state koneksi antara consumer dan provider. Hal yang diingat terutama adalah shared secret key, yang dipakai untuk menjaga integritas pesan dengan fungsi HMAC. Dengan mengingat shared key ini, consumer tidak perlu lagi melakukan verifikasi setelah user di-redirect ke consumer website dari openid provider (untuk lebih jelasnya lihat langkah 1-7 di bawah ini).

Alur authentication openid diperlihatkan pada gambar di bawah ini. Gambar tersebut diambil dari white paper Eugene Tsyrklevich dan Vlad Tsyrklevich pada acara BlackHat USA 2007. Pada gambar di bawah ini komunikasi tidak langsung terjadi pada langkah nomor 4 dan 7, yaitu redirect. Sedangkan komunikasi langsung terjadi pada langkah nomor 3, yaitu negotiate crypto keys.

openid authentication flow

Gambar tersebut memperlihatkan alur ketika user login ke consumer website atau relying party. Penjelasan dari skenario pemakaian OpenID tersebut:

1. Login with openid URL
User membuka halaman consumer website (misal livejournal.com) dan login dengan memasukkan identifier openidnya, misal: masrizki.ilmuhacking.com
2. Download openid URL
Livejournal mengakses url http://masrizki.ilmuhacking.com dan menerima file html.
3. Negotiate crypto keys
Dari html yang didapat di url masrizki.ilmuhacking.com, livejournal menemukan delegation server di http://masrizki.pip.versignlabs.com. Di balik layar, livejournal berkomunikasi secara langsung dengan server openid provider pip.verisignlabs.com dengan protokol HTTP untuk menegosiasikan kunci kriptografi yang akan dipakai bersama. Kunci ini dipakai untuk menjaga integritas pesan antara consumer dan provider.
Openid memakai HMAC (Hash Message Authentication Code) untuk menjaga integritas pesan, oleh karena itu kedua pihak harus mengetahui kunci rahasia yang sama. Pertukaran kunci rahasia menggunakan protokol Diffie Helman.
4. Redirect
Karena user belum login ke pip verisign, maka livejournal mengirimkan perintah redirect ke halaman login pip verisignlabs.
5. Enter password
User memasukkan password di halaman login pip.
6. Authorize RP
Bila authentication berhasil (password benar), maka pip verisignlabs, akan meminta user untuk meng-otorisasi relying parter (livejournal.com). Bila user men-set Allow untuk selamanya (Never Expire), maka berikutnya tidak akan dimintai konfirmasi seperti ini.
7. Redirect
Provider berkomunikasi dengan consumer secara tidak langsung melalui browser user dengan mengirimkan perintah Redirect. Informasi yang dikirimkan dari provider ke consumer adalah status authentication, apakah sukses atau gagal. Bila authentication sukses, maka consumer web akan mengijinkan user mengakses consumer website dan mensetup session antara user dan consumer.
Langkah ke-7 adalah langkah terakhir bila menggunakan mode smart. Namun bila memakai mode dumb, ada satu langkah tambahan yaitu verifikasi. Verifikasi ini berguna untuk memastikan bahwa user yang bersangkutan benar-benar telah ter-otentikasi (autenticated) di provider, sehingga mencegah attacker yang ingin menipu consumer dengan request palsu.
Consumer akan mengirimkan request HTTP POST ke provider dengan membawa semua parameter yang diterima dari hasil redirect browser (langkah ke-7). Kemudian provider akan menjawab request tersebut dengan status valid atatu tidak valid.

Kesimpulan

OpenID menjanjikan solusi untuk mengelola identitas digital lebih baik dan lebih mudah. Dalam artikel ini saya hanya menjelaskan basic concept dan sekilas komunikasi openid. Penjelasan teknis dan detil komunikasi yang terjadi tidak saya expose di sini, saya akan expose dalam artikel berikutnya sekaligus membahas tentang keamanan openid.

Read more »

Memahami Authentication dan Authorization

Pemahaman akan authentication dan authorization sangat penting karena semua proses security berpusat pada dua hal itu.

Banyak orang yang masih bingung dengan kedua istilah penting itu. Banyak yang mengira bahwa authentication dan authorization itu sama, padahal keduanya sangat berbeda.

Salah satu tujuan dari security adalah menjamin agar resource hanya boleh diakses oleh orang yang berhak dan orang yang berhak itu bisa mengakses resource tanpa halangan.

Bayangkan dalam satu pesawat umum terdapat dua kelas penumpang, yaitu kelas VIP dan kelas ekonomi. Prosedur dan proses security harus menjamin agar penumpang menempati tempat duduk sesuai haknya. Untuk itu penumpang harus menunjukkan bukti berupa tiket yang di situ tertera namanya. Kemudian dari daftar penumpang pramugari akan tahu bahwa anda berhak duduk di kelas VIP atau ekonomi. Bila anda memegang tiket ekonomi mencoba duduk di kelas VIP maka pramugari akan menolak anda. Apalagi bila anda tidak memegang tiket, mencoba naik pesawat itu, sudah pasti anda akan ditendang.

Authentication: Proof That You are Who You Claim to Be

Sebelum bisa memberikan layanan kepada pengguna, penyedia layanan perlu tahu siapa anda. Jika anda menyatakan bahwa anda adalah Tukul Arwana, maka buktikanlah bahwa anda memang Tukul. Proses membuktikan siapa anda (identitas) inilah yang disebut authentication. Bila authentication berhasil, maka akan terjalin hubungan trust antara pemberi layanan dan pengguna layanan.

Salah satu bukti identitas yang bisa diterima adalah informasi rahasia. Logikanya adalah bila ada orang yang bisa menyebutkan suatu rahasia yang tidak mungkin orang lain tahu kecuali Tukul, maka saya akan yakin bahwa orang itu adalah benar-benar Tukul.

Bukti identitas lain yang bisa diterima adalah sesuatu yang unik, hanya dimiliki oleh satu orang saja di seluruh dunia. Logikanya adalah bila ada orang yang membawa barang yang hanya mungkin dimiliki Tukul, maka saya akan yakin bahwa dia adalah benar-benar Tukul. Dalam film kungfu cina biasanya pejabat utusan Kaisar akan membawa stempel kerajaan. Stempel ini adalah metode authentication yang sangat ampuh. Siapa saja yang memegang stempel itu otomatis identitasnya dijamin sebagai utusan kaisar.

Metode authentication yang berbasis pada kerahasiaan informasi adalah:

• Password/PIN: Hanya pemiliknya yang tahu password/pin.
• Digital Certificate: Berbasis pada asymmetric cryptography yang mengandung informasi rahasia yaitu private key.
• Private Key: Hanya pemiliknya yang tahu private key, orang lain hanya tahu public key.

Sedangkan metode authentication yang berbasis pada keunikan adalah:

• Retina: Tidak mungkin ada 2 orang yang pola retinanya sama.
• Fingerprint: Tidak mungkin ada 2 orang yang sidik jarinya sama.
• Paspor: Hanya pemiliknya yang bisa menunjukkan foto di paspor sesuai dengan wajahnya.
• Tandatangan: Hanya pemiliknya yang bisa menuliskan tandatangan dengan sempurna.

Setelah terjalin hubungan trust, selanjutnya layanan apa yang bisa dinikmati pengguna tergantung dari proses authorization.
Authorization: What are You Allowed to Do

Authorization adalah proses menentukan apa sajakah layanan yang bisa dinikmati pengguna yang telah jelas identitasnya (authenticated user). Jadi sebelum ada authorization, harus melalui proses authentication. Identitas yang telah dibuktikan di proses authentication menjadi dasar untuk menentukan layanan yang berhak dinikmati seorang pengguna.

Logikanya adalah tanpa mengetahui siapa anda, saya tidak tahu apa saja yang boleh dan tidak boleh untuk anda. Jadi tanpa authentication tidak ada authorization. Contohnya setelah saya tahu anda adalah Tukul Arwana, maka saya tahu anda boleh memandu acara empat mata, dan tidak boleh memandu di acara Dorce Show. Biasanya pengguna yang tidak ter-otentikasi (anonymous guest) tetap bisa menikmati layanan, namun dengan akses yang sangat terbatas.

Hubungan antara client,server,authentication dan authorization system bisa dilihat pada gambar di atas. Client sebelum bisa menikmati layanan server harus melalui proses authentication. Setelah authentication berhasil akan terjalin hubungan trust antara client dan server sehingga cukup sekali saja authentication sampai client logout/keluar. Selanjutnya setiap ada permintaan layanan, server akan menghubungi system authorization untuk menentukan apakah client tersebut berhak atas layanan yang dimintanya.

Souce code

Read more »

Malware Terbaru

Malware Target Rekening Bank
'Gameover' Delivered Via Phishing E-Email


Penjahat cyber telah menemukan cara lain untuk mencuri uang susah payah Anda: skema phishing terakhir melibatkan spam e-mail-konon dari National Automated Clearing House Association (NACHA), Federal Reserve Bank, atau Federal Deposit Insurance Corporation (FDIC )-yang dapat menginfeksi komputer penerima dengan malware dan memungkinkan akses ke rekening bank mereka.
Malware ini tepat disebut "gameover" karena setelah itu pada komputer Anda, dapat mencuri username dan password dan mengalahkan metode umum otentikasi pengguna yang dipekerjakan oleh lembaga keuangan. Dan sekali para penjahat masuk ke rekening bank Anda, itu jelas "permainan berakhir."
Gameover adalah varian baru dari malware Zeus, yang diciptakan beberapa tahun lalu dan secara khusus ditargetkan informasi perbankan.

Bagaimana Cara Melindungi Diri Anda? - Jelas, pastikan software anti-virus komputer Anda adalah up to date. - Jangan mengklik lampiran e-mail dari pengirim yang tidak diminta. NACHA, FDIC, dan Federal Reserve semua mengatakan mereka tidak mengirimkan e-mail yang tidak diminta untuk pemegang rekening bank. Jika Anda ingin mengkonfirmasi ada masalah dengan account Anda atau salah satu transaksi terakhir Anda, hubungi institusi keuangan Anda secara langsung. - Jangan menerima pekerjaan yang tidak diminta online yang mengharuskan Anda untuk menerima dana dari rekening bank banyak dan kemudian mentransfer uangnya ke luar negeri rekening-Anda bisa terjebak dalam penyelidikan kriminal.

Bagaimana skema kerjanya: Biasanya, Anda menerima e-mail yang tidak diminta dari NACHA, Federal Reserve, atau FDIC mengatakan bahwa ada masalah dengan rekening bank Anda atau transaksi ACH terakhir. (ACH singkatan Automated Clearing House, sebuah jaringan untuk berbagai transaksi keuangan di AS) Pengirim telah memasukkan link dalam e-mail untuk Anda yang konon akan membantu Anda menyelesaikan apa pun masalah ini. Sayangnya, link masuk ke website palsu, dan sekali Anda berada di sana, Anda secara tidak sengaja men-download malware gameover, yang segera menginfeksi komputer Anda dan mencuri informasi perbankan Anda.
Setelah pelaku mengakses account Anda, mereka melakukan apa yang disebut distributed denial of service, atau DDoS, serangan dengan menggunakan botnet, yang melibatkan beberapa komputer membanjiri server lembaga keuangan dengan lalu lintas dalam upaya untuk menolak pemakai resmi mengakses situs-mungkin di upaya untuk mengalihkan perhatian dari apa yang orang-orang jahat lakukan.
Tapi itu bukan akhir dari skema: penyelidikan terbaru menunjukkan bahwa sebagian dana dicuri dari rekening bank pergi ke arah pembelian batu mulia dan jam tangan mahal dari high-end toko perhiasan. Para penjahat menghubungi toko-toko perhiasan, katakan kepada mereka apa yang mereka ingin membeli, dan berjanji mereka akan mentransfer uang itu keesokan harinya. Jadi keesokan harinya, seseorang yang terlibat dalam aspek pencucian uang dari kejahatan-disebut "bagal uang"-datang ke toko untuk mengambil barang dagangan. Setelah memverifikasi bahwa uang itu di rekening toko, perhiasan itu diserahkan ke bagal, yang kemudian memberikan item ke penyelenggara skema atau mengubah mereka untuk kas dan menggunakan layanan transfer uang untuk mencuci dana.
Dalam banyak kasus, bagal uang adalah peserta bersedia dalam skema kriminal. Tapi semakin, sebagai bagian dari skema ini, kita melihat peningkatan jumlah bagal tidak curiga disewa melalui "bekerja di rumah" iklan yang akhirnya pencucian sebagian dana dicuri dari rekening bank. Para penjahat e-mail bakal calon yang mengaku telah melihat resume mereka di situs Web pekerjaan dan menawarkan mereka pekerjaan. Para karyawan yang bekerja disediakan kontrak kerja yang panjang dan tampak sah dan situs yang sebenarnya untuk login ke. Mereka diinstruksikan untuk baik membuka rekening bank atau menggunakan rekening bank mereka sendiri untuk menerima dana melalui kawat dan transaksi ACH dari bank banyak ... dan kemudian menggunakan uang timbul layanan untuk mengirim uang luar negeri.
Jika Anda pikir Anda sudah menjadi korban jenis skema, hubungi institusi keuangan Anda untuk melaporkannya, dan mengajukan keluhan dengan FBI Internet Crime Center Pengaduan .

 
Souce Code

Read more »

TEHNIK BUDIDAYA BELUT DALAM TONG / DRUM.

 

TEHNIK BUDIDAYA BELUT DALAM TONG / DRUM.

Lahan sempit atau pekarangan rumah yang sempit sering menjadi kendala untuk menjalankan sebuah usaha, namun seiring dengan perkembangan teknologi dan ilmu pengetahuan di sektor perikanan, peternakan dan perkebunan , kondisi ini sudah bukan menjadi kendala.

Usaha peternakan yang dapat dilakukan dilahan sempit adalah Budidaya belut. Mengapa kita dapat membudidayakan belut dilahan sempit , karena kita akan menggunakan media drum atau tong dari besi atau plastik.

A.    PERLENGKAPAN , yang dibutuhkan untuk budidaya adalah sebagai berikut :

a.     Tong / drum , disarankan dari bahan plastik, supaya tidak berkarat.

b.     Paralon.

c.      Kawat kasa.

d.     Tandon penampungan air.

e.     Ember , serok , cangkul , baskom dan jerigen dll.

 

B.     PERSIAPAN DAN TEHNIK BUDIDAYA.

Sebelum kita menjalankan budidaya belut dalam drum / tong , dibutuhkan media pemeliharaan sebagai tempat belut berkembang biak atau membesar, media pemeliharaan ini sangat penting mengingat keberhasilan budidaya yang kita lakukan sangat bergantung pada media pemeliharaan ini. Untuk media pembesaran hal yang perlu diperhatikan adalah sebagai berikut :

 

1.     Drum / Tong.

Tong  yang digunakan sebaiknya tdk bocor dan berkarat , jika menggunakan drum / tong dari besi yang berkarat sebaiknya dibersihkan dahulu dari karat dan lakukan pengecatan ulang dan diamkan sampai kering dan tidak berbau cat lagi.

Cara merakit Drum / tong :

a.     Letakkan tong pada posisi mendatar , agar media menjadi lebih luas.

b.     Buka bagian tengah drum / tong , sisakan 5 cm pada sisi kanan dan kiri.

c.      Pasanglah alat / ganjal supaya drum / tong tidak menggelinding , atau bergerak .

d.     Buat saluran pembuangan dibawah tong , letak dapat disesuaikan dengan penampungan limbah pembuangan.

e.     Buat peneduh, sehingga intensitas panas matahari tidak terlalu tinggi dan terkena langsung ke permukaan drum / tong, bahan bisa dibuat dengan memasang shading net / waring atau bisa juga dengan bahan yang murah dan mudah didapat lainnya.

 

2.     Media Tanah.

Tanah yang digunakan sebaiknya tanah yang tidak berpasir , tidak terlalu liat serta masih memiliki kandungan hara , disarankan untuk menggunakan media tanah dari sawah. Untuk melakukan pematangan media tanah tahapan yang dilakukan yaitu :

a.     Masukkan tanah kedalam drum / tong hingga ketinggian 30 – 40 cm.

b.     Masukkan air hingga tanah becek namun tidak menggenang.

c.      Masukkan EM 4 sebanyak 4 botol kedalam tong.

d.     Aduk tanah sebanyak 2 kali sehari hingga tanah lembut dan gembur.

Perlakuan tahapan diatas tidak berlaku , apabila menggunakan tanah dari sawah.

 

3.     Media Instan Bokashi.

Media instan ini dibuat diluar drum/tong yang merupakan campuran bahan utama dan bahan campuran . Penggunaan 100 kg bahan akan menghasilkan 90 kg media instan bokashi. Setiap drum / tong ukuran 200 liter dibutuhkan 45 kg bokashi.

Bahan utama terdiri atas :

a.     Jerami Padi (40 %).

b.     Pupuk Kandang (30 %).

c.      Bekatul (20%).

d.     Potongan batang pisang (10% ).

Bahan campuran terdiri atas :

a.     EM4.

b.     Air sumur.

c.      Larutan 250 gram gula pasir untuk menghasilkan 1 liter larutan (molases).

 

Cara membuat Media Instan Bokashi:

a.     Cacah jerami dan potongan batang pisang kemudian keringkan. Tanda bahan sudah kering adalah hancur ketika digenggam.

b.     Campuran cacahan bahan diatas dengan bahan pokok lain dan aduk hingga merata.

c.      Campurkan bahan campuran sedikit demi sedikit tapi tidak terlalu basah.

d.     Tutup media dengan karung goni atau terpal selama  4 – 7 hari . bolak balik campuran agar tidak membusuk.

 

4.     Mencampur Media point 1 dan 2.

a.     Masukkan media instan kedalam tong dan aduk hingga merata.

b.     Massukkan air kedalam  drum/tong  hingga ketinngian 5 cm dan diamkan hingga terdapat plankton  dan cacing ( sekitar 1 minggu) selama proses ini berlangsung drum/tong tidak perlu ditutup.

c.      Keluarkan air dari drum/ tong dan ganti dengan air baru dengan ketinggian yang sama.

d.     Massukkan tumbuhan air yang tidak terlalu besar sebanyak ¾ bagian dan ikan ikan kecil..

e.     Masukkan vetsin secukupnya sebagai perangsang nafsu makan belut dan diamkan selama 2 hari.

Yang perlu diperhatikan ketinggian seluruh media , kecuali tumbuhan air tidak lebih dari 50 cm.

 

5.     Masukkan bibit belut.

Setelah semua media budidaya tersebut siap tahapan selanjutnya menebarkan bibit belut. Bibit yang ditebar sebaiknya sebanyak 2 kg dengan jumlah bibit sebesar 80 – 100 ekor per kg.

C.     PERAWATAN.

Perawatan belut didalam tong drum / tong relative lebih mudah karena pemantauan budidaya relative kecil, namun demikian perawatan tetap harus diperhatikan, antara lain:

1.     Pemberian Pakan.

Tidak ada aturan baku volume pemberian pakan, namun sebaiknya pakan diberikan 5% dari jumlah bibit yang ditebarkan. Pakan yang sebaiknya diberikan yaiyu cacing, kecebong , ikan ikan kecil , dan cacahan keong mas atau bekicot. Pemberian pakan diberikan pada hari ke 3 setelah bibit ditebar dalam drum/ tong. Pemberian pakandilakukan pada sore hari seperti kebiasaan belut dialam yang makan disore / malam hari.

2.     Pengaturan Air.

Pengaturan air sangat diperlukan untuk membuang sisa makanan agar tidak menumpuk dan menimbulkan bibit penyakit. Pengaturan air ini dengan cara mengalirkan air bersih kedalam drum/tong , sebaiknya air yang masuk berupa percikan air untuk melakukan ini digunakan pipa paralon sebagai media aliran. Sedangkan untuk saluran pembuangan dengan membuat lubang pada drum /tong dengan ketinggian 8 cm dari genangan air di media. Selain sebagai pengatur pembuangan sisa kotoran percikan air ini juga berfungsi sebagai penambah oksigen.

3.     Perawatan Tanaman Air.

Tanaman air ini digunakan sebagai penjaga kelembaban tempat budidaya dan juga menjaga belut dari kepanasan.

4.     Pemberian EM4.

EM4 berfungsi sebagai penetralisir sisa sisa pakan, selain itu juga berfungsi untuk mengurangi bau. EM4 diberikan2-3 kali sehari dengan dosis ½ sendok makan dilarutkan dalam 1 liter air.

5.     Perawatan Sekitar Lokasi.

Perawatan sekitar lokasi ini untuk menjaga tong dari tanaman liar , lumut , dan hama maupun predator pemangsa seperti ayam.

 

D.    PEMANENAN.

Pemanenan dilakukan setelah 3 – 4 bulan budidaya dilakukan atau sesuai dengan keinginan kita dan keinginan (permintaan) pasar . Pemanenan untuk media drum / tong tentunya lebih mudah , dan belut hasil budidaya siap dipasarkan.

Untuk menunjang bududaya belut yang berkelanjutan sebaiknya juga dipersiapkan bagaiman supply makanan yakni cacing , keong mas , bekicot dan lainnya. Selain itu juga diperhatikan bagaimana kelangsungan bibit setelah panen untuk budidaya berikutnya.

Read more »

Cara Seting Bridge Microtik

Mode bridge memungkinkan network yang satu tergabung dengan network di sisi satunya secara transparan, tanpa perlu melalui routing, sehingga mesin yang ada di network yang satu bisa memiliki IP Address yang berada dalam 1 subnet yang sama dengan sisi lainnya.



Berikut ini langkah-langkah setting mikrotik wireless sebagai Bridge :


¤ Login ke mikrotik dengan winbox
¤ Klik menu Interface, maka akan terlihat 2 interface Ethernet dan Wireless

¤ Langkah selanjutnya mulai setting bridge dengan klik menu Bridge
¤ Kemudian ADD Bridge dengan klik tanda plus+


¤ Misalkan pada kolom Name: kita kasih nama bridge1 dan klik OK


¤ Maka akan tampil seperti pada gambar dibawah ini


¤ Selanjutnya adalah setting Bridge Port, masih pada menu Bridge klik tab Ports
¤ Add Bridge Port yang pertama dengan klik tanda plus+
¤ Pada bagian Interface misal pilih ether1 dan pada Bagian Bridge pilih bridge1 (sesuai dengan nama bridge yang tadi dibuat) kemudian klik OK


¤ Add Bridge Port yang kedua dengan klik tanda plus+
¤ Pada bagian Interface misal pilih wlan1dan pada Bagian Bridge pilih bridge1 (sesuai dengan nama bridge yang tadi dibuat) kemudian klik OK


¤ Maka akan terlihat hasil pembuatan dari Add Bridge Port, seperti di bawah ini


¤ Selanjutnya pengalamatan IP ADDRESS pada interface bridge1
¤ Klik menu IP Address


¤ Add Address dengan klik tanda plus +
¤ Pada bagian Address isikan ip address yang kita inginkan, contoh seperti gambar dan pada bagian Interface pilih bridge1 dan klik OK


¤ Hasilnya seperti pada gambar di bawah ini


¤ Misalkan pada jaringan wireless ada gateway bisa dimasukkan ip gateway tersebut
¤ Ketikkan ip route add gateway=10.0.2.1 dan Enter


¤ Sekarang saatnya setting wirelessnya
¤ Klik menu Wireless, kemudian klik 2 kali pada bagian wlan1
¤ Klik tab Wireless

pada bagian Mode: pilih sebagai station pseudobridge

“pernah ada kasus dibagian sebagai Mode: station bridge dari mikrotik wireless (RB411U) ping
ke AP bisa Reply, sedangkan dari komputer klient Request timed out”

pada bagian Band: pilih frekuensi sesuai jaringan anda

pada bagian SSID: sesuaikan dengan jaringan anda, contoh disini SSID dengan nama wireless

kemudian klik OK


¤ Sekarang test ping ke gateway dari TerminalMikrotik, jika hasilnya Reply berarti sudah beres



¤ Sekarang test ping ke gateway dari komputer klien, jika hasilnya Reply berarti sudah beres, tapi kalau hasilnya Request timed out coba cek lagi pada setting Mode wirelessnya
¤ Contoh hasil ping dari komputer klien yang berhasil

sekarang boleh di test....................

Read more »