Microsoft Authenticator açığı MFA hesaplarını üzerine yazıp kullanıcıları kilitliyor

• MFA kullanımının arttığı bir dönemde Microsoft Authenticator, QR koduyla eklenen yeni TOTP hesabı nedeniyle mevcut hesabın üzerine yazıp kullanıcıyı hesabından kilitleyebiliyor
• Çakışmanın temelinde, hesapları ayırmak için yalnızca label kullanan tasarım yer alıyor; Google Authenticator ve Okta gibi uygulamalarda olduğu gibi issuer ile label birlikte kullanılmıyor
• Üzerine yazma durumu hemen fark edilmediği için kullanıcılar, haftalar ya da aylar sonra eski hesaba erişmeye çalıştıklarında ancak erişim kaybı yaşayabiliyor
• Geçici çözüm olarak başka bir doğrulama uygulaması kullanmak ya da Secret Key'i elle girmek mümkün, ancak kurumsal ortamdaki sıradan kullanıcılar için bu pek pratik değil
• Microsoft bunun amaçlanan davranış olduğunu ve bir uyarı mesajı sunduğunu söyledi; daha sonra bazı sağlayıcılarda issuer eksikliği gerekçesini öne sürerek yalnızca ileride iyileştirme ihtimaline açık kapı bıraktı

---

QR taraması mevcut MFA hesabının üzerine nasıl yazıyor

• Microsoft Authenticator, yeni bir hesabı QR taraması ile eklerken aynı kullanıcı adına sahip mevcut bir hesabın üzerine yazabiliyor
• Kullanıcı adı olarak çoğu zaman e-posta adresi kullanıldığından, farklı servislerin MFA hesaplarının aynı label'ı paylaşması yaygın bir durum
• Google Authenticator ve diğer doğrulama uygulamalarının çoğu, çakışmayı önlemek için banka ya da otomotiv şirketi gibi issuer adını da birlikte kullanıyor
• Microsoft Authenticator ise issuer'ı birlikte kullanmıyor ve hesabı yalnızca kullanıcı adına göre tanımlıyor
• Üzerine yazma sonrasında hem yeni oluşturulan hesapta hem de üzerine yazılan eski hesapta doğrulama sorunları yaşanabiliyor

Fark edilmesi zor hesap kilitlenmesi

• Kilitlenme yaşandığında kullanıcılar bunun Microsoft Authenticator'dan değil, doğrulamayı sağlayan şirketten kaynaklandığını sanabiliyor
• Sonuç olarak kurumsal help desk ekipleri, kendi oluşturmadıkları bir sorunu çözmek için zaman harcamak zorunda kalabiliyor
• Hangi hesabın üzerine yazıldığını kolayca görmek mümkün değil
• Mevcut hesabın kaybolduğu gerçeği, kullanıcı o hesabı yeniden kullanmaya çalışana kadar ortaya çıkmayabiliyor
  • Bu da haftalar ya da aylar sonra olabilir

Geçici çözümler ve eski şikayetler

• En kolay geçici çözüm, Microsoft Authenticator yerine başka bir doğrulama uygulaması kullanmak
• QR kod taraması yerine Secret Key elle girilirse sorun önlenebiliyor
• Microsoft hesabına bağlı doğrulama hesaplarında bu sorunun görünmediği anlaşılıyor
• CSO Online, bu sorunla ilgili şikayetlerin 2020'ye kadar uzandığını doğruladı; sorunun kendisinin ise Microsoft Authenticator'ın Haziran 2016'daki çıkışından beri var olduğu düşünülüyor
• 2020'de bir kullanıcı, Identity Provider Secret Key'inin elle girilmesine dayanan bir geçici çözümden söz etti; ancak kurumsal ortamdaki ortalama son kullanıcı için rastgele dizelerle uğraşmanın faydalı olmadığı değerlendirildi

Sahada yeniden üretilen üzerine yazma sorunu

