Langsung ke konten

Arsip

Autentikasi

16 artikel
Keamanan Siber 21 Sep 2026 6 min read

Verifikasi Host Key SSH Mengikat Koneksi ke Identitas Server

Verifikasi Host Key SSH Mengikat Koneksi ke Identitas Server SSH mengenkripsi koneksi, tetapi enkripsi saja tidak memastikan endpoint yang dicapai merupakan server yang dituju. Saat key exchange, server membuktikan kepemilikan host private key. Client kemudian harus memutuskan apakah identitas publik yang terkait dapat dipercaya untuk host tersebut. Keputusan itu merupakan boundary autentikasi host. Jika client menerima host key milik penyerang tanpa dasar trust yang valid, channel yang terbentuk tetap dapat terenkripsi tetapi berakhir pada mesin yang salah. Password, command, forwarded agent, dan data sesi kemudian dapat melintasi boundary yang tidak dimaksudkan operator.

Keamanan Siber 21 Sep 2026 6 min read

Sertifikat SSH Mengikat Identitas ke Principal dan Batasan

Sertifikat SSH Mengikat Identitas ke Principal dan Batasan Public key SSH mentah menjawab pertanyaan yang sempit: apakah client yang terhubung memiliki private key yang berpasangan dengan public key ini? Authorization masih membutuhkan pemetaan lain. Server biasanya menaruh key yang diterima di authorized_keys, sering kali bersama option yang membatasi tindakan key tertentu. Sertifikat OpenSSH menambahkan layer identitas bertanda tangan di sekitar public key. Sertifikat dapat membawa principal, interval validitas, critical option, extension, serial number, dan key identifier. Server yang dikonfigurasi untuk mempercayai signing CA dapat memvalidasi sertifikat tersebut tanpa menyimpan public key mentah milik pemegangnya sebagai entry authorization terpisah.

Keamanan Siber 21 Sep 2026 4 min read

RP ID WebAuthn Membatasi Penggunaan Kredensial

RP ID WebAuthn Membatasi Penggunaan Kredensial Kredensial WebAuthn bukan key yang dapat diminta oleh situs mana pun dari authenticator. Registrasi dan autentikasi terikat pada relying party identifier, atau RP ID, sementara browser juga memeriksa origin pemanggil. Pasangan ini membentuk batas domain untuk kredensial public-key. Pada deployment umum di https://login.example.com, RP dapat memakai host tersebut sebagai RP ID: origin: https://login.example.com RP ID: login.example.com RP juga dapat memakai suffix registrable domain seperti example.com jika deployment memerlukan kredensial untuk subdomain yang memenuhi syarat:

Keamanan Siber 21 Sep 2026 6 min read

Mutual TLS Mengautentikasi Kedua Sisi Koneksi

Mutual TLS Mengautentikasi Kedua Sisi Koneksi Koneksi HTTPS konvensional mengautentikasi server dengan certificate, sementara client biasanya membuktikan identitasnya kemudian melalui mekanisme aplikasi seperti session cookie, bearer token, atau password. Mutual TLS, yang umum disingkat mTLS, menambahkan autentikasi client berbasis certificate ke dalam exchange TLS. Hasilnya adalah transport channel tempat setiap peer dapat memverifikasi certificate chain dan proof of possession atas private key dari sisi lainnya. Hal itu mengubah boundary autentikasi, tetapi tidak menjadikan certificate sebagai authorization policy. Identitas client yang valid tetap dapat ditolak saat mengakses resource tertentu.

Keamanan Siber 20 Sep 2026 5 min read

Rotasi ID Session Menutup Celah Session Pra-Autentikasi

Rotasi ID Session Menutup Celah Session Pra-Autentikasi Aplikasi web dapat membuat session sebelum user masuk. Session anonim itu mungkin menyimpan token CSRF, locale, isi keranjang, atau state sementara lain. Autentikasi mengubah otoritas yang melekat pada session: server kini memperlakukan request yang membawa session tersebut sebagai milik akun tertentu. Jika aplikasi mempertahankan identifier session yang sama sepanjang transisi itu, nilai yang sudah ada sebelum autentikasi dapat berubah menjadi pegangan untuk session terautentikasi. Serangan session fixation memanfaatkan kesinambungan tersebut. Batas pertahanannya berada tepat pada peristiwa autentikasi: pertahankan hanya state yang memang perlu dibawa, terbitkan identifier baru yang tidak dapat diprediksi, lalu hentikan identifier lama.

Keamanan Siber 20 Sep 2026 5 min read

Pemeriksaan Audience JWT Menjaga Token di Batas Layanan yang Dituju

