Jangan jadikan tautan email magic/tragic sebagai satu-satunya opsi login

• Magic link, yang mengirim tautan login lewat email, dapat mengurangi risiko phishing kata sandi dan kebocoran kata sandi yang digunakan ulang, tetapi jika menjadi satu-satunya opsi, friksi login dialihkan ke pengguna
• Pengguna yang memakai beberapa komputer atau memisahkan perangkat kerja dan pribadi bisa dengan mudah mengalami alur yang terputus karena perangkat yang menerima email berbeda dari browser yang ingin dipakai untuk login
• Karena keterlambatan SMTP dan proses meneruskan tautan, login bisa tertunda dari 2 detik hingga beberapa menit, dan di browser dalam aplikasi serta aplikasi pembaca RSS, kegunaan di mobile juga bisa rusak
• Cara memasukkan langsung OTP yang diterima lewat email atau SMS juga merepotkan, tetapi ketika sulit memindahkan tautan antara klien email dan browser, cara ini bisa lebih baik daripada magic link
• Sekalipun memakai magic link sebagai default, layanan tetap perlu menyediakan alternatif yang kuat seperti passkeys bagi kelompok pengguna yang teknis dan mengutamakan privasi

---

Situasi ketika magic link menjadi merepotkan

• “Magic Links” dulu berarti PDA futuristis, tetapi sekarang istilah ini digunakan oleh perusahaan seperti Auth0 untuk merujuk pada tautan login yang disertakan dalam email
• 404 Media membela magic link dalam “We Don’t Want Your Password”, dengan pandangan bahwa tautan email lebih sulit di-phishing daripada kata sandi, tidak menyebabkan kebocoran kata sandi, dan mengurangi risiko penggunaan ulang kata sandi yang sudah bocor
• Dalam kehidupan yang berpusat pada satu laptop dan perangkat mobile, ini tampak mudah, tetapi bagi pengguna yang memakai banyak perangkat dan browser, kompleksitas itu berpindah begitu saja kepada mereka
• Contoh ketidaknyamanan:
  • Beberapa perangkat: pengguna yang tidak menaruh email pribadi di PC gaming atau laptop kerja sulit membuka tautan login secara langsung
  • Kecepatan: karena keterlambatan SMTP dan proses memindahkan tautan ke browser yang tepat, login bisa melambat dari 2 detik hingga beberapa menit
  • Mobile: penggunaan browser dalam aplikasi bisa rusak, sehingga menangani tautan lokal di aplikasi pembaca RSS menjadi tidak nyaman
  • Keamanan: alur yang mendorong pengguna membuka email pribadi di perangkat kerja, atau sebaliknya, bukanlah keuntungan dari sisi keamanan

Alternatif dan perbaikan minimal

• Metode passwordless dengan memasukkan langsung OTP yang diterima lewat email atau SMS juga merepotkan, tetapi bisa lebih praktis dalam situasi ketika tautan tidak mudah dipindahkan dari klien email ke browser yang akan dipakai untuk login
• Stratechery melalui Passport menyediakan klik tautan atau input OTP, dan meski masih punya keterbatasan karena meneruskan ketidaknyamanan kepada pengguna tanpa implementasi passkeys, pendekatan ini lebih mempertimbangkan situasi pengguna dibanding magic link saja
• Sekalipun tetap bersikeras menjadikan tautan magic/tragic sebagai default, lebih baik turut menyediakan alternatif yang kuat seperti passkeys
• Tulisan referensi Ricky Mondello, Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over, membahas cara passkeys dapat meredakan masalah ini

[GN⁺]

Komentar Hacker News

