Son güncelleme: 2026-10-05
Bir veri ihlalinden sonra “Parolalar özetlenmişti” demek yeterli bir açıklama değildir. Sağlanan koruma; algoritmaya, yapılandırmasına, parolaların kendisine ve saldırganın neyi ele geçirdiğine bağlıdır.
Parola saklamak için doğrudan MD5 kullanılması özellikle kaygı vericidir: Bu yöntem, parola tahminlerinin düşük maliyetle denenmesine imkân tanır. Bir platform sağlayıcısıyla çalışan işletmelerin sorması gereken soru, sağlayıcının kimlik bilgilerinin nasıl korunduğunu ve güvenliği ihlal edilen hesapların nasıl yeniden güvenceye alınacağını kanıtlayıp kanıtlayamadığıdır.
Bambi Deri Mamülleri A.Ş. hakkında 30 Eylül 2026 tarihinde yayımlanan kamuoyu duyurusunda şu bilgiler yer alıyor:
Bu tahmin, parolası kırılmış kişi sayısını göstermez. MD5 ifadesi bu duyuruya özgüdür; eylül ayında yayımlanan diğer veri ihlali bildirimlerinde hangi algoritmaların kullanıldığını ortaya koymaz.
Duyuruda veri işleyenin adı, salt kullanılıp kullanılmadığı, MD5’in doğrudan mı yoksa başka bir yapının parçası olarak mı kullanıldığı, parola politikası, yönetici parolalarının saklanma yöntemi, özetlerin dışarı çıkarıldığının doğrulanıp doğrulanmadığı, parola sıfırlama talimatları veya etkilenen oturum ve kimlik doğrulama belirteçleri açıklanmıyor. Duyuru, devam eden bir incelemeyi aktarıyor; nihai bulgular veya bir yaptırım kararı içermiyor.
5 Ekim 2026 itibarıyla kamuya açık kaynaklarda yaptığımız incelemede, bu belirsizlikleri gideren ek bir veri sorumlusu açıklamasına veya nihai karara rastlamadık. Bu durum, müşterilere özel bildirim yapılıp yapılmadığını göstermez.
Bir parola saklama sistemi, parolanın kendisi yerine, girilen parolayı doğrulamak için kullanabileceği bir değer saklar. Giriş sırasında sistem, kayıtlı algoritmayı ve parametreleri girilen parolaya uygular ve sonucu karşılaştırır.
Özetleme işleminde, özgün parolayı geri getiren bir şifre çözme anahtarı yoktur. Ancak saldırgan, olası parolaları deneyebilir, bunların özetlerini hesaplayabilir ve eşleşme arayabilir. İnsanların seçtiği parolalar, rastgele üretilmiş gizli değerlere kıyasla genellikle daha kolay tahmin edilir.
Bu nedenle “tek yönlü”, “tahmin edilemez” anlamına gelmez.
Genel amaçlı kriptografik özet fonksiyonları, veriyi verimli biçimde işlemek için tasarlanır. Parola saklama ise art arda tahmin yürütmeyi maliyetli hâle getiren bir yöntem gerektirir. Doğrudan MD5 kullanımını tek bir SHA-256 hesaplamasıyla değiştirmek bu tasarım sorununu çözmez.
MD5’in ayrıca bilinen başka bir zayıflığı vardır: Çakışma direnci kırılmıştır. Çakışma, aynı özet değerini üreten iki farklı girdi bulunmasıdır. Bu, belirli bir kullanıcının parolasını elde etmekten farklıdır. Olağan parola tahmin saldırıları, MD5 çakışmalarından yararlanmayı gerektirmez; olası parolaların saklanan değere karşı denenmesine dayanır.
Dolayısıyla “MD5 çakışmaları saldırganların tüm parolaların şifresini çözmesini sağlar” demek, hem saldırı yöntemini hem de mevcut kanıtları yanlış aktarır.
Salt, parola özeti üretilirken kullanılan benzersiz ve rastgele bir değerdir. Sonuçla birlikte saklanabilir; amacı gizli tutulmak değildir.
Salt kullanılmadığında aynı yöntemle işlenen aynı parolalar aynı özetleri üretir ve saldırganlar önceden hesaplanmış sonuçları yeniden kullanabilir. Farklı salt değerleri, sonuçların hesaplar arasında bu şekilde doğrudan yeniden kullanılmasını ve karşılaştırılmasını engeller. Ancak zayıf bir parolayı güçlü hâle getirmez veya doğrudan MD5’i hesaplama maliyeti yeterince yüksek bir parola saklama fonksiyonuna dönüştürmez.
Bambi olayında salt kullanılıp kullanılmadığı açıklanmamıştır. Ne “MD5 kullanıldığına göre salt yoktu” ne de “belki salt vardı, dolayısıyla güvenliydi” sonucu mevcut bilgilerle desteklenir.
Saldırgan kullanılabilir parola doğrulama kayıtlarını ve gerekli parametreleri elde ettiğinde, tahminleri kendi donanımında deneyebilir. Web sitesindeki istek sınırlamaları ve hesap kilitleme kuralları, bu çevrimdışı hesaplamaları sınırlamaz.
Her parola mutlaka elde edilecek değildir. Sonuç; parolanın tahmin edilebilirliğine, saklama yöntemine, kullanılabilen hesaplama kaynaklarına ve doğrulama için gereken ek gizli değerlere bağlıdır. Yalnızca algoritmanın adı, veri kümesindeki tüm parolaların ne kadar sürede kırılacağına ilişkin güvenilir bir tahmin sağlamaz.
Elde edilen parola başka hizmetlerde de kullanılıyorsa saldırgan aynı e-posta ve parola çiftini bu hizmetlerde deneyebilir. Bu saldırıya “credential stuffing”, yani ele geçirilmiş kimlik bilgilerinin başka hizmetlerde denenmesi denir. Bu, önceki çevrimdışı parola tahmin aşamasından farklıdır.
Çok faktörlü kimlik doğrulama (MFA), hesapların ele geçirilmesi riskini azaltabilir; ancak çalınan bir parola özeti üzerinden tahmin yürütülmesini engellemez. Müşteriler, aynı parolayı kullandıkları diğer hesaplarda da parolalarını değiştirmeli ve her hesap için farklı bir parola kullanmalıdır. Bir parola yöneticisi bunu kolaylaştırır.
Bir müşteri hesabı ile platform yönetici hesabının sağladığı yetkiler çok farklı olabilir. Uygulamaya bağlı olarak yönetici erişimi, veri dışa aktarımına, hesap değişikliklerine veya entegrasyon yönetimine imkân verebilir.
Önerimiz; müşteri kimlik doğrulaması, satıcı yönetici hesapları, sağlayıcının destek erişimi ve servis hesapları için ayrı kanıt istemektir. Hangilerinin uygulamada saklanan parolaları kullandığını, hangilerinin bir kimlik sağlayıcısına dayandığını belirleyin. Ayrıcalıklı erişim için MFA zorunluluğu getirin ve bu hesapların hangi işlemleri yapabildiğini inceleyin.
Kullanıcı giriş bilgileri hakkındaki bir duyurudan, yönetici hesaplarının da etkilendiği veya aynı saklama algoritmasını kullandığı sonucunu çıkarmayın.
Yeni bir uygulamada, bakımı sürdürülen bir parola özetleme kütüphanesi kullanın ve desteklendiği durumlarda Argon2id’i tercih edin. Yerleşik alternatifler arasında scrypt bulunur; ilgili gereklilikler veya platform kısıtları söz konusu olduğunda PBKDF2 uygun olabilir. Mevcut bcrypt uygulamalarının yapılandırma ve geçiş açısından incelenmesi gerekir.
Argon2id, bellek ve hesaplama maliyetlerinin yapılandırılmasına imkân tanır. Bu ayarlar önemlidir: Amaç, meşru girişlerin doğrulanmasını operasyonel açıdan yönetilebilir tutarken parola tahminlerini maliyetli hâle getirmektir. Algoritmanın adı, uygulamanın bu dengeyi sağlayıp sağlamadığını göstermez.
Teknik ekipten kullanılan parametreleri belgelemesini ve hedef altyapıda eş zamanlı giriş yükünü test etmesini isteyin. Tek bir giriş için test edilen ayar, hizmetin yoğun trafiğe dayanabileceğinin kanıtı değildir.
Salt değerini yöneten, algoritmayı ve parametreleri parola doğrulama kaydıyla birlikte saklayan üst düzey bir doğrulama API’si kullanın. Uygulama kodunda geliştirilen özel birleştirme yöntemlerinden, tekrarlı özetlemeden veya belgelenmemiş kombinasyonlardan kaçının.
Planlı bir yükseltmede uygulama, meşru bir girişi eski yöntemle doğrulayıp girilen paroladan yeni bir doğrulama kaydı oluşturabilir. Kullanılmayan hesaplar için ayrı karar gerekir; bu hesaplar yükseltmeyi tetikleyecek bir giriş yapmayabilir.
Önerimiz, eski yöntemi kullanmaya devam eden hesapları takip etmek, geçişten sorumlu bir kişi belirlemek ve hangi noktada hesaba yeniden erişimden önce parola sıfırlamasının zorunlu olacağını tanımlamaktır. Zayıf parola doğrulama kayıtlarının açığa çıktığı bir olayda, normal girişleri beklemek yerine zorunlu sıfırlama gerekebilir.
Canlı veri tabanını güncellemek, saldırganın elindeki eski kopyanın korumasını güçlendirmez. Bu nedenle geçiş planında, mevcut parolaların kullanılmaya devam edilmesinin güvenli olup olmadığı ayrıca değerlendirilmelidir.
Takvime bağlı rutin parola değişiklikleri ile bir olay nedeniyle yapılan sıfırlamalar farklı amaçlara hizmet eder. Güncel teknik rehberler, böyle bir kanıt yokken periyodik değişiklik dayatmak yerine, güvenliğin ihlal edildiğine dair kanıt olduğunda değişiklik istenmesini destekler.
Uygulamaya yönelik önerimiz, inceleme sonucunda zayıf parola doğrulama kayıtlarının açığa çıktığı belirlendiğinde etkilenen hesaplar için sıfırlamayı zorunlu tutmaktır. Her parolanın elde edildiğinin kanıtlanmasını beklemeyin. Açığa çıkma durumu belirsizse mevcut kanıtları, kayıt tutma sınırlamalarını, hesap yetkilerini ve müdahaleyi geciktirmenin sonuçlarını belgeleyin.
Bu bir olay müdahalesi önerisidir; Bambi’nin veya Kurulun parola sıfırlama talimatı verdiği iddiası değildir.
Erişimi yeniden açmadan önce ihlali kontrol altına alın ve yeni parolaların uygun biçimde saklanacağından emin olun. Parola politikasını da gözden geçirin: Uzun parolalara ve parola yöneticilerine izin verin; yeni parolaları yaygın kullanılan veya ele geçirilmiş parolalara karşı kontrol edin. Karmaşıklık kuralları tek başına zayıf saklama yöntemini düzeltmez.
Tahmin edilemeyen, süreli ve tek kullanımlık sıfırlama belirteçleri kullanın. Sıfırlama sürecini otomatik kötüye kullanıma karşı koruyun ve başarılı değişiklikten sonra kullanıcıya bildirim yapın. Müşterileri bildikleri web sitesine veya uygulamaya yönlendirin; destek ekibine eski parolalarını vermelerini asla istemeyin.
Parola değişikliği mevcut oturumları mutlaka sonlandırmaz. Sonuç, uygulamanın nasıl geliştirildiğine bağlıdır.
Etkilenen hesaplarda etkin web oturumlarını, kalıcı “beni hatırla” erişimini ve mobil oturumları değerlendirin. İlgili oturumları sunucu tarafında geçersiz kılın ve yeniden kimlik doğrulama isteyin. Yalnızca tarayıcı çerezini silmek, oturum kimliğinin çalınmış bir kopyasını geçersiz kılmaz.
OAuth kullanılıyorsa yenileme belirteçlerinin iptalini ayrıca kontrol edin. Bir yenileme belirtecinin iptali, o belirteç üzerinden yeni erişim belirteçleri alınmasını engeller; daha önce verilmiş erişim belirteçlerinin nasıl reddedileceğini veya ne zaman sona ereceğini de belirleyin. Parola değişikliğinin, web oturumunu kapatmanın ve belirteç iptalinin aynı işlem olduğunu varsaymayın.
Hesabın ele geçirildiğinden şüpheleniliyorsa kurtarma adresleri, MFA yöntemleri ve güvenilir cihazlardaki değişiklikleri inceleyin. Saldırgan başka bir erişim yolu oluşturmuşsa parolanın değiştirilmesi hesabın kontrolünü geri almaya yetmeyebilir.
Önerimiz, kurtarma sürecini bir test hesabıyla göstermektir: İki cihazda oturum açın, olay müdahalesi kapsamında sıfırlama yapın ve eski oturumların ve ilgili belirteçlerin artık erişim sağlamadığını doğrulayın. Devam eden bir geçerlilik süresi varsa bunu ve bu süreyi kabul etme veya ortadan kaldırma kararını kaydedin.
İlk erişim yolu kapatılsa da kimlik bilgilerinin kötüye kullanılması devam edebilir. Başarılı ve başarısız girişleri, olağandışı cihazları, sıfırlama işlemlerini ve hassas hesap ayarlarındaki değişiklikleri inceleyin. Tanımadığınız bir IP adresini hesabın ele geçirildiğinin kanıtı saymak yerine olayları birlikte değerlendirin.
Uyarıları ve müşteri bildirimlerini inceleyecek bir sorumlu belirleyin; şüpheli hesapları güvenceye almak için izlenecek yolu tanımlayın. Doğrulanmış yetkisiz etkinliklerin yanı sıra tespit edilen ve engellenen girişimleri de takip edin. Başarısız giriş sayısının düşük olması güvenliği kanıtlamaz: Çalınmış geçerli bir parola ilk denemede çalışabilir.
İncelemeye yardımcı olacak olay kimliklerini ve zaman damgalarını saklayın; ancak parolaları veya kullanılabilir oturum ve erişim belirteçlerini izleme kayıtlarına yazmayın. Kayıtlara erişimi sınırlayın ve saklama süresini incelemenin ihtiyaçlarına ve geçerli gerekliliklere göre belirleyin.
Görünürlüğünüzün de bir sınırı vardır. Kendi kimlik doğrulama kayıtlarınız, bir müşterinin tekrar kullandığı parolanın başka bir şirketin hizmetinde kötüye kullanılıp kullanılmadığını genellikle gösteremez. Müşteri iletişimi, başka hizmetlerde de ihlal gerçekleştiğini iddia etmeden bu kalan riski açıklamalıdır.
E-ticaret veya SaaS hizmeti alan bir veri sorumlusu için “Parolalar özetleniyor” yanıtı, teknik incelemenin başlangıcı olmalıdır. Aşağıdaki liste önerilen kanıt talepleridir; her durumda kanunen zorunlu olan bir belge listesi değildir.
Hassas kanıtları, üzerinde mutabık kalınan güvenli bir kanal üzerinden inceleyin. Kanıt yokluğunu olumlu bir yanıt saymak yerine, yanıtlanmamış soruları bir sorumlu ve takip tarihi belirleyerek eksik olarak kaydedin.
Sağlayıcının işe yarar bir yanıtı, kullanılan saklama yöntemini, eski korumayı kullanmaya devam eden hesapları ve test edilmiş kurtarma işlemlerini açıklar. İşletme, iyileştirme ve olay müdahalesi kararlarını bu bilgiler üzerine kurabilir.
Tedarikçinizin yanıtı “özetlenmiş” demekle sınırlı kalıyorsa bu kanıtları isteyin. Kooch’un KVKK ve GDPR Gap Analizi hizmeti, mutabık kalınan kapsamda tedarikçi ve güvenlik kanıtlarını inceleyerek belirlenen eksikleri, önerilen sorumlular ve bağımlılıklarla birlikte önceliklendirilmiş bir iyileştirme planına dönüştürebilir.
Bu yazıda olaya ilişkin bilgiler ile teknik öneriler birbirinden ayrılmıştır. Aşağıdaki teknik kaynaklar rehber ve teknik şartname niteliğindedir; Türk hukukunun belirli algoritmalara ilişkin zorunlulukları olarak sunulmamaktadır.
Kamuya açık ek açıklamalara yönelik kontrollerde, yeni resmî duyurular için yapılan hedefli aramaların yanı sıra Bambi’nin web sitesi, KVKK sayfası ve gizlilik ve güvenlik sayfası da incelenmiştir. Kamuya açık kaynakların incelenmesi, müşterilere özel bildirimlerin içeriğini ortaya koyamaz.