• Avustralyalı BT danışmanı Brett Randall, bir tedarikçi eğitim oturumunda katılımcıların Microsoft Authenticator ile MFA QR kodlarını tararken başka bir uygulamanın TOTP anahtarının üzerine yazıldığı durumlar yaşadığını aktardı
• Randall'a göre MFA QR kodu birden çok değer içeren bir dize oluşturuyor ve diğer uygulamalar label ile issuer'ı birleştirerek ilgili anahtarın benzersiz kimliğini oluşturuyor
• Microsoft Authenticator ise bu standart davranış yerine yalnızca label kullanıyor; bu label da genellikle e-posta adresi oluyor
• Aynı e-posta adresini kullanan son TOTP anahtarı yeni anahtarla üzerine yazılabiliyor
• Randall, Microsoft'un bu sorunu fark edip harekete geçmesini sağlamanın neredeyse imkansız olduğunu söyledi

Güvenlik ve BT uzmanlarının tepkileri

• CSO Online, çeşitli güvenlik ve BT uzmanlarından sorunu yeniden üretmelerini istedi ve hepsi bunu başardı
• IllumineX'in fractional CTO'su Gary Longsine, bunu bir tasarım kusuru olarak gördüğünü ve Microsoft Authenticator'ı tavsiye etmeyeceğini söyledi
• Wallarm ürün başkan yardımcısı Tim Erlin, aynı e-posta adresine sahip ikinci bir giriş eklendiğinde çakışma oluştuğunu ve üzerine yazma sonrası hangi hesabın etkilendiğinin anlaşılamadığını söyledi
• Erlin, kullanıcıların nedenini bilmeyebileceği için bu sorunun gerçekte olduğundan daha az biliniyor olabileceğini belirtti
• Netography chief product officer'ı David Meltzer, sorunu bizzat yeniden ürettikten sonra bunun açık bir bug olduğunu ve Microsoft'un düzeltmesinin görece kolay olduğunu söyledi
• Google sözcüsü Kimberly Samra, Google Authenticator'ın kodların üzerine yazmadığını ve bunun bilinçli bir karar olduğunu söyledi

Microsoft'un tutumu ve uyarı metni

• Microsoft sorunu doğruladı ancak bunun bir bug değil, amaçlanan davranış olduğunu belirtti
• İlk yazılı açıklamasında, kullanıcı QR kodunu taradığında hesap ayarlarının üzerine yazabilecek bir işlemden önce bir onay mesajı gördüğünü anlattı
• Gerçek uyarı metni şöyle: “This action will overwrite existing security information for your account. To prevent being locked out of your account, continue only if you initiated this action from a trusted source.”
• Bu ifade, kullanıcı işlemi kendisi başlattıysa ve kaynak güvenilirse devam etmesini söylüyor
  • Banka ya da otel gibi meşru hizmetlerde kullanıcı QR taramasını kendisi başlattığında bu iki koşul çoğu zaman sağlanmış oluyor
  • Talimat izlenirse hesabın üzerine yazılabiliyor
• Uyarı penceresi, doğrulama girişiminden vazgeçmek dışında üzerine yazmayı önleyecek bir yol sunmuyor

issuer eksikliği etrafındaki sorumluluk tartışması

• Microsoft daha sonra verdiği daha uzun ikinci açıklamada, bazı site veya tedarikçilerin label içinde issuer'ı, yani site adını ya da Identity Provider adını, belirtmediğini söyledi
• Aynı label'a sahip mevcut bir hesap varsa uygulama, yeni taranan TOTP hesabıyla mevcut hesabın üzerine yazmaya çalışabiliyor
• Microsoft, bu durumda kullanıcının her zaman bir üzerine yazma onay mesajı aldığını ve devam edip etmeme seçeneğine sahip olduğunu belirtti
• “Ürünü geliştirmeye devam ediyoruz ve bunu dikkate alarak gelecekteki iyileştirmelere uygulayacağız” ifadesi, Microsoft'un sorunu düzeltebileceğine işaret eden tek cümle oldu