• Masalah yang dialami saat membuat aplikasi dengan magic link: karena pengguna mungkin perlu login dari perangkat yang sulit mengakses email, kode login alternatif harus disertakan bersama magic link
  Selain itu, perlu menangani kasus ketika klien email otomatis membuka tautan untuk membuat screenshot pratinjau, dan mempertimbangkan klien email yang membuka tautan di browser dalam aplikasi alih-alih browser pilihan pengguna
  Misalnya, meskipun pengguna iOS lebih suka Firefox mobile, aplikasi email bisa memaksa tautan terbuka di browser dalam aplikasi berbasis Safari

  • Cukup repot menyesuaikan implementasi magic link agar bisa bekerja dengan software anti-phishing, pemeriksa tautan perusahaan, dan sebagainya; sebagian prosesnya dirangkum di https://github.com/FusionAuth/fusionauth-issues/issues/629
    Menurut saya, pendekatan yang mengarah ke halaman input kode sekali pakai bisa menghindari banyak masalah seperti ini
  • Sekarang juga perlu mempertimbangkan bahwa alat perlindungan ancaman email seperti Microsoft Defender in Exchange Online mengklik tautan di dalam email untuk tujuan pemeriksaan
    Baru-baru ini saya mengalami masalah akun email baru otomatis terverifikasi, dan ketika pengguna mengkliknya, magic link sudah tidak valid, karena Microsoft lebih dulu login lewat tautan itu saat pemeriksaan
  • Di mobile, perlu juga memastikan tautan login terhubung dengan benar ke aplikasi mobile
    Setelah McDonald's beralih dari email/kata sandi ke magic link, membuat tautan bekerja di aplikasi McD benar-benar sulit, dan biasanya hanya membuka situs web McD
    Karena sekitar 98% saat saya makan McD, kalau tidak bisa memesan lewat aplikasi maka saya tidak jadi makan, ini cukup menyebalkan, dan akhirnya saya beralih ke “Sign in With Apple”(SIWA)
    Saya tidak menemukan cara menambahkan SIWA ke akun McD yang lama, jadi saya harus memakai SIWA yang menyembunyikan email asli saya dari McD, dan akun baru pun dibuat sehingga poin reward akun lama hilang, tetapi setidaknya saya bisa memakai aplikasi McD lagi
    Di aplikasi ada promo “Free Medium Fries on Friday” untuk pesanan minimal 1 dolar setiap Jumat, jadi setiap makan siang Jumat saya biasanya membuat sandwich di rumah lalu mengambil cookie dan kentang goreng gratis dari McD sebagai pelengkap
  • Hal yang belakangan menyebalkan di Slack adalah saya ingin chat kantor ada di ponsel, tetapi tidak ingin email kantor ada di ponsel, karena hak kontrol atas ponsel terlalu luas
    Jadi saya menerima magic link di komputer kantor lalu membuat kode QR, tetapi sistem karantina email telah mengganti seluruh tautannya sehingga saya harus mengekstrak tautan asli
    Tidak berhenti di situ, URL redirect kembali ke Slack rusak karena URL encoding, jadi saya harus memperbaikinya sendiri lalu membuat kode QR
    Padahal cukup sertakan kode QR atau kode di email magic link aslinya
  • Salah satu keunggulan terbesar magic link adalah, tidak seperti passkey, ia mudah digunakan sekaligus mustahil di-phishing
    Begitu Anda memasukkan kode, keunggulan itu benar-benar hilang, dan penyerang tinggal membuat situs web palsu yang meminta kode
    Magic link harus membuat perangkat tempat tautan diklik menjadi login, bukan perangkat yang meminta sesi login
    Cara lain mungkin sedikit lebih tidak merepotkan, tetapi itu masalah keamanan dan harus diperlakukan demikian

