Arka kapısı olmayan güvenli kullanıcı hesabı kurtarma

Kullanıcı arar veya bir talep bırakır: "Telefonumu değiştirdim, iki adımlı doğrulama kodu gelmiyor, hesabımı açın." Siz panelin arkasında oturuyorsunuz ve birkaç dakika içinde karar vermeniz gerekiyor. Tam da bu anda, kullanıcı hesabı kurtarma yolunuzun tasarlanmış mı yoksa herhangi birinin bir e-postayla kötüye kullanabileceği bir "yönetici tarafından sıfırla" düğmesi mi olduğu ortaya çıkar. Eğer o düğme kuralsızsa, 2FA için harcadığınız tüm emek sıfırlanır; saldırganın kodu kırmasına gerek yok, sadece desteği ikna etmesi yeter.

Kullanıcı hesabı kurtarma yolu neden 2FA'nın zayıf noktasıdır

İki adımlı doğrulama, ikinci faktörün (telefon, TOTP uygulaması, donanım anahtarı) kullanıcının elinde olduğunu varsayar. Ancak her kurtarma sistemi bu varsayım üzerine bir istisna inşa eder: "İkinci faktör yoksa ne yapacağız?" Ve saldırgan tam da bu istisna üzerinde çalışır. Güvenlik literatüründe bu saldırıya MFA fatigue veya iki adımlı yorgunluk denir; yani şifreyi kırmak yerine destek insanı üzerinde baskı kurulur.

Pratikte üç başarısızlık modelini çok gördüm:

• Yedek e-posta ile sıfırlama: Kullanıcı kurtarma e-postasını yıllar önce kaydetmiştir ve aynı e-posta veri sızıntılarında açığa çıkmıştır. Saldırgan o e-postayla kurtarma talebi gönderir ve kod kendi gelen kutusuna düşer.
• Telefon numarası ile sıfırlama: Numarayı kullanıcı profilinden okuyorsanız ve numara doğrulanmamışsa, saldırgan kendi numarasını kaydeder ve ardından kurtarma başlatır.
• Yönetici tarafından manuel sıfırlama: En kötü durum. Yorgun bir operatör, sabah 3'te, kullanıcı panelinden sahte bir ekran görüntüsüyle şifreyi değiştirir.

Çoğu kişinin gözden kaçırdığı nokta şudur: kullanıcı hesabı kurtarma bir kimlik doğrulama yoludur, bir destek süreci değil. Tıpkı giriş gibi günlüğü olmalı, hız sınırı olmalı ve denetlenebilir olmalıdır. Denetim günlüğünüz yalnızca "başarılı giriş"i kaydediyor da "yönetici tarafından şifre sıfırlama"yı kaydetmiyorsa, aslında körsünüz. Denetim günlüğü nedir ve onu nasıl bozulmadan koruruz? yazısında hangi alanları kaydetmeniz gerektiği ve günlüğü operatör müdahalesinden nasıl koruyacağınız hakkında ayrıntılı yazdım.

Kurtarma kodu: nasıl saklanır ve nasıl geçersiz kılınır

Kurtarma kodu (recovery code) tıpkı şifre gibi tek kullanımlık ve hash'lenmiş olarak saklanmalıdır. Kodu recovery_code sütununda plaintext olarak tutuyorsanız, basit bir SQL Injection tüm hesapları açar. Doğru model şudur:

-- Önerilen yapı
CREATE TABLE recovery_codes (
  id BIGINT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  code_hash CHAR(60) NOT NULL,      -- bcrypt
  used_at DATETIME NULL,
  created_at DATETIME NOT NULL,
  INDEX idx_user (user_id)
);

Üretim sırasında kodu bcrypt veya argon2id ile hash'leyin ve kullanıcıya yalnızca bir kez gösterin. Kod sayısını sınırlayın; on kod yeterlidir. Kullanılan her kodun used_at alanı doldurulmalı ve artık kullanılamamalıdır. Kullanıcı tüm kodları kaybederse, yol otomatik sıfırlamaya değil, insan kimlik doğrulamasına gitmelidir.

Yaygın bir tuzak: "kod uzun" diye kurtarma kodunu md5 veya sha1 ile hash'lerler. Kodun uzunluğunun hash güvenliğiyle ilgisi yoktur. Kurtarma kodu genellikle 16 karakterdir ve arama uzayı küçüktür; salt olmadan ve yavaş bir algoritma olmadan bir GPU ile birkaç saat içinde kırılır.

Burada hata yapıyorlar

Çok gördüğüm gerçek hata: güvenlik ekibi kurtarma kodunu doğru uygular, ancak giriş formuna doğrudan e-postayla şifreyi değiştiren ve 2FA'yı atlayan bir "şifremi unuttum" seçeneği koyar. Yani 2FA'sı olan bir kullanıcı, "şifremi unuttum"a tıklayıp e-postaya erişerek iki adımlı doğrulama kodu olmadan giriş yapar. İşareti de şudur: günlüklerde 2FA'sı etkin kullanıcıların bazen iki adımlı doğrulama olayı kaydedilmeden giriş yaptığını görürsünüz. Bunu görürseniz, bilin ki 2FA'nız süslemedir.

Destek kimlik doğrulaması: neyin taklit edilmesi mümkün değildir

Kullanıcı tüm yolları kapattığında, son savunma hattı insan kimlik doğrulamasıdır. Burada veri sızıntılarında bulunmayan sorular sormalısınız. Doğum tarihi, ulusal kimlik numarası, kartın son dört hanesi ve anne adı, hepsi İran sızıntılarında defalarca görülmüştür ve kanıt değeri yoktur.