Diğer doğrulama uygulamalarıyla karşılaştırma

• Randall, son kullanıcıların yanlışlıkla diğer uygulamalardaki anahtarların üzerine yazmasını önlemek için iki yol olduğunu düşünüyor
  • Tüm uygulamaların otpauth yapılarını denetlemek ve her şirketi hatalı uygulamaları düzeltmeye ikna etmek
  • Microsoft'un bir kez düzeltme yapması ve sonrasında kimsenin aynı kaygıyı yaşamaması
• Randall, 14 farklı doğrulama uygulamasında aynı çakışma davranışını test ettiğini ancak Microsoft Authenticator ile aynı davranışa rastlamadığını söyledi
• Test edilen uygulamalar arasında Google Authenticator, Okta Verify, Duo Mobile, LastPass Authenticator, 2FA Authenticator, Twilio Authy, Salesforce Authenticator, OneAuth, ForgeRock Authenticator, Authenticator 7, Authenticator App, Auth0 Guardian, OTP Auth ve Authenticator 2FA Sentinel yer aldı

[GN⁺]

Hacker News görüşleri

• Kullanılabilirliği olmayan güvenlik sorununu gösteren küçük ama gerçekten etkileyici bir örnek
  “Güvenlik” adına yaşadığımız saçma şeyleri düşünmek yeterli: zorunlu periyodik parola değişiklikleri, çılgın parola kuralları, deneme yanılmayla öğrenilmesi gereken belgelenmemiş gereksinimler, güvenlik jargonuyla dolu karmaşık hata mesajları, cevabını hatırlamadığınız “gizli sorular” gibi şeyler
  Oysa bu sistemlerin kendi güvenliği elek gibi delik deşik. Veri sızıntıları ve bilgi ifşaları neredeyse her gün haber oluyor; bazen bunun nasıl böyle sürüp gittiğini merak ediyorum

  • Capital One bir noktada “kullanıcı adı” kavramını devreye sokup e-posta adresiyle oturum açmayı bozdu; bunu belgelemediği gibi kullanıcı adında e-posta adresi kullanılmasını da engellemedi
    Aylar boyunca her girişte “hesabımı bul” seçeneğini kullanmak zorunda kaldım ve her seferinde kullanıcı adını yeniden e-posta adresime ayarladım. Neredeyse 10 yıl boyunca giriş bilgim bu olduğu için bu gayet doğaldı
    Kullanıcı adında @ veya . kullanılamayacağı kısıtı, oturum açma aşamasına gelene kadar hiç uygulanmıyordu; sonunda aylar sonra bunu başka bir değerle değiştirmem gerektiğini anladım
    Asıl hesap ING Direct’ti; sonra Capital One 360 oldu, ardından Capital One’ın geri kalan karmaşasına tamamen entegre edildi. Bu kullanıcı adı sorununun da bununla ilgili olduğunu düşünüyorum
  • Dün iyi bir örnek yaşadım
    Web sitesi: “Özel karakter ve rakam içeren, en az 8 karakterlik karmaşık bir parola seçin”
    Parola yöneticisini açıp 128 karakterlik rastgele parola ürettim ve kendimle gurur duydum
    Bir sonraki ziyaretimde web sitesi: “Parolanızın 31., 98. ve 102. karakterlerini girin”
    Bir Birleşik Krallık konut kredisi sitesiydi
    Şimdi düşününce, bunu yapabilmeleri parolayı düz metin olarak sakladıkları ya da en azından hashlemek yerine şifreleyip istedikleri zaman çözebildikleri anlamına geliyor
  • Uzun süre kullanmadığım bir web sitesinde hesabım olduğunu fark edip giriyorum; e-posta ve site URL’sinden algoritmayla ürettiğim doğru parolayı yazıyorum ama başarısız oluyor — en nefret ettiğim kalıp bu
    Acaba eski sürüm algoritmayla üretilmiş parolaydı diye tekrar deniyorum, yine olmuyor. Sonunda parola sıfırlamaya basıyorum, e-postayı alıp bağlantıya tıklıyorum ve algoritmanın ürettiği parolayı yeni parola olarak girince “bu özel karakter kullanılamaz” diyor
    Kendi kuralıma göre o özel karakteri bir sonraki karakterle değiştirince bu kez “mevcut parolanızla sıfırlama yapılamaz” diyor
  • Şimdiye kadar gördüklerim arasında https://studentaid.gov/ en kötüsüydü. Sahte bilgi girmek istemedim; gereksinimleri tekrar kontrol etmek için hesabı çoğaltmam da mümkün değildi
    Hatırladığım kadarıyla “kelime yasak”, “son 24 parolanın yeniden kullanımı yasak”, “bazı özel karakterler hariç”, “5 güvenlik sorusu” ve başka birçok parola gereksinimi vardı
    Güvenlik sorularının büyük/küçük harfe duyarlı olup olmadığını kimse bilmiyor
    Hesap oluşturma bilgilerinin doğru olduğunu ve kişinin siz olduğunu doğrulamanız gerektiğini; yanlış veya yanıltıcı bilgi verirseniz para cezası, hapis ya da ikisiyle birden karşılaşabileceğinizi söyleyen bir ifade de vardı
  • İyi haber şu ki saydıklarınız, hem son kullanıcılar hem de güvenliği anlayan insanlar tarafından kötü fikirler olarak biliniyor. Ne yazık ki güvenlik politikalarını uygulayan insanların çoğu bu gruba girmiyor
    Dört veya daha fazla sözlük kelimesi kullanarak gayet iyi parola güvenliği elde edebilirsiniz; güvenlik sorularının yanıtlarında da aynı yöntem kullanılabilir. Tüm gizli değerleri hatırlama sorununu çözen çok sayıda ücretsiz ve ücretli parola yöneticisi de var. İki faktörlü kimlik doğrulama gizli değerlerini yedeklemek için de iyi
    “Karmaşık hata mesajı”, kullanıcının kendi başına düzeltmesi beklenen bir hataysa, bunun yerine genel bir hata ve benzersiz bir ID döndürüp destek ekibiyle iletişime geçmesini sağlayabilirsiniz. Jargon bombardımanı can sıkıcı ama güvenliğe özgü bir sorundan çok, insanların hataları açıklayamamasına dair yaygın bir beceriksizliğe benziyor
    Çoğu kuruluş, işin bütünü başarılı olsa bile aynı anda pek çok şeyi batırıyor; güvenlik de bunlardan biri. Yeterince büyük bir kuruluşta beceriksiz insanların beceriksiz işler yapmasını önlemenin zor olduğunu düşünüyorum

