Logo Logo
Yükleniyor...
Logo

Bcrypt

  • Kripto Hesaplayıcı
TR Türkçe EN English
Light
Dark
System

Bcrypt Aracı

  • Şifre hash üretimi, doğrulama ve rehash kontrolü
Bu modül, bcrypt tabanlı parola süreçlerini tek ekranda test etmeniz ve standartlaştırmanız için tasarlanmıştır.
Not: Bcrypt, girdinin ilk 72 baytını esas alır. Daha uzun metinler kırpılabilir.
Teknik not
Bcrypt algoritması 72 bayt sınırı nedeniyle çok uzun parolalarda farklı davranabilir. Uzun parolalar için uygulama katmanında ek stratejiler (ör. pre-hash) değerlendirilebilir.
Sonuç burada görünecek...
Sonuç burada görünecek...
Sonuç burada görünecek...
Kullanım örneği (PHP)
// Hash üret
$hash = password_hash($password, PASSWORD_BCRYPT, ["cost" => 12]);

// Doğrula
if (password_verify($password, $hash)) {
  // Rehash gerekli mi?
  if (password_needs_rehash($hash, PASSWORD_BCRYPT, ["cost" => 12])) {
    $hash = password_hash($password, PASSWORD_BCRYPT, ["cost" => 12]);
  }
}

Bcrypt rehberi ve uygulama notları

Bu sayfa, bcrypt kullanımını netleştirmek, maliyet-performans dengesini oturtmak ve doğrulama/rehash stratejisini standartlaştırmak için hazırlanmıştır.

Bcrypt, parolayı “geri döndürülemez” bir forma sokmak için tasarlanmış, maliyeti ayarlanabilen (cost) bir parola hash yaklaşımıdır.

Bu modül; hash üretimi, doğrulama, rehash gereksinimi kontrolü ve hash bilgisi okuma işlemlerini tek ekranda sunar. Hedef; geliştirme/test süreçlerinde tutarlılık sağlamak ve üretim ortamına taşınacak “parola politikası” kararlarını veriyle desteklemektir.

Bcrypt; her kullanıcı için benzersiz bir salt kullanarak aynı parolanın her seferinde farklı hash üretmesini sağlar. Hash; parolanın kendisi değildir, paroladan türetilen tek yönlü bir çıktıdır.

Özetle: veritabanında parola saklamak yerine bcrypt hash saklarsın; giriş sırasında da password_verify ile “eşleşme” kontrolü yaparsın.

Parola güvenliği, sistemin en kritik ama en kolay “geçiştirilen” noktasıdır. Bcrypt gibi yavaşlatılabilir algoritmalar, kaba kuvvet denemelerini maliyetli hale getirir.

Bu ekran; cost standardını belirlemenize, legacy hashleri planlı şekilde dönüştürmenize (rehash), entegrasyon testlerini hızlandırmanıza ve ekip içinde aynı yaklaşımı uygulamanıza yardımcı olur.

1) Hash üretiminde password_hash, salt + cost parametresi ile bcrypt çıktısı üretir.
2) Doğrulamada “yeniden hash” mantığı yoktur; password_verify mevcut hash’i kullanarak parolayı sınar.
3) Parola doğruysa password_needs_rehash ile yeni cost/politika gereği güncelleme ihtiyacı kontrol edilir.
4) Rehash gerekiyorsa yeni hash üretilir ve veritabanında güncellenir.

Cost, hash üretimini kasıtlı olarak yavaşlatan ayardır. Cost arttıkça güvenlik maliyeti yükselir; aynı zamanda login/şifre değiştirme gibi işlemler de daha fazla CPU tüketir.

Bu modülde cost alanı 4–15 aralığında çalışır ve 15’i aşınca 4’e döner (ekip içi hızlı test/karar süreçleri için pratik). Üretimde ideal cost; sunucu gücü, eşzamanlı kullanıcı sayısı ve hedef yanıt süresi ile benchmark edilerek seçilmelidir.

Pratik hedef: giriş başına hash doğrulamasının sisteminizi boğmayacak ama saldırgana pahalı gelecek bir aralıkta kalması.

Bcrypt, girişin ilk 72 baytını esas alır. Bu “karakter” değil “bayt” olduğu için; çok baytlı (ör. emoji, bazı unicode karakterler) içeriklerde beklenenden erken sınıra gelinebilir.

Bu ne demek? Çok uzun parolalarınız varsa, iki farklı parola ilk 72 baytta aynıysa bcrypt aynı davranabilir. Uygulama katmanında parola politikası (uzunluk, karakter seti, kullanıcıya anlatım) net olmalı; gerekiyorsa ek stratejiler değerlendirilmelidir.

Standart akış şudur: önce password_verify ile doğrula; doğruysa password_needs_rehash ile güncel politikanıza uyuyor mu bak.

Rehash, “kullanıcı giriş yaptıktan sonra” sessizce güncelleme yapmak için idealdir. Böylece kullanıcı şifre değiştirmeden sistem zamanla daha güçlü cost/politika seviyesine taşınır.

