- Kebijakan yang sering meminta autentikasi hanya menimbulkan ketidaknyamanan bagi pengguna tanpa efek nyata dalam memperkuat keamanan
- Dengan meningkatnya ancaman keamanan modern seperti serangan kelelahan MFA, autentikasi berulang justru bisa menjadi kerentanan
- Fitur kunci layar sistem operasi dan pembaruan kebijakan akses secara real-time merupakan sarana perlindungan yang lebih efektif
- Autentikasi tambahan hanya diperlukan tepat sebelum pekerjaan sensitif, dan siklus login singkat yang sewenang-wenang tidak diperlukan
- Pendekatan kontrol akses modern menerapkan kebijakan secara otomatis dan cepat tanpa mengganggu pengguna
Mengapa autentikasi yang sering tidak memperkuat keamanan
Masalah yang ditimbulkan oleh autentikasi berulang
- Sesi yang kedaluwarsa di tengah alur kerja memaksa pengguna berulang kali memasukkan kata sandi dan MFA (autentikasi multi-faktor), sehingga produktivitas menurun
- Awalnya pengguna hanya perlu memasukkan ulang kata sandi, tetapi setelah tahap MFA ditambahkan, waktu yang terbuang dan keluhan pengguna pun meningkat
- Semakin sering permintaan MFA muncul, semakin tinggi pula kemungkinan keberhasilan serangan kelelahan MFA (MFA fatigue attacks)
- Di masa lalu, pergantian kata sandi yang sering atau masa kedaluwarsa sesi yang pendek dianggap sebagai langkah keamanan yang efektif, tetapi dalam panduan modern justru dinilai kontraproduktif
- Keamanan tidak bergantung pada siklus login, melainkan pada seberapa cepat pengelolaan hak akses dan perubahan kebijakan dapat diterapkan
Hakikat metode autentikasi
- Autentikasi pada umumnya membuktikan salah satu dari dua hal berikut
- Bukti kepemilikan perangkat: memastikan seseorang secara fisik memiliki perangkat, seperti melalui Windows Hello PIN, YubiKey, atau smart card
- Bukti identitas diri: mengidentifikasi apakah orang tersebut benar pengguna yang dimaksud, seperti melalui kata sandi, Face ID, atau Touch ID
- Peran utama Identity Provider (IdP) berfokus pada verifikasi identitas
- Face ID, Touch ID, Windows Hello, dan sejenisnya merupakan sistem terpadu yang menangani bukti kepemilikan perangkat dan bukti identitas diri sekaligus, sehingga keamanannya lebih tinggi
- Banyak administrator menetapkan masa kedaluwarsa sesi yang singkat karena kekhawatiran bahwa perubahan kebijakan tidak akan langsung diterapkan
Ancaman keamanan nyata dan peran autentikasi
- Sebagian besar penyerang melancarkan serangan melalui phishing jarak jauh, dan pencurian kata sandi sangat mudah dilakukan
- Untuk menghadapi serangan jarak jauh, penggunaan autentikasi kedua (misalnya YubiKey) merupakan sarana pertahanan yang penting
- Saat terjadi serangan fisik seperti perangkat hilang atau dicuri, biasanya layar sudah dalam keadaan terkunci
- Sebaliknya, semakin sering login dilakukan, semakin banyak pula peluang pencurian kredensial bagi penyerang, yang berdampak buruk pada keamanan
Peran sistem operasi dan layanan web
- Sistem operasi modern melindungi sistem secara otomatis melalui fitur kunci layar saat pengguna meninggalkan perangkatnya
- Daripada menambah ketidaknyamanan pengguna lewat frekuensi autentikasi tambahan, lebih baik menerapkan kebijakan kunci otomatis
- Kecuali pada komputer bersama, kedaluwarsa sesi web yang singkat hanyalah peninggalan dari lingkungan warnet internet lama
- Di luar layanan sensitif seperti internet banking, kebijakan waktu kedaluwarsa sesi yang tidak tepat justru menurunkan keamanan dan kegunaan sekaligus
Model keamanan yang efisien dan ramah pengguna
- Autentikasi seketika sebelum pekerjaan sensitif (on-demand authentication) adalah pendekatan yang ideal
- Mode check di Tailscale SSH, Slack Accessbot, dan lainnya menyediakan fungsi verifikasi pengguna secara langsung saat dibutuhkan
- Dengan dibarengi pemaksaan kunci layar dari sistem operasi, keseimbangan antara keamanan dan kenyamanan dapat dipertahankan
- Pemeriksaan status keamanan berkelanjutan (device posture check) dan kontrol akses real-time berjalan otomatis tanpa bergantung pada tindakan pengguna
- Contoh:
- Jika perangkat sedang offline, hilang, atau gagal pemeriksaan keamanan, hak akses langsung dicabut
- Jika terjadi perubahan peran atau perubahan identitas, kebijakan akses diperbarui secara otomatis
- Dibandingkan memaksa pengguna melakukan autentikasi berulang, pendekatan otomatisasi real-time jauh lebih cerdas dan aman
Kesimpulan
- Login yang sering tidak secara efektif meningkatkan keamanan, dan justru dapat memicu penggunaan ulang kata sandi, phishing, dan kelelahan MFA
- Sistem keamanan yang senyap dan terotomatisasi adalah perlindungan terbaik
- Tailscale mengejar keamanan yang adaptif, cerdas, dan benar-benar membantu
- Tanpa pengguna harus mengatur sendiri siklus login, sistem dirancang agar hanya menimbulkan gesekan autentikasi seminimal mungkin pada saat diperlukan
- Fitur pemeriksaan keamanan real-time dari Tailscale juga dapat diperluas ke aplikasi lain untuk melindungi bahkan sistem legacy dengan aman
Tautan referensi
4 komentar
Seperti juga disebutkan di komentar HN, dibandingkan dengan lingkungan TI yang berubah cepat, pemeriksaan/aturan keamanan yang dibicarakan berdasarkan standar lama dan kaku memang sering menjadi penghambat. Mungkin ini juga sudah jadi hal yang sangat dipahami oleh mereka yang bekerja di garis depan... hehe
Banyak layanan di Korea menampilkan notifikasi yang mengganggu agar kita mengatur ulang kata sandi setiap 30 hari sekali.
Karena ini bagian yang selama bertahun-tahun diwajibkan demi kewajiban keamanan data pribadi, memang sangat merepotkan... terisak
Pendapat Hacker News
Saya rasa kebijakan perubahan atau kedaluwarsa kata sandi berkala yang dipaksakan adalah masalah yang lebih besar; kebijakan seperti ini sering membuat orang terkunci dari akun mereka (misalnya, kata sandi kedaluwarsa saat sedang liburan), lalu setelah itu mereka harus repot datang langsung ke IT, menelepon IT berjam-jam untuk meminta reset, atau menghubungi lewat rekan kerja yang tidak terkunci akun.
Banyak (sebagian besar?) perusahaan masih menerapkan kebijakan seperti ini, padahal NIST kini tidak lagi merekomendasikan perubahan kata sandi sewenang-wenang.
Dokumen resmi NIST
Microsoft juga tidak merekomendasikan kedaluwarsa kata sandi karena dinilai lebih merugikan.
Dokumen resmi Microsoft
Namun demikian, di kalangan IT atau keamanan tampaknya rekomendasi seperti ini belum dianggap cukup "otoritatif", dan masih ada panduan yang terus menganjurkan kebijakan seperti ini.
Kadang saat login ke situs acak dan tiba-tiba dipaksa reset kata sandi, saya jadi berpikir mungkin ini bukan karena kedaluwarsa berbasis waktu, melainkan karena akun saya bocor atau sempat disusupi.
Jika operator situs tahu akun tertentu masuk dalam daftar kebocoran data, menurut saya masuk akal bila mereka mewajibkan perubahan kata sandi saat login berikutnya.
Saat saya membicarakan ini dengan orang keamanan siber, saya diberi tahu bahwa standar PCI memang mewajibkan perubahan kata sandi berkala, jadi akhirnya bergantung pada audit mana yang lebih diprioritaskan.
Dulu saya sangat jengkel dengan kebijakan seperti ini, jadi saya akali dengan menambahkan satu huruf alfabet di akhir kata sandi setiap kali, berurutan dari a sampai z.
Untungnya, di perusahaan saya sekarang saya sudah memakai kata sandi yang sama selama 3 tahun, dan saya puas dengan itu.
Menurut saya tidak masuk akal bila penyedia meminta saya mengganti kata sandi secara berkala padahal kata sandi saya tidak bocor.
Absurd rasanya bahwa ini masih diterapkan seolah-olah standar resmi.
Pada akhirnya semua akun saya jadi cuma memakai pola 1234abcd@.
Saya benar-benar merasa terganggu karena produk Apple.
Saya melihat pola ini berlaku di semua produk Apple.
Di Mac, meski sudah menyiapkan TouchID, setelah login akun Apple di App Store lalu mencoba memasang aplikasi, tetap terus muncul jendela yang meminta kata sandi; padahal seharusnya bisa diautentikasi dengan TouchID.
Hal yang sama juga terjadi saat memasang aplikasi gratis, dan menurut saya ini prosedur yang benar-benar tidak perlu.
Pola ini juga kadang muncul di iPhone pasangan saya.
Terutama saat mereset ponsel dan mengaturnya kembali, Apple berulang kali meminta kata sandi dimasukkan lagi.
Padahal situasinya sudah cukup aman dengan TouchID, jadi sangat membuat frustrasi.
Jika mengakses layanan Apple dari perangkat non-Apple, ketidaknyamanannya malah lebih parah.
Setiap kali login ke icloud.com, meski saya sudah menekan "percaya perangkat ini", besoknya tetap harus mengulangi proses autentikasi dua langkah dengan kata sandi + kode sekali pakai.
Jika Face ID gagal saat pembayaran atau pemasangan aplikasi, sistem tidak menggantinya dengan PIN dan malah memaksa saya memasukkan seluruh kata sandi akun Apple, sementara aplikasi pengelola kata sandi pun tidak bisa dibuka.
Kalau mengalami ini di kasir, rasanya benar-benar menyebalkan.
Pastikan pengaturan untuk menyetujui pembelian dengan TouchID memang sudah diaktifkan.
(Perlu diatur di Settings > Touch ID & Password)
Kalau ini belum disetel, sistem bisa terus meminta kata sandi.
Pengalaman saya, setelah restart hanya perlu autentikasi sekali, lalu setelah itu sebagian besar autentikasi bisa dilakukan dengan TouchID.
Setiap kali menghubungkan iPhone ke Mac untuk sinkronisasi, muncul jendela "Apakah Anda memercayai perangkat ini?" baik di Mac maupun iPhone, dan meskipun selalu memilih "Ya", saat koneksi berikutnya tetap ditanya lagi.
Menurut saya wajar kalau pekerjaan yang membutuhkan hak SUDO meminta autentikasi ulang.
Dalam kasus seperti ini, kalau pekerjaan terkait dikelompokkan supaya cukup autentikasi sekali, jumlah permintaan autentikasi ulang bisa dikurangi.
Anak saya memakai iPad yang sangat tua, masih iOS 10.3, jadi aplikasi pengelola kata sandi tidak berjalan, dan browser-nya juga aplikasi 32-bit sehingga bahkan tidak bisa membuka situs web modern.
Akibatnya, setiap memakai App Store saya harus mengetik manual kata sandi lebih dari 50 karakter setiap kali, dan itu sangat merepotkan.
Menurut saya orang yang perlu membaca artikel seperti ini adalah para auditor yang melakukan audit keamanan.
Selama standar yang mereka harapkan tidak berubah, banyak perusahaan akan terus mengikuti kebijakan-kebijakan bodoh yang secara formal disebut standar industri.
Terutama perusahaan kecil di bidang tertentu juga harus mendapat nilai tinggi dalam audit keamanan, sehingga mereka mengadopsi banyak prosedur keamanan yang tidak berguna.
Ada setidaknya 6 kontrol keamanan yang kita tahu tidak efektif tetapi tetap dipaksakan, dan sejauh ini para auditor belum mau banyak berubah.
Saat menjalani audit SOC2, saya terus menunjukkan pedoman NIST.
Kalau ditunjukkan tautannya, kebanyakan akhirnya menerima standar NIST.
Baik Apple maupun Microsoft sama-sama mendukung pengaturan enterprise yang menonaktifkan opsi "ingat perangkat saya" dan "percaya perangkat ini" oleh tim keamanan perusahaan.
Auditor atau CISO (Chief Information Security Officer) pada dasarnya hanya mengaudit berdasarkan checklist, jadi apakah itu benar-benar meningkatkan keamanan tidak penting; yang lebih penting adalah lolos audit.
Pengaturan seperti ini hanya menambah ketidaknyamanan pengguna dan pada kenyataannya justru memperburuk keamanan dunia nyata.
Saya rasa Microsoft juga merusak game PC dengan pola seperti ini.
Saat hendak menjalankan game seperti Minecraft atau Master Chief Collection, saya menunda-nunda karena tahu akan muncul jendela autentikasi ulang entah dari mana.
Karena kerepotan seperti ini, saya bahkan mematikan 2FA (autentikasi dua faktor) di akun saya.
Ini cuma game biasa, bukan verifikasi rekening bank; tolong biarkan saya bermain game dengan santai.
Katanya belakangan ada fitur autentikasi dengan memindai QR code, tapi menurut saya orang yang merancang sistem seperti ini benar-benar jauh dari pengalaman pengguna nyata.
Ada bagian yang hampir tidak disinggung dalam tulisan ini.
Menurut saya UX (pengalaman pengguna) yang buruk itu sendiri bisa menjadi kerentanan keamanan.
Kalau sistem bertindak tidak masuk akal dalam keadaan normal, pengguna jadi lebih mungkin tidak menyadari perubahan atau perilaku aneh saat masalah sungguhan terjadi.
Misalnya, kalau permintaan memasukkan kata sandi muncul terlalu sering, orang akan memasukkannya secara kebiasaan, dan dalam situasi seperti itu lebih sulit menyaring risiko seperti phishing.
Selain itu, kalau OS tidak mengelola program startup atau kode mencurigakan yang berjalan di latar belakang dengan baik, penyalahgunaan juga jadi lebih mudah.
Masalah lainnya, banyak profesional keamanan biasa hampir tidak mempertimbangkan "psikologi manusia" sebagai variabel penting, dan semuanya cenderung dirancang serba checklist atau dari sudut pandang perusahaan.
Ini sebenarnya kesalahan yang bisa dicegah dengan desain produk yang baik, tetapi pemasok produk dan layanan jauh lebih aktif terhadap perubahan regulasi dibanding konsumen, sehingga perbaikannya tidak banyak terjadi.
Karena itu, saya justru berpikir regulasi yang lebih ketat memang membantu kinerja keamanan, tetapi dari sudut pandang perusahaan muncul situasi aneh di mana tidak ada yang menyambut regulasi atas produk/layanan mereka sendiri.
Sistem yang sering meminta autentikasi ulang pada praktiknya tidak meningkatkan keamanan secara nyata (meski periode kedaluwarsa yang sangat panjang mungkin sedikit pengecualian).
Dalam sistem autentikasi yang baik, yang penting adalah kemampuan untuk segera mencabut hak akses lewat kedaluwarsa sesi atau manajemen sesi yang eksplisit.
Dalam praktik, dibanding siklus autentikasi ulang, yang jauh lebih penting adalah "latensi" dari saat hak akses sesi dicabut hingga sesi itu benar-benar berakhir dan kehilangan seluruh akses.
Hal ini makin rumit seiring makin banyaknya sistem penyusun dan struktur skema autentikasi.
Itulah mengapa refresh token diperlukan.
Token aktual memang kedaluwarsa secara berkala, tetapi klien diberi kesempatan terpisah untuk memperbarui token baru.
Pencabutan token dikendalikan dengan cara memblokir pembuatan token baru.
Saya juga berpikir serupa.
Di perusahaan kami, kami memakai autentikasi dua tahap.
Sekali atau dua kali sehari saya login ke keycloak lewat ADFS + MFA, dan sebagian besar sistem memakai keycloak sebagai OIDC provider serta token diperbarui tiap 10–15 menit.
Karena itu, biasanya saya hanya perlu melewati proses autentikasi yang merepotkan sekali sehari, dan bila perlu akses ke layanan yang terhubung lewat VPN bisa diputus total dalam waktu 15 menit.
Keunggulannya, saat penggunaan normal perubahan seperti ini hampir tidak terasa.
Yang dibutuhkan bukan autentikasi ulang, melainkan pembaruan token yang sudah ada secara berkala.
Sebaiknya waktu kedaluwarsa autentikasi (auth) dipisahkan dari waktu kedaluwarsa otorisasi (authorization).
Jika terlalu sering memaksa autentikasi ulang, orang justru akan mencari cara untuk mengakalinya.
Mereka menulis kata sandi di kertas, menyimpannya di Google Docs, memasang Arduino + servo motor ke Yubikey, meneruskan SMS ke email, atau mengirim kode TOTP lewat Wechat—segala macam "akal-akalan" akan muncul.
Pada akhirnya, makin parah kebijakan autentikasi yang menyulitkan, makin besar dilema bahwa pengguna akan mencari jalan pintas yang lebih tidak aman hanya agar bisa memakai komputer sedikit lebih bebas.
Artikel itu menyiratkan bahwa "sekarang sebagian besar OS bisa dibuka dengan sidik jari/wajah, jadi tidak ada alasan untuk tidak mengunci layar saat meninggalkan meja," tetapi dalam kenyataan hal itu sangat terbatas di workstation (PC desktop).
Selama 30 tahun saya memberi dukungan lapangan, saya baru pernah melihat tepat 1 desktop yang punya pemindai sidik jari.
Kamera juga hampir tidak ada; dari PC di 5 lokasi yang saya kelola saat ini, kurang dari 2% komputer punya kamera.
Pengenalan wajah juga punya faktor tambahan yang membuat pengguna tidak nyaman.
Kita sudah sangat tidak percaya pada pengenalan wajah tanpa persetujuan yang dilakukan diam-diam (kamera pengawas, sekolah/perusahaan/polisi, dll.), dan menurut saya ketidaknyamanan akibat hal itu wajar.
Meski perangkat itu milik saya, perusahaan perangkat lunak pada praktiknya merancang sistem dengan cara yang melampaui otoritas saya tanpa batas moral yang jelas.
Karena itu, saya rasa security key lebih cocok untuk workstation.
Kebijakan keamanan IT di industri bergerak seperti gagasan "tak ada yang dipecat karena membeli IBM"; semua orang hanya mengikuti apa yang dilakukan orang lain.
Apakah sistemnya rusak atau tidak nyaris tidak penting; yang penting adalah kita sudah melakukannya "sesuai buku".
Masalahnya, buku (standar) itu adalah sesuatu yang sangat buruk dan dibuat 30 tahun lalu.
Karena itu, perlu energi luar biasa untuk meyakinkan penanggung jawab keamanan informasi bahwa kata sandi tidak perlu diganti tiap 3 bulan.
Di salah satu perusahaan klien, semua sistem dibatasi sesi 30 menit.
Saya memang sejak awal tidak suka Jira, tetapi harus login ulang setiap kali hanya untuk melihat tiket membuatnya sangat menyiksa.
Akhirnya saya malah cuma membuka Hacker News alih-alih bekerja.
Untungnya sekarang kebanyakan layanan setidaknya menyimpan isi pekerjaan saya di cache.
Namanya SSO itu "SINGLE sign on", tetapi kenyataannya terus-menerus meminta autentikasi berulang.
Saya heran kenapa saya harus melihat pesan untuk autentikasi SSO ratusan kali sehari.
Untuk ponsel saya masih bisa mengerti karena ada risiko hilang/dicuri, tetapi desktop masih sering ditinggal tanpa logout di komputer umum (misalnya perpustakaan), dan banyak pengguna tidak menyadari hal ini.
Sepemahaman saya, makna SSO adalah login ke banyak sistem dengan satu ID yang sama, bukan berarti tindakan login itu sendiri hanya dilakukan satu kali.