Güvenlikte Tuzlama Nedir? Parola Karma Algoritması Açıklaması

Haziran 2012'de bir saldırgan, 117 milyon LinkedIn hesap kaydını bir Rus forumuna sızdırdı. Liste, tuzlanmamış SHA-1 özetlerinden oluşan bir duvar gibiydi. SHA-1 hızlıdır. Aynı şifreleri ayırmak için tuz kullanılmadığı için, aynı özet binlerce kez yan yana geldi. Yaklaşık yetmiş iki saat içinde, güvenlik araştırmacıları dosyanın yaklaşık yüzde doksanını kırmıştı. Mayıs 2016'da 167 milyon kayıtlık bir veri kümesinin parçası olarak ihlal yeniden ortaya çıktığında, bu kimlik bilgileri yıllarca süren kimlik bilgisi hırsızlığı kampanyalarına kaynak sağladı.

Bu güvenlik açığını önemsiz bir ayrıntı haline getirecek savunma yöntemi - her saklanan parolaya tuz eklemek - 1979'da zaten mevcuttu. Buna tuzlama denir. Yeni değil, pahalı değil ve özellikle zekice de değil. Bu, bir veritabanı sızıntısının kontrol altına alınmış bir olay olmasından, yarım on yıl boyunca herkesin parola sorunu haline gelmesine kadar olan farkı yaratır.

Günümüzdeki parola saklama hatalarının çoğu hala aynı temel nedenden kaynaklanıyor: Birileri "SHA-256 kullanıyoruz"un yeterli olduğuna karar verdi. Bu makale, tuzlama işleminin ne olduğunu, pratikte nasıl çalıştığını, neleri koruyup korumadığını ve OWASP'ın 2026 varsayılanı olarak ne önerdiğini ele alıyor.

Güvenlikte ve parola karma algoritmalarında tuzlama nedir?

Konuyu tek bir cümleye indirgeyelim. Tuzlama, bir parolanın karma işlemine tabi tutulmadan önce ona rastgele veri eklemek anlamına gelir. Rastgele değer (tuz), her hesap için bir kez, yeni parola karmasıyla birlikte oluşturulur, elde edilen karmanın yanında açık bir şekilde saklanır ve her giriş yapıldığında tekrar okunur. Bu bir anahtar değildir. Bir sır değildir. Şifreleme değildir. Tam olarak tek bir görevi olan herkese açık bir değiştiricidir: İki kullanıcının aynı parolaya sahip olması durumunda, asla aynı saklanmış karma parolayı paylaşmamalarını sağlamak.

Tek başına karma işlemi tek yönlüdür. Bir parolayı SHA-256 veya Argon2id'den geçirdiğinizde, hiçbir algoritmanın tersine çeviremeyeceği sabit uzunlukta bir değer elde edersiniz. Buradaki püf nokta, "hiçbir algoritma" ifadesinin ucuz bir kısayolu dışlamasıdır: karma değerini önceden hesaplanmış bir sözlükte aramak. Tuzlama bu kısayolu ortadan kaldırır. Karma işlemine tuz eklemek, temel parola metni kelimesi kelimesine aynı olsa bile, her kullanıcı için benzersiz bir karma değeri oluşturur. "Password" ve "qwerty" gibi yaygın parolalar artık veritabanında çakışmaz. Tuzlama, bir satırın sızdırılmasının saldırgana başka hiç kimse hakkında hiçbir şey söylememesini sağlar.

Kullanılabilir bir tuzu işe yaramaz bir tuzdan ayıran üç kural vardır. Birinci kural: Her parola, kullanıcı kaydolduğunda veya sıfırladığında yeniden oluşturulan kendi rastgele tuzuna sahip olur. Hesaplar arasında tekrar kullanılan tuzlu bir parola, tuzsuz bir paroladan pek de farklı değildir; toplu saldırı aynı şekilde çalışır. İkinci kural: Tuz herkese açık olabilir. Tuzu tek başına bilmek, saldırgana altta yatan karma fonksiyonuna karşı hiçbir kısayol sağlamaz. Bu nedenle tuz, karma fonksiyonunun yanında veritabanında bulunur ve bu yerleşim uygundur, hatta teşvik edilir. Üçüncü kural: Tuz değerleri, kriptografik olarak güvenli bir sözde rastgele sayı üretecisinden gelir. Linux, `getrandom(2)` aracılığıyla bunu sunar. Node buna `crypto.randomBytes` der. Python'ın standart kütüphanesi bunu `secrets.token_bytes` içine sarar. Kriptografik olmayan `Math.random()` uygun değildir, ancak gerçek denetlenmiş kodda olması gerekenden çok daha sık görünür.