• Saya sudah memakai magic link selama beberapa tahun, juga karena di tahap MVP ingin menghindari beban keamanan berupa penyimpanan kata sandi pengguna. Masalah terbesarnya adalah sebagian pengguna, sekitar 0,1%, sama sekali tidak bisa menerima email
  Saya sudah mencoba IP sendiri, MailGun, PostMark, bahkan retry berurutan lewat beberapa alat email transaksional, tetapi tetap ada orang yang benar-benar tidak bisa login
  Selain itu, orang mengklik magic link dari 6 bulan lalu lalu frustrasi karena “tidak berfungsi”, jadi alih-alih pesan error, kami memutuskan menampilkan halaman seperti Docusign yang menjelaskan situasinya dan mengirim ulang tautan
  Orang juga sering salah memasukkan alamat email, lalu ketika tidak menerima kode mereka menyalahkan sistem
  Meski begitu, saya merasa tiket dukungan jauh lebih sedikit dibanding metode email+kata sandi, jadi saya masih lebih suka magic link

  • Menarik bahwa cukup banyak orang salah menulis alamat email, atau kotak masuknya terlalu penuh sehingga tidak bisa menerima email lagi
    Saya belum pernah memakai magic link, tetapi beberapa bulan lalu menambahkan Google Sign in ke SaaS, dan itu langsung mencakup lebih dari 90% pendaftaran baru
    Padahal basis penggunanya developer, yang cenderung punya pemahaman teknis dan sensitivitas privasi tinggi; saya tidak berpikir metode lain kini menjadi prioritas. Tentu saja email/kata sandi tetap kami pertahankan
  • Magic link bisa berguna, tetapi masalahnya adalah hanya mendukung magic link bagi sebagian pengguna
  • Lucunya, sebagian besar masalah seperti ini juga persis berlaku pada kata sandi. Orang memakai kata sandi lama lalu mengeluh tidak bisa, atau salah memasukkan sesuatu lalu menyalahkan sistem, atau meminta email reset kata sandi tetapi tidak menerima emailnya. Jadi yang terlihat hanya kelebihannya
  • Namun dari sisi kegunaan, ini mimpi buruk
  • Email tidak boleh dianggap sebagai kanal yang aman
    Username+kata sandi yang digunakan bersama password manager, atau passkey, kemungkinan merupakan hampir satu-satunya cara untuk menukar kredensial secara end-to-end encrypted di atas HTTPS sambil memberikan pengalaman pengguna yang baik bagi masyarakat umum
    Password manager memastikan kredensial hanya digunakan pada domain yang benar

• Saya adalah pelanggan setia Mercury, tetapi bahkan setelah melewati kata sandi yang aman, pengelola kata sandi, dan TOTP yang valid, setiap kali alamat IP berubah mereka memaksa magic link sebagai faktor autentikasi ketiga, sampai-sampai membuat saya mempertimbangkan memindahkan rekening bank perusahaan ke tempat lain
  Kalau login dari lokasi atau ISP yang bukan yang saya pakai selama lima tahun terakhir, saya bisa mengerti. Namun kalau satu-satunya yang berubah dibanding login kemarin hanyalah oktet terakhir alamat DHCP, itu tidak masuk akal
  Karena saya membaca email melalui SSH di komputer yang berbeda dari komputer untuk browsing web, menyalin dan menempelkan tautan login sepanjang ratusan karakter benar-benar menyiksa
  Di Emacs, tautan itu ditampilkan melintasi beberapa baris, sehingga saya juga harus menghapus sendiri \ di batas baris
  Menambahkan friksi setiap kali login merusak kesan terhadap semua interaksi berikutnya di aplikasi, dan membuat saya enggan menggunakannya

  • Saya CTO Mercury
    Jika itu perangkat yang pernah digunakan sebelumnya, seharusnya permintaan verifikasi perangkat tidak muncul. Untuk memastikannya kami menyimpan cookie permanen, dan kami juga tidak memintanya pada IP yang sama. Saya penasaran apakah cookie Anda mungkin dihapus secara berkala
    Fitur ini kami tambahkan setelah penyerang membuat situs tiruan http://mercury.com dan bahkan menjalankan iklan Google
    Jika pelanggan memasukkan kata sandi dan TOTP di situs phishing, phisher akan login dengan kredensial itu, membuat kartu virtual, lalu membeli kripto, emas, dan sebagainya. Pengguna kemudian dialihkan ke Mercury yang asli, dengan harapan mereka menganggapnya sebagai error sementara
    Tautan verifikasi perangkat yang kami kirim menyetujui IP/perangkat yang membuka tautan tersebut, dan dengan cara ini kami hampir sepenuhnya menghentikan phisher
    WebAuthn kebal terhadap serangan phishing seperti ini, jadi jika Anda memakai WebAuthn kami tidak meminta verifikasi perangkat
    Jika memungkinkan, kami sangat merekomendasikan TouchID/FaceID atau WebAuthn per perangkat. Lebih nyaman dan lebih aman, dan bisa ditambahkan di sini: https://app.mercury.com/settings/security
    Namun secara internal kami sedang mendiskusikan tulisan ini, dan kami juga menyadari bahwa seiring makin luasnya IPv6, IP akan jauh lebih sering berubah. Kami akan mempertimbangkan apakah pembatasan pencocokan IP yang sama perlu dilonggarkan

