Bayinin Şifresi Zaten Sızmış: E-pin Scriptinde Kimsenin Konuşmadığı Şifre Politikası Açığını Böyle Kapatıyorsun

Çoğu e-pin satıcısı şifre güvenliğini bir onay kutusu meselesi sanır. Panele "en az 8 karakter, bir büyük harf, bir sayı" kuralını koyar, yanına yeşil bir tik çıkar ve konu kapanır. Oysa sahada yaşanan hesap ele geçirmelerinin büyük kısmı zayıf şifreden değil, başka bir sitede sızmış şifrenin senin panelinde aynen kullanılmasından doğuyor. Bayin "Kaan.2019!" şifresini üç yıl önce bir forumda kullandı, o forum hacklendi, veri satıldı ve şimdi aynı dizeyi senin bayi girişinde deniyorlar. Karmaşıklık kuralını da fazlasıyla geçiyor.

Bu yazıda, bir e-pin satış scripti üzerinde şifre politikasının gerçekte ne anlama geldiğini; sızmış şifre kontrolünün nasıl yapıldığını, hangi hash algoritmasının artık kabul edilemez olduğunu ve bakiye taşıyan bir panelde parola sıfırlama akışının neden en zayıf halka olduğunu tek tek açıyoruz. Pinova gibi lisanslı bir dijital ürün satış yazılımı kullanıyorsan bu kontrollerin çoğu hazır gelir; kendi kodunu yazıyorsan listeyi elle kapatman gerekir. Her iki durumda da bilmen gereken şey aynı.

Karmaşıklık kuralları neden seni koruyamıyor?

Karmaşıklık kuralı, insanın tahmin edilebilirliğini hesaba katmaz. Bir kullanıcıya "büyük harf, sayı ve özel karakter koy" dediğinde ortaya çıkan şey neredeyse her zaman aynı kalıptır: baş harf büyük, sonuna yıl, en sona ünlem. Saldırgan bunu bilir. Kullandığı sözlükler senin kuralını zaten karşılayan milyonlarca varyasyon üretir. Yani kuralı sıkılaştırdıkça kullanıcıyı daha tahmin edilebilir bir kalıba itiyorsun.

Asıl ölçüt uzunluk ve daha önce sızmış olmama durumudur. 16 karakterlik üç kelimelik bir Türkçe cümle, 9 karakterlik simge çorbasından kat kat güçlüdür ve kullanıcı onu yazabilir. Bu yüzden modern bir e-pin yazılımı kurulumunda yapman gereken ilk değişiklik, minimum uzunluğu 12'ye çekip zorunlu özel karakter şartını kaldırmak, yerine sızma listesi kontrolünü koymaktır. Kullanıcı deneyimi iyileşir, güvenlik ölçülebilir biçimde artar.

Sızmış şifre kontrolü pratikte nasıl çalışır?

Korkulan senaryo şudur: kontrol yapmak için kullanıcının şifresini bir dış servise göndermek. Bunu asla yapmıyorsun. Doğru yöntem k-anonimlik denen yaklaşımdır. Şifrenin SHA-1 özetini alırsın, bu özetin yalnızca ilk beş karakterini sorgularsın, servis o önekle başlayan bütün hash kuyruklarını sana döner, eşleşmeyi kendi sunucunda ararsın. Ne şifre ne de tam hash ağdan çıkar. Bir talep yaklaşık 600 satırlık bir yanıt getirir ve 100 milisaniyenin altında sonuçlanır.

Bu kontrolü üç noktada tetiklemelisin: kayıt, şifre değişimi ve başarılı girişten sonraki arka plan taraması. Üçüncüsü en kıymetlisidir; çünkü bugün temiz olan bir şifre yarın sızabilir. Girişten sonra sessizce kontrol eder, eşleşme varsa bayiye bir sonraki oturumda zorunlu değişim ekranı gösterirsin. Sipariş akışını hiç kesmeden riski kapatmış olursun. Bakiyeli bir panelde bu davranış, şifre kuralından çok daha fazla iş görür.

Veritabanındaki hash'ler hâlâ MD5 mi?

Devraldığın eski kurulumlarda en sık gördüğümüz şey budur: md5($sifre) ya da tuzsuz SHA-1. Bu, veritabanı bir gün sızarsa bütün bayi şifrelerinin dakikalar içinde açık metne dönmesi demektir. Ve bayilerin çoğu aynı şifreyi e-postasında da kullanıyordur; yani zararı senin sistemini aşar, ticari itibarına dokunur.