Pemeriksaan Audience JWT Menjaga Token di Batas Layanan yang Dituju Signature JSON Web Token yang valid membuktikan hal yang terbatas: byte token ditandatangani dengan key yang diterima verifier dan tidak diubah setelahnya tanpa membuat signature menjadi tidak valid. Hasil itu tidak menetapkan bahwa token diterbitkan untuk layanan yang sedang menerimanya. Perbedaan ini penting pada sistem tempat satu authority menerbitkan token bagi beberapa API, atau beberapa authority memakai key yang dapat dijangkau aplikasi melalui konfigurasi. Token dapat valid secara kriptografis tetapi berasal dari konteks keamanan yang berbeda. Claim iss dan aud memberi verifier input untuk menegakkan batas tersebut.

Keamanan Siber 20 Sep 2026 5 min read

Link Reset Password Memerlukan Origin Publik yang Tepercaya

Link Reset Password Memerlukan Origin Publik yang Tepercaya Email reset password sering memuat salah satu URL paling sensitif yang dibuat aplikasi. Kepemilikan token reset yang valid dapat cukup untuk menetapkan kredensial baru bagi akun terkait, sehingga tujuan yang ditanamkan pada URL tersebut merupakan bagian dari batas keamanan. Kesalahan implementasi yang umum adalah membentuk URL reset absolut dari informasi host pada HTTP request yang masuk. Header seperti Host digunakan untuk routing request, sedangkan deployment di belakang proxy juga dapat mengekspos metadata host atau scheme yang diteruskan. Kecuali aplikasi telah menetapkan secara eksplisit intermediary mana yang dipercaya dan nilai mana yang valid, metadata request tersebut bukan sumber otoritas yang aman untuk link keluar yang sensitif terhadap keamanan.

Keamanan Siber 19 Sep 2026 5 min read

Token PASETO Public dan Local Tidak Menyelesaikan Revokasi Sesi

Token PASETO dapat melindungi claim secara kriptografis tanpa mengetahui apakah pengguna sudah logout. Batas ini lebih penting daripada sekadar membandingkan JWT dengan PASETO: mengganti format token tidak otomatis menghasilkan mekanisme revokasi sesi. PASETO memberi setiap token version dan purpose yang eksplisit. Pada Version 4, v4.public menandatangani message dengan Ed25519, sedangkan v4.local mengenkripsi dan mengautentikasi message dengan symmetric cryptography. Pilihan tersebut menentukan siapa yang dapat membaca token serta siapa yang dapat membuat atau memverifikasinya. Pilihan itu tidak menentukan apakah token yang sebelumnya valid masih boleh diterima setelah state sesi berubah.

Go 19 Sep 2026 7 min read

OTP Email di Go: Kode Sekali Pakai, Kedaluwarsa, dan Perlindungan Replay

OTP Email di Go: Kode Sekali Pakai, Kedaluwarsa, dan Perlindungan Replay OTP email terlihat sederhana: buat enam digit, kirimkan, lalu bandingkan dengan input pengguna. Namun, batas keamanannya bukan berada pada API email. Bagian pentingnya adalah lifecycle challenge di sisi server. Implementasi yang benar harus membuat kode sulit ditebak, membatasi masa berlakunya, membatasi tebakan, menonaktifkan challenge lama ketika diperlukan, dan memastikan kode yang sudah berhasil dipakai tidak dapat dikonsumsi untuk kedua kalinya. Properti ini berbeda dari TOTP, meskipun keduanya sering disebut OTP.

Keamanan Siber 19 Sep 2026 5 min read

MQTT over TLS pada ESP32: Enkripsi Transport dan Autentikasi Broker Adalah Batas yang Berbeda

ESP32 yang memindahkan koneksi MQTT dari port 1883 ke 8883 tidak sekadar berpindah port. Stream TCP sekarang diharapkan membawa MQTT di dalam TLS. Data dalam perjalanan terlindungi hanya jika client TLS juga memvalidasi sertifikat broker. Autentikasi username/password MQTT merupakan mekanisme terpisah: kredensial mengidentifikasi client kepada broker, sedangkan validasi sertifikat mengidentifikasi broker kepada ESP32. Menyebut konfigurasi ini “MQTT dengan HTTPS” mencampur dua protokol aplikasi. MQTT tidak berubah menjadi HTTP ketika TLS ditambahkan. MQTT dapat berjalan melalui TCP biasa atau melalui koneksi TCP yang dilindungi TLS.

Keamanan Siber 19 Sep 2026 6 min read

Kontinuitas Host Key SSH Adalah Batas Trust di Sisi Client