• Menurut saya ini tanggapan yang sangat bagus terhadap tulisan 404 minggu lalu. Saya suka 404, tetapi karena alasan yang sama seperti yang disebut penulis, magic link memang menyebalkan
  Tulisan Ricky Mondello minggu lalu[1] layak dibaca karena menjelaskan dengan baik bahwa passkey bisa digunakan bersama magic link, seperti yang diisyaratkan di akhir tulisan
  [1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/

  • Saya belum pernah mengalami masalah khusus ini dengan magic link, tetapi ini mengingatkan saya pada saat Epic meluncurkan Epic Games Store dan mengirim kode 2FA email untuk login
    Saat mencoba login ke store, saya diminta memasukkan kode 2FA yang dikirim lewat email. Emailnya tidak datang selama beberapa menit, lalu saat meminta kode baru juga tidak datang, dan ketika saya menyerah lalu melakukan hal lain, 30 menit kemudian kedua kode itu tiba sekaligus
    Sebenarnya email sulit diandalkan bahkan dalam kondisi terbaik sekalipun. Bisa masuk folder spam, diblokir filter spam perusahaan, atau inbox bisa penuh
    Secara pribadi, email saya hanya ada di iPhone, dan di laptop kerja atau PC gaming saya harus login ke icloud.com untuk memeriksanya, yang merepotkan
    Saya berharap mereka membiarkan saya memasukkan kata sandi, atau memindai kode QR seperti pada perangkat embedded, atau setidaknya memberi satu opsi lain
  • Tulisan ini lebih baik daripada tulisan aslinya. Saat membaca yang asli, cukup membingungkan bahwa passkey diposisikan sebagai alternatif magic link; jauh lebih masuk akal melihatnya sebagai pelengkap
    Magic link memberi akses ke passkey, dan passkey pada dasarnya adalah versi yang diperkuat dari “ingat komputer ini”
  • Saya belum melihat tautan itu, dan kalau saya tahu Ricky Mondello sudah menulis tulisan itu, mungkin saya tidak akan repot menulis yang ini
    Saya masih terbiasa dengan masa ketika orang-orang Apple hampir tidak pernah terlihat di publik

• Entah apakah saya salah paham, tapi passkey sepertinya sebenarnya bukan alternatif untuk magic link
  Semua implementasi passkey yang pernah saya lihat sejauh ini menyarankan pengguna membuat passkey setelah sudah login dengan cara lain
  Saya belum menggali terlalu dalam, tetapi dari sisi pengalaman pengguna, passkey lebih terlihat seperti alternatif tombol “ingat komputer ini” daripada alternatif untuk kata sandi secara umum
  Dengan cara apa pun, layanan harus mengetahui bahwa perangkat baru ini telah disetujui
  Tergantung penyedianya, memang ada sinkronisasi passkey, tetapi itu tidak menyelesaikan bagaimana autentikasi awal dilakukan
  Inti wawasan magic link adalah bahwa sistem keamanan tidak bisa lebih kuat daripada mekanisme pemulihannya
  Dunia tempat passkey diperlakukan sebagai satu-satunya sarana autentikasi tidak akan datang; mekanisme pemulihan akan selalu tersisa, dan sebagian besar akan berupa pemulihan otomatis lewat email
  Kalau begitu, magic link itu jujur karena menyederhanakan tanpa berpura-pura ada lapisan yang lebih aman di atasnya
  Jika mekanisme pemulihan dijadikan sarana interaksi utama dalam alur autentikasi, berarti kita lebih jujur tentang tingkat keamanan nyata dari sistem autentikasi tersebut
  Edit: filmgirlcw meninggalkan tautan ke tulisan yang lebih baik yang menjelaskan bagaimana kedua pendekatan ini sebenarnya saling melengkapi: https://news.ycombinator.com/item?id=42628226

  • Seperti yang ditulis Ricky dalam tulisannya minggu lalu[1], menurut saya passkey seharusnya memperkuat magic link atau sarana autentikasi lain
    Magic link memang punya kelebihan, tetapi saya tidak yakin membuat email menjadi vektor serangan yang lebih kuat adalah sebuah kelebihan
    Bagi orang yang memakai password manager, magic link jelas menjadi titik friksi, dan passkey jelas bisa menguranginya
    Masalah pengalaman pengguna pada passkey juga masih bisa diperbaiki, dan jika ekspor sudah dimungkinkan, sinkronisasi antarsistem akan jauh lebih baik
    Salah satu alasan saya memakai 1Password sebagai sistem kata sandi dan passkey utama juga karena penggunaan passkey lintas perangkat; perusahaan saya juga memakai 1Password, jadi saya bisa login ke akun pribadi dan akun perusahaan lalu melakukan autentikasi dari perangkat pribadi atau kerja bila perlu
    Namun jika masalah yang didefinisikan 404 adalah tidak ingin memikul tanggung jawab menyimpan kata sandi atau kontrol autentikasi, menurut saya bagi sebagian pengguna passkey lebih baik daripada magic link
    Meski begitu, seperti Ricky, saya pikir ini bukan salah satu dari keduanya, melainkan harus keduanya
    [1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
  • Passkey saat ini sedang berada dalam masa transisi
    Menggunakan passkey tidak berarti harus selalu ada metode login pengganti, tetapi belum ada layanan yang benar-benar beralih ke passkey saja
    Pengguna OS lama atau Linux mungkin belum bisa membuat dan menyimpan passkey, dan banyak pengguna tidak memakai pengelola kredensial lintas platform
    Misalnya, jika Anda membuat passkey dengan iCloud Passwords, saat ini tidak ada cara untuk login dari Linux
    Beberapa tahun lagi, saya rasa kita akan mulai melihat alur ketika layanan meminta pengguna membuat passkey sejak awal dan sama sekali tidak mengumpulkan kata sandi
    Saya berharap spesifikasi portabilitas passkey diimplementasikan, dan Gnome/KDE juga mengimplementasikan dukungan passkey
  • Pikiran pertama saya setelah membaca tulisan ini adalah, setelah mengkritik masalah spesifik pada tautan atau kode OTP, bagaimana mungkin ia bisa mengusulkan passkey. Passkey juga punya masalah yang hampir sama, bahkan 10 kali lipat
    Jika memakai OTP dari ponsel atau menyalin tautan dari ponsel saat mengunjungi situs web di PC kantor saja menyakitkan, saya bertanya-tanya seberapa jauh lebih mudah dan lebih baik membuat komputer kantor terhubung dengan passkey pribadi di tempat seperti laptop

• Saya tidak memakai layanan yang hanya mendukung magic link untuk autentikasi. Itu sangat tidak ramah pengguna, dan dari sudut pandang keamanan jelas lebih buruk daripada kata sandi yang dipakai bersama password manager
  Yang paling fatal adalah, dalam pengaturan pribadi saya, itu sama sekali tidak berfungsi
  Demi keamanan dan keselamatan akun, saya tidak mengakses akun email dari perangkat yang saya pakai untuk login
  Hanya Anthropic yang saya jadikan pengecualian karena Claude adalah LLM terbaik, tetapi setiap kali harus login lagi rasanya sangat menyiksa dan saya sudah berkali-kali mengirim keluhan

  • Apakah dari sudut pandang keamanan itu benar-benar lebih buruk daripada kata sandi? Sebagian besar layanan yang sering dipakai, mungkin semuanya, menyediakan pemulihan email saat pengguna lupa kata sandi
  • Sayang sekali tidak cukup banyak orang memakai password manager, sehingga nilainya tidak cukup besar bagi perusahaan untuk menargetkan alur itu

• Setiap kali melihat magic link, saya selalu berpikir, “Bukankah sejak awal kita tidak seharusnya mengklik tautan email?”
  Ketika memikirkan tautan email, phishing juga ikut terpikir
  Saya benar-benar tidak suka magic link

  • Apakah ada orang yang bingung soal itu? Tautan reset kata sandi sudah sejak dulu dikirim lewat email
    Intinya adalah jangan mengklik tautan yang mencurigakan. Jika Anda tahu magic link telah dikirim, maka tautan itu tidak mencurigakan
    Namun saya tetap tidak suka magic link karena keterlambatannya
  • Saya juga tidak memuat gambar. Alamat email bisa berujung pada alamat IP
    Cara perlindungan privasi email Apple tampak menarik. Apple selalu memuat semua gambar, tetapi saya tidak tahu apakah ada kekurangannya

• Implementasi terbaik yang pernah saya lihat adalah yang mengharuskan pengguna mengeklik tautan di perangkat yang menerima email, tetapi tidak memindahkan sesi ke perangkat itu; login diselesaikan di perangkat tempat proses login awalnya dimulai

  • Ini buruk karena phishing
    Solusi yang lebih baik adalah membuat login hanya terjadi di perangkat yang membuka tautan, dan untuk penggunaan lintas perangkat, juga menyediakan kode OTP yang bisa dibaca di perangkat penerima lalu mudah dimasukkan ke perangkat asal
    Atau bisa juga hanya menyediakan kode OTP tanpa tautan
  • Setuju. Kalau semuanya bekerja seperti ini, rasanya akan memuaskan
    Tidak ada yang lebih buruk daripada sedang bekerja di satu browser, lalu ketika membuka email, autentikasi terjadi di browser default, atau lebih parah lagi di perangkat lain, sehingga harus meneruskan tautan ke sana lalu membukanya lagi
    Ada juga kasus ketika seseorang tidak ingin mengakses email tertentu di perangkat tertentu, jadi ini bukan skenario yang aneh
    Cara situs mengirim OTP seperti crazy-pink-horse-3837 agar bisa disalin-tempel adalah titik tengah yang cukup baik jika implementasi tautan untuk mengautentikasi permintaan asli terlalu sulit
  • Kalau begitu, bukankah siapa saja bisa login ke akun saya hanya dengan menerima email lalu mengekliknya tanpa sengaja?
  • Sejauh yang saya tahu, aplikasi mobile McDonald’s memakai cara ini. Mereka tidak mengizinkan login dengan kata sandi
    Namun masalah implementasinya adalah magic link yang dikirim dibungkus dengan pelacak klik, dan domain itu diblokir oleh alat seperti pihole
    Akibatnya, saya tidak bisa mencapai URL autentikasi sebenarnya dan menyelesaikan proses login
  • Ini adalah cara yang tidak akan pernah diizinkan jika tim keamanan sedikit saja kompeten. Sama saja meminta pengguna agar terkena phishing

• Browser dalam aplikasi harus dihapuskan. Terutama browser dalam aplikasi yang tidak memberi opsi “buka di browser biasa”; kalau itu pembaca RSS, opsi tersebut semestinya wajib ada

  • Serius, ini harus diakhiri dengan hukuman paling berat yang diizinkan hukum
    Semua manajer produk yang memaksa pengguna memakai browser dalam aplikasi harus dipenjara
  • Apa itu pembaca RSS?

• Pilihan yang jauh lebih baik adalah passkey yang memakai kode OTP yang dikirim lewat email dan Conditional Mediation UI
  Jika pengguna login dari perangkat yang sudah memiliki passkey, CM UI bisa langsung memunculkan pilihan sehingga pengguna dapat login seketika
  Jika perangkat belum memiliki passkey, pengalaman pengguna bisa dirancang agar mereka memasukkan kode email, lalu setelah berhasil, langsung menyiapkan passkey supaya berikutnya bisa login langsung
  Dengan begitu, di perangkat yang sudah ada Anda mendapatkan keamanan passkey, sementara di perangkat baru Anda mendapatkan penyiapan tanpa kata sandi dan pemulihan akun
  Sebagai bonus, Anda juga bisa menghindari ketergantungan vendor, yaitu ketika penyedia cloud memiliki semua passkey

  • Sayangnya, cara meminta pengguna memasukkan kode email tidak mencegah serangan man-in-the-middle