<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Autentikasi on Nalar</title>
    <link>https://nalar.dev/id/tags/autentikasi/</link>
    <description>Recent content in Autentikasi on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Sat, 19 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/autentikasi/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Counter Tanda Tangan WebAuthn Adalah Sinyal Kloning, Bukan Jaminan Sesi</title>
      <link>https://nalar.dev/id/counter-tanda-tangan-webauthn-adalah-sinyal-kloning-bukan-jaminan-sesi/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/counter-tanda-tangan-webauthn-adalah-sinyal-kloning-bukan-jaminan-sesi/</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;Field &lt;code&gt;signCount&lt;/code&gt; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Kontinuitas Host Key SSH Adalah Batas Trust di Sisi Client</title>
      <link>https://nalar.dev/id/kontinuitas-host-key-ssh-adalah-batas-trust-di-sisi-client/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/kontinuitas-host-key-ssh-adalah-batas-trust-di-sisi-client/</guid>
      <description>&lt;h1 id=&#34;kontinuitas-host-key-ssh-adalah-batas-trust-di-sisi-client&#34;&gt;Kontinuitas Host Key SSH Adalah Batas Trust di Sisi Client&lt;/h1&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;Pada banyak client interaktif, artefak yang terlihat adalah entri &lt;code&gt;known_hosts&lt;/code&gt;. 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>MQTT over TLS pada ESP32: Enkripsi Transport dan Autentikasi Broker Adalah Batas yang Berbeda</title>
      <link>https://nalar.dev/id/mqtt-over-tls-esp32-enkripsi-transport-autentikasi-broker/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/mqtt-over-tls-esp32-enkripsi-transport-autentikasi-broker/</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;Menyebut konfigurasi ini &amp;ldquo;MQTT dengan HTTPS&amp;rdquo; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>OTP Email di Go: Kode Sekali Pakai, Kedaluwarsa, dan Perlindungan Replay</title>
      <link>https://nalar.dev/id/otp-email-di-go-kode-sekali-pakai-kedaluwarsa-dan-perlindungan-replay/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/otp-email-di-go-kode-sekali-pakai-kedaluwarsa-dan-perlindungan-replay/</guid>
      <description>&lt;h1 id=&#34;otp-email-di-go-kode-sekali-pakai-kedaluwarsa-dan-perlindungan-replay&#34;&gt;OTP Email di Go: Kode Sekali Pakai, Kedaluwarsa, dan Perlindungan Replay&lt;/h1&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Token PASETO Public dan Local Tidak Menyelesaikan Revokasi Sesi</title>
      <link>https://nalar.dev/id/token-paseto-public-local-tidak-menyelesaikan-revokasi-sesi/</link>
      <pubDate>Sat, 19 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/token-paseto-public-local-tidak-menyelesaikan-revokasi-sesi/</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;PASETO memberi setiap token version dan purpose yang eksplisit. Pada Version 4, &lt;code&gt;v4.public&lt;/code&gt; menandatangani message dengan Ed25519, sedangkan &lt;code&gt;v4.local&lt;/code&gt; 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.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