"Hunter2" şifresini seçen iki kişinin, saklanan hash değerlerinin tamamen farklı olması gerekir. Tuzlama (salting) bunu mümkün kılar. Tuzlamayı atlarsanız, veritabanı yalnızca hash değerlerini değil, kimin hangi şifreyi kiminle paylaştığına dair sosyal grafiği de sızdırır.

Parola tuzlama nasıl çalışır?

Bu mekanizma dört adımdan oluşuyor ve on yıllık parola saklama ihlalleri, neredeyse her hatanın birilerinin bu adımlardan birini atlamasından kaynaklandığını gösteriyor.

Birinci adım kayıt sırasında çalışır. Uygulama, bir CSPRNG'den on altı ila otuz iki arasında rastgele bayt ister. Bu, tuzdur. OWASP'ın 2025 kılavuzu on altı baytı (128 bit) minimum değer olarak kabul eder; auth0 ve çeşitli parola yöneticisi satıcıları otuz ikiye çıkmayı önerir. NIST'in SP 800-63B-4'ü dört baytlık bir minimum değer belirler, ancak bu boyutta altmış beş bin kullanıcı civarında doğum günüyle ilgili çakışmaların ortaya çıkmaya başladığı konusunda uyarıda bulunur; bu nedenle aslında kimse dört bayt kullanmaz.

İkinci adımda tuz, kullanıcının seçtiği parolayla birleştirilir. En yaygın yöntem birleştirmedir; tuz, parola dizesinin başına veya sonuna yerleştirilir. Bazı sistemler bunun yerine HMAC kullanır ve tuzu HMAC anahtarı olarak ele alarak, ham birleştirmedeki bazı belirsiz uzunluk uzatma sorunlarını ortadan kaldırır.

Üçüncü adımda, birleştirilmiş girdi, parola karma algoritmasından geçirilir; kriptografi ders kitaplarında buna anahtar türetme fonksiyonu veya KDF denir. Çoğu ekip bu adımda genellikle genel bir karma algoritmasına başvurup işin bittiğini düşünerek hata yapardı. Düz SHA-256, tek başına parolaları saklamak için uygun bir yöntem değildir. 2026 yılında bir tüketici GPU'su saniyede yüz milyardan fazla SHA-256 karması işleyebilir, bu nedenle tuzlama ile bile kriptografik karma işleminde tahmin başına maliyet önemsiz kalır. Tuzlama, gökkuşağı tablosu saldırı vektörlerini etkisiz hale getirir. Tek başına kaba kuvvetle parola kırmayı yavaşlatmaz. Burada doğru araç, kasıtlı olarak yavaş, bellek açısından zorlayıcı bir fonksiyondur: Argon2id, OWASP tarafından tercih edilen varsayılan algoritmadır; scrypt ve bcrypt kabul edilebilir, FIPS-140 uyumluluğunun zorunlu kıldığı durumlarda ise çok yüksek yineleme sayılarına izin verilen PBKDF2 kullanılabilir.

Dördüncü adımda hem hash hem de tuz saklanır. Modern kütüphaneler saklama biçimini otomatik olarak yönetir, böylece saklanan tuzu elle yönetmenize gerek kalmaz. Bir bcrypt çıktısı `$2b$12$9f4c8a7b...kQR8YZpL9` gibi görünür; bu tek dize algoritma tanımlayıcısını, maliyet faktörünü, tuzu ve hash değerini taşır. Argon2id, benzer PHC dize biçimini kullanır: `$argon2id$v=19$m=19456,t=2,p=1$$`. Bu dizeyi bir veritabanı sütununa yazarsınız ve işiniz biter. Kütüphane, parolaları güvenli bir şekilde saklamak için gereken her şeyi yapmıştır: tuz için rastgele veri oluşturmuş, parolayı yavaş bir hash algoritmasından geçirmiş ve sonucu erişim için paketlemiştir.

