MeldID Panik Modu Ekledi: Hesaba Güvenilmez Olduğunda Neler Oluyor

Önceki makalemde MeldID sisteminin normal modda nasıl çalıştığını anlatmıştım: yönetilen profili saklar, bağlı hizmetlere girişte yardımcı olur, TOTP kayıtlarını cihazlar arasında senkronize eder ve yeni doğrulamalar için mobil uygulama üzerinden onay sağlar.

Ancak her kimlik doğrulama sisteminde de sıkça akla gelmeyen bir senaryo vardır: kullanıcı artık erişim durumuna güvenmediğinde ne yapmalı?

Bunun için zaten sisteminizin ihlal edildiğini bilmeniz gerekmez. Bazen beklenmedik bir şifre sıfırlama e-postası, bilinmeyen bir oturum veya kullanımda olmayan bir cihazdan giriş görebilirsiniz.

İşte böyle durumlar için MeldID’ye iki yeni mekanizma eklendi: ertelemiş şifre değişikliği ve panik modu.

MeldID şifresinin nasıl yapıldığını anlamak önemli

MeldID’de kullanıcı kendisi şifre oluşturmaz — sistem tarafından otomatik üretilir. Bu, zayıf ve tahmin edilebilir kombinasyonların, alışılmış şifrelerin tekrar kullanılmasının ve diğer kendi kendine seçimle ilgili sorunların önüne geçer.

Aksi takdirde geçerli şifre kullanıcıya e-posta ile gönderilmez. E-posta, MeldID şifresi almak için kullanılabilecek bir yer değildir.

Kurtarma prosedürü de eski şifreyi açığa çıkarmaz. Sadece yeni bir şifre oluşturulmasını sağlar.

Bu nedenle e-posta’nın ele geçirilmesi başka bir tehlike yaratır: e-posta erişimi olan biri, MeldID’nin geçerli şifresini bilmez, fakat kurtarma prosedürünü kullanarak yeni şifre talep edebilir.

İşte bu senaryo, kurtarma mantığını değiştirme ihtiyacını doğurdu.

Şifre artık anında değişmiyor

Geleneksel kurtarma senaryosunda, hemen hemen her şey hızlıdır. Kullanıcı yeni şifre isteğinde bulunur, e-posta alır ve süreci tamamlar.

Bu kullanışlıdır, e-posta kullanıcının kontrolü altındaysa. Ancak e-posta başka biri tarafından erişilebilir hale gelmişse, anında geri yükleme doğrudan hesabı ele geçirme yoluna dönüşebilir.

MeldID’de yeni şifre talebi önce uyarı olur, anında eski şifreyi değiştirmez. Kullanıcıya geri yükleme girişimi hakkında bildirim gönderilir ve ardından belirli bir bekleme süresi başlar.

Bu süre değişebilir, ama temel prensip aynıdır: talep ile yeni şifrenin aktif hale gelmesi arasında bir zaman dilimi vardır ve bu süre içinde duruma bakılır.

Bu aşamada eski şifre hala geçerlidir. Yani, geri yükleme girişimi, hesabın kontrolünü başka birine devretmiş olduğu anlamına gelmez.

Uygulama erişilebilir değilse

Görebileceğiniz önemli bir senaryo var: kullanıcı şifreyi kendisi sıfırlamak istiyor, fakat MeldID uygulamasına erişimi yok, telefon kayıp, bozuk, şarjı bitmiş ya da geçici olarak kullanılamaz duruma gelmiş.

Bu durumda, geri yükleme yine de tamamlanabilir. Belirli bir süre sonunda, yeni şifre otomatik olarak aktif hale gelir. Mobil uygulama kullanmak zorunlu değildir; standart kurtarma prosedürü bu durumu idare eder.

Dolayısıyla, şifre değişimi başlatmış ve şu anda uygulamaya erişimi olmayan biri, işlemi yeniden başlatmak zorunda kalmaz. Sadece bekler ve yeni şifre ile giriş yapar.

Eğer uygulama erişilebilir olursa, daha fazla seçenek var: kullanıcı yeni şifreyi hemen aktif edebilir veya şüpheli talebi iptal edebilir. Erişim yoksa, standart ertelemeli kurtarma devam eder.

Kullanıcı kendi kararını verir

Eğer kurtarma gerçekten hesap sahibi tarafından başlatılmışsa ve uygulamaya erişimi varsa, kullanıcı MeldID’yi açıp yeni şifreyi hemen aktif hale getirebilir, bekleme süresi dolmadan.

