emirhan.sec
Gözlemci
- Katılım
- 23 Ocak 2026
- Mesajlar
- 2
- Tepkime puanı
- 12
- Puan
- 3
Cryptographic Failures (Kriptografik Hatalar), hassas verilerin yanlış, zayıf veya eksik kriptografik yöntemlerle korunması sonucu ortaya çıkan güvenlik problemleridir. Bu zafiyet türü, genellikle saldırganın sisteme “hack” yapmasından değil; geliştiricinin yanlış algoritma seçmesinden, hatalı konfigürasyondan veya kötü anahtar yönetiminden kaynaklanır.
Bu yazıda kavramı daha net anlamak için zararsız ve yalnızca eğitim amaçlı örnekler üzerinden ilerleyelim.
Örneğin en klasik hatalardan biri zayıf hash algoritması kullanmaktır. Diyelim ki bir uygulama kullanıcı parolasını şu şekilde saklıyor:
password → MD5(password)
MD5 artık güvenli değildir. Aynı parolayı kullanan iki kullanıcı aynı hash değerini üretir. Örneğin “123456” parolasının MD5 çıktısı her zaman aynıdır. Bu durum rainbow table saldırılarına karşı sistemi savunmasız bırakır. Eğitim amaçlı basit bir örnek payload şu olabilir:
123456
Bu parola birçok veri ihlalinde en sık görülen şifrelerden biridir. Eğer sistem zayıf hash kullanıyorsa, saldırgan kırılmış parola listeleriyle eşleştirme yapabilir. Güvenli yöntem ise salted ve maliyetli bir algoritma kullanmaktır. Örneğin:
password → bcrypt(password + unique_salt)
Buradaki “unique_salt” her kullanıcı için farklı olmalıdır. Böylece aynı parola farklı hash üretir.
Bir diğer yaygın cryptographic failure örneği HTTP kullanımıdır. Eğer bir uygulama HTTPS yerine HTTP üzerinden çalışıyorsa, login isteği şu şekilde gözükebilir:
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=test&password=test123
Bu veri HTTPS yoksa ağ üzerinde düz metin olarak iletilir. Zararsız bir test için geliştiriciler şunu kontrol edebilir: siteye http:// ile girildiğinde otomatik https yönlendirmesi var mı? Eğer yoksa bu bir yapılandırma problemidir.
JWT (JSON Web Token) tarafında da kriptografik hatalar görülebilir. Örneğin zayıf secret key kullanımı ciddi risk oluşturur. Eğitim amaçlı basit bir JWT payload örneği:
{
“user”: “emirhan”,
“role”: “user”
}
Eğer uygulama çok zayıf bir secret key kullanıyorsa (örneğin “123456”), teorik olarak token yeniden imzalanabilir. Bu yüzden secret key’in güçlü ve tahmin edilemez olması gerekir. Ayrıca JWT doğrulamasında algoritma manipülasyonuna karşı kontrol yapılmalıdır.
Bir başka örnek, Base64 ile şifreleme karıştırılmasıdır. Bazı geliştiriciler veriyi şu şekilde saklar:
email → Base64(email)
Base64 bir şifreleme değildir, sadece encoding yöntemidir. Örneğin:
dGVzdEBnbWFpbC5jb20=
Bu değer kolayca decode edilebilir. Eğer hassas veri sadece Base64 ile saklanıyorsa bu bir cryptographic failure’dır. Gerçek şifreleme simetrik (AES-256) veya asimetrik algoritmalarla yapılmalıdır.
TLS konfigürasyon hataları da bu kategoriye girer. Örneğin eski TLS sürümlerinin aktif olması (TLS 1.0 veya 1.1) sistemi downgrade saldırılarına açık bırakabilir. Geliştiriciler SSL/TLS test araçlarıyla sunucularını kontrol etmelidir. Minimum TLS 1.2 veya tercihen TLS 1.3 kullanılmalıdır.
Hardcoded secret da sık görülen bir problemdir. Örneğin:
SECRET_KEY = “mysecret”
Bu kod bir public repository’ye yüklenirse tüm sistem güvenliği tehlikeye girer. Doğru yöntem environment variable kullanmaktır:
SECRET_KEY = os.getenv(“SECRET_KEY”)
Bu sayede anahtar kod içinde görünmez.
Cryptographic failures’ın etkisi genellikle zincirleme olur. Örneğin:
Zayıf hash → Parola kırma → Hesap ele geçirme
HTTP kullanımı → Trafik dinleme → Session hijacking
Zayıf JWT secret → Token forgery → Yetki yükseltme
Bu nedenle kriptografi sadece “veriyi şifreledik mi?” sorusuyla sınırlı değildir. Doğru algoritma, doğru anahtar yönetimi ve doğru konfigürasyon birlikte uygulanmalıdır.
Sonuç olarak cryptographic failures çoğu zaman görünmezdir. Sistem çalışır, kullanıcı giriş yapar, veri akar. Ancak arka plandaki küçük bir hata büyük bir veri ihlaline dönüşebilir. Güvenli yazılım geliştirmede en temel prensiplerden biri şudur:
Zayıf kriptografi = Güvenlik açığı.
Güçlü algoritmalar, güvenli anahtar yönetimi ve doğru yapılandırma olmadan uygulama güvenli kabul edilemez.
Bu yazıda kavramı daha net anlamak için zararsız ve yalnızca eğitim amaçlı örnekler üzerinden ilerleyelim.
Örneğin en klasik hatalardan biri zayıf hash algoritması kullanmaktır. Diyelim ki bir uygulama kullanıcı parolasını şu şekilde saklıyor:
password → MD5(password)
MD5 artık güvenli değildir. Aynı parolayı kullanan iki kullanıcı aynı hash değerini üretir. Örneğin “123456” parolasının MD5 çıktısı her zaman aynıdır. Bu durum rainbow table saldırılarına karşı sistemi savunmasız bırakır. Eğitim amaçlı basit bir örnek payload şu olabilir:
123456
Bu parola birçok veri ihlalinde en sık görülen şifrelerden biridir. Eğer sistem zayıf hash kullanıyorsa, saldırgan kırılmış parola listeleriyle eşleştirme yapabilir. Güvenli yöntem ise salted ve maliyetli bir algoritma kullanmaktır. Örneğin:
password → bcrypt(password + unique_salt)
Buradaki “unique_salt” her kullanıcı için farklı olmalıdır. Böylece aynı parola farklı hash üretir.
Bir diğer yaygın cryptographic failure örneği HTTP kullanımıdır. Eğer bir uygulama HTTPS yerine HTTP üzerinden çalışıyorsa, login isteği şu şekilde gözükebilir:
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=test&password=test123
Bu veri HTTPS yoksa ağ üzerinde düz metin olarak iletilir. Zararsız bir test için geliştiriciler şunu kontrol edebilir: siteye http:// ile girildiğinde otomatik https yönlendirmesi var mı? Eğer yoksa bu bir yapılandırma problemidir.
JWT (JSON Web Token) tarafında da kriptografik hatalar görülebilir. Örneğin zayıf secret key kullanımı ciddi risk oluşturur. Eğitim amaçlı basit bir JWT payload örneği:
{
“user”: “emirhan”,
“role”: “user”
}
Eğer uygulama çok zayıf bir secret key kullanıyorsa (örneğin “123456”), teorik olarak token yeniden imzalanabilir. Bu yüzden secret key’in güçlü ve tahmin edilemez olması gerekir. Ayrıca JWT doğrulamasında algoritma manipülasyonuna karşı kontrol yapılmalıdır.
Bir başka örnek, Base64 ile şifreleme karıştırılmasıdır. Bazı geliştiriciler veriyi şu şekilde saklar:
email → Base64(email)
Base64 bir şifreleme değildir, sadece encoding yöntemidir. Örneğin:
dGVzdEBnbWFpbC5jb20=
Bu değer kolayca decode edilebilir. Eğer hassas veri sadece Base64 ile saklanıyorsa bu bir cryptographic failure’dır. Gerçek şifreleme simetrik (AES-256) veya asimetrik algoritmalarla yapılmalıdır.
TLS konfigürasyon hataları da bu kategoriye girer. Örneğin eski TLS sürümlerinin aktif olması (TLS 1.0 veya 1.1) sistemi downgrade saldırılarına açık bırakabilir. Geliştiriciler SSL/TLS test araçlarıyla sunucularını kontrol etmelidir. Minimum TLS 1.2 veya tercihen TLS 1.3 kullanılmalıdır.
Hardcoded secret da sık görülen bir problemdir. Örneğin:
SECRET_KEY = “mysecret”
Bu kod bir public repository’ye yüklenirse tüm sistem güvenliği tehlikeye girer. Doğru yöntem environment variable kullanmaktır:
SECRET_KEY = os.getenv(“SECRET_KEY”)
Bu sayede anahtar kod içinde görünmez.
Cryptographic failures’ın etkisi genellikle zincirleme olur. Örneğin:
Zayıf hash → Parola kırma → Hesap ele geçirme
HTTP kullanımı → Trafik dinleme → Session hijacking
Zayıf JWT secret → Token forgery → Yetki yükseltme
Bu nedenle kriptografi sadece “veriyi şifreledik mi?” sorusuyla sınırlı değildir. Doğru algoritma, doğru anahtar yönetimi ve doğru konfigürasyon birlikte uygulanmalıdır.
Sonuç olarak cryptographic failures çoğu zaman görünmezdir. Sistem çalışır, kullanıcı giriş yapar, veri akar. Ancak arka plandaki küçük bir hata büyük bir veri ihlaline dönüşebilir. Güvenli yazılım geliştirmede en temel prensiplerden biri şudur:
Zayıf kriptografi = Güvenlik açığı.
Güçlü algoritmalar, güvenli anahtar yönetimi ve doğru yapılandırma olmadan uygulama güvenli kabul edilemez.