Giriş işlemi, aynı işlem hattını ters yönde izler. Uygulama, kullanıcının tuzunu ve saklanan hash değerini arar, gönderilen parolayı aynı algoritma ve aynı tuz ile çalıştırır ve sonucu saklanan hash değeriyle sabit zamanlı bir karşılaştırma kullanarak karşılaştırır. Sabit zaman önemlidir: Basit bir `==` operatörü, kaç baytın eşleştiği hakkında bilgi sızdırır ve bu da gerçek zamanlama saldırısı güvenlik açıklarına yol açmıştır. `hmac.compare_digest`, `crypto.timingSafeEqual` veya çerçevenizin eşdeğerini kullanın.

Tuzlamanın önemi: Gökkuşağı sofra problemi

Gökkuşağı tabloları, tuzlama yönteminin icat edilme amacını oluşturan özel bir saldırı türüdür. Her olası şifreyi (her sözlük kelimesi, yaygın varyasyon, sızdırılmış liste girişi) SHA-256 özetine eşleyen önceden hesaplanmış bir arama tablosu düşünün. Bu tablolar mevcuttur, şifre kırma forumlarında satılmaktadır ve terabayt boyutlarındadır. Bir saldırgan tuzlanmamış özetlerin veritabanı dökümünü ele geçirdiğinde, gökkuşağı tablosunda bir özet aramak bir veritabanı sorgusudur, şifre kırma işlemi değildir. LinkedIn 2012'de tam olarak bu şekilde gerçekleşti: Gökkuşağı tablosuna karşı 117 milyon tuzlanmamış SHA-1 özeti, yaklaşık üç günde yüzde doksanı kırıldı.

Kullanıcı başına tuz değeri eklenirse, gökkuşağı tabloları çalışmayı durdurur. Saldırganın her benzersiz tuz değeri için ayrı bir önceden hesaplanmış tabloya ihtiyacı olacaktır. On altı baytlık rastgele bir tuz değeriyle, bu 117 milyon kullanıcı için 117 milyon farklı tablo anlamına gelir ve her tablo yine de terabaytlarca büyüklükte olacaktır. Sadece depolama maliyetleri bile bunu imkansız hale getirir. Saldırı, tehdit modelinden çıkarılır.

Tuzlama işleminin tüm görevi budur. Bilerek dar kapsamlıdır. Tuzlama, belirli bir kullanıcıya karşı yapılan kararlı bir kaba kuvvet saldırısını yavaşlatmaz. Tuzlama, önceki bir sızıntıdan kaynaklanan kimlik bilgilerinin ele geçirilmesini engellemez. Şifrenin kendisi "123456" ise tuzlama yardımcı olmaz; saldırgan bariz sözlükleri dener ve tuz her tahmin için yeniden hesaplanır, ancak tahmin başına maliyeti anlamlı bir şekilde değiştirmez.

Tuzlama yönteminin güvenilir bir şekilde azalttığı sorunlar: gökkuşağı tabloları ve aynı veritabanındaki kullanıcılar arasında parola tekrar kullanım bilgilerinin sızması. Yavaş karma algoritmasının azalttığı sorunlar: tahmin başına maliyet. Pepper yönteminin azalttığı sorunlar: yalnızca veritabanı hırsızlığı. Çok faktörlü kimlik doğrulamanın (MFA) azalttığı sorunlar: kimlik bilgisi doldurma. Tuzlama, güvenlik katmanlarından biridir; parolaları kırmayı zorlaştırmak için tuz eklemek, her parolayı ayrı ayrı tahmin etmeyi zorlaştırmakla aynı şey değildir. Tuzlamanın amacı, her kullanıcı için farklı bir karma değer elde etmektir; her tahmini pahalı hale getirmek ayrı bir sorundur.

Karma algoritması, şifreleme ve tuzlama karşılaştırması

Özellikle uzman olmayan kişilerin yazılarında karıştırılan üç terim. Bunlar birbirinin yerine kullanılamaz.

Şifreleme, daha sonra geri almak istediğiniz verileri korur. Alıcı anahtarı elinde tutar, uygular ve orijinalini okur. Karma işlemi tek yönlüdür: bir parola bir kez karma haline geldiğinde, hiçbir algoritma onu tersine çeviremez. Tuzlama, karma fonksiyonunun girdisine uyguladığınız bir değiştiricidir; kendi başına bir anlamı yoktur.

