Tombol “Masuk dengan akun perusahaan” seharusnya mempermudah akses pengguna. Namun, di belakang tombol tersebut, aplikasi dapat mengambil keputusan yang terlalu jauh: menemukan akun lokal dengan alamat email yang sama, lalu menghubungkan keduanya tanpa meminta bukti kepemilikan tambahan.

Bagi tim pengembang, keputusan ini terlihat efisien. Pengguna tidak perlu membuat akun baru, riwayat aktivitas tetap tersedia, dan tim dukungan tidak perlu menangani banyak profil ganda.

Persoalannya, aplikasi sedang melakukan sesuatu yang lebih besar daripada merapikan data pengguna. Aplikasi menambahkan jalur masuk ke akun yang sudah memiliki dokumen, transaksi, dan kewenangan tertentu.

Apabila dasar keputusannya hanya kesamaan email, kemudahan tersebut dapat membuka jalan bagi pengambilalihan akun. Kelemahannya terletak pada cara aplikasi menyimpulkan hubungan antara dua identitas yang berasal dari proses autentikasi berbeda.

Email yang Sama Terlalu Sering Dianggap sebagai Bukti yang Cukup

Banyak aplikasi tumbuh dengan menjadikan email sebagai pusat pengelolaan pengguna. Alamat tersebut dipakai untuk mendaftar, masuk, menerima notifikasi, hingga memulihkan kata sandi.

Ketika Single Sign-On atau SSO ditambahkan, pola pikir yang sama sering dipertahankan. Aplikasi menerima email dari penyedia identitas, mencarinya dalam basis data, kemudian menggunakan akun yang ditemukan.

Pendekatan ini menyederhanakan implementasi, tetapi menyatukan tiga hal yang seharusnya dibedakan: alamat kontak, identitas dari penyedia autentikasi, dan kepemilikan akun internal.

Alamat email dapat berubah. Dalam lingkungan organisasi, alamat tertentu juga dapat dialihkan kepada pengguna lain. Sementara itu, setiap penyedia identitas mempunyai aturan tersendiri mengenai pengelolaan dan verifikasi atribut pengguna.

Standar OpenID Connect menyatakan bahwa email tidak boleh diandalkan sebagai pengenal unik pengguna. Untuk mengenali pengguna secara stabil dalam konteks protokol tersebut, aplikasi menggunakan pasangan penerbit identitas, yaitu iss, dan pengenal subjek, yaitu sub.

Konsekuensinya jelas: kecocokan email dapat membantu aplikasi menemukan kemungkinan hubungan antarprofil. Keputusan untuk memberikan akses tetap membutuhkan dasar pembuktian yang lebih kuat.

Pengambilalihan Dapat Dipersiapkan Sebelum Pemilik Akun Datang

Risiko penggabungan akun tidak selalu dimulai ketika penyerang mencoba memasuki akun yang sudah aktif. Pada desain tertentu, masalah dapat dipersiapkan sebelum pengguna yang sah mulai memakai layanan.

Bayangkan sebuah aplikasi bisnis menyediakan pendaftaran lokal menggunakan email dan kata sandi. Pendaftaran tersebut belum mewajibkan verifikasi email sebelum kredensial dapat digunakan.

Seseorang kemudian membuat akun menggunakan alamat email milik calon pengguna. Ia menetapkan kata sandi yang diketahuinya sendiri.

Beberapa waktu kemudian, pemilik email yang sebenarnya masuk melalui SSO. Aplikasi menemukan kecocokan alamat dan langsung menghubungkan identitas SSO dengan akun lokal tersebut.

Dari sudut pandang pengguna, proses berjalan normal. Ia berhasil masuk dan mulai menggunakan aplikasi. Namun, apabila kredensial lokal yang dibuat sebelumnya tetap berlaku, pihak yang menyiapkannya berpotensi masih memiliki jalan masuk.

Risiko semacam ini menjadi bagian dari pembahasan penelitian Pre-hijacked Accounts: An Empirical Study of Security Failures in User Account Creation on the Web, yang dipublikasikan dalam USENIX Security 2022. Penelitian tersebut menyoroti bagaimana kelemahan dalam proses pembuatan dan pengelolaan akun dapat dimanfaatkan sebelum korban mulai menggunakan layanan.

