Bagaimana Saya Memberi Identitas pada Saluran Pesan Publik

Pendahuluan

A. Saluran yang bisa dipakai siapa saja

GPU laptop saya punya video memory 4 GB, dan itu tak cukup untuk bagian terberat dari beberapa project saya. Bagian itu — membuat gambar dan narasi dengan model besar — berjalan di runtime Google Colab dengan T4 dan sekitar 15 GB VRAM. Laptop memegang sisanya, termasuk antarmuka di browser tempat saya memulai pekerjaan, membuat ulang item, dan memantau kemajuan.

Runtime Colab tak bisa dipanggil dari luar. Ia tak punya alamat tetap dan tak punya port yang bisa dibuka ke dunia, jadi antarmuka tak bisa sekadar mengirim request kepadanya. Yang menyambungkan keduanya adalah message broker yang berbicara MQTT: server kecil yang dihubungi oleh kedua pihak. Antarmuka mem-publish perintah ke topic bernama dan berlangganan status; worker di Colab sebaliknya. Tak ada yang perlu bisa dijangkau, sebab keduanya menghubungi keluar. Dua fitur MQTT berperan di bawah. Pesan retained disimpan broker lalu diserahkan kepada siapa pun yang berlangganan belakangan. Last Will adalah pesan yang di-publish broker atas nama sebuah klien bila klien itu lenyap tanpa pamit.

Broker pertamanya broker publik — gratis, sudah berjalan, tak ada yang perlu dipasang. Untuk mencari tahu apakah rancangannya bekerja sama sekali, itu pilihan yang persis tepat, dan rancangannya memang bekerja. Tapi broker publik tak punya gagasan siapa pun itu siapa. Siapa saja yang menebak nama topic bisa membaca apa yang di-publish di sana, dan siapa saja bisa mem-publish ke sana, termasuk perintah untuk worker saya. Selama pesannya cuma status pekerjaan milik saya sendiri, risiko itu bisa ditanggung; begitu antarmukanya mau dibuka dari internet, ia berhenti bisa ditanggung.

Tantangannya: memberi saluran pesan publik itu sebuah identitas — menggantinya dengan saluran yang tahu siapa yang tersambung, mengizinkan tiap klien cuma yang semestinya, dan mengenkripsi apa pun yang melintasi internet — tanpa merusak apa pun yang sudah memakainya.

Gampang dirumuskan, canggung dibangun. Nyaris tak ada kesulitan di broker-nya sendiri, yang memang sudah saya jalankan untuk pekerjaan lain. Kesulitannya ada di kedua klien, dan di pengaman yang sempat tumbuh di kedua klien itu demi broker publik — sebagian jadi tak berguna begitu broker punya identitas, dan sebagian malah jadi berbahaya. Pengaman yang tak berguna cuma memboroskan perawatan; pengaman yang berbahaya justru membuka celah atas nama menutupnya.

B. Kenapa harus berubah, dan apa arti "identitas" di sini

Empat alasan datang bersamaan. Pertama, keterbukaan: topic dan isi pesan di broker publik terbuka bagi siapa pun yang bisa menebak namanya. Kedua, keandalan: broker publik itu mengumumkan bahwa satu klien boleh punya 32 pesan melayang sekaligus, dan saat diukur, ia menerima empat sebelum menolak dengan "quota exceeded". Ketiga, antarmukanya perlu dibuka dari internet, di balik login — dan login tak banyak berarti kalau saluran di bawahnya membiarkan siapa saja lewat. Keempat membuat ketiga alasan lain terjangkau: saya sudah menjalankan broker sendiri, lengkap dengan kendali akses, untuk project lain.

"Identitas" di sini berarti tiga perkara yang konkret. Autentikasi: tiap sambungan membuktikan siapa dirinya — worker dengan username dan password, browser dengan token hasil login. Otorisasi: sebuah access-control list (ACL) di broker menentukan topic mana yang boleh dibaca dan ditulis tiap identitas. Enkripsi: segala yang melintasi internet lewat TLS, sehingga password atau token tak bisa dibaca di tengah jalan. Ketiganya saling membutuhkan: identitas tanpa enkripsi membocorkan kredensialnya, dan enkripsi tanpa identitas cuma melindungi percakapan dengan siapa saja.