Geçiş için sistemi kapatmana gerek yok. Tembel yeniden hash'leme uygularsın: kullanıcı giriş yaptığında eski algoritmayla doğrulama yapar, doğruysa aynı istekte şifreyi Argon2id ya da bcrypt ile yeniden yazarsın. Birkaç hafta içinde aktif kullanıcıların tamamı yeni algoritmaya taşınır; kalan uykudaki hesaplara zorunlu sıfırlama gönderirsin. Bu, iyi yazılmış her dijital ürün satış scripti için standart bir olgunluk işaretidir ve Pinova'da doğrulama katmanı bunu kutudan çıktığı gibi yapar.

Parola sıfırlama akışı en büyük arka kapı mı?

Şifre politikasını kusursuz yapıp sıfırlama akışını açık bırakmak, kapıyı çelikleştirip pencereyi aralık bırakmaktır. Sahada gördüğümüz klasik hatalar: tahmin edilebilir token üretimi, süresiz geçerli bağlantı, tokenin bir kez kullanıldıktan sonra iptal edilmemesi ve en kötüsü, "bu e-posta kayıtlı değil" gibi hesap varlığını sızdıran mesajlar.

Doğrusu şudur: kriptografik güvenli üretilmiş en az 32 baytlık token, veritabanında hash'lenmiş olarak saklanır, 30 dakika ömrü vardır, tek kullanımlıktır ve kullanıldığı anda o hesabın bütün aktif oturumları düşürülür. Yanıt mesajı ise e-posta kayıtlı olsun ya da olmasın birebir aynı kalır. Sıfırlama talebi hem IP hem hesap bazında saatlik sınırlanır. Bu beş maddeyi kapattığında, panelinin en çok istismar edilen yüzeyini kapatmış olursun.

Deneme-yanılma saldırısını nasıl sessizce boğuyorsun?

Kimlik bilgisi doldurma saldırıları tek hesaba yüz deneme yapmaz; yüz hesaba birer deneme yapar. Bu yüzden "5 hatalı girişte hesabı kilitle" kuralı bu saldırıyı hiç görmez, üstüne bir de rakibinin bayilerini toplu kilitleyerek sana hizmet kesintisi yaşatmasına izin verir. İhtiyacın olan ölçüm hesap değil, kaynak bazlı olmalı.

Pratik reçete: IP ve IP bloğu başına dakikada başarısız giriş sayacı, aynı tarayıcı parmak izinden gelen çoklu kullanıcı adı denemesine artan gecikme, eşik aşıldığında kilit değil yavaşlatma ve doğrulama devreye alma. Bir de kullanıcı adı hatasıyla şifre hatasında aynı süreyi harcadığından emin ol; aksi halde yanıt süresi farkı üzerinden geçerli hesapları listeleyebilirler. Bunları düzgün kurgulayan bir e-pin scripti, saldırganı fark ettirmeden ekonomik olarak verimsiz bir hedefe çevirir.

Bayilerini nasıl ikna edersin?

Güvenlik kuralı, satışı yavaşlattığı anda bayi tarafından sabote edilir. O yüzden dili değiştir: "zorunlu kural" değil, "paran korunuyor" çerçevesi kur. Panelde her bayiye kendi güvenlik skorunu göster; şifresinin sızma listesinde olup olmadığını, son değişim tarihini, açık oturumlarını ve tanımadığı cihazları tek ekranda sun. İnsanlar soyut riske değil, kendi verisine tepki verir.

İkinci hamle kademeli uygulamadır. Yeni kayıtlara kuralı bugünden uygula, mevcut bayilere 30 günlük geçiş ver, bakiye eşiğini aşan hesaplarda ise süre tanımadan zorla. Böylece riskli azınlığı hızlı kapatır, çoğunluğu kırmadan taşırsın. İyi bir e-pin satış yazılımı bu kademeleri yönetici panelinden ayarlanabilir kılmalı; her kuralı koda gömmek zorunda kalıyorsan yazılımın seni yavaşlatıyor demektir.

Şifre katmanı, e-pin işinde görünmeyen ama en pahalı arızayı üreten yerdir: tek bir bayi hesabı ele geçtiğinde kaybettiğin şey bakiye değil, güvendir. Yukarıdaki on maddeyi kendi kurulumunda tek tek işaretle; hangilerinin hazır geldiğini görmek istersen özellik listesine ve fiyatlandırmaya göz at, sonra bu kontrollerin panel içinde nasıl göründüğünü canlı demo üzerinden kendi gözünle dene.