• Bu, birçok katmanda anlaşılmaz. Microsoft Authenticator öğeleri yalnızca etikete göre mi saklıyor demek oluyor? İç anahtar gibi bir şey de mi oluşturmuyor?
  Sonra da web sitesinin yayıncıyı etikete değil de olması gerektiği gibi issuer alanına koymasını mı sorun diye gösteriyorlar?
  Microsoft’ta gerçekten kendi Authenticator’ını kullanan kimse var mı merak ediyorum. Bir şeyi kaçırmıyorsam, bir e-postayı bir sitede kullandığınız anda başka bir siteye ekleyemeyeceğiniz için neredeyse tüm uygulamalarda kullanılamaz gibi duruyor

  • Benzer şekilde, arama devi Google, Android için Google Authenticator’ı arama çubuğu bile olmadan çıkardı ve çok sayıda özellik isteğine rağmen bunu bilerek eklememeye devam ediyor
    Ama iOS sürümünde arama çubuğu var. Nedenini hiç anlamıyorum
    Devasa Piper deposunun içinde, tek bir değişiklik listesiyle eklenebilecek yerel bir arama kütüphanesi zaten var gibi geliyor; gerçi o büyük dil modeli değil
  • Yazıya göre Microsoft, ücretsiz ürün olduğu ve gelir üretmediği için düzeltmeye niyetlenmemiş
  • Microsoft çalışanları kendi Authenticator’larını kullanıyorsa, olsa olsa Microsoft’un tek yayıncı olduğu şirket içi iş hesapları için kullanıyorlardır
    Ve çok sayıda insanın hiç kullanmadığını düşünüyorum
  • Burada bir şeyler tutarsız. Aynı e-postayla birden fazla hesabım var ve yedek TOTP uygulamam Authenticator’daki kodlarla doğru kodları karşılaştırdım; eşleşiyordu
    Ancak kullanıcının yanlış kodu görmesine yol açabilecek bir UI sorunu buldum. Ekranda görünen ilk birkaç hesabın kodları her 30 saniyede bir yenileniyor ama ekran dışında kalan kodlar yenilenmiyor
    Kaydırıp ekran dışındaki kodu getirdiğinizde eski bir kod görünüyor; bir durumda doğru koddan 4 döngü geride kalan bir kod görünmüştü
  • Muhtemelen yalnızca şirketin zorunlu tuttuğu tek bir iş MS hesabı için kullanıyorlardır. Başka yerlerde kullanmazlar; çünkü kötü olduğunu biliyorlar