Şüpheli bir talep ise, uygulama üzerinden iptal edilebilir. Bu durumda, yeni şifre etkin olmaz, eski şifre kalır.

Bence bu, kurtarma mantığında önemli bir değişiklik. Sistem, her talebin otomatik olarak doğru olduğunu varsaymaz; sahip olduğu uygulama ile müdahale ve karar verme hakkı kullanıcına bırakılır.

Örneğin, kullanıcı bilmeden şifre değişikliği talep edildiğinde, uygulama bu uyarıyı gösterir ve iptal edilmesini sağlar. Bu durumda, eski şifre geçerliliğini korur.

MeldID, kompromite olmuş bir e-posta ile kontrolü kaybetmeyi engelleyemez, ancak e-postanın anında yeni şifre oluşturmak için kullanılmasını önleyebilir. Onun yerine, kendine özgü zamanlı gecikmeli bir süreç uygular ve erişim yeniden yapılandırması da kullanıcı müdahalesi ile gerçekleşir.

Panik modu aktif erişimleri iptal eder

Ertelemiş şifre değişikliği, zaman kazandırır. Panik modu ise, bu yetmediğinde ve kullanıcı acil olarak erişimleri durdurmak istediğinde devreye girer.

Mobil uygulamadan tek tıkla aktive edilir.

Aktif hale getirildiğinde, sistem mevcut tokenleri — giriş anahtarlarını — iptal eder, böylece uygulamalar ve web siteleri, kullanıcı girişli olduğunu kabul eden oturumları sonlandırır. Ayrıca, bu hesapla bağlı mobil ve web tabanlı tüm oturumlar da sona erer.

Bu, sadece telefondaki mevcut oturumu değil, başka telefonlar, tabletler, tarayıcılar ve giriş yapılmış diğer uygulamaları da kapsar.

Bu özellik, belirlenen süre boyunca geçerlidir. Süre değişebilir, önemli olan ilkeleridir: mevcut erişimler sonlandırılır ve kullanıcılara durumu kontrol etmek için güvenli bir zaman tanınır.

Güvenlik verileri silinmez

Gerçekten radikal görünebilecek bir isim, burada biraz açıklama gerekebilir: bu mod ne yapmaz?

Panik modu, TOTP kayıtlarını, saklanan profili, ayarları veya diğer kullanıcı verilerini silmez. Hesabın içeriğini temizlemez veya boş hale getirmez.

Erişim durumu değişir: aktif tokenler iptal edilir ve açık oturumlar sona erer. Hesap eski haline dönerse, saklanan veriler yerinde kalır ve tekrar eklenmesi gerekmez.

Bu, acil erişimi kesmek ile içerik silmek arasındaki temel farktır. Kullanıcı, mevcut bağlantıları kapatabilir; verilerin veya ayarların kaybolmasından endişe etmez.

Panik sırasında şifre değişimi ne olur?

Panik modunun başka önemli bir kuralı daha var: tüm tamamlanmamış şifre değişim girişimlerini durdurur.

Ne zaman istenir ise istensin, — yeni şifre talebi panik aktivasyonundan önce ya da sırasında — bu talep, koruma modundan çıkınca otomatik olarak tamamlanmaz.

Panik sona erdiğinde, aktif olan şifre, aktif edildiği şifredir — yani, panik başlamadan önceki şifre.

Bunun bilinçli yapıldığını söylemek gerek. Normal kurtarma prosedürü, kullanıcıya MeldID uygulamasında şüpheli bir talep görüp iptal etme imkânı sunar; yeni şifre, bu durumda, aktive olmadan önce iptal edilebilir.

Panik sırasında, bu senaryoya güvenmek artık mümkün değildir. Kullanıcı, şüpheli aktivite fark eder etmez panik modunu aktif hale getirebilir; ancak bu durumda, zamanlayıcı işlemesini devam ettirse de, saldırganlar panik sırasında yeni şifre talep edebilir. Eğer bekleme süresi, panik süresinden önce tamamlanırsa, yeni şifre yine de aktif olur ve hesap normale dönmeden önce erişim değişir.

Karmaşa ortaya çıkar: kullanıcı yükseltilmiş güvenlik aktif eder, ama tam da bu dönem sistem yeni şifreyi değiştirmesine izin verir; sahip, geleneksel iptal mekanizmasını kullanamadığı için. Bu nedenle, panik modu kurtarma işlemini duraklatmaz; tamamlanmış bir işlemi keser.

Tüm önceki şifre değişim talep ve girişleri, panik modundan sonra değiştirilemez. Aynı şekilde, panik sırasında yeni talepler de etkili olmaz.