Ada dua klien yang sangat berbeda untuk dipindahkan. Worker adalah program Python di dalam notebook, yang bisa tersambung lewat TCP polos dan menyetel opsi apa pun sesukanya. Antarmuka adalah halaman web, yang cuma bisa menjangkau broker lewat WebSocket — sambungan yang dibuka halaman web ke server dan dibiarkan terbuka, sehingga pesan bisa mengalir dua arah — dan terbatas pada apa yang diizinkan browser. Sebagian besar hambatan di bawah milik salah satunya, dan beberapa ternyata tempat ketika browser memang tak sanggup melakukan apa yang diandaikan rancangan yang paling jelas.

Perbedaan itu yang membuat pindah broker tak bisa dikerjakan sebagai satu langkah. Worker bisa diubah dengan menyunting beberapa baris di notebook; browser harus mengikuti aturan yang tak bisa ditawar.

C. Delapan hambatan yang menghalangi

Empat perubahan sekaligus membuat tiap kegagalan ambigu. Broker baru, login, token yang kedaluwarsa, dan enkripsi wajib, dinyalakan serentak, akan meninggalkan tiap kegagalan tanpa sebab yang jelas.

Pengaman yang cuma masuk akal di broker publik. Nama topic diturunkan dari sebuah hash supaya tak ada yang bisa menebaknya — dihitung di empat tempat terpisah yang semuanya wajib sepakat.

Kendali akses gagal tanpa suara. Sambungan yang ditolak mentah-mentah gampang didiagnosis. Sambungan yang sukses lalu diam-diam tak menerima apa pun tidak — dan begitulah rupa ketidakcocokan ACL.

Worker yang ditolak tetap berjalan. Di broker publik tak ada yang pernah ditolak, jadi worker tak pernah memeriksanya. Di broker berpassword, mengabaikan penolakan berarti berjam-jam operasi yang tampak normal tapi tak menghasilkan apa pun.

Browser tak bisa menambah header pada handshake WebSocket. Cara lazim menyerahkan token — header Authorization — tak tersedia bagi halaman web yang membuka sambungan jenis ini.

Token kedaluwarsa di bawah sambungan yang sedang hidup. Login menerbitkan token berumur pendek, dan broker memutus klien yang tokennya sudah kedaluwarsa. Antarmuka wajib memperbarui sambungannya tanpa kehilangan pesan di selanya.

Langganan bersama tak mengantar pesan retained. Fitur yang mencegah antarmuka menerima tiap pesan dua kali selama pembaruan ternyata menyembunyikan persis pesan yang menyatakan apakah worker masih hidup.

Port terenkripsi tidak menolak klien yang tak terenkripsi — ia menggantung. Gejalanya mirip password yang salah, dan itu mengirim penyelidikan ke arah yang keliru.

Urutannya mengikuti perpindahan itu sendiri. Hambatan pertama soal bagaimana mengubah apa pun sama sekali; tiga berikutnya soal worker dan aturan broker; tiga sesudahnya soal browser; dan yang terakhir soal enkripsi, yang datang paling akhir karena itulah satu-satunya perubahan yang akan mematahkan semua klien sekaligus.

Metode

A. Empat tahap, dan satu probe sebelum semuanya

Inilah jawaban atas hambatan pertama: ubah satu perkara pada satu waktu, dan jadikan tiap langkah bisa diuji dan dibatalkan sendiri-sendiri.

# tahap 1  broker sendiri, prefix topic tetap, kredensial worker
# tahap 2  login browser (PKCE), token diserahkan ke broker
# tahap 3  cuma enkripsi: port polos ditutup, port TLS wajib

Tiap tahap adalah perubahan terpisah yang membiarkan sistemnya tetap jalan. Kalau tahap dua merusak sesuatu, tahap satu tetap jadi keadaan yang sudah diketahui baik untuk kembali, dan daftar tersangkanya pendek.

Sebelum pekerjaan antarmuka mana pun, sebuah script kecil ditulis untuk membuktikan bahwa broker, penyedia login, dan aturan aksesnya bekerja dengan sendirinya. Tanpa itu, tiap kegagalan di antarmuka membawa dua kemungkinan sebab: bug di antarmuka, atau broker yang dikonfigurasi berbeda dari dugaan. Dengan itu, kegagalan di antarmuka memang kegagalan di antarmuka.

Script itu perlu melakukan login sungguhan, dan code login yang sudah jalan sudah ada di project saya yang lain. Ia mengimpor code itu ketimbang menyalinnya:

sys.path.insert(0, str(APIGA_SCRIPTS))
from login import fetch_code

code, verifier, _nonce = fetch_code(...)

Alasannya perawatan, bukan kepraktisan. Dua implementasi alur login yang sama yang harus terus sepakat pada akhirnya akan berselisih, dan yang melenceng selalu yang tak sedang diperhatikan siapa pun.

B. Hash yang kehilangan alasan keberadaannya

Ini menjawab hambatan kedua. Di broker publik, prefix topic diturunkan dari hash kunci akses storage, supaya tak bisa ditebak:

export async function topicHash(accessKey: string): Promise<string> {
  const bytes = new TextEncoder().encode(accessKey)
  const digest = await crypto.subtle.digest('SHA-256', bytes)
  return Array.from(new Uint8Array(digest))
    .map((b) => b.toString(16).padStart(2, '0'))
    .join('')
    .slice(0, 8)
}

Perhitungan itu ada dalam empat salinan — antarmuka, worker gambar, worker audio, dan worker palsu untuk pengujian — dan keempatnya wajib menghasilkan delapan karakter yang persis sama. Kalau satu melenceng, antarmuka dan worker akan mendengarkan topic berbeda, dan masing-masing duduk diam menunggu yang lain.

Hash itu ada karena broker-nya publik. Nama yang tak tertebak adalah satu-satunya isolasi yang tersedia. Begitu broker mengautentikasi tiap klien dan ACL menentukan siapa boleh menyentuh topic mana, isolasi datang dari identitas, dan hash tak lagi melindungi apa pun. Jadi ia dibuang, dan prefix-nya jadi nilai tetap:

PREFIX = MQTT_TOPIC_ROOT   # prefix tetap, mis. "app/studio"

Uji kontrak kini membaca seluruh sumber secara langsung dan gagal bila ada yang tak sepakat, jadi prefix tetap itu tak bisa melenceng seperti hash dulu.

C. Penolakan yang tampak seperti sepi

Ini menjawab hambatan ketiga, dan membuang hash ternyata menutup dua kegagalan senyap sekaligus.

Yang pertama: prefix berhash yang lama takkan pernah cocok dengan ACL di broker baru, yang mengizinkan satu prefix tetap dan tak lebih. Klien yang memakai prefix lama akan tersambung dengan sukses — lalu tiap langganannya ditolak. MQTT melaporkan penolakan itu di dalam konfirmasi langganan, sebagai kode 128, dan klien yang tak melihat kode itu cuma melihat sambungan yang jalan tapi tak menerima pesan. Jadi antarmuka kini memeriksa tiap konfirmasi:

c.subscribe(f, o, (err, granted) => {
  if (err) return reject(err)
  // SUBACK 128 = ditolak ACL; sambungannya sendiri "berhasil"
  const bad = (granted ?? []).find((g) => g.qos >= 128)
  if (bad) return reject(new Error(...))
  resolve()
})

Yang kedua ada di hash-nya sendiri. crypto.subtle cuma ada di secure context — halaman yang disajikan lewat HTTPS atau dari localhost. Buka antarmuka lewat HTTP polos dan ia melempar, prefix-nya tak pernah terhitung, dan user terjebak di layar kredensial tanpa satu pun error. Menghapus fungsinya ikut menghapus jebakannya.

D. Worker yang sadar ia ditolak

Ini menjawab hambatan keempat. Di broker publik, callback sambungan worker tak pernah memeriksa apakah ia diterima, sebab tak ada yang pernah ditolak. Di broker berpassword, password yang salah menghasilkan penolakan, dan worker yang mengabaikannya jalan terus — mencetak log seperti biasa, membuat apa pun yang takkan dilihat siapa pun, berjam-jam sampai ada yang bertanya kenapa antreannya tak bergerak.

def _on_connect(client, userdata, flags, reason_code, properties=None):
    if reason_code != 0:
        # ditolak: katakan sekarang, di baris-baris pertama log
        print(...)

Kredensialnya sendiri diambil dari penyimpanan secret milik Colab, dengan variabel environment sebagai cadangan supaya notebook tetap bisa disimulasikan di laptop:

try:
    from google.colab import userdata
    user = userdata.get("MQTT_USERNAME")
    pw = userdata.get("MQTT_PASSWORD")
except Exception:
    pass
user = user or os.environ.get("MQTT_USERNAME")
pw = pw or os.environ.get("MQTT_PASSWORD")