• Garip bir şekilde Microsoft’tan, oltalama gibi görünen ama sanki değilmiş gibi duran bir e-posta aldım.
  İçerik “İşlem gerekli: 15 Ekim 2024’e kadar kiracınızda çok faktörlü kimlik doğrulamayı etkinleştirin” diyordu; “genel yönetici” olduğum için gönderildiğini söylüyor, kuruluş adı olmadan yalnızca bir UUID yazıyordu.
  15 Ekim 2024’ten itibaren Azure portalı, Microsoft Entra yönetim merkezi ve Intune yönetim merkezi oturum açmalarında MFA gerekeceği için o tarihe kadar MFA’yı etkinleştirmem gerektiğini belirtiyordu. Yapamıyorsam yürürlük tarihinin ertelenmesi için başvurmamı söylüyordu.
  Sorun şu ki Microsoft’ta herhangi bir kuruluş yönetmiyorum. Sadece kişisel Office365 Family hesabı gibi şeylerim var ve hesabımda zaten iki adımlı doğrulama ayarlı.
  E-postada ne adım ne de sözde kuruluş adı vardı, yalnızca bir ID olduğu için ne demek istediğini hiç anlayamadım. Yine de e-posta gerçekten Microsoft’tan gelmişti.

  • Azure portalına giriş yaparsanız benzer bir mesaj görür ve ilgili kaynağa gidebilirsiniz.

