Giriş yaparken düz metin şifre gönderme alternatifleri
Not: HTTPS üzerinden düz metin şifre göndermek uygun mu? ve https güvenliği - şifre, sunucu tarafında mı yoksa istemci tarafında mı hashing uygulanmalıdır? , ancak burada özel bir değiştirme yöntemi hakkındadır (aşağıya bakın).
Cloudflare blogunda yeni bir kimlik doğrulama yöntemi hakkında bir makale okuduktan sonra POST
, "Geliştirici Araçları> Ağ" ile kimlik doğrulama yapılırken gönderilen isteklere baktım . Birçok popüler web sitesi (Reddit, HN, vb.) Yine de parolayı (SSL korumalı) POST
istekte düz metin olarak gönderir (aşağıdaki ekran görüntüsüne bakın).
Bu oturum açma yöntemi hala endüstri standardı mı?
Aşağıdaki alternatif, HTTPS üzerinden düz metin şifre göndermekten daha güvenli midir?
kayıt: istemci rastgele bir oluşturur
salt
ve demeti(username, salt, hash(plain_password + salt))
birPOST
istek yoluyla gönderir . Daha sonra düz metin parolası asla sunucuya ulaşmaz.sonraki oturumlar: sunucunun belirli bir kullanıcıyla oturum açmaya çalışan herhangi bir istemciye
salt
geri göndermesi gerekir , böylece istemci aynı tuzla hash yapabilir. Bu, sunucunun belirli bir kullanıcı adıyla oturum açmaya çalışan herkese ifşa ettiği anlamına gelir .username
salt
avantaj: sunucu tuzlu + karma bir şifre saklar (bu standarttır), ancak aynı zamanda sunucu düz metin şifresini bir kez bile görmemiştir (bu nedenle sunucu ele geçirilirse, risk sınırlıdır)
Notlar:
çünkü
H = hash(plain_password + salt)
şimdi yeni gibi biraz davranırplaintext
(2. cevaba bakınız ? Sıfır Bilgi Şifre Kanıtı: neden istemci tarafında değil ZKP şifre karma edilir ), sonra sever saklayabilir(username, salt, server_salt, hash(H + server_salt))
veritabanında yerine(username, salt, H)
.Azaltmak tekrar saldırılar için riskleri için, sunucu aynı zamanda eşsiz gönderebilir
nonce
birliktesalt
bir giriş denemesinden sonra sona her giriş içinBuradaki ana amaç, sunucunun hiçbir zaman düz metin parolasına veya basit bir karma değerine erişemeyeceğidir (bu, genellikle tüm site için tek bir gökkuşağı tablosu ile tersine çevrilebilir). Bir saldırganın kullanıcı başına bir gökkuşağı tablosu hesaplama riskiyle karşı karşıyayım .
Hafifletmek istediğim örnek saldırı: eğer sunucu bir düz metin şifresine erişime sahipse ve güvenliği ihlal edilmişse (örneğin Spectre / Meltdown vuln.), Kullanıcının şifresiz metin şifresi (muhtemelen diğer web sitelerinde yeniden kullanılır) tuzlanmadan önce çalınabilir -hashed edilmiş ve veritabanına kaydedilmiştir.