Kontinuitas Host Key SSH Adalah Batas Trust di Sisi Client Koneksi SSH dapat menegosiasikan enkripsi yang kuat tetapi tetap mengautentikasi server yang salah. Enkripsi melindungi transport setelah key exchange membentuk konteks kriptografinya; enkripsi tidak secara mandiri menyatakan bahwa server key tersebut milik host yang memang dituju client. Keputusan identitas itu berada pada verifikasi host key. Pada banyak client interaktif, artefak yang terlihat adalah entri known_hosts. Properti keamanan yang lebih mendasar adalah kontinuitas: client memerlukan dasar tepercaya untuk menerima sebuah host key saat ini dan untuk menentukan apakah key yang berbeda di kemudian hari merupakan rotasi yang sah atau endpoint yang tidak diharapkan.

Keamanan Siber 19 Sep 2026 6 min read

Counter Tanda Tangan WebAuthn Adalah Sinyal Kloning, Bukan Jaminan Sesi

Sebuah assertion WebAuthn dapat memiliki signature yang valid tetapi tetap menunjukkan anomali operasional: signature counter-nya tidak lebih besar daripada nilai yang disimpan setelah assertion sukses sebelumnya. Kondisi ini berguna sebagai sinyal, tetapi tidak sama dengan bukti bahwa private key telah disalin, dan counter tersebut bukan mekanisme pencegah replay. Field signCount berada di dalam authenticator data. Relying party menerima authenticator data itu sebagai bagian dari assertion lalu memverifikasinya bersama client data dan signature. Counter dapat memberi relying party bukti mengenai state authenticator di antara ceremony yang sukses. Nilai keamanannya bergantung pada perilaku counter milik authenticator dan pada kemampuan relying party menyimpan nilai sebelumnya secara benar.

Keamanan Siber 19 Sep 2026 6 min read

Counter Tanda Tangan WebAuthn Adalah Sinyal Kloning, Bukan Bukti Identitas

Counter Tanda Tangan WebAuthn Adalah Sinyal Kloning, Bukan Bukti Identitas Relying party dapat memverifikasi assertion WebAuthn yang valid dan tetap menerima nilai counter yang tidak memberikan bukti berguna mengenai kloning credential. Tanda tangan membuktikan penguasaan private key credential untuk assertion yang ditandatangani. Field signCount memiliki peran yang lebih sempit: ketika authenticator memelihara counter tanda tangan yang dapat digunakan, perubahan nilainya dapat memberi relying party indikasi bahwa credential yang sama mungkin aktif di lebih dari satu tempat.

Keamanan Siber 13 Sep 2026 8 min read

Verifikasi JWT Harus Mengikat Algorithm, Key, dan Issuer

Verifikasi JWT Harus Mengikat Algorithm, Key, dan Issuer Token yang ditandatangani dapat valid secara kriptografis tetapi tetap tidak dapat diterima oleh service yang menerimanya. Signature menjawab pertanyaan sempit: byte token cocok dengan signature yang dibuat menggunakan cryptographic key tertentu di bawah algorithm tertentu. Authorization bergantung pada kumpulan fakta yang lebih luas, termasuk siapa yang mengendalikan key tersebut, issuer mana yang dipercaya, audience mana yang dituju token, dan algorithm mana yang memang dimaksudkan aplikasi untuk diterima.

Keamanan Siber 10 Sep 2026 11 min read

Ikat Callback OAuth ke Login yang Memulainya

Callback OAuth dapat terlihat valid meskipun berasal dari interaksi browser yang salah. Authorization server mungkin telah menerbitkan code yang nyata, redirect URI mungkin benar, dan pertukaran code mungkin berhasil. Namun jika client tidak dapat menentukan apakah browser ini benar-benar memulai authorization flow tersebut, client dapat mengaitkan identitas eksternal atau authorization yang salah ke session saat ini. Ini adalah bentuk cross-site request forgery pada callback OAuth. Dalam login flow, salah satu konsekuensinya adalah login CSRF: korban dapat berakhir login ke client sebagai account yang terkait dengan orang lain. Detailnya berbeda antar-aplikasi, tetapi pertanyaan defensifnya tetap sama: apakah callback ini milik transaksi login yang dimulai user agent ini?

Keamanan Siber 09 Sep 2026 9 min read

Buat Request Sensitif Tahan terhadap Replay

Server dapat membuktikan dengan benar bahwa sebuah request berasal dari client tepercaya tetapi tetap memprosesnya lebih banyak dari yang dimaksudkan. Jika request terautentikasi mengatakan “setujui pembayaran ini” atau “ubah alamat pemulihan ini”, menerima request valid yang sama dua kali dapat menimbulkan masalah keamanan walaupun tidak ada salinan yang dipalsukan. Ini adalah masalah replay. Replay terjadi ketika pesan yang sebelumnya valid disajikan kembali dan penerima tidak dapat mengetahui bahwa otoritasnya sudah digunakan, atau bahwa pesan tersebut terlalu lama untuk dipercaya.