İki Faktörlü Doğrulama: Sitenizde Kurmak ve Yönetmek
Kullanıcı şifresi çalındı ve hesabı ele geçirildi. Şifre güçlüydü, sızıntı sizden kaynaklanmadı — kullanıcı aynı şifreyi başka bir sitede kullanmıştı. Tek başına şifre, hesap güvenliği için artık yeterli bir savunma değildir.
Bu yazı, ikinci doğrulama katmanının kurulumunu ele alıyor.
Neden Gerekli
| Tehdit | Şifre yeterli mi |
|---|---|
| Başka siteden sızan şifre | Hayır |
| Kimlik avı | Hayır |
| Kaba kuvvet denemesi | Kısmen |
| Zararlı yazılım | Hayır |
Birinci satır en yaygın gerçek senaryodur: kullanıcıların büyük kısmı aynı şifreyi birden fazla sitede kullanır — başka bir sitede yaşanan sızıntı, sizin sitenizde de hesapların ele geçirilmesine yol açar ve sizin hiçbir hatanız yoktur.
Bu saldırılar otomatik araçlarla yapılır.
Sızan listeler tek tek denenir.
İkinci katman bu denemeleri tamamen etkisiz kılar.
Yöntemler
- Uygulama tabanlı tek kullanımlık kod.
- E-posta ile gönderilen kod.
- Kısa mesaj ile gönderilen kod.
- Donanım anahtarı.
Birinci madde çoğu site için en iyi dengedir: telefondaki bir doğrulayıcı uygulamanın ürettiği kod internet bağlantısı bile gerektirmez, ücretsizdir ve araya girme riski kısa mesajdan çok daha düşüktür.
Kısa mesaj yöntemi hem maliyetli hem daha zayıftır.
Numara taşıma saldırıları bilinen bir risktir.
Dördüncü madde en güçlüsüdür ama kullanıcı için ek maliyet demektir.
Uygulama Kodları Nasıl Çalışır
- Sunucu bir gizli anahtar üretir.
- Kullanıcı bunu uygulamasına ekler.
- İki taraf aynı algoritmayı çalıştırır.
- Kod zamana göre değişir.
Üçüncü adım tasarımın zarafetidir: kod sunucudan telefona gönderilmez — iki taraf aynı gizli anahtar ve saatle aynı kodu bağımsız olarak hesaplar, bu yüzden araya girip yakalanacak bir iletim yoktur.
Dördüncü madde ise kodun kısa ömrünü açıklar.
Genellikle otuz saniyede bir yenilenir.
Bu, çalınan bir kodun kullanım penceresini daraltır.
Saat Kayması
| Durum | Sonuç |
|---|---|
| Saatler uyumlu | Kod kabul edilir |
| Sunucu saati kaymış | Tüm kodlar reddedilir |
| Telefon saati kaymış | O kullanıcı giremez |
İkinci satır ciddi bir kesinti üretir: sunucu saatinin kayması, tüm kullanıcıların doğrulama kodlarının reddedilmesine yol açar — kimse giriş yapamaz ve neden anlaşılamaz çünkü şifreler doğrudur.
Bu nedenle zaman senkronizasyonu zorunludur.
Doğrulamada küçük bir tolerans penceresi tanınmalıdır.
Bir önceki ve sonraki kod da kabul edilebilir.
Kurtarma Kodları
- Kurulumda üretilir.
- Kullanıcı bunları saklamalıdır.
- Her biri tek kullanımlıktır.
İkinci madde göz ardı edilirse destek yükü patlar: telefonunu kaybeden ve kurtarma kodu olmayan bir kullanıcı hesabına giremez — kurtarma kodları olmadan tek yol, kimlik doğrulaması yaparak manuel sıfırlamadır.
Bu süreç hem yavaş hem risklidir.
Kodlar kurulum ekranında indirilebilir sunulmalıdır.
Veritabanında özetlenerek saklanmalıdır.
Zorunlu mu, İsteğe Bağlı mı
- Yöneticiler için zorunlu.
- Ödeme yetkisi olanlar için zorunlu.
- Sıradan kullanıcılar için isteğe bağlı.
Birinci madde tartışmasızdır: yönetim paneline erişen hesaplarda ikinci katman zorunlu olmalıdır — tek bir yönetici hesabının ele geçirilmesi tüm siteyi ve tüm kullanıcı verisini riske atar.
Bu hesaplar en değerli hedeflerdir.
Üçüncü madde ise dönüşüm kaygısını dengeler.
Zorunlu kılmak bazı kullanıcıları kaybettirebilir.
Teşvik etmek daha iyi bir yaklaşımdır.
Nerede Sorulmalı
| Nokta | Doğrulama |
|---|---|
| Her girişte | Temel kural |
| Şifre değiştirirken | Ek doğrulama |
| Yeni cihazda | Mutlaka |
| Bilinen cihazda | Hatırlanabilir |
Dördüncü satır kullanım kolaylığı sağlar: kullanıcının onayladığı bir cihazı belirli bir süre hatırlamak, her girişte kod istemenin yarattığı yorgunluğu azaltır — bu, ikinci katmanın benimsenme oranını belirgin biçimde artırır.
Hatırlama süresi makul tutulmalıdır.
Kullanıcı bu cihazları listeleyip kaldırabilmelidir.
Şifre değişiminde tüm hatırlanan cihazlar sıfırlanmalıdır.
Sık Yapılan Hatalar
- Kodu deneme sayısı sınırlanmaz.
- Kod tekrar kullanılabilir kalır.
- Gizli anahtar düz saklanır.
İkinci madde koruma değerini düşürür: kullanılmış bir doğrulama kodunun tekrar kabul edilmesi, o kodu ele geçiren birinin pencere süresi boyunca giriş yapabilmesi demektir — her kod bir kez kullanılıp geçersiz kılınmalıdır.
Birinci madde ise kaba kuvvet denemesine kapı açar.
Altı haneli bir kod sınırsız denemede kırılabilir.
Üçüncü madde ise veritabanı sızıntısında tüm korumayı yok eder.
Kullanıcı hesaplarını koruyan ayarları yapılandırabilmek için sunucu erişimi gerekir; Linux hosting çözümleri ile oturum ve güvenlik ayarlarınızı kendiniz yönetebilirsiniz.
Sonuç
Şifre tek başına yeterli değildir çünkü başka bir sitede yaşanan sızıntı sizin sitenizde de hesapların ele geçirilmesine yol açar. Uygulama tabanlı kodlar çoğu site için en iyi dengedir. Kurulumda kurtarma kodu verin, sunucu saatini senkronize tutun — saat kayması tüm kullanıcıların kodlarının reddedilmesine yol açar — ve yönetici hesaplarında ikinci katmanı zorunlu kılın.
Sıkça Sorulan Sorular (SSS)
Güçlü şifre yeterli değil mi?
Değil. Kullanıcıların büyük kısmı aynı şifreyi birden fazla sitede kullanır; başka bir sitedeki sızıntı sizin sitenizde de hesapların ele geçirilmesine yol açar ve sizin hiçbir hatanız olmaz. Bu saldırılar sızan listelerle otomatik yapılır.
Hangi yöntemi seçmeliyim?
Uygulama tabanlı kodlar çoğu site için en iyi dengedir: internet bağlantısı gerektirmez, ücretsizdir ve araya girme riski kısa mesajdan çok daha düşüktür. Kısa mesaj hem maliyetli hem daha zayıftır; numara taşıma saldırıları bilinen bir risktir.
Kodlar neden birden reddedilmeye başladı?
Sunucu saati kaymış olabilir. İki taraf aynı gizli anahtar ve saatle kodu bağımsız hesapladığı için saat kayması tüm kullanıcıların kodlarının reddedilmesine yol açar; şifreler doğru olduğu için neden anlaşılamaz. Zaman senkronizasyonunu kontrol edin.
Kullanıcı telefonunu kaybederse?
Kurulumda verilen kurtarma kodlarıyla girer. Bu kodlar yoksa tek yol, kimlik doğrulaması yaparak manuel sıfırlamadır; hem yavaş hem risklidir. Kodları kurulum ekranında indirilebilir sunun ve veritabanında özetleyerek saklayın.