Yani, tamamlanmamış kurtarma hiçbiri, panik sınırlarına taşınmaz.

Kullanıcı ilk olarak şifreyi değiştirmek isterse?

Panik modu, kullanıcının hareket sırasını kısıtlamaz. Eğer MeldID uygulamasına erişimi varsa ve şifresini değiştirmek istiyorsa, önce şifre değişikliği yapıp yeni şifreyi onaylayabilir. Bu adım, panik başlamadan önce tamamlanır.

Sonra, panik modu aktif hale gelir ve güncel, yeni şifreyle devam eder. Bu şifre, panikten çıktıktan sonra geçerliliğini korur.

Alternatif olarak, kullanıcı önce panik modunu aktif eder, şüpheli etkinliği araştırır, daha sonra gerekirse yeni bir şifre değiştirme işlemi başlatır.

Farklı bir amacın peşinde değil. Esas kural: tamamlanmamış şifre değişikliği, panik modundan sonra devam etmemelidir.

Panik, mail kontrolünü yeniden sağlar

Bir senaryo var ki, bu mekanizma burada özellikle önemli hale gelir: kullanıcı, sorunun meldID değil, e-posta olduğunu düşünüyor.

E-posta, recovery kanallarından biri. Bu nedenle, e-posta ele geçirilmiş olsa bile, aktif MeldID şifresi bilinmiyor olsa da, yine de tehlikeli olabilir.

Böyle bir durumda, kullanıcı panik modunu aktif edip sorumlu kaynağa odaklanabilir: E-posta erişimini yenileyip, şifreyi değiştirip, bilinmeyen oturumları kapatabilir, ayarları kontrol edebilir.

Panik süresi boyunca, MeldID kurtarma prosedürü yeni bir şifre oluşturamaz. Eğer birisi panikten önce kurtarma talebinde bulunduysa, bu giriş panik sırasında geçersiz olur. Yeni talep panik sırasında görünürse, sonuç aynıdır.

Bu, güvenli bir geçici pencere sağlar: MeldID erişimleri iptal edilmiş, potansiyel olarak ele geçirilmiş e-posta, panik sona ermeden yeni şifre oluşturmak için kullanılamaz ve sahibi, kontrolü yeniden sağlayabilir.

Panik sona erdikten sonra, mevcut şifre aynen kalır. E-posta kontrolü sağlandıysa ve başka belirti yoksa, kullanıcı normal modda hesabını kullanmaya devam edebilir. Eğer şifreyi değiştirmeyi tercih ederse, bu işlemi ayrı yapabilir.

Panik modu etkinleştirmeyi tetikleyebilecek pek çok neden vardır

Başlangıçta, bu modu başlatmak için ilk olarak ihlal kanıtı göstermek gerekmez. Telefon başkalarının eline geçmiş olabilir. Tanımlanamayan oturumlar listesine eklenmiş olabilir. Kullanıcı aniden giriş veya geri yükleme bildirimleri almış olabilir. Bazı durumlarda, tek bir belirgin olay değil, birkaç küçük belirtinin toplamı nedeniyle şüphe oluşabilir.

Bu durumda, ilk koruma adımını atmadan önce detaylı araştırma yapmak gerekmez. Bazen, öncelikle aktif erişimleri geçici olarak iptal etmek ve ardından detayları araştırmak daha akıllıca olur.

Burada MeldID, basit bir mantık izler: eğer hesap sahibi durumu tehlikeli görüyorsa ve güvenilir bir uygulama erişimi varsa, hemen koruma senaryosunu başlatabilmeli. Sistem, ilk önce saldırı kanıtını göstermesini istemez.

Neden sadece şifre değiştirmek yeterli olmayabilir?

Şifre, sadece bir giriş unsurudur. Bir yerde zaten aktif bir oturum veya token varsa, sadece şifre değişimi, önceki erişimleri geri çağırmak kadar etki etmez.

İşte bu yüzden, panik modu çok daha geniş çalışır. Sadece bir hesap parametresini değiştirmez; hesabı ayrı bir koruma durumuna geçirir.

Sıralama şu şekildedir:

1. Mevcut oturumlar ve tokenler iptal edilir;

2. Panik öncesi başlatılmış tamamlanmamış şifre değişiklikleri durdurulur;

3. Panik sırasında yapılan kurtarma talepleri, moddan çıktıktan sonra değişiklik yapamaz;

4. Hesabın panik moduna girdiği şifre aktif kalır;

5. Kullanıcıya mail, cihaz ve diğer potansiyel sorunları kontrol etme zamanı verilir;

