- E-postayla giriş bağlantısı gönderen magic link yöntemi, parola kimlik avı ve yeniden kullanılan parolaların sızması riskini azaltabilir; ancak tek seçenek haline geldiğinde giriş sürtünmesi kullanıcıya yüklenir
- Birden fazla bilgisayar kullanan ya da iş ve kişisel cihazlarını ayıran kullanıcılar için, e-postanın geldiği cihaz ile giriş yapılmak istenen tarayıcı farklı olduğundan akış kolayca kopar
- SMTP gecikmesi ve bağlantının iletilme süreci nedeniyle giriş 2 saniyeden birkaç dakikaya kadar gecikebilir; uygulama içi tarayıcılarda ve RSS okuyucu uygulamalarında mobil kullanılabilirlik de bozulabilir
- E-posta veya SMS ile gelen OTP'yi doğrudan girme yöntemi de zahmetlidir; ancak bağlantıyı e-posta istemcisi ile tarayıcı arasında taşımak zor olduğunda magic link'ten daha iyi olabilir
- Magic link varsayılan olarak kullanılsa bile, teknik ve mahremiyete önem veren kullanıcı kitlesi için passkeys gibi sağlam alternatifler de birlikte sunulmalıdır
Magic link'lerin kullanışsız hale geldiği durumlar
- “Magic Links” geçmişte fütüristik PDA'ları ifade ediyordu, bugün ise Auth0 gibi şirketlerin e-postadaki giriş bağlantısı için kullandığı bir terim
- 404 Media, “We Don’t Want Your Password” yazısında magic link'leri savunuyor; e-posta bağlantılarının parolalara göre kimlik avına daha zor hedef olduğunu, parola sızıntısına yol açmadığını ve sızmış parolaların yeniden kullanımı riskini azalttığını söylüyor
- Tek bir dizüstü ve mobil cihaz merkezli bir yaşamda kolay görünse de, birden fazla cihaz ve tarayıcı kullanan kullanıcılar için karmaşıklık aynen kullanıcıya aktarılıyor
- Rahatsız edici örnekler:
- Birden fazla cihaz: Oyun PC'sinde veya iş dizüstünde kişisel e-postasını bulundurmayan kullanıcılar giriş bağlantısını hemen açmakta zorlanabilir
- Hız: SMTP gecikmesi ve bağlantıyı doğru tarayıcıya taşıma süreci nedeniyle 2 saniyeden birkaç dakikaya kadar yavaşlayabilir
- Mobil: Uygulama içi tarayıcı kullanımı bozulur ve RSS okuyucu uygulamalarında yerel bağlantıları ele almak zahmetli hale gelir
- Güvenlik: Kişisel e-postayı iş cihazında ya da tersini açmaya yönlendiren akışlar güvenlik açısından bir avantaj değildir
Alternatifler ve asgari iyileştirme
- E-posta veya SMS ile alınan OTP'yi doğrudan giren passwordless yöntem de zahmetlidir; ancak bağlantının e-posta istemcisinden giriş yapılacak tarayıcıya kolayca taşınamadığı durumlarda daha pratik olabilir
- Stratechery, Passport üzerinden bağlantıya tıklama veya OTP girme seçeneği sunuyor; passkeys uygulamadan zahmeti kullanıcıya yükleme sınırı sürse de, yalnızca magic link sunmaktan daha fazla kullanıcı durumunu dikkate alıyor
- Magic/tragic link'leri varsayılan olarak dayatmakta ısrar edilse bile, passkeys gibi sağlam alternatifleri birlikte sunmak daha iyi olur
- Ricky Mondello'nun Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over yazısı, bu sorunun passkeys ile nasıl hafifletilebileceğini ele alan bir referans metin
1 yorum
Hacker News yorumları
Magic link ile uygulama geliştirirken yaşanan sorunlar: Kullanıcıların e-postaya erişmenin zor olduğu bir cihazda oturum açması gerekebileceği için magic link’e alternatif bir oturum açma kodu eklemek gerekiyor.
Ayrıca e-posta istemcisinin önizleme ekran görüntüsü oluşturmak için bağlantıyı otomatik açtığı durumları ele almak ve bağlantıyı kullanıcının tercih ettiği tarayıcı yerine uygulama içi tarayıcıda açan e-posta istemcilerini de hesaba katmak gerekiyor.
Örneğin iOS kullanıcıları Firefox mobil kullanmayı tercih etse bile e-posta uygulaması bağlantıyı Safari tabanlı bir uygulama içi tarayıcıda zorla açabilir.
Tek kullanımlık kod giriş sayfasına yönlendiren bir yaklaşımın bu sorunların çoğundan kaçınabileceğini düşünüyorum.
Yakın zamanda yeni bir e-posta hesabının otomatik olarak doğrulandığı, kullanıcı tıkladığında ise magic link’in çoktan geçersiz hale geldiği bir sorun yaşadım; çünkü Microsoft denetim sırasında o bağlantıyla önce oturum açmıştı.
McDonald's e-posta/parola yönteminden magic link’e geçtikten sonra bağlantıyı McD uygulamasında çalıştırmak gerçekten zordu; genellikle yalnızca McD web sitesi açılıyordu.
McD yediğim zamanların yaklaşık %98’inde uygulamadan sipariş veremiyorsam yememeyi tercih ettiğim için bu epey sinir bozucuydu; sonunda “Sign in With Apple”(SIWA) yöntemine geçtim.
Mevcut McD hesabıma SIWA eklemenin bir yolunu bulamadığım için gerçek e-postamı McD’den gizleyen SIWA’yı kullanmak zorunda kaldım; yeni bir hesap oluştu ve eski hesabımdaki ödül puanlarını kaybettim ama en azından McD uygulamasını yeniden kullanabilir hale geldim.
Uygulamada her cuma 1 dolar ve üzeri siparişlerde “Free Medium Fries on Friday” kampanyası olduğu için, cuma öğlelerinde evde sandviç yapıp McD’den kurabiye ve ücretsiz patates kızartması alıp yanına eklerdim.
Bu yüzden şirket bilgisayarında magic link’i aldım ve bir QR kod oluşturdum; ancak e-posta karantina sistemi bağlantının tamamını değiştirdiği için orijinalini çıkarmam gerekti.
İş bununla da bitmedi; Slack’e geri dönen yönlendirme URL’si URL encoding yüzünden bozulmuştu, onu elle düzelttikten sonra QR kodu oluşturmam gerekti.
Oysa yapılması gereken tek şey, ilk magic link e-postasına QR kodu veya kod da eklemek.
Kod girmeye başladığınız anda bu avantaj tamamen ortadan kalkar; saldırganın tek yapması gereken kod isteyen sahte bir web sitesi hazırlamaktır.
Magic link, tıklanan cihazda oturum açtırmalıdır; oturum açma oturumunu isteyen cihazda oturum açtırmamalıdır.
Bunun dışındaki yaklaşımlar biraz daha az zahmetli olabilir ama bir güvenlik sorunudur ve öyle ele alınmalıdır.
Birkaç yıldır magic link kullanıyoruz; MVP aşamasında kullanıcı parolalarını saklama güvenlik yükünden kaçınma nedenimiz de vardı. En büyük sorun, kullanıcıların yaklaşık %0,1’lik bir kısmının e-postayı hiç alamaması.
Kendi IP’mizi, MailGun’ı, PostMark’ı, çeşitli transactional mail araçlarını sırayla yeniden deneme yöntemini bile denedik ama hâlâ kesinlikle oturum açamayan insanlar var.
Ayrıca insanlar 6 ay önceki magic link’e tıklayıp “çalışmıyor” diye sinirlendiği için, hata mesajı yerine Docusign gibi durumu açıklayan ve bağlantıyı yeniden gönderen bir sayfa göstermeye karar verdik.
İnsanlar e-posta adresini sık sık yanlış yazıp kodu alamayınca sistemi suçlayabiliyor.
Yine de e-posta+parola yöntemine kıyasla destek taleplerinin çok daha az olduğunu düşündüğüm için hâlâ magic link’i tercih ediyorum.
Magic link hiç kullanmadım ama birkaç ay önce SaaS’ımıza Google Sign in ekleyince yeni kayıtların %90’dan fazlasını oluşturmaya başladı.
Kullanıcı kitlemiz geliştiricilerden oluştuğu için teknik okuryazarlığı ve gizlilik hassasiyeti yüksek sayılır; buna rağmen böyle oldu ve artık başka bir yöntemin öncelikli olduğunu düşünmüyorum. Elbette e-posta/parola yöntemini hâlâ sürdürüyoruz.
Parola yöneticisiyle birlikte kullanılan kullanıcı adı+parola veya passkey, HTTPS üzerinde geniş kitlelere iyi bir kullanıcı deneyimi sunarken kimlik bilgilerini uçtan uca şifreli biçimde değiş tokuş etmenin muhtemelen neredeyse tek yolu.
Parola yöneticileri, kimlik bilgilerinin yalnızca doğru alan adında kullanılmasını garanti eder.
Mercury’nin sadık bir müşterisiydim, ancak güvenli bir parola, parola yöneticisi ve geçerli bir TOTP’den geçtikten sonra bile IP adresi her değiştiğinde üçüncü kimlik doğrulama faktörü olarak magic link’i zorunlu tutmaları, şirket bankacılığını başka bir yere taşımayı düşünmeme kadar yol açtı
Son 5 yıldır kullandığım konum ya da ISP dışında bir yerden giriş yapıyorsam bunu anlarım; ama dünkü girişime göre değişen tek şey DHCP adresinin son oktetiyse bu mantıklı değil
E-postayı web’de gezinmekten farklı bir bilgisayarda SSH üzerinden okuduğum için yüzlerce karakterlik giriş bağlantısını kopyalayıp yapıştırmak gerçekten eziyet
Emacs’ta birkaç satıra bölünmüş görünüyor ve satır sınırlarındaki
\karakterlerini de elle kaldırmak gerekiyorHer girişte sürtünme eklerseniz, uygulama içindeki sonraki tüm etkileşimlerin izlenimi kötüleşir ve insan kullanmak istemez
Daha önce kullanılan bir cihazsa cihaz doğrulama isteği çıkmamalı. Bunu anlamak için kalıcı bir çerez saklıyoruz ve aynı IP’de de istemiyoruz. Acaba çerezleriniz düzenli olarak siliniyor olabilir mi merak ediyorum
Bu özelliği, saldırganlar http://mercury.com kopya siteleri oluşturup Google reklamları bile verdikten sonra ekledik
Müşteri kimlik avı sitesine parolasını ve TOTP’sini girdiğinde, phisher bu kimlik bilgileriyle giriş yapıp sanal kart oluşturuyor, kripto para, altın vb. satın alıyordu; kullanıcıyı da gerçek Mercury’ye yönlendirip bunun geçici bir hata olduğunu sanmasını umuyordu
Gönderdiğimiz bu cihaz doğrulama bağlantısı, bağlantıyı açan IP/cihazı onaylıyor ve bu yöntemle phisher’ları neredeyse tamamen engelledik
WebAuthn bu tür kimlik avı saldırılarına karşı bağışık olduğundan, WebAuthn kullanırsanız cihaz doğrulaması istemiyoruz
Mümkünse TouchID/FaceID veya cihaza özgü WebAuthn kullanmanızı şiddetle öneririm. Daha kullanışlı ve daha güvenli; buradan ekleyebilirsiniz: https://app.mercury.com/settings/security
Bununla birlikte bu yazıyı şirket içinde tartışıyoruz ve IPv6 daha yaygınlaştıkça IP’lerin çok daha sık değişeceğinin de farkındayız. Aynı IP eşleşmesi kısıtını gevşetmemiz gerekip gerekmediğini değerlendireceğim
Geçen haftaki 404 yazısına bir tepki olarak bunun çok iyi olduğunu düşünüyorum. 404’ü seviyorum ama yazarın söylediği aynı nedenlerle magic link can sıkıcı
Ricky Mondello’nun geçen hafta yazdığı yazı[1], passkey’lerin yazının sonunda ima edildiği gibi magic link’lerle birlikte kullanılabileceğini iyi açıklıyor; okumaya değer
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Store’a giriş yapmaya çalışınca e-postayla gönderilen 2 adımlı kodu girmemi istiyordu; birkaç dakika boyunca e-posta gelmiyor, yeni kod istesem de gelmiyor, vazgeçip başka bir işle uğraşınca 30 dakika sonra iki kod birden geliyordu
Aslında e-posta en iyi zamanında bile güvenmesi zor bir şey. Spam klasörüne düşebilir, şirket spam filtresi bağlantıyı engelleyebilir veya gelen kutusu dolu olabilir
Kişisel olarak e-posta yalnızca iPhone’umda var; şirket dizüstüsünde veya oyun PC’sinde kontrol etmek için icloud.com’a giriş yapmam gerekiyor, bu da zahmetli
Keşke parola girmeme izin verseler, gömülü cihazlardaki gibi QR kod taratsalar ya da en azından bir alternatif sunsalar
Magic link’ler passkey’e erişmeyi sağlıyor; passkey de temelde “bu bilgisayarı hatırla” seçeneğinin güçlendirilmiş hali
Hâlâ Apple’daki insanların kamuya açık şekilde neredeyse hiç görünmediği zamanlara alışkınım
Bir şeyi yanlış mı anladım bilmiyorum ama passkey'lerin gerçekte magic link'lere alternatif olduğunu sanmıyorum
Şimdiye kadar gördüğüm tüm passkey uygulamaları, başka bir yöntemle zaten oturum açtıktan sonra passkey oluşturmayı öneriyordu
Çok derinine inmedim ama kullanıcı deneyimi açısından passkey'ler genel olarak parolaların alternatifi olmaktan çok “bu bilgisayarı hatırla” düğmesinin alternatifi gibi görünüyor
Bir şekilde servisin bu yeni cihazın onaylandığını bilmesi gerekiyor
Sağlayıcıya göre passkey senkronizasyonu olsa da ilk kimlik doğrulamanın nasıl yapılacağı sorununu çözmüyor
Magic link'in temel içgörüsü, bir güvenlik sisteminin kurtarma mekanizmasından daha güçlü olamayacağıdır
Passkey'lerin tek kimlik doğrulama aracı sayıldığı bir dünya gelmeyecek; her zaman bir kurtarma mekanizması kalacak ve bunların çoğu e-posta üzerinden otomatik kurtarma olacak
O hâlde magic link, üstünde daha güvenli bir katman varmış gibi yapmayıp sadeleştirmesi bakımından dürüst
Kurtarma mekanizmasını kimlik doğrulama akışının ana etkileşim yolu hâline getirirseniz, kimlik doğrulama sisteminin gerçek güvenlik seviyesi konusunda daha dürüst olmuş olursunuz
Düzenleme: filmgirlcw, iki yöntemin pratikte birbirini nasıl tamamladığını anlatan daha iyi bir yazının bağlantısını bıraktı: https://news.ycombinator.com/item?id=42628226
Magic link'lerin de avantajları var ama e-postayı daha güçlü bir saldırı vektörü hâline getirmenin bir avantaj olup olmadığından emin değilim
Parola yöneticisi kullananlar için magic link'ler bariz bir sürtünme noktası ve passkey'ler bunu kesinlikle azaltabilir
Passkey'lerin kullanıcı deneyimi sorunlarında da iyileştirme alanı var; dışa aktarma mümkün hâle gelirse sistemler arası senkronizasyon çok daha iyi olacaktır
1Password'ü varsayılan parola ve passkey sistemi olarak kullanmamın nedenlerinden biri de cihazlar arasında passkey kullanabilmek; şirket de 1Password kullanıyor, böylece kişisel ve kurumsal hesaplarda oturum açmış kalıp gerektiğinde kişisel ya da iş cihazından doğrulama yapabiliyorum
Ancak 404'ün tanımladığı sorun, parola ya da kimlik doğrulama denetimlerini saklama sorumluluğunu üstlenmek istememekse, bazı kullanıcılar için passkey'lerin magic link'lerden daha iyi olduğunu düşünüyorum
Yine de Ricky gibi bunun ikisinden biri değil, ikisi birden olması gerektiğini düşünüyorum
[1]: https://rmondello.com/2025/01/02/magic-links-and-passkeys/
Passkey kullanıyor olmak mutlaka alternatif bir giriş yöntemi olması gerektiği anlamına gelmez, ancak henüz hiçbir servis yalnızca passkey'e geçmedi
Eski OS veya Linux kullanıcıları hâlâ passkey oluşturup saklayamayabilir ve birçok kullanıcı çapraz platform kimlik bilgisi yöneticisi kullanmıyor
Örneğin iCloud Passwords ile bir passkey oluşturduysanız şu anda Linux'ta oturum açmanın bir yolu yok
Birkaç yıl daha geçince, servislerin en baştan passkey oluşturtup parolayı hiç toplamadığı akışları görmeye başlayacağımızı düşünüyorum
Passkey taşınabilirliği spesifikasyonunun uygulanmasını ve Gnome/KDE'nin de passkey desteği eklemesini umuyorum
İş bilgisayarında bir web sitesini ziyaret ederken telefondaki OTP'yi kullanmak ya da telefondan bağlantı kopyalamak eziyetse, iş bilgisayarını dizüstü bilgisayar gibi bir yerdeki kişisel passkey'le ilişkilendirmek ne kadar daha kolay ve iyi olur, merak ediyorum
Kimlik doğrulama için yalnızca magic link destekleyen servisleri kullanmıyorum. Kullanıcıya karşı son derece düşmanca ve güvenlik açısından da parola yöneticisiyle kullanılan bir paroladan açıkça daha kötü
En kritik nokta, benim kişisel kurulumumda bunun hiç çalışmaması
Güvenlik ve hesap emniyeti için giriş yaptığım cihazlarda e-posta hesabıma erişmediğim için
Yalnızca Anthropic'i, Claude en iyi LLM olduğu için istisna tutuyorum ama her yeniden giriş yapmam gerektiğinde büyük bir eziyet oluyor ve defalarca şikâyet gönderdim
Magic link gördüğüm her seferinde hep “en başta e-posta bağlantılarına tıklamamamız gerekmiyor muydu?” diye düşünüyorum
E-posta bağlantıları deyince aklıma phishing de geliyor
Magic link'lerden gerçekten nefret ediyorum
Asıl mesele şüpheli bağlantılara tıklamamak. Magic link'in gönderildiğini biliyorsanız şüpheli bir bağlantı değildir
Yine de gecikme yüzünden magic link'leri sevmiyorum
Apple'ın e-posta gizliliği yaklaşımı ilginç görünüyor. Apple'ın her zaman tüm görselleri yüklediği bir yöntem; dezavantajı var mı bilmiyorum
Gördüğüm en iyi uygulama, bağlantıya e-postayı aldığın cihazda tıklamanı gerektiriyor ama oturumu o cihaza taşımıyor; girişi ilk giriş sürecini başlattığın cihazda tamamlatıyor
Daha iyi çözüm, girişin yalnızca bağlantının açıldığı cihazda yapılmasını sağlamak ve cihazlar arası kullanım için alıcı cihazda okunup orijinal cihaza kolayca girilebilecek bir OTP kodu da sunmak
Ya da bağlantı olmadan yalnızca OTP kodu da verilebilir
Bir tarayıcıda çalışırken e-postayı açınca varsayılan tarayıcıda doğrulanmaktan, daha da kötüsü başka bir cihazda doğrulanıp bağlantıyı oraya ilettikten sonra tekrar açmak zorunda kalmaktan daha kötü bir şey yok
Belirli bir cihazda belirli bir e-postaya erişmek istemediğin durumlar da olabilir; yani bu tuhaf bir senaryo değil
Sitenin
crazy-pink-horse-3837gibi bir OTP gönderip bunu kopyalayıp yapıştırmana izin vermesi, ilk isteği doğrulayan bağlantı uygulaması çok zorsa fena olmayan bir orta yolAma uygulamadaki sorun, gönderilen sihirli bağlantının bir tıklama izleyicisi ile sarmalanmış olması ve bu alan adının pihole gibi araçlar tarafından engellenmesiydi
Bu yüzden gerçek kimlik doğrulama URL’sine ulaşıp giriş sürecini tamamlayamıyordun
Uygulama içi tarayıcılar ortadan kalkmalı. Özellikle “normal tarayıcıda aç” seçeneği sunmayan uygulama içi tarayıcılar; bir RSS okuyucusuysa zaten bu seçeneği sunmalı
Kullanıcıyı uygulama içi tarayıcıya zorlayan ürün yöneticilerinin hepsi hapse gönderilmeli
Çok daha iyi seçenek, e-postayla gönderilen OTP kodu ve Conditional Mediation UI kullanan passkey’lerdir
Kullanıcı zaten passkey’i olan bir cihazdan giriş yapıyorsa, CM UI hemen seçim yaptırıp anında giriş sağlayabilir
Passkey’i olmayan bir cihazdaysa, e-posta kodunu girmesini sağlayıp başarılı olunca hemen passkey kurdurarak sonraki sefer doğrudan giriş yaptıran bir kullanıcı deneyimi tasarlayabilirsiniz
Böylece mevcut cihazlarda passkey’in güvenliğini, yeni cihazlarda ise parolasız kurulum ve hesap kurtarmayı elde edebilirsiniz
Üstelik bulut sağlayıcısının tüm passkey’lere sahip olduğu vendor lock-in durumundan da kaçınabilirsiniz