Saat ini, organisasi mana pun memiliki direktori LDAP yang diisi dengan pengguna organisasi ini. Jika Anda melihat lebih dekat, Anda akan menemukan satu atau lebih aplikasi yang menggunakan direktori yang sama untuk "otentikasi". Dan tanda kutip tidak disengaja di sini, karena LDAP adalah protokol akses direktori yang dirancang untuk membaca, menulis, dan mencari layanan direktori. Ini bukan protokol otentikasi. Istilah "otentikasi LDAP", lebih tepatnya, merujuk pada bagian protokol tersebut (operasi bind), yang menentukan siapa Anda dan hak akses apa yang Anda miliki terhadap informasi direktori.
Seiring waktu, LDAP telah menjadi layanan otentikasi de facto. Layanan LDAP yang tersebar luas dan terjangkau, seperti Active Directory, telah menjadi berita gembira bagi pengembang perangkat lunak yang ingin mengintegrasikan otentikasi ke dalam produk mereka. Pustaka klien LDAP tersedia untuk hampir semua kerangka kerja, dan integrasi relatif mudah diimplementasikan.
Tetapi terlepas dari kenyataan bahwa penggunaan LDAP dapat membantu memecahkan masalah penerapan otentikasi pengguna di berbagai aplikasi perusahaan, itu menciptakan banyak masalah. Tidak seperti protokol otentikasi yang dirancang khusus, menggunakan LDAP menyebabkan berbagai kerentanan keamanan informasi.
Untuk memahami apa kerentanan ini, Anda harus terlebih dahulu memahami cara kerja otentikasi LDAP.
Cara Kerja Otentikasi LDAP
Bayangkan situasi berikut (jauh dari kenyataan, tetapi esensi disampaikan dengan sempurna).
Misalkan saya memesan di toko online sehingga dikirim ke rumah saya jika saya tidak ada. Kurir datang dan meninggalkan catatan di bawah pintu dengan teks "Maaf, kami tidak menemukan Anda" dan meminta saya untuk mengambil pesanan di titik pengambilan terdekat pada waktu yang tepat. Pada titik pengambilan, karyawan meminta nama saya, alamat dan meminta kunci rumah untuk mengkonfirmasi identitas saya. Kemudian petugas layanan pengiriman datang ke rumah saya dan membuka pintu dengan kunci saya. Dia masuk ke dalam untuk memastikan bahwa saya tinggal di sana, misalnya, dari foto-foto di dinding atau dengan nama penerima pada korespondensi. Setelah itu, karyawan kembali ke titik masalah dan memberi tahu saya bahwa ia telah berhasil mengkonfirmasi identitas saya, dan saya dapat menerima paket saya! Hore!
Selain masalah dengan logistik, situasi ini penuh dengan masalah lain. Bagaimana jika pengulas yang tidak jujur membuat salinan kunci saya? Atau apakah dia meninggalkan kunci untuk waktu yang lama tanpa pengawasan, dan apakah ada orang lain? Bagaimana jika penguji diserang dan kunci saya diambil? Ketika saya memberikan kunci apartemen saya kepada orang asing, saya tidak bisa memastikan kesopanan dan keamanan saya.
Untungnya, di dunia nyata kita memiliki dokumen identifikasi, misalnya, SIM atau paspor, yang dikeluarkan oleh lembaga pemerintah, dan keasliannya tidak diragukan. Saya dapat memberikan dokumen-dokumen ini kepada kurir untuk identifikasi saya sendiri tanpa menyerahkan kunci.
Di dunia LDAP, kita masih harus melewati kunci kita untuk membuka pintu atas nama kita. Kami mentransfer kata sandi kami ke pihak ketiga, dan dia mencoba menembus server LDAP. Jika ia berhasil mendapatkan akses, kami tidak dapat memastikan bahwa kredensial kami tidak terganggu. Dalam hal ini, penyerang tidak hanya akan mendapatkan kemampuan untuk membuka kunci pintu LDAP, tetapi juga akses ke aplikasi apa pun yang menggunakan kredensial yang sama.
Untungnya, di dunia autentikasi yang lebih lengkap, kami juga memiliki paspor dan SIM! Protokol autentikasi seperti Kerberos, SAML, dan token masalah OpenID Connect kepada pihak ketiga. Token mengkonfirmasi bahwa Anda adalah siapa yang Anda klaim menjadi, dan tidak perlu mentransfer kunci Anda kepada siapa pun. Karena LDAP tidak pernah dirancang sebagai protokol otentikasi, LDAP tidak memiliki mekanisme yang sesuai.
Kerugian LDAP sebagai Sistem Otentikasi
Pada tahun 2007, Shumon Hack merilis artikel fiksi ilmiah (
Kelemahan LDAP sebagai Sistem Otentikasi Pusat ) di mana ia menjelaskan tiga masalah khusus saat menggunakan LDAP sebagai sistem otentikasi.
1. Aplikasi mungkin tidak cukup aman untuk menangani kredensial
Penulis menekankan bahwa melindungi satu set kecil server otentikasi dari serangan jauh lebih mudah daripada melindungi sejumlah besar server aplikasi.
Sebagian besar, server otentikasi, sebagai suatu peraturan, berada di bawah pengawasan ketat para spesialis dengan pengalaman yang signifikan di bidang keamanan informasi.
Di sisi lain, server aplikasi memiliki tingkat keamanan yang sama sekali berbeda dan lebih berisiko dikompromikan. Mereka kurang aman, bekerja dengan tumpukan perangkat lunak yang lebih kompleks, dan lebih cenderung memiliki kerentanan. Dan lebih sering mereka dikelola oleh orang-orang yang tidak memiliki pengetahuan keamanan yang mendalam. Membangun sistem keamanan yang tepat adalah proses yang rumit di mana sangat mudah untuk melakukan kesalahan.
Masalahnya adalah bahwa jika satu server aplikasi dikompromikan, maka semua kredensial yang digunakan oleh pemiliknya selama serangan juga dikompromikan. Sistem lain apa pun yang menggunakan direktori LDAP yang sama untuk otentikasi berisiko.
2. Server LDAP tidak dapat mengamankan mekanisme otentikasi yang digunakan untuk mendapatkan kredensial
Server LDAP tidak dapat menjamin keamanan transaksi. Meskipun server LDAP, misalnya, dapat memberlakukan pengikatan pada TLS untuk memastikan bahwa kredensial tidak dikirim dalam teks yang jelas, server itu sendiri tidak pernah mengambil peran apa pun dalam memperoleh kredensial dari pengguna. Ada risiko bahwa aplikasi akan menerima kata sandi melalui saluran yang tidak aman.
3. Pengguna dipaksa untuk berbagi rahasia autentikasi dengan pihak ketiga
Kata sandi pengguna atau rahasia otentikasi harus
dirahasiakan . Itu harus diketahui hanya untuk pengguna dan sistem otentikasi. Saat menggunakan otentikasi LDAP, pengguna dipaksa untuk membagikan rahasianya dengan pihak ketiga sehingga ia dapat menggunakan rahasia ini untuk berinteraksi dengan direktori LDAP atas nama pengguna.
Penting untuk disebutkan bahwa ketika menggunakan protokol otentikasi yang dirancang khusus seperti Kerberos, dan bahkan dari NTLM sebelumnya, rahasia pengguna tidak pernah dikirimkan melalui jaringan. Perangkat klien dan server menggunakan operasi kriptografi untuk saling membuktikan bahwa mereka memiliki rahasia yang sama dan bahkan tidak bertukar rahasia itu sendiri.
Untuk poin-poin dari Shumon Hook, saya akan menambahkan deskripsi beberapa nuansa otentikasi LDAP, berdasarkan pengalaman saya sendiri. Pertama-tama, topik tersebut menyangkut penggunaan Active Directory.
4. Banyak pengembang tidak cukup tahu tentang mekanisme LDAP untuk menggunakannya dengan benar
Salah satu posting
blog saya sebelumnya menjelaskan bagaimana ikatan anonim dan tidak terauthentikasi dibiarkan mengecoh pengembang aplikasi dan memaksa pengguna yang tidak sah untuk melewatinya. Kemampuan untuk melakukan operasi bind tanpa otentikasi adalah salah satu seluk-beluk protokol yang bahkan para ahli LDAP paling berpengalaman tidak sadari.
Direktori tidak mudah diatur dan mampu menyimpan sejumlah besar informasi organisasi dan menyediakan banyak cara yang dapat disesuaikan untuk menyimpannya. Saya melihat banyak kasus di mana pengembang aplikasi berasumsi bahwa ada kelas objek atau atribut tertentu, dan ketika mereka tidak terdeteksi, aplikasi macet. Untuk otentikasi pengguna, pengetahuan tentang struktur data yang disimpan dalam direktori tidak perlu dan diterapkan. Protokol otentikasi harus diabstraksi dari detail repositori objek yang terletak di level yang lebih rendah.
5. Administrator aplikasi sering tidak mengonfigurasi klien LDAP dengan benar
Ketika mengelola Active Directory di lingkungan terdistribusi besar, ada satu nuansa yang tidak menyenangkan: sulit untuk menentukan aplikasi spesifik mana yang menggunakan Active Directory sebagai direktori LDAP, dan bagaimana tepatnya administrator aplikasi mengkonfigurasi klien LDAP.
Berikut ini adalah contoh-contoh kengerian kesalahan konfigurasi.
- Hardcoding DN dalam aplikasi atau menggunakan DN dalam operasi bind. Masalah terus-menerus terjadi ketika mengganti nama atau memindahkan objek di dalam direktori, dan semua karena seseorang di suatu tempat DN hardcode. (Catatan untuk mereka yang melakukan operasi bind sederhana dengan Active Directory: tidak perlu menggunakan DN. Active Directory juga menyediakan format DN alternatif yang lebih dapat diandalkan daripada menggunakan format tradisional).
- Untuk operasi bind, bukan akun layanan yang digunakan, tetapi akun pribadi pengembang atau administrator (bayangkan apa yang akan terjadi ketika pemilik akun meninggalkan perusahaan).
- Mengirim kata sandi dalam teks yang jelas ke port 389.
- Ada aplikasi di mana kotak centang "Validasi sertifikat" tidak diperlukan saat menghubungkan ke AD menggunakan TLS (port 636). Mengapa ini secara umum dapat diterima? Bagaimana saya bisa meneruskan kata sandi ke layanan pihak ketiga tanpa diyakinkan keasliannya?
Membuat klien LDAP berfungsi dengan mudah. Tetapi fakta bahwa itu berfungsi tidak berarti bahwa konfigurasi sudah benar.
6. Otentikasi LDAP dan layanan otentikasi modern saling eksklusif
Aplikasi yang menggunakan LDAP untuk autentikasi akan selalu harus bergantung pada nama pengguna dan kata sandi. Mencoba menerapkan teknologi modern, seperti otentikasi multi-faktor dan sistem masuk tunggal, hampir tidak mungkin (kecuali Anda akan menerapkan teknologi Anda sendiri, yang dengan sendirinya merupakan ide yang buruk). Aliansi FIDO berkomitmen untuk menjadikan kata sandi sebagai peninggalan masa lalu, dan setiap aplikasi yang menggunakan otentikasi LDAP akan menjadi penghambat kebijakan bebas kata sandi.
Apa saja pilihannya?
Aplikasi web saat ini benar-benar dapat melakukannya tanpa otentikasi LDAP. Ada banyak protokol otentikasi web yang bagus, seperti SAML, WS-Federation, dan OpenID Connect, yang tidak memerlukan kredensial pengguna untuk bekerja dengan aplikasi pihak ketiga. Produk yang tak terhitung jumlahnya menyediakan layanan ini, termasuk Layanan Federasi Direktori Aktif (dibangun ke dalam Windows Server) atau layanan pihak ketiga seperti Microsoft Azure AD, Okta, Ping, dan lainnya. Jika organisasi Anda tidak memiliki IDP gabungan, hal pertama yang harus dilakukan adalah menerapkannya.
Hal utama yang harus Anda perhatikan ketika memilih perangkat lunak baru adalah dukungan protokol otentikasi modern. Sekalipun bisnis membutuhkan aplikasi di sini dan sekarang, jangan buru-buru memilih solusi, terutama jika pilihan ini hanya terbatas pada produk dengan otentikasi LDAP. Sebaiknya sampaikan kepada vendor yang dipilih perlunya memperbaiki produk menggunakan protokol otentikasi yang lebih modern. Mungkin dia akan mendengarkan dan merevisi rencana pengembangannya.
Jumlah aplikasi desktop dengan "klien tebal" yang mendukung protokol otentikasi modern semakin meningkat, dan ini memang tren yang menyenangkan. Aplikasi ini biasanya merupakan kubu otentikasi LDAP. Semakin banyak SDK, seperti Microsoft Authentication Library (MSAL), memudahkan pengembang untuk menambahkan dukungan untuk layanan otentikasi modern ke aplikasi mobile dan desktop mereka.
Pada akhirnya, perlu diakui bahwa dalam kenyataan saat ini, tidak semua aplikasi mendukung protokol otentikasi modern, dan mungkin tidak pernah ada. Menerapkan larangan lengkap pada otentikasi LDAP mungkin tidak dimungkinkan di organisasi mana pun. Namun, otentikasi LDAP sama sekali tidak dianjurkan dalam organisasi. Penggunaan LDAP harus dipertimbangkan hanya jika tidak ada pilihan lain.