Bu modülde Rehash sekmesi; eşleşme varsa “rehash gerekli mi?” kararını ve gerekiyorsa yeni hash üretimini gösterir.

• Parolayı asla loglama, asla e-posta ile gönderme, asla geri döndürmeye çalışma.
• Login endpoint’lerinde rate limit ve şüpheli deneme izleme kullan.
• Hash’i kullanıcı tablosunda tek alanda tut, ekstra “parola kopyaları” üretme.
• Şifre sıfırlama token’larını süreli ve tek kullanımlık tasarla.
• Veritabanı sızsa bile saldırganın işini zorlaştırmak için sistem genel güvenlik katmanlarını (2FA, IP kuralı, oturum koruması) devreye al.
• Kullanıcıya parola politikasını net ve anlaşılır anlat; “güvenlik” kullanıcı deneyimiyle kavga etmek zorunda değil.

Cost her artışta işlem süresi genellikle hissedilir biçimde yükselir. Bu yüzden “en yüksek cost” her zaman “en iyi” değildir; doğru hedef, sisteminizin yük altında stabil kalmasıdır.

Benchmark yaklaşımı: test ortamında farklı cost değerlerinde hash/verify sürelerini ölç, eşzamanlı login senaryolarını simüle et, hedef bir yanıt süresi belirle ve cost’u buna göre standardize et. Bu modül, hızlı bir ilk ölçüm ekranı olarak kullanılabilir.

• “Aynı parola iki kez hashlenince farklı çıktı”: normaldir (salt).
• Hash’i string olarak kıyaslayıp “neden aynı değil” demek: yanlış test yaklaşımıdır; password_verify kullanılır.
• Cost çok yüksek seçilirse: girişlerde yavaşlık ve CPU şişmesi görülür.
• Parolayı trim/normalize ederek değiştirmek: kullanıcı tarafında sürpriz eşleşme hataları doğurabilir.
• Hash formatı beklenmiyorsa: password_get_info ile algoName kontrol edilmelidir.

Bcrypt günümüzde halen yaygın ve güvenilir bir seçenektir. Ancak güvenlik bir “tek ayar” işi değildir: doğru hash + doğru rate limit + doğru oturum güvenliği + doğru reset akışı birlikte çalışmalıdır.

PHP sürümünüz destekliyorsa argon2id gibi modern seçenekler de değerlendirilebilir; yine de birçok sistemde bcrypt, doğru cost ve doğru operasyonel kontrollerle gayet güçlü bir standarttır.

Legacy sistemlerden geçişte tipik strateji: kullanıcı giriş yaptığında önce eski yönteme göre doğrula; başarılıysa hemen bcrypt ile yeni hash üret ve kaydet. Böylece “toplu reset” dayatmadan kademeli geçiş sağlanır.

Bu modül, yeni standardın test edilmesi ve cost/rehash politikasının ekip içinde sabitlenmesi için pratik bir kontrol noktasıdır.

Neden aynı parola her seferinde farklı hash üretiyor?
Çünkü bcrypt her hash üretiminde benzersiz salt kullanır. Bu sayede hashler “kopya tespiti” için kullanılmaz ve rainbow table gibi saldırılara karşı direnç artar.
Hash geri çözülebilir mi?
Hayır. Hash geri çözmek için tasarlanmaz. Doğrulama, parolayı tekrar üretmek değil; girilen parolanın mevcut hash ile eşleşip eşleşmediğini kontrol etmektir.
Cost artırmak güvenliği nasıl etkiler?
Cost artınca hash hesaplama daha yavaş olur. Bu, saldırganın deneme başına maliyetini artırır. Ancak çok yükseltmek sisteminizi de yavaşlatır; bu yüzden benchmark ile karar verilmelidir.
72 bayt limiti tam olarak ne anlama geliyor?
Bcrypt girişin ilk 72 baytını dikkate alır. Çok uzun (özellikle çok baytlı) parolalarda beklenmeyen davranışlar olabilir. Parola politikası ve kullanıcıya anlatım bu gerçeğe göre şekillenmelidir.

Kısa Kontrol Listesi

  • Hash üretimi: password_hash (bcrypt) + seçilmiş cost standardı.
  • Doğrulama: string kıyaslama yok, sadece password_verify.
  • Politika değişimi: password_needs_rehash ile kademeli güncelleme.
  • Operasyonel koruma: rate limit, şüpheli giriş izleme, gerekirse 2FA.
  • Şifre reset: süreli, tek kullanımlık token; kullanıcıya net akış.
  • Log hijyeni: parola ve token loglanmaz.
  • Performans: yük altında ölç, “en yüksek cost” yerine “en doğru cost”.
  • Ekip standardı: aynı politika, aynı test ekranı, aynı çıktı beklentisi.
2017 - 2026© Exnek Project Infrastructure ~ Versiyon : 3.0.24
PTA : 32690 | PTC : 68