Adobe'nin 2013'teki veri ihlali burada ibretlik bir örnek teşkil ediyor. Adobe, 153 milyon kullanıcı kaydını, tek bir site genelinde kullanılan anahtar altında ECB modunda 3DES ile şifreleyerek sakladı. Bu seçim üçlü bir hataydı. Şifreleme, parola depolama için yanlış bir yöntemdir. ECB modu, aynı girdileri aynı çıktılar olarak sızdırır. Tüm veritabanında tek bir anahtarın yeniden kullanılması, anahtarın bir kez çözülmesinin 153 milyon kaydın tamamını çözmesi anlamına geliyordu. Schneier bunu tarihteki en kötü parola ihlallerinden biri olarak adlandırdı. Her katmandaki çözüm, tuzlanmış, yavaş karma algoritmasına geçmekti.

Tuz mu, biber mi: iki katmanlı savunma

Pepper, salt'ın daha az bilinen kuzenidir. Kavram şu şekildedir: Uygulamanın işlediği her parolaya uygulanan, ancak veritabanının dışında saklanan ek bir gizli değer. Bu bir ortam değişkeni, bir anahtar yönetim hizmeti girişi veya HSM'de bulunan bir anahtar olabilir. Salt, hash'in yanında düz metin olarak bulunur. Pepper ise bulunmaz.

Tehdit modeli yalnızca veritabanı hırsızlığıdır. Saldırgan yalnızca veritabanını çalarsa (SQL enjeksiyonu, yanlış yapılandırılmış yedekleme veya sızdırılmış döküm yoluyla), tuz ve hash'lere sahip olur ancak "biber"e sahip olmaz. Biber olmadan, kaba kuvvet saldırısına bile başlayamazlar çünkü hash'ledikleri her tahminde global gizli değiştirici eksiktir.

Tipik bir uygulama, `argon2id(salt + password + pepper)` komutunu çalıştırır veya daha dikkatli bir şekilde, önce `HMAC(pepper, password + salt)` işlemini hesaplar ve sonucu Argon2id'ye iletir. OWASP, yüksek değerli sistemler için pepper kullanımını önerir ancak bunun dezavantajını da kabul eder: pepper rotasyonu operasyonel olarak zahmetlidir. Rotasyon, her kullanıcının şifresinin bir sonraki oturum açmada yeniden şifrelenmesi anlamına gelir ve pepper yedekleme olmadan kaybolursa, her hesap kontrol edilemez hale gelir. Çoğu tüketici uygulaması pepper kullanımını atlar. Bankalar, devlet kurumları ve sağlık hizmetleri genellikle kullanmaz.

2026'da Modern Parola Karma İşlemleri

OWASP'ın 2025 parola saklama kılavuzu, tercih sırasına göre dört algoritmayı sıralıyor. Tuzlama (salt) algoritması bunların hepsine entegre edilmiş durumda; manuel olarak oluşturmanıza gerek yok.

Argon2id bellek açısından yoğundur; yani her tahmin yalnızca CPU döngülerine değil, belirli bir RAM bloğuna da mal olur. OWASP'ın hash başına minimum 19 MiB gereksinimi, özel bir ASIC oluşturan bir saldırganın ayrıca çok miktarda hızlı bellek oluşturması gerektiği anlamına gelir ve bellek, herhangi bir sistemin en pahalı parçasıdır. "id" varyantı, ilk yarıda Argon2i (yan kanal dirençli) ve ikinci yarıda Argon2d (GPU dirençli) çalıştırarak Argon2i'yi birleştirir.

scrypt, Argon2id'den daha eski ve aynı bellek yoğun prensibiyle çalışıyor. bcrypt ise daha da eski, daha basit ve bazen uzun parolalar kullanan uygulamaları zorlayan 72 baytlık katı bir giriş sınırına sahip; daha uzun girişlere ihtiyacınız varsa SHA-256 ile ön hash yapın ve base64 ile kodlayın. PBKDF2, yavaş ama FIPS uyumlu bir seçenektir; OWASP, 2023 yılında SHA-256 için yineleme sayısını 310.000'den 600.000'e çıkardı.

Bu listede yer almaması gerekenler: düz SHA-256, düz SHA-512, MD5, SHA-1 ve "+ salt" ile biten herhangi bir özel fonksiyon. Hız, eleme kriteridir. SHA-256, standart donanımlarda hızlı olacak şekilde tasarlanmıştır. Bu, parola depolamasının ihtiyaç duyduğu şeyin tam tersidir.