Yanıtlar
Teklifinizin mevcut müşteri tarafı hashing yaklaşımlarından nasıl daha iyi olduğunu anlamıyorum, ancak uygulamayı diğerlerinden daha karmaşık buluyorum. Ne yazık ki erişmeye çalıştığınız belirli bir riski tanımlamıyorsunuz, bu yüzden sadece yaygın olarak görülen tipik tehditleri varsayıyorum.
Ortadaki adam saldırgan
Bu durumda, ortadaki bir kişinin trafiğe erişimi olduğu varsayılır, örneğin kurumsal bir güvenlik duvarındaki bazı güvenilir trafik TLS müdahalesini tehlikeye attığı veya süper balık durumunda olduğu gibi güvenilir bir CA'da tuttuğu için .
Bu senaryoda, saldırgan daha H
önce yaptığı gibi erişim elde eder plain_password
. Yana H
kimlik doğrulaması için gerekli olan her şeyin ne olduğunu saldırganın böylece başarılı ve yaklaşımınız burada herhangi bir ek koruma eklemez .
Zayıf parolaları gizleme ve parolanın yeniden kullanımı
İstemci tarafı hashing için yaygın bir argüman, zayıf veya yeniden kullanılan bir parolayı sunucuya göstermemek, bunun yerine karmaşık bir türetilmiş parolayla kimlik doğrulaması yapmaktır. Kişisel yaklaşım karma ile yapar plain_password
rastgele oluşturulan bazı kullanıcı ile salt
ve daha sonra göndermek H
ve salt
şifre kurulumuna sunucuya.
Bu her işe yararken kimlik şimdi ek bir adım gerektirir : İlk kullanıcıdan kullanıcıya daha önce kullanılan tuz almak gerekiyor ve o zaman bunu kullanabilirsiniz salt
hash plain_password
. Bu ek adım, kimlik doğrulamayı daha karmaşık hale getirir, çünkü önce kullanıcıyı sunucuyla kontrol etmesi gerekir ve daha sonra parolayı kontrol edebilir. Buna ek olarak, bunun önemsiz bir uygulaması bir bilgi sızıntısına yol açar, çünkü kullanıcının daha fazla kimlik doğrulaması olmaksızın ilk etapta var olup olmadığını (tuz iade edilmiş veya edilmemiş) kontrol etmeyi mümkün kılar.
Bu bilgi sızıntısı, kullanıcı var olsun ya da olmasın sunucu tarafından bir miktar tuz döndürerek kapatılabilir. Elbette bu rastgele bir tuz olamaz, çünkü aksi takdirde bir saldırgan aynı kullanıcıyı iki kez kontrol edebilir ve döndürülen tuz farklıysa kullanıcının var olmadığı sonucuna varabilir. Dolayısıyla, mevcut olmayan kullanıcı için tuzun aslında sabitlenmesi gerekir, yani kullanıcı adından türetilmelidir.
Ve bu aynı zamanda yaklaşımınızı basitleştirmek için bir yol gösterir : kullanıcı tarafından rastgele bir tuz oluşturmak, onu sunucuda depolamak ve daha sonra tekrar almak yerine , tuzu istemci tarafındaki kullanıcı adından kolayca türetebiliriz . Basit bir salt=hash(username+domain)
etki alanı başına benzersiz bir tuz üretmek ve böylece hem yapmak yeterli olacaktır salt
ve H
farklı olsa bile username
ve plain_password
farklı etki yeniden olsun. Ve sizin yaklaşımınızın aksine , kullanıcı için önceden kullanılan tuzu ilk olarak almak için sunucuya ek bir geziye gerek yoktur .
Kısaca: Bu basitleştirilmiş yaklaşım, temelde hash(plain_password+username+domain)
orijinal şifre yerine göndermedir . Domain emin bile emin olmak için eklenir username
ve plain_password
birden çok site üzerinde yeniden kullanılır, türetilmiş şifre yeniden değildir.
PAKE ve SRP gibi protokollerin çözmeyi amaçladıkları problem tam olarak budur . PAKE / SRP ile, istemci ve sunucu, istemcinin bildiği bir parolaya (ve sunucu tarafından bilinen parolanın türetilmesine) dayalı olarak karşılıklı olarak birbirlerini doğrular.
İstemci, sunucuya parolayı (veya parola eşdeğer verileri) göndermeden sunucuya parolayı bildiğini gösterir. İşlemin sonunda, istemci ve sunucu paylaşılan bir sırrı paylaşır.
Sunucu, parolayı (veya parolaya eşdeğer verileri) depolamaz ve sözlük saldırılarına açık değildir. Kablodan gönderilen düz metni görüntüleyebilen bir gizli dinleyici veya ortadaki adam, parolayı türetmek için yeterli bilgiyi elde edemez. Bu, sahte sertifikalar kullanan ortadaki adam saldırılarını etkili bir şekilde önler ve 'kimlik avı' sitelerinin kullanıcıların parolalarını çalmasını önler.
1password'ün SRP'yi nasıl uyguladığına dair iyi bir yazı için bkz. https://blog.1password.com/developers-how-we-use-srp-and-you-can-too/
Steffen Ullrich'in cevabına ek olarak :
Oturum açma sırasında kullanıcı yalnızca hash gönderirse, saldırganın şifreyi bilmesi gerekmez. Parola veri tabanının çalınması yeterlidir. Daha sonra, oturum açma isteği sırasında saldırgan, hash'i veritabanından gönderir. Sunucu, istemcinin parolayı kullanıp kullanmadığını ve hashing uygulayıp uygulamadığını veya istemcinin (saldırgan) hash'i gönderip göndermediğini ayırt etmeyecektir.
OPAQUE ile ilgili makale şu soruna da değiniyor: Parola veri tabanını çalmak saldırgana yardımcı olmayacaktır. Basit kullanıcı şifresinin bilinmesi gerekir.
Saldırgan, sunucunuzun güvenliğini ihlal ettiyse, yalnızca sunucunuzda çalışan yazılımın değil, istemcilerde çalışan yazılımın da kontrolü elindedir.
Tasarladığınız güzel tasarlanmış kimlik doğrulama şeması ne olursa olsun, saldırgan bunu tarayıcıya gönderilmeden önce değiştirebilir.
Artık bir yumurta-tavuk sorununuz var: Saldırgan, toplanma ve sunucunuza gönderilme şeklini kontrol ediyorsa bir şifreyi güvence altına alamazsınız.
Bir veri ihlali konusunda endişeleniyorsanız, yönteminiz bir koruma olarak çalışır, ancak uygun bir parola hashing sunucu tarafı da işe yarar.
MITM saldırıları konusunda endişeleniyorsanız, TLS bunları çözer.
TLS üzerinden MITM saldırıları konusunda endişeliyseniz, demek istediğim gibi, onlara karşı iyi bir savunma her zaman bir Krav Maga kılavuzuyla başlar. Sürekli olarak TLS'yi kırmak için yeterli kaynağa sahip olan bir saldırgan, düzgün ve özel olarak eğitilmiş olmayan herhangi bir kişiden istediklerini elde etmekte sorun yaşamaz (evet, işkence, şantaj, adam kaçırma ve cinayetten bahsediyorum).
Yalnızca sunucu tarafından alınan verileri okuyabilen bir tehdit aktörü hakkında endişeleniyorsanız, yaklaşımınız (Steffen tarafından düzeltildiği şekliyle) onlara karşı çalışacaktır. Bununla birlikte, bu, genellikle büyük ölçüde yanlış yapılandırılmış bir sunucudan ve kötü gelişen uygulamalardan (yani, GET istekleri üzerinden kimlik bilgilerinin gönderilmesi ve erişim günlüğünün herkese açık olarak depolanması) kaynaklanan garip ve nadir bir durumdur. Bu hataları düzeltmek, sadece onlarla başa çıkmak için bir protokol icat etmekten daha kolaydır.
Bahsettiğiniz her iki güvenlik açığının da (aslında, Meltdown teknik olarak Spectre'nin bir çeşidi olduğu için yalnızca bir tanesidir), sonunda yerel bir ayrıcalık artışına neden olacak ve saldırgana web sunucunuzun tam kontrolünü verecektir. Yine, bir saldırganın web sunucunuz tarafından alınan verilere salt okunur erişiminin olduğu senaryonun ne kadar nadir olduğunu vurgulamak.
Bu nedenle, birçok büyük sitenin bunu kullanmamasının nedeni, büyük olasılıkla yanlış yapılandırmalar olan belirli durumlarda, hemen hemen hiçbir şey eklememesidir. Ayrıca, bir saldırgan sunucunuzda hangi verilerin aktarıldığını okuyabilirse, oyunun kaybeden tarafına çok uzaksınız demektir. Unutmayın, katmanlı korumalara sahip olmak iyidir, ancak asıl amacınız ilk etapta bunun gerçekleşmesini sağlamak değil . Ve buna odaklanmak sizi yeni planlar icat etmekten de kurtarır.
Her neyse, Steffen'in gösterdiği gibi, önerilen planın yine çok garip bir saldırı modelinde işe yarayabilir. Hala sözlükte bir kelime olan uzak olasılığa hükmetmek hash(hash(domain + username) + password)
yerine , yine de kullanırdım . Mti2935'in gösterdiği gibi, SRP daha ilginç bir alternatiftir. Sertifikaya dayalı kimlik doğrulama (yani tarayıcı tarafından yönetilen) başka bir seçenektir (bunu, yorumlarda önerdiğiniz gibi potansiyel olarak bozuk bir JS betiğinde manuel olarak yapmaktan daha iyi buluyorum).hash(domain + username + password)
domain + username + password