Gerçekten işe yarayan sorular, saldırganın erişimi olmayan sistem içi verilerden gelir:

1. Hesaba son başarılı giriş tarihi (birkaç gün farkla kabul edilebilir).
2. Kullanıcının oluşturduğu iki alan adı veya iki projenin adı, panelde gösterilmeden.
3. Ödenen son fatura tutarı ve ödeme yöntemi.
4. Yalnızca iç günlükte bulunan yakın tarihli bir olay, örneğin "belirli bir tarihte DNS değişikliği".

Kullanıcı bunlara cevap veremiyorsa, kurtarmayı reddedin. Evet, gerçek bir müşteri memnuniyetsiz olabilir. Ancak çalınmış bir hesabın maliyeti, memnuniyetsiz bir talepten çok daha fazladır. Burada tavır almanız gereken yerdir, "bu seferlik açalım" diyerek işin içinden sıyrılmak değil.

Hız sınırı ve kademeli kilitleme

Hız sınırı olmayan kurtarma yolu, şifre test etmek için bir oracle'dır. En azından şunları uygulayın:

Üçüncü maddeyi ciddiye alın. Bir operatör kullanıcıların şifrelerini sonsuz kez sıfırlayabiliyorsa, insan bir arka kapı yaratmışsınız demektir. Dört göz kuralı (four-eyes) burada pahalı değildir; sadece ek bir onaydır.

Kullanıcı gerçekten erişimini kaybettiğinde

Zor durum: kullanıcının ne kurtarma kodu var, ne e-postaya erişimi var, ne de numaraya. Burada iki seçeneğiniz var. Birincisi, insan kimlik doğrulamasıyla ve günlüğe tam kayıtla tam kurtarma. İkincisi, reddetmek ve kullanıcının kendi verisini taşıyarak yeni hesap oluşturmasını önermek. Ben birincisini seçerim, ancak yalnızca denetim günlüğü bozulmamış ve değiştirilemezse ve iki kişi onayı zorunluysa. Bu iki koşul yoksa, ikincisini seçin; risk daha düşüktür.

Pratik bir not: kendi altyapınız üzerinde hizmet veriyorsanız, bu işin bir kısmı ağ katmanına döner. Kurtarma yolunu hedefleyen credential stuffing saldırıları genellikle belirli birkaç IP'den gelir ve DDoS koruması ve ağ kenarında hız filtrelemesiyle kontrol altına alınabilir. Ayrıca isteklerin nereden geldiğini incelemek için DNS ve ağ inceleme araçları, trafiğin belirli bir ASN'den gelip gelmediğini anlamanıza yardımcı olur.

Bugün değiştirmeniz gerekenler

Yalnızca bir şey yapabiliyorsanız, şu olsun: ikinci faktör olmadan şifreyi değiştiren her yol ya kaldırılmalı ya da zorunlu günlükle insan kimlik doğrulamasının arkasına alınmalıdır. Ardından kurtarma kodlarını hash'leyin ve hız sınırı koyun. Ekibiniz hâlâ ortak şifreyle çalışıyorsa, önce Ekiplerde şifre yönetimi yazısını okuyun; çünkü hesap kurtarma, şifreler baştan doğru yönetildiğinde anlam kazanır.

Ve WordPress üzerinde çalışıyorsanız, REST API'nin çoğu zaman gayri resmi bir kurtarma yolu olduğunu unutmayın. WordPress REST API güvenliği yazısında kullanıcı listesi sızıntısını nasıl önleyeceğinizi açıkladım, çünkü o liste kurtarma yoluna saldırının başlangıç noktasıdır.

Sık sorulan sorular

Kurtarma kodu hash'lenmeli mi yoksa şifrelenmeli mi?

Hash'lenmeli ve bcrypt veya argon2id gibi yavaş bir türle. Şifreleme yalnızca kodu kullanıcıya yeniden göstermek istediğinizde gerekir ki kurtarma kodu için bunu kesinlikle yapmamalısınız. Kod tek kullanımlıktır ve ilk gösterimden sonra artık okunmasına gerek yoktur.

Kaç kurtarma kodu yeterlidir?

On kod yeterlidir. Bundan fazlası, gerçek bir fayda olmadan saldırı yüzeyini büyütür. Sayıdan daha önemlisi, her kodun yalnızca bir kez kullanılabilmesi ve beş yanlış denemeden sonra tüm kodların geçersiz kılınmasıdır.

Kullanıcının e-posta ve numaraya erişimi yoksa ne yapmalıyız?

İç sorularla insan kimlik doğrulaması kullanmalı ve tüm süreci denetim günlüğüne kaydetmelisiniz. İki kişi onayı imkânınız yoksa, kurtarmayı reddetmek ve kullanıcıya yeni hesap oluşturup verisini taşımasını söylemek daha iyidir.

Kurtarma tamamen otomatikleştirilebilir mi?

Hayır, ciddi bir 2FA istiyorsanız. Her otomatik kurtarma, 2FA üzerinde bir istisnadır ve saldırgan tam da bunun üzerinde çalışır. Otomatik kurtarma yalnızca başka bir ikinci faktör (örneğin yedek donanım anahtarı) mevcutsa kabul edilebilir.

Hizmetinizin alt katmanlarının istikrarlı durumda olduğundan emin olmak istiyorsanız, hizmetlerin anlık durumunu kontrol edin ve teknik ayrıntılar için dokümantasyon ve bilgi tabanına göz atın. Bu kontrolleri baştan doğru kurmak isteyen ekipler için ServerNet güvenlik hizmetleri mantıklı bir başlangıç noktasıdır.