Gerçek denetimlerde ortaya çıkan yaygın tuzlama hataları

Gerçek dünya veri ihlali raporları sürekli olarak aynı birkaç hatayı işaret ediyor.

Her kullanıcı için aynı tuzu yeniden kullanmak tüm mekanizmayı bozar; gökkuşağı tablosu problemi, sadece bir adım daha eklenerek geri döner. Kullanıcı adını tuz olarak kullanmak daha da kötüdür, çünkü kullanıcı adları sistemler arasında tekrarlanır ve popüler olanlar için gökkuşağı tabloları önceden hesaplanabilir. On altı bayttan daha kısa tuz uzunlukları, büyük kullanıcı tabanlarında çakışmalara yol açmaya başlar. Kriptografik olmayan rastgele bir fonksiyonla tuz üretmek (`Math.random()`, `time(0)` mod bir şey, dilin varsayılan RNG'si) tahmin edilebilir değerler üretir ve tuzlamanın faydasını ortadan kaldırır.

Daha incelikli bir hata ise tuzu "güvenlik gerekçesiyle" farklı bir sunucuda saklamaktır. Tuz gizli bir bilgi değildir. Bunu sistemler arasında bölmek, kriptografik gücü artırmadan operasyonel karmaşıklığı artırır. Tuzu, hash ile aynı satırda saklayın. Modern PHC dizeleri bunu sizin için yapar.

2026 denetimlerinde en büyük sorun, düz SHA-256 artı tuzlama ve gönderim ile yapılan karma işlemidir. Tuzlama, gökkuşağı tablolarını önler. Ancak, tek bir hesaba karşı saniyede on milyar tahmin çalıştıran bir GPU çiftliği üzerinde hiçbir etkisi yoktur. Çözüm, ikinci bir tuzlama eklemek değil; Argon2id gibi yavaş bir KDF'ye geçmektir.

Son olarak: eski tuzlanmamış hash'ler. Geçiş isteğe bağlı değildir. Standart yöntem, bir sonraki oturum açmada eski hash'i doğrulamak, modern algoritmayla yeniden hash'lemek ve üzerine yazmaktır. Bir daha asla giriş yapmayan kullanıcılar için, belirli bir zaman diliminde parola sıfırlama işlemi zorunlu kılınır.

Sadece tuzlamanın neden yeterli olmadığı

Tuzlama bir koruma katmanıdır, kale değil. Belirli bir saldırıyı (önceden hesaplanmış tabloları) etkisiz hale getirir ve altta yatan parolanın gücü hakkında hiçbir bilgi vermez. Kaba kuvvet saldırıları zayıf parolalara karşı hala etkilidir. Kimlik bilgisi doldurma saldırıları tekrar kullanılan parolalara karşı hala etkilidir. Kimlik avı saldırıları ise her türlü parolaya karşı etkilidir.

2026'da gerçek parola güvenliği dört savunma mekanizmasını bir araya getiriyor. Kullanıcı başına on altı baytlık tuzlama (salt) kullanan Argon2id, depolamayı yönetiyor. İsteğe bağlı ancak hassas sistemler için faydalı olan "pepper" (biber) özelliği, yalnızca veritabanı hırsızlığını engelliyor. Çok faktörlü kimlik doğrulama, kimlik bilgilerinin çalınmasını ve çoğu kimlik avı saldırısını engelliyor. Sürekli ihlal izleme (Have I Been Pwned ve API'si gibi hizmetler), bir kullanıcının kimlik bilgilerinin bir sızıntıda göründüğü anı yakalayarak sıfırlanmaya zorlanmasını sağlıyor.

Bu katmanlardan herhangi birini atlarsanız, saldırgan sonunda açığı bulur. Sadece tuzlama (salting) veya herhangi bir savunma yöntemi tek başına, son on yıldaki her ihlal sonrası incelemesinde başarısızlık noktası olarak tanımlanan şeydir.

Jordan Morris

Jordan Morris is an AI expert with over a decade of experience and the author of a widely-read blog focused on artificial intelligence. His content spans a range of topics—from the ethics of machine learning to real-world applications of neural networks in business. Known for his clear writing and deep insights, Jordan has become a trusted voice in the AI community, appealing to both newcomers and seasoned professionals alike.