Yang dicegahnya lebih berarti ketimbang yang dikerjakannya. Notebook-nya di-commit ke repository git, jadi password yang ditulis di dalamnya akan menetap di riwayat selamanya, bahkan sesudah dihapus dari file-nya. Ada juga aturan urutan: library MQTT mengirim kredensial di dalam paket paling pertama sambungan, jadi ia wajib disetel sebelum tersambung. Menyetelnya sesudahnya tak mengubah apa pun dan tak menghasilkan error.

E. Token di tempat password

Ini menjawab hambatan kelima. Browser login lewat OAuth2 dengan PKCE — alur yang dirancang untuk aplikasi yang tak bisa menyimpan rahasia, sebab apa pun yang dikirim ke browser bisa dibaca. Ia menerima JWT berumur pendek, token bertanda tangan yang menyatakan siapa user-nya. Broker perlu melihat token itu. Tempat bakunya adalah header Authorization pada sambungan, dan halaman web tak bisa menambah header pada handshake WebSocket.

Jadi token itu berjalan sebagai password MQTT, yang bisa disetel browser:

clientId: `slideshow-ui-${Math.random().toString(16).slice(2, 10)}`,
username: auth?.username,
password: token,
reconnectPeriod: 0,

Dua rincian setelan itu adalah aturan yang dipaksakan broker, ditemukan lewat pengujian ketimbang lewat membaca. Username MQTT wajib persis sama dengan klaim preferred_username di dalam token; selain itu ditolak dengan reason code 134. Dan client ID wajib baru pada tiap sambungan, sebab sambungan kedua dengan ID yang sama menendang yang pertama — dan itu berarti di seksi berikutnya.

Alur login-nya sendiri membawa dua pemeriksaan yang gampang terlewat, justru karena meninggalkannya tetap jalan:

if (q.get('state') !== flow.state) throw new Error(...)

const c = decodeClaims(tok.id_token) as Claims & { nonce?: string }
if (c.nonce && c.nonce !== flow.nonce) throw new Error(...)

Tanpa pemeriksaan state, penyerang bisa memancing korban menuntaskan login memakai authorization code milik penyerang, sehingga korban akhirnya masuk sebagai akun penyerang. nonce mengikat identity token yang kembali ke upaya login yang ini. Token-tokennya disimpan di session storage, bukan local storage, sehingga lenyap begitu tab ditutup, dan implementasi PKCE-nya diuji terhadap test vector resmi dari spesifikasinya, bukan terhadap nilai buatan saya sendiri.

F. Memperbarui sambungan tanpa celah

Ini menjawab hambatan keenam. Token hidup 300 detik, dan broker memutus klien ketika tokennya kedaluwarsa. Karena itu antarmuka harus mengganti sambungannya tiap beberapa menit, tanpa henti, tanpa melewatkan pesan.

Cara yang paling jelas adalah membiarkan library MQTT tersambung ulang secara otomatis. Itulah sebabnya reconnectPeriod bernilai nol di setelan di atas: reconnect otomatis milik library akan tersambung ulang memakai token yang sudah dipegangnya — yang sudah kedaluwarsa — lalu ditolak lagi, selamanya.

Sebagai gantinya, pembaruannya make-before-break. Di 80% umur token, sambungan kedua dibuka, dan yang pertama baru ditutup setelah yang kedua benar-benar siap:

const tok = await auth.refresh()
const next = makeClient(tok.access_token)
attach(next)
await onceConnected(next)
await subscribeAll(next)
const old = client
client = next
old.end(true)   // baru sekarang, setelah yang baru benar-benar siap

"Benar-benar siap" berarti sudah berlangganan, bukan sekadar tersambung. Sambungan yang sudah ada tapi belum tuntas berlangganan tak menerima apa pun, jadi menutup yang lama pada saat itu akan membuang apa pun yang tiba di selanya. Dan kalau pembaruan gagal — penyedia login sedang tak tersedia sesaat, misalnya — sambungan lama dipertahankan, tetap melayani sampai tokennya sendiri benar-benar habis, dan pembaruan dicoba lagi beberapa detik kemudian.

G. Langganan yang menyembunyikan denyut worker