Skenario ini tidak berarti seluruh aplikasi yang menyediakan login lokal dan SSO otomatis rentan. Eksploitasi bergantung pada rangkaian kondisi, termasuk kebijakan verifikasi, aturan penggabungan, dan keberlanjutan akses lama.

Justru rangkaian itulah yang perlu diperiksa. Satu kontrol yang terlihat benar belum tentu menutup kelemahan pada keseluruhan proses.

Login SSO yang Sah Masih Bisa Dipetakan ke Akun yang Keliru

Ada anggapan bahwa risiko pengambilalihan akun telah selesai ketika token SSO dinyatakan valid. Padahal, validasi token dan pemetaan akun menjawab dua pertanyaan berbeda.

Validasi token memeriksa apakah bukti autentikasi dapat diterima oleh aplikasi. Pemetaan akun menentukan pengguna internal mana yang akan memperoleh sesi dari bukti tersebut.

Aplikasi dapat menerima token yang sah, tetapi tetap salah memberikan akses apabila identitas di dalamnya dipetakan hanya melalui atribut email.

Microsoft Security Response Center pernah memperingatkan risiko peningkatan hak akses pada aplikasi yang menggunakan klaim email untuk otorisasi atau identifikasi utama pengguna. Peringatan tersebut memperlihatkan pentingnya pemilihan atribut identitas setelah proses autentikasi berlangsung.

Dalam aplikasi perusahaan, kesalahan pemetaan dapat membawa pengguna ke profil dengan akses dokumen, data pelanggan, atau fungsi persetujuan yang tidak seharusnya dimiliki.

Artinya, pengujian keamanan SSO tidak cukup berhenti pada pertanyaan apakah token diterima atau ditolak. Tim juga perlu memastikan bahwa token yang diterima menghasilkan akses ke akun yang benar.

Email Terverifikasi Memiliki Batas Pembuktian

Memeriksa status verifikasi email merupakan langkah penting. Namun, makna “terverifikasi” perlu ditempatkan secara tepat.

Dalam OpenID Connect, atribut email_verified menunjukkan bahwa penyedia identitas telah mengambil langkah untuk memastikan penguasaan alamat tersebut ketika verifikasi dilakukan. Atribut ini tidak dengan sendirinya membuktikan bahwa pengguna menguasai akun lokal yang hendak dihubungkan.

Perbedaan tersebut menjadi penting ketika akun lokal mempunyai riwayat tersendiri. Akun itu mungkin sudah memiliki kata sandi, sesi aktif, metode pemulihan, atau hubungan dengan organisasi tertentu.

Verifikasi email pada satu penyedia tidak otomatis menyelesaikan persoalan mengenai siapa yang sebelumnya mengendalikan seluruh akses tersebut.

Karena itu, keputusan penggabungan perlu mempertimbangkan asal identitas, kebijakan penyedia, kondisi akun tujuan, dan bukti penguasaan terhadap kedua akun.

Menambahkan pemeriksaan email_verified tanpa meninjau proses lainnya berisiko memberikan rasa aman yang berlebihan.

Menghubungkan Identitas Berarti Mengubah Kendali atas Akun

Istilah “menggabungkan akun” terdengar administratif. Padahal, dampaknya setara dengan menambahkan metode autentikasi.

Setelah identitas baru terhubung, pemilik identitas tersebut mungkin dapat memasuki akun tanpa menggunakan kata sandi lokal. Ia memperoleh akses melalui jalur lain yang kini dianggap setara oleh aplikasi.

Karena itu, proses penggabungan perlu diperlakukan sebagai perubahan keamanan yang sensitif.

Tim pengembang harus menentukan akun mana yang menjadi tujuan, data apa yang dipertahankan, dan kewenangan mana yang tetap berlaku. Menggabungkan seluruh peran dari dua akun secara otomatis dapat menghasilkan akses yang lebih luas daripada yang dimaksudkan.

Masalah serupa berlaku pada aplikasi dengan banyak organisasi atau tenant. Dua identitas yang membawa email sama tidak seharusnya menjadi alasan untuk mencampurkan keanggotaan maupun data dari lingkungan yang berbeda.

Persetujuan pengguna pun perlu menjelaskan konsekuensinya. Pesan bahwa profil telah diperbarui terlalu umum apabila tindakan sebenarnya adalah menambahkan cara baru untuk masuk.

