Örnek sorular
As Authentication SessionZorluk 1
SHA-256 güçlü bir kriptografik hash fonksiyonu olmasına rağmen, parolaları düz SHA-256 hash'i olarak saklamak neden güvensiz kabul edilir?
- aSHA-256'nın ürettiği hash, çakışmaya (collision) dayanıklı olamayacak kadar kısadır, bu da bir saldırganın aynı digest'e hashlenen iki farklı parola bulmasını mümkün kılar
- bSHA-256, çoğu programlama dilinde ücretli lisans olmadan uygulanamaz
- cSHA-256 son derece hızlı çalışacak şekilde tasarlanmıştır, bu da saldırganların çalınan bir hash dökümüne karşı saniyede milyarlarca tahmin denemesine izin verir✓
- dSHA-256 girdiden bağımsız olarak her zaman aynı çıktı uzunluğunu üretir, bu da parola uzunluğunu sızdırır
Açıklama:SHA-256 gibi genel amaçlı hash fonksiyonları hız için tasarlanmıştır ve bu, parola saklama için tam olarak yanlış özelliktir: sızmış bir hash veritabanına sahip bir saldırgan, ucuz donanımda büyük ölçekte paralel brute-force veya sözlük saldırısı çalıştırabilir. Parola hashleme fonksiyonları (bcrypt, scrypt, argon2) kasıtlı olarak yavaş ve ayarlanabilirdir, böylece her tahmin pahalıya mal olur.
As Authentication SessionZorluk 1
bcrypt gibi parola hashleme algoritmaları bağlamında, kullanıcı başına rastgele bir salt'ın amacı nedir?
- aAlgoritmaya işlemesi için daha kısa bir girdi vererek hashleme hesaplamasını hızlandırır, yüksek trafikli kimlik doğrulama endpoint'lerinde bir girişi doğrulamak için gereken süreyi kısaltır
- bHashlemeden önce parolayı sabit bir uzunluğa sıkıştırır, böylece veritabanı sütunu daha küçük olabilir
- cHash'i şifreler, böylece destek talepleri için daha sonra orijinal parolaya geri çözülebilir
- dAynı parolaya sahip iki kullanıcının farklı saklanmış hash'ler almasını sağlar, böylece önceden hesaplanmış rainbow-table saldırılarını etkisiz kılar✓
Açıklama:Salt, hashlemeden önce girdiye karıştırılan ve hash ile birlikte saklanan rastgele veridir. Kullanıcı başına farklı olduğu için, aynı parolalar farklı hash'ler üretir; bu da önceden hesaplanmış arama tablolarını (rainbow table) işe yaramaz hale getirir ve saldırganı her hash'e ayrı ayrı saldırmaya zorlar.
As Authentication SessionZorluk 2
bcrypt'teki 'work factor' (maliyet parametresi) neyi kontrol eder?
- aİç hesaplamanın kaç tur yapıldığını, bu da her hash işleminin ne kadar yavaş (dolayısıyla brute-force için ne kadar pahalı) olduğunu doğrudan kontrol eder✓
- bParola tekrar kullanımını önlemek için kaç önceki parolanın hatırlandığını, kimlik doğrulama servisinin yeni değeri kabul etmeden önce her parola değişikliği isteğinde danıştığı bir geçmiş listesi
- cGirdi parolanın kesilmeden önce izin verilen maksimum uzunluğunu
- dHash'in saklanmış sayılması için kaç veritabanı replikasının yazmayı onaylaması gerektiğini
Açıklama:bcrypt'in work factor'ü üstel bir maliyet parametresidir: artırıldığında hash başına hesaplama süresi ikiye katlanır. Bu, donanım hızlandıkça operatörlerin hashleme maliyetini yukarı ayarlamasına izin verir ve brute-force saldırılarını zaman içinde pahalı tutar.
As Authentication SessionZorluk 1
Bir JWT (JSON Web Token) tipik olarak noktalarla ayrılmış hangi üç bölümden oluşur?
- aHeader, payload ve signature✓
- bPublic key, private key ve ciphertext
- cSession ID, CSRF token ve expiry timestamp
- dIssuer, subject ve şifrelenmiş payload
Açıklama:Bir JWT header.payload.signature şeklindedir, her bölüm base64url ile kodlanmıştır. Header algoritmayı ve token tipini tanımlar, payload claim'leri (kullanıcı ID'si ve son kullanma tarihi gibi) tutar, signature ise alıcının token'ın değiştirilmediğini doğrulamasını sağlar.
As Authentication SessionZorluk 2
JWT alg: none saldırısının güvenlik riski nedir?
- aPayload'ın boyutunu iki katına çıkararak token'ı çoğu HTTP başlığı için çok büyük hale getirir, bu da herhangi bir imza kontrolü gerçekleşmeden önce sunucunun isteği doğrudan bir header-boyut-sınırı hatasıyla reddetmesine neden olur
- bSunucuyu o istek için HTTPS yerine düz HTTP'ye geri dönmeye zorlar
- cToken'ın hemen süresinin dolmasına neden olarak meşru kullanıcılar için hizmet reddine yol açar
- dToken'ın kendi
alg başlığına güvenen kötü yazılmış bir doğrulayıcı, imzasız bir token'ı geçerli kabul edebilir ve saldırganın rastgele claim'ler uydurmasına izin verebilir✓
Açıklama:JWT header'ındaki alg alanı saldırgan tarafından kontrol edilebilen bir girdidir. Bir kütüphane token'ın iddia ettiği alg'ı saf bir şekilde kabul ederse, saldırgan alg: none ayarlayıp imzayı kaldırabilir ve sunucu sahte token'ı gerçekmiş gibi kabul edebilir. Çözüm, doğrulama tarafında beklenen algoritmaları allowlist'e almak ve güveni asla token'ın kendisinden türetmemektir.
As Authentication SessionZorluk 1
Bir JWT payload'ındaki exp (expiration/son kullanma) claim'i neyi kontrol eder?
- aToken'ın çağırabileceği maksimum API endpoint sayısını
- bToken'ı iletim sırasında korumak için kullanılan şifreleme algoritmasını, bunu client ve sunucu token'ın kendi içeriğinden ayrı olarak müzakere eder
- cBu zamandan sonra token'ın süresi dolmuş sayılıp herhangi bir doğrulayıcı tarafından reddedilmesi gereken zaman damgasını✓
- dYeni bir giriş gerekmeden önce token'ın kaç kez yenilenebileceğini
Açıklama:exp, bir Unix zaman damgası tutan standart bir registered claim'dir. Doğrulayıcılar mevcut zamanı buna göre kontrol etmeli ve bu zaman geçtiğinde token'ı reddetmelidir; bu da çalınmış bir token'ın saldırgan için ne kadar süre kullanışlı kalacağını sınırlar.