Ini menjawab hambatan ketujuh. Selama pembaruan, dua sambungan sempat terbuka bersamaan, dan keduanya berlangganan topic yang sama — jadi tiap pesan akan tiba dua kali. Langganan bersama MQTT, ditulis dengan awalan $share/group/, menyelesaikannya: broker mengantar tiap pesan cuma ke satu anggota kelompok.

Pengujian terhadap broker ini memperlihatkan efek samping yang tak diperingatkan dokumentasinya. Langganan bersama tidak menerima pesan retained. Padahal pesan retained persis cara antarmuka tahu, saat dibuka, apakah worker masih hidup — lewat status worker dan Last Will-nya. Jadi antarmuka memegang dua langganan:

return [
  [`$share/${GROUP}/${prefix}/#`, { qos: 1 }],
  [`${prefix}/worker/status/#`, { qos: 1 }],
]

Satu langganan bersama untuk semuanya, dan satu langganan biasa khusus untuk status worker. Pesan status kini bisa tiba dua kali selama pembaruan, dan itu tak berbahaya: tiap pesan membawa timestamp-nya sendiri, dan antarmuka menilai kesegarannya dari situ, bukan dari berapa salinan yang diterimanya.

H. Port yang menggantung

Ini menjawab hambatan kedelapan. Begitu broker bisa dijangkau dari internet, port MQTT polos ditutup dan port TLS jadi satu-satunya pintu masuk. Browser tak terdampak — WebSocket-nya memang sudah lewat HTTPS. Worker terdampak.

Klien yang berbicara MQTT polos ke port TLS tidak ditolak. Server menunggu handshake TLS yang tak pernah datang, dan klien menunggu balasan yang tak pernah tiba, sampai timeout. Dari luar itu tampak seperti persoalan kredensial, jadi waktunya habis untuk memeriksa password. Di Colab itu berarti satu cell duduk diam bermenit-menit. Diagnostik worker kini membedakan keduanya: penolakan dengan reason code 134 atau 135 berarti kredensial, dan menggantung tanpa balasan sama sekali berarti enkripsi.

c.tls_set(cert_reqs=ssl.CERT_REQUIRED)   # sebelum connect()
c.username_pw_set(_user, _pw)            # sebelum connect()
c.connect(MQTT_HOST, MQTT_PORT, ...)

Urutan itu bukan soal gaya. Library memakai setelan TLS saat membangun socket, jadi memanggil tls_set sesudah connect tak berpengaruh — sambungannya jalan terus, tanpa enkripsi, tanpa satu keluhan pun. Dari seluruh kekeliruan yang sengaja dicoba untuk memastikan uji-ujinya menangkapnya, yang satu itu paling halus.

Dua hal sengaja ditinggalkan. Tak ada opsi mematikan verifikasi sertifikat, sebab sakelar darurat semacam itu cenderung tetap menyala lalu diam-diam jadi default — dan yang akan dibukanya di sini adalah password yang melintasi internet. Dan script uji broker kehilangan satu baris yang dulu mematikan verifikasi, ketika broker masih memakai sertifikat lokal yang tak tepercaya. Membiarkannya berarti uji itu tetap lulus walau rantai sertifikatnya rusak, menyembunyikan persis kegagalan yang hendak ditangkap uji itu.

Hasil dan Pembahasan

A. Apa yang dijumlahkan kedelapan keputusan itu

Worker dan antarmuka sudah berjalan lewat broker pribadi itu berminggu-minggu sejak perpindahan: browser login dan memperbarui sambungannya tiap beberapa menit tanpa kehilangan pesan, dan worker Colab tersambung lewat TLS dengan kredensial yang tak pernah muncul di repository.

B. Pengaman milik environment-nya

Sebagian besar pekerjaan ini bukan menambah keamanan. Melainkan memeriksa ulang pengaman yang benar untuk environment lama dan mencari tahu jadi apa masing-masing di environment baru.

Sebagian jadi tak berguna. Nama topic berhash adalah pertahanan yang tepat di broker tempat siapa saja bisa menguping, dan di broker beridentitas ia cuma menambah empat salinan perhitungan yang bisa saling menjauh. Sebagian jadi berbahaya. Reconnect otomatis adalah default yang masuk akal sampai token kedaluwarsa, lalu ia berubah jadi lingkaran sambungan yang ditolak. Flag yang melewati pemeriksaan sertifikat adalah kemudahan yang wajar untuk broker uji lokal, dan jadi lubang begitu broker-nya di internet.