Pengguna perlu mengetahui identitas apa yang dihubungkan dan akun mana yang akan dapat diakses melalui identitas tersebut.

Bukti Penguasaan Kedua Akun Perlu Menjadi Dasar

Desain account linking yang lebih kuat menempatkan pembuktian kepemilikan sebelum penggabungan.

Pengguna masuk ke akun yang sudah dimilikinya, memilih penambahan metode login, lalu menjalani autentikasi untuk identitas lain yang hendak dihubungkan. Untuk perubahan yang sensitif, aplikasi dapat meminta autentikasi ulang sesuai tingkat risiko.

Dokumentasi keamanan Auth0 merekomendasikan autentikasi terhadap kedua akun sebelum penghubungan dilakukan. Pendekatan ini menempatkan penguasaan akun sebagai dasar keputusan, sementara kesamaan email hanya membantu menemukan kandidat akun.

Pelaksanaannya tetap perlu dirancang dengan cermat. Keberadaan sesi lama tidak selalu cukup untuk mengizinkan perubahan penting, khususnya ketika sesi tersebut sudah berlangsung lama atau aktivitasnya menunjukkan anomali.

Jika pengguna kehilangan akses ke salah satu akun, aplikasi perlu mengarahkannya ke proses pemulihan yang terkontrol. Kendala tersebut tidak semestinya diselesaikan dengan melewati pembuktian kepemilikan dan langsung menggabungkan akun.

Untuk migrasi SSO dalam skala perusahaan, pemetaan akun sebaiknya menjadi pekerjaan yang direncanakan. Organisasi dapat memvalidasi hubungan identitas melalui data dan persetujuan administratif yang berwenang, dengan penanganan khusus terhadap konflik maupun akun yang meragukan.

Migrasi identitas terlalu penting untuk diserahkan sepenuhnya kepada pencocokan email saat login pertama.

Identitas Stabil Harus Dipisahkan dari Informasi Kontak

Perbaikan yang bertahan lama membutuhkan model data yang tepat.

Aplikasi sebaiknya memiliki ID pengguna internal yang tidak bergantung pada perubahan email. Identitas lokal dan identitas federasi kemudian dihubungkan ke ID internal tersebut melalui relasi yang dikelola secara eksplisit.

Pada OpenID Connect, pasangan iss dan sub digunakan untuk mengenali identitas eksternal. Email tetap dapat dipakai untuk komunikasi, tampilan profil, atau membantu pencarian, tetapi perubahan alamat tidak otomatis mengubah pemilik akun.

Google juga mengingatkan pengembang agar tidak menggunakan email sebagai pengenal unik pengguna karena alamat yang terkait dengan akun dapat berubah.

Prinsip tersebut perlu diterapkan secara konsisten pada seluruh siklus akun. Jika proses login memakai identitas stabil tetapi fitur perubahan email diam-diam menghubungkan ulang akun berdasarkan alamat, kelemahan yang sama muncul melalui jalur berbeda.

Konsistensi juga dibutuhkan pada fitur undangan organisasi, pemulihan kata sandi, dan pemindahan akun. Setiap fitur tersebut dapat memengaruhi hubungan antara identitas dan hak akses.

Mengaktifkan SSO Tidak Otomatis Menutup Login Lokal

Perusahaan dapat mewajibkan SSO karena ingin memusatkan kebijakan autentikasi dan penonaktifan pengguna. Namun, tujuan tersebut tidak tercapai apabila aplikasi masih menyediakan jalur lokal yang berjalan di luar kebijakan.

Sebagai contoh, akun perusahaan sudah dinonaktifkan pada penyedia identitas, tetapi pengguna masih dapat masuk melalui kata sandi lokal yang tersimpan sebelumnya.

Dalam keadaan lain, fitur “Lupa kata sandi” mungkin memungkinkan pengguna membuat kredensial lokal baru, meskipun akun organisasi seharusnya hanya dapat diakses melalui SSO.

Kondisi tersebut membutuhkan keputusan kebijakan yang jelas. Apakah login lokal tetap diizinkan? Siapa yang mendapat pengecualian? Bagaimana proses penonaktifan diterapkan pada sesi dan metode autentikasi lain?

Perusahaan juga perlu memperhatikan sesi aplikasi yang telah terbentuk sebelum akun SSO dinonaktifkan. Penonaktifan pada penyedia identitas belum tentu langsung mengakhiri seluruh sesi aplikasi tanpa mekanisme pencabutan yang sesuai.