• Gmail hesapları oluşturduktan sonra ülke ve bilgisayar değiştirirken birkaçını kaybettim. Giriş yapmaya çalışınca Google, parolanın doğru olduğunu ama cihazın ve IP’nin tanıdık olmadığını söyledi.
  Kurtarma adresi üzerinden kurtarmanın neden işe yaramadığını tam hatırlamıyorum; kurtarma e-posta adresine hâlâ erişebildiğim hâlde başarısız olmuştu. Muhtemelen Google’a kurtarma e-posta adresinin ne olduğunu söylemem gerekiyordu ve ben de kurtarma adresinde rastgele bir + son eki kullanmış olabilirim.
  Eskiden Gmail hesabımda Google Authenticator kullanıyordum ama Google’ın pek bir çare sunmadığı bir durumda bozulabilecek bir unsurun daha eklenmesinden korktuğum için kapattım.
  Parolam yaklaşık 96 bitten fazla entropiye sahip; /dev/urandomdan 256 bit çekip çok duyarlıklı bir tamsayıya dönüştürüyorum, ardından divmod ile rakam, küçük harf, büyük harf ve sembollerden birer tane seçiyorum; kalanını tüm alfabeden seçtikten sonra kalan entropiyle Fisher-Yates karıştırması çalıştırıp ilk karakterin her zaman rakam olmamasını sağlıyorum.
  Siteye özel parolalar kullanıyorum ve bunları 2000’lerin başında kendi yaptığım gpg tabanlı parola yöneticisinde saklıyorum.
  Çok faktörlü kimlik doğrulama, devam eden bazı aktif ihlallere karşı yardımcı olur ama veritabanı ihlali sonucu parola hash dökümleri için işe yaramaz. Parolayı bildiğim hâlde kurtarma e-posta adresiyle kurtarma yapamamak gerçekten çok can sıkıcı.
  Birkaç aydır hiçbir yerden giriş yapmadıysam ve doğru parolaya sahipsem, en azından benden kurtarma adresini söylememi istemek yerine kurtarma adresine doğrulama bağlantısı ya da kod göndermeleri gerekir. Nereye gönderdiklerini söylemek zorunda değiller ama kurtarma adresini ezberlenmesi gereken bir başka parola hâline getirmek gerçekten sinir bozucu.

  • Bunu bilmiyordum. Riski daha da büyütmek için kurtarma adresimi başka bir atıl Gmail hesabı olarak ayarlamıştım.
    Google’a, zaten verdiğim ve mutlaka vermem gereken verilerin ötesinde artık güvenmiyorum.
    Uluslararası taşınma planlandığı için, ciddi bir sorun çıkmadan önce e-posta hayatımı test ettiğim ücretli hesap olan Proton Maile taşıma sürecini hızlandırmam gerekiyor.
    Gmail’in masum göründüğü dönemlerde, idari işlemler çevrimiçi olmaya başladığında vergi, sağlık, kamu kurumları gibi yerlere iletişim adresi olarak Gmail vermeye başlamıştım. Bu iyi çalıştı ve birkaç uluslararası taşınma boyunca Gmail önemli bir idari araç hâline geldi.
    Orada burada atıl hesaplarım da var ama bir gün gerekebilecek önemli işler duruyor. Örneğin birkaç yıl geçerli Avustralya seyahat izinleri gibi şeyler.
    Kitlesel gözetim hızlandıktan sonra bile Gmail az çok zararsız görünüyordu; hangi kurumlarla iş yaptığım gerçeği dışında gerçek sırlar ya da çok kişisel derin bilgiler neredeyse yoktu.
    Ama çevrimiçi idari işlemler fiilen zorunlu hâle gelip diğer yollar asgari düzeyde kalınca, Gmail artık rahatsız edici derecede merkezi bir konumda. Otomatik botların şüphe uyandırmayan kullanıcılara merhamet ya da itiraz hakkı olmadan yaptığı endişe verici şeyler yüzünden taşınmaya başlamak zorunda kaldım.
    O kadar yaygın kullanılmış ki hepsini tek tek bulmaya zaman yetmiyor; unutulmuş hesaplar da silik anıları kazmayı gerektirdiği için işkence gibi. Yine de yapmak zorundayım.
    İkiz kızlarım kamu işleri için e-postaya ihtiyaç duyacak yaşa geldiğinde onları Google botlarının insafına bırakmak istemiyorum.
  • Kurtarma e-postasını eklediğinizde o hesaba bir bildirim e-postası almış olmanız gerekir. Gelen kutusunda o e-postayı bulursanız to alanından rastgele son eki öğrenebilirsiniz.
  • Benzer bir şey yaşadım. Bir açık kaynak projesinin Google alan adına eklenip bir e-posta adresi aldım, ama Google telefon numarası istediği için giriş yapamıyorum.
    Muhtemelen yöneticiyle konuşup sıfırlatabilirim ama kişisel bilgilerimi verene kadar hesabı fiilen rehin tutmaları epey rahatsız edici.
  • Konuşacak kimsenin olmaması yüzünden, bilgisayar olmaz derse iş orada bitiyor.

• İş hesabı yüzünden Microsoft’unkini kullanıyordum. Zaten Office365’in içine iyice gömülü olduğu için kullanmamak için bir neden yoktu.
  Böyle bir iletişim kutusu hiç görmedim; eklediğim hesaplarda da sorun olmadı. İş hesabı olduğu için %99 hesap adı olarak şirket e-postamı paylaşıyorum.
  Bu, kullandığım sitelerin yeterince benzersiz etiketler sağladığı için şanslı olduğum anlamına mı geliyor? Sorunun tam olarak ne olduğunu tamamen anlamamış gibiyim.

  • Donanım anahtarını iki aşamalı kimlik doğrulama için kullanmak istiyordum ama her sistem desteklemiyor, destekleyenler de düzgün desteklemiyor. Kaydedilebilen anahtar en fazla 1 taneyse, bu neyin kafası diye düşünüyorsunuz.
    Sonunda zaman geçip gidiyor; bu ailemin geçimini sağlayan iş değil, sadece giriş yapmak için ne yapmam gerektiğini deşmem gereken can sıkıcı bir iş. Bu yüzden önceki iş yerimin zorunlu tuttuğu MS çözümünü kullanmaya karar verdim.
    Çevrimiçi hesapları kullanırken anlamlı bir şey yapmak yerine böyle şeylerle oyalanarak zaten çok fazla zaman harcadım.
    Çevrimiçi kimlik doğrulamanın tamamı ciddi biçimde güvenilmez; büyük deliklerle ve daha da büyük risklerle dolu, biz de tüm hayatımızı bunun üzerine inşa ediyoruz.
    On yıllardır parola zayıflıkları yüzünden ciddi zararlar yaşanmasına rağmen hâlâ parola kullanıyoruz; yara bandı ya da üstüne boya çekerek idare etmeye çalışıyoruz.
    Neredeyse her hafta bir çevrimiçi sistem, kötüye kullanılması kolay büyük miktarda kişisel veriyi sızdırıyor; biz ise yanan odanın ortasında kahve içen köpek mem’i gibi “Sorun yok, sorun yok” diye oturuyoruz.
    Her sistemde farklı, 8 karakterden uzun parolalar kullanırsak güvende olacağımıza inanıp bunun yeterli olacağını düşünüyoruz.
  • Bu hata yalnızca iOS uygulamasında QR kodu tararken ortaya çıkıyor gibi görünüyor.
  • Ben de aynı durumdayım. Aynı e-posta adresini kullanan 3 kişisel hesabım var; ikisi FAANG, neredeyse 10 yıldır sorunsuz çalışıyor.
  • Microsoft’un yanıtını okuyunca, Microsoft’un MFA yayımlayan şirketleri “yayımlayıcıyı etikete koymamakla” suçladığı görülüyor. MSFT, yayımlayıcının orada olması gerektiğini bekliyor.
    Eğer böyle bekliyorlarsa Microsoft ürünleri yayımlayıcıyı zaten etikete koyacağından sorun çıkmayacaktır.
    Sorun, aynı e-postayı tanımlayıcı olarak kullanıp yayımlayıcıyı kaydetmek için var olan issuer alanına yayımlayıcıyı koyan başka sağlayıcıları kullandığınızda ortaya çıkıyor. Sanki çok tuhaf bir şey yapıyorlarmış gibi.