Dan sebagian perlindungan memang belum pernah ada, sebab environment lama tak pernah melahirkan kegagalan yang dijaganya. Tak ada yang menolak worker di broker publik, jadi ia tak pernah belajar mendengarkan penolakan. Tak ada yang memeriksa langganan, sebab tak ada yang menampiknya. Tak ada yang harus membedakan TLS yang menggantung dari password yang salah, sebab TLS-nya belum ada.

Versi umumnya pantas dinyatakan. Ketika environment di bawah satu sistem berubah, pengamannya tak bisa dibawa menyeberang tanpa diperiksa. Tiap pengaman adalah jawaban atas pertanyaan yang diajukan environment lama. Pekerjaannya adalah menanyakan pertanyaan apa yang diajukan environment baru — dan mengandaikan bahwa beberapa kegagalan barunya akan senyap, sebab environment lama tak pernah membutuhkan mereka bersuara.

C. Yang tidak dicakup

Ini sistem satu orang. Aturan aksesnya memisahkan antarmuka dari worker, bukan satu anggota tim dari anggota lain, dan susunan banyak user akan butuh identitas dan aturan per orang. Umur token 300 detik adalah setelan penyedia login; titik pembaruan 80% mengikutinya, dan umur yang berbeda akan mengubah waktunya tapi tidak rancangannya.

Kedua kliennya juga tidak diperlakukan sama. Kredensial browser kedaluwarsa tiap lima menit dan memperbarui dirinya sendiri; password worker berlaku sampai ada yang menggantinya, dan menggantinya adalah langkah manual di penyimpanan secret Colab. Ketimpangan itu bisa diterima untuk worker yang cuma dinyalakan satu orang, tapi itulah yang pertama kali perlu ditinjau ulang bila kelak ada lebih banyak worker, atau lebih banyak orang, yang tersambung.

Simpulan

GPU 4 GB menaruh pekerjaan berat di runtime Colab, broker publik menyambungkannya ke laptop, dan broker itu bekerja. Memberinya identitas — autentikasi, kendali akses, enkripsi — mengganti broker-nya dalam satu sore. Memindahkan kedua kliennya menghabiskan sisanya: membuang hash yang tak lagi melindungi apa pun, menyadari penolakan yang datang tanpa suara, menaruh token di tempat yang tersisa ketika browser tak punya header, memperbarui sambungan sebelum kedaluwarsa, berlangganan dua kali karena satu jenis langganan menyembunyikan pesan yang paling penting, dan membedakan menggantung dari penolakan.

Mengerjakannya dalam empat tahap terpisah, dengan broker dibuktikan sendirian lebih dulu, itulah yang menjaga tiap kejutan tetap kecil. Sebagian besar kejutan itu adalah pengaman yang benar untuk environment lama dan keliru untuk yang baru.

Yang terbawa ke mana-mana adalah satu kebiasaan untuk migrasi apa pun: daftar tiap pengaman yang diandalkan susunan lama, lalu untuk masing-masing tanyakan apa yang dilindunginya sekarang — dan kegagalan baru apa yang bisa dilahirkan susunan baru yang tak pernah bisa dilahirkan susunan lama.

Istilah

WebSocket

Sambungan dua arah berumur panjang yang dibuka halaman web ke server. Inilah satu-satunya cara browser berbicara dengan message broker, dan ia membatasi apa yang bisa dilampirkan halaman saat menyambung.

ACL

Access-control list. Sekumpulan aturan di broker yang menentukan identitas mana boleh mem-publish atau berlangganan ke topic mana.

SUBACK

Konfirmasi broker atas permintaan berlangganan. Ia membawa satu kode per topic; kode 128 ke atas berarti langganannya ditolak.

JWT

JSON Web Token. Token bertanda tangan berumur pendek yang menyatakan siapa pemegangnya, dan bisa diverifikasi server tanpa menghubungi penerbitnya.

PKCE

Proof Key for Code Exchange. Ekstensi OAuth2 yang membuat aplikasi yang tak bisa menyimpan rahasia, seperti halaman web, bisa menuntaskan login dengan aman.

make-before-break

Mengganti sambungan dengan membuka dan menyiapkan penuh yang baru sebelum menutup yang lama, sehingga tak pernah ada saat tanpa keduanya.

secure context

Halaman web yang disajikan lewat HTTPS atau dari localhost. Beberapa fitur browser, termasuk API kriptografi yang dipakai untuk hash, cuma ada di sana.