Penggabungan akun yang aman tidak berhenti pada keberhasilan menambahkan SSO. Organisasi perlu memahami seluruh jalur yang masih dapat digunakan untuk memperoleh akses.

Pengujian Harus Menelusuri Pertemuan Antaralur

Celah logika bisnis sering muncul ketika beberapa fitur yang terlihat aman secara terpisah digunakan dalam urutan tertentu.

Pendaftaran lokal, login SSO, perubahan email, pemulihan akun, dan pelepasan identitas mungkin masing-masing lolos pengujian fungsional. Namun, hubungan di antara fitur-fitur tersebut dapat menghasilkan kondisi akses yang tidak direncanakan.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Untuk mengevaluasi keamanan account linking, pengujian perlu mencakup beberapa pertanyaan berikut:

• Apa yang terjadi jika akun lokal belum memverifikasi email ketika login SSO dilakukan?
• Apakah identitas dari penyedia berbeda dengan email sama diperlakukan sebagai pengguna yang sama?
• Apakah perubahan email menyebabkan perpindahan atau penggabungan akun otomatis?
• Apakah kata sandi dan sesi lama tetap berlaku setelah identitas baru dihubungkan?
• Bagaimana peran dan keanggotaan organisasi ditentukan setelah penggabungan?
• Apakah pemulihan kata sandi dapat mengaktifkan jalur lokal yang seharusnya dilarang?
• Apakah pelepasan identitas benar-benar mencabut jalur akses terkait?
• Bagaimana aplikasi menangani dua permintaan penggabungan yang berlangsung hampir bersamaan?

Pengujian sebaiknya menggunakan akun terkendali dengan kondisi dan kewenangan berbeda. Tujuannya adalah memastikan siapa yang dapat masuk, ke akun mana, dan melalui dasar pembuktian apa.

Temuan juga perlu diterjemahkan menjadi konsekuensi bisnis. Akses ke profil biasa memiliki dampak berbeda dari akses ke akun yang dapat mengekspor data pelanggan atau menyetujui transaksi.

Karena itu, evaluasi tidak cukup menghasilkan pernyataan bahwa dua akun berhasil digabungkan. Evaluasi harus memperlihatkan apakah penggabungan tersebut mempertahankan batas kepemilikan dan kewenangan yang semestinya.

Kemudahan Login Harus Berdiri di Atas Kepastian Kepemilikan

Penggabungan akun tetap memiliki manfaat. Pengguna dapat berpindah metode autentikasi tanpa kehilangan riwayat, sementara perusahaan dapat mengurangi profil ganda dan menyederhanakan pengelolaan akses.

Manfaat tersebut perlu dibangun di atas pembuktian kepemilikan yang memadai.

Kesamaan email dapat menjadi titik awal pemeriksaan. Keputusan untuk menghubungkan identitas harus mempertimbangkan identitas stabil, penguasaan kedua akun, kewenangan pengguna, serta metode akses yang tetap aktif setelah perubahan.

Bagi perusahaan yang sedang mengintegrasikan SSO, menambah pilihan login, atau memigrasikan pengguna lama, peninjauan account linking sebaiknya menjadi bagian dari pengembangan sejak awal.

Menemukan konflik identitas sebelum peluncuran memungkinkan tim memperbaiki aturan pemetaan dan akses sebelum akun tersebut menyimpan data bisnis yang sensitif.

Pastikan Integrasi Login Tidak Menambahkan Akses yang Keliru

Fourtrezz menyediakan layanan Penetration Testing dan Vulnerability Assessment untuk membantu perusahaan mengidentifikasi kelemahan keamanan pada aplikasi maupun infrastruktur.

Jika aplikasi perusahaan Anda menggunakan akun lokal sekaligus SSO, bekerja sama dengan Fourtrezz dapat menjadi langkah untuk mengevaluasi alur autentikasi, penggabungan identitas, pemulihan akun, dan kontrol akses sesuai ruang lingkup pengujian yang disepakati.

Ajak tim Fourtrezz meninjau kebutuhan pengujian aplikasi Anda. Pastikan kemudahan akses yang diberikan kepada pengguna tetap disertai kepastian tentang siapa yang berhak menguasai akun dan mengakses data perusahaan.

Hubungi Fourtrezz:
Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]