• Safari’de de benzer bir hata vardı; hiçbir uyarı vermeden passkey’in üzerine yazarak hesabınızdan tamamen kilitlenmenize neden oluyordu. Sonradan düzeltildi ama bu yüzden GitHub erişimimi kaybettim.
  https://bugs.webkit.org/show_bug.cgi?id=270553
  Safari’de hâlâ, sabit kodlanmış istisnalar dışında farklı alt alan adlarında barındırılan web sitelerini ayırt edemeyen bir hata var; bir alt alan adının parolasını başka bir alt alan adının parolasıyla değiştiriyor. Bunu her ay yaşıyorum.

  • Keychain’in StackOverflow ve StackExchange alt alan adlarında parolanın yeniden kullanıldığına dair uyarı vermesi, tek bir öğeye birden çok siteyi elle ekleyebildiğim üçüncü taraf bir parola yöneticisi kullanmaya başlamamın nedenlerinden biriydi.
    Ama bu aptallığın daha derinlere uzandığını bilmiyordum.

• Güvenlik açıkları olsa da SMS ile çok faktörlü kimlik doğrulamanın kullanıcılar arasında popüler olmasının nedeni tam da bu.
  Genelde SIM swap saldırısının hedefi olmadığınız sürece yeterince iyi. Çoğu kişi hedef olmaz ama çok faktörlü kimlik doğrulama anahtarını kaybetme sorununu yaşama olasılığı epey yüksek.

  • Doğru. Basit ve neredeyse herkes anlıyor. Parolanın kendisi gibi.
    YubiKey gibi daha güvenli yöntemlerin genel kitleye yayılamamasının nedeni de bu. Zahmetli ve kafa karıştırıcı.
  • İki kez etkinleştirdim. İlkinde etkinleştirdikten hemen sonra telefon tamamen bozuldu, ikincisinde çalındı.
    Şimdi sadece rastgele oluşturulmuş parolalara güveniyorum.
  • Bence ileriye giden yol FIDO ve çok ucuz NFC kart anahtarlarından geçiyor.
    Bir yere giriş yapmanız gerektiğinde cüzdanınızdan kartı çıkarıp telefona veya dizüstüne dokundurursunuz.
    Ücretli müşterileri olan bir şirket için, alternatif kimlik doğrulama yöntemlerini desteklemektense müşteride kart yoksa fiziksel olarak postayla göndermek daha mantıklı olacak kadar ucuz olmalı.
    Çoğu hizmet için ikinci bir kimlik doğrulama katmanı bile gerekmeyebilir. Birisi cüzdanınızı çalsa gerçekten Reddit hesabınızı da umursar mı, emin değilim.

• Test ettim; aynı hesap adı/e-postayı kullanan birden fazla hesap arasında çakışma olmadı.
  Her öğede yayımlayıcı simgesi doğru görünüyor ve yayımlayıcı her öğeye kaydedilmiş.
  MS Authenticator’ı yıllardır kullanıyorum; bu tür bir sorun hiç yaşamadım ve doğal olarak hesap adı ya da kullanıcı adı olarak hep aynı e-postayı kullanıyorum.
  Sadece test sonucumu yazıyorum. Bunun Authenticator veya Microsoft hakkındaki düşüncemi değiştireceğini sanmıyorum ama.

  • Hangi platform olduğunu merak ediyorum. O sorunun, ya da “özelliğin”, iOS sürümüyle sınırlı olduğunu duymuştum.

• Bir süre güncellemeden kullandıktan sonra MS Authenticator’ı güncellediğimde bu benim de başıma geldi.
  Tüm veriler silindi ve tüm hesaplarımdan kilitlendim. MS Authenticator özenle hazırlanmış bir ürün değil.

• Yaklaşık 1 yıl önce Google Authenticator uygulaması yeni sürüme otomatik güncellendiğinde benzer bir şey yaşamıştım.
  Güncelleme sırasında tüm hesaplarımı kaybettim ve kesinlikle birkaç ders çıkardım.

  • Bu kâbus yüzünden MFA QR kodlarını her zaman yedekliyorum ve bunları, verileri başka bir yerde de yedekleyebilen açık kaynaklı bir uygulamaya ekliyorum.