6. Koruma modundan çıkıştan sonra, normal işleyiş devam eder veya yeni bir şifre değişikliği yapılır.

Bu, normal güvenlik mekanizmalarının yerine değil, aksiyon anında, güvensizlik durumunu geçici olarak yönetmek için ayrı bir acil planıdır.

Mobil uygulama, güvenilir nokta olarak

Yeni özellikler, MeldID’nin iPhone ve Android uygulamalarında bulunuyor. Bu yapıda, telefon artık sadece giriş cihazı değil, hesap güvenliği yönetiminde güvenilir bir nokta haline gelir.

Uygulama aracılığıyla:

• ertelenmiş şifre değişikliği onaylanabilir;

• şüpheli talep iptal edilebilir;

• panik modu aktif hale getirilebilir;

• farklı cihazlardaki aktif oturumlar durdurulabilir;

• hesabın sonraki durumu belirlenebilir.

Ancak, mobil uygulama TOTP’yu iptal etmez veya diğer koruma yollarını yerine geçmez. Sadece, normal girişin yetersiz olduğu durumlar için, ek bir kontrol kanalı ekler.

MeldID’nin güvenlik sınırı nerede?

Önemli olan, MeldID sisteminin güvenliği ile kullanıldığı ortamın güvenliğinin ayrılmasıdır.

MeldID, servisin geçerli şifreyi almaya yönelik normal bir kanal oluşturmasını engeller. Şifre, sistem tarafından üretilir, kullanıcı tarafından seçilmez ve e-posta ile iletilmez. Kurtarma da, mevcut şifreyi açığa çıkarmaz; yeni şifre oluşturma prosedürünü başlatır.

Ama kullanıcı, yine de, bilgilerini başkasına iletebilir veya uygun olmayan yerlerde kullanabilir.

Bir başka güvenlik seviyesi ise, cihazın ve işletim sisteminin güvenliğidir. Mobil uygulama, iOS ve Android’in koruma mekanizmaları içinde çalışır ve platformun güvenliğini tamamen yerine geçemez.

Bu nedenle, MeldID, kendi tarafında kontrollü olabilecek riskleri değerlendirir: giriş bilgisi üretimi, doğrulama, tokenlar, oturumlar, kurtarma ve kurtarma kanalının potansiyel ihlali durumları.

Girişten tepki verme aşamasına

MeldID ile ilk tanıştığımda, onu kimlik doğrulama ve profil yönetimi sistemleri olarak tanımlayabilmiştik. Mobil uygulamalar ve yeni koruma mekanizmaları çıktıktan sonra bu tanım çok dar kalmıştı.

Şimdi sistem, sadece "nasıl girilir?" sorusuna değil, daha karmaşık sorulara da yanıt veriyor:

• beklenmedik bir kurtarma girişiminde ne yapılmalı;

• uygulamaya erişimi olmadan hesabı nasıl kurtarırız;

• yeni şifre aktive edilmeden önce nasıl zaman tanırız;

• sahibi olmayan bir kurtarma talebi nasıl iptal edilir;

• aktif oturumlar nasıl geri çağrılır;

• saldırgan maili kullanarak şifre değiştirmesini nasıl engelleriz;

• dış kurtarma kanalını nasıl yeniden güvenilir hale getiririz;

• Tüm aktif erişimler durdurulduktan sonra kullanıcı verilerini nasıl koruruz;

• durumu kontrol edip normal işleyişe nasıl döneriz.

Sonuç olarak, koruma modeli katman katman ilerler.

Mevcut şifre, kurtarma kanalıyla iletilmez. E-posta erişimi kendi başına şifreyi açığa çıkarmaz, fakat yeni bir şifre oluşturmak için giriş yapılabilir. Bu nedenle, gecikmeli yapılır ve güvenilir uygulama ile iptal edilebilir.

Eğer bu da yeterli değilse, panik modu aktif erişimleri sonlandırır, tokenleri iptal eder ve tamamlanmamış kurtarmanın süresinden önce sonuç vermesini engeller.

Kullanıcı, olayın gerçek bir ihlal olduğunu tespit ederse, zaman kazanır: e-posta erişimini geri kazanabilir, cihazları kontrol edebilir ve durumu netleştirebilir. Yalnızca bundan sonra normal erişime dönebilir.

İşte bu nedenle, MeldID’de panik modu, basit bir "tümden çıkış" düğmesi değil, erişim durumunu yeniden güvenli hale getirmek için tasarlanmış, bağımsız bir müdahale senaryosudur.

Daha fazla bilgi için: meldid.de.