Kullanıcıların giriş yapmasını gerektiren bir web uygulaması yapıyorum. Tüm iletişim https üzerinden geçer. Şifreleri hash etmek için bcrypt kullanıyorum.
Ben bir ikilemle karşı karşıyayım - Bir şifre karma istemci tarafı (JavaScript kullanarak) yapmak ve daha sonra sadece DB sunucu tarafında karma ile karşılaştırmak daha güvenli olduğunu düşünüyorum kullanılır. Ama bunun https üzerinden düz metin şifresi göndermekten ve daha sonra sunucu tarafında hash etmekten daha iyi olmadığından emin değilim.
Benim akıl yürütme, eğer saldırgan https trafiğini kesebilirse (= düz metin parolasını oku) örneğin JavaScript'i değiştirebilir, böylece düz metin parolayı karma parolayla birlikte gönderir - burada araya girebilir.
karşı istemci tarafının karmaşası sadece kullanım kolaylığıdır. Eğer istemci tarafını karma yaparsam, karma için iki ayrı kitaplık kullanmam gerekir. Bu çözülemez bir sorun değil, ama bir sıkıntı.
İstemci tarafındaki karma kullanımında güvenlik kazancı var mı? Neden?
O zaman meydan okuma yanıtı mı kullanmalıyım?
GÜNCELLEME: Beni en çok ilgilendiren şey bu - bu teknikler (istemci tarafı karma, istek-yanıt) https kullanılması durumunda önemli bir güvenlik kazancı ekliyor mu? Öyleyse neden?
İstemci tarafında karma yaparsanız, karma parola gerçek parola olur (karma algoritması bir kullanıcı tarafından tutulan anımsatıcısını gerçek parolaya dönüştürmenin bir yolundan başka bir şey değildir).
Bu, veritabanında tam "düz metin" parolasını (karma) depolayacağınız ve en başta karma işlemin tüm avantajlarını kaybedeceğiniz anlamına gelir.
Bu rotaya gitmeye karar verirseniz, herhangi bir karma işlemden vazgeçebilir ve kullanıcının ham şifresini iletebilir ve saklayabilirsiniz (bu arada, özellikle tavsiye etmem).
İstemcide karma yapma, yalnızca sunucuya bir şekilde güvenmiyorsanız ve "gerçek" parolayı (insan kullanıcının hatırladığı parola) göstermek istemiyorsanız mantıklıdır. Neden söz konusu şifrenin yararlandığı siteye şifreyi göstermek istemiyorsunuz? Başka bir yerde şifreyi tekrar kullandığınız için ! Şimdi bu genellikle kötü, ancak this one veya o bir (Kaliteleri için kefil değilim). Bunlar, kullanıcı kullanıcının, site etki alanı adını bir tür tuz olarak kullanarak, siteye özgü bir parolanın oluşturulduğu bir "ana parolayı" hatırladığı, böylece iki ayrı sitenin farklı parolalar aldığı araçlardır.
Bu senaryo mantıklı olsa da, sunucunun kendisi tarafından gönderilen Javascript ile yapmak mantıklı değildir. Gerçekten de, parola istemcisi tarafının hash edilmesi noktası, sunucunun potansiyel olarak düşmanca (ör., Bir saldırgan tarafından altüst edilmiş) olmasıdır ve bu nedenle, bu sunucu tarafından gönderilen Javascript kodu en azından şüphelidir. Değerli şifrenizi bazı düşman Javascriptlerine girmek istemezsiniz ...
İstemci tarafında karma için başka bir örnek yaklaşık yavaş karma. Parolalar tanım gereği zayıf olduğu için sözlük saldırıları engellemek istiyorsunuz. Kötü adamın sunucu veritabanının bir kopyasını aldığını ve kendi makinelerinde "parolaları deneyeceğini" varsayarsınız (bu konuda bazı tartışmalar için bkz --- bu blog yazısı ). Düşmanı yavaşlatmak için, doğası gereği yavaş bir karma işlemi uygularsınız ( bcrypt gibi), ancak bu, sunucu dahil herkes için işlemi yavaşlatacaktır. Sunucuya yardımcı olmak için, istemcideki işin bir kısmını boşaltmak isteyebilirsiniz, bu nedenle en azından bir kısmını istemci tarayıcısında çalışan bazı Javascript kodunda yapın ...
Ne yazık ki, Javascript bu tür bir işte çok yavaştır (tipik olarak iyi C kodundan 20 ila 100 kat daha yavaştır) ve istemci sistemi karma çabasına önemli bir katkıda bulunamaz. Fikir sağlam ama daha iyi teknoloji beklemek zorunda kalacak (bir Java istemci ile çalışacaktı: iyi bir JVM ile optimize edilmiş Java kodu bir karma işi için optimize edilmiş C kodundan yaklaşık 2 ila 4 kat daha yavaştır).
Özetle, sunucunun kendisi tarafından gönderilen Javascript kodundan, istemci tarafı şifre karma işlemi yapmak için gerçekten iyi bir durum yoktur. Şifreyi bir HTTPS tüneli (giriş sayfası, form hedef URL'si ve şifre ile korunan tüm sayfalar) sunucuya "olduğu gibi" gönderin hepsi SSL üzerinden sunulmalıdır, aksi takdirde parola kullanmaktan daha acil güvenlik sorunlarınız olur).
Tüm kaygılarınızı sağlam buluyorum, ama benim tavsiyem bunu sunucu tarafında yapmak.
Her zaman bir kullanıcının terminalini açık bırakması ve manipülasyona izin vermesi oldukça büyük bir şanstır. Ve ayrıca; karma mantığınız istemci tarafı ise, onu açığa çıkarırsınız.
Başka bir seçenek de parolaları sunucu tarafı oluşturmaktır; açık metin şifresi göndermiyorsunuz. Ancak şifreyi yine de kullanıcıya iletmeniz gerekir. Çoğu kullanıcı hala şifreli e-posta kullanmadığından, bunu daha az güvenli buluyorum.
Şifreli bir tünelden cep telefonuna şifre göndermek için çözümler gördüm; ancak güvenliğin SSL'den daha iyi olduğundan şüpheliyim. Belki birisi bunu ispatlayabilir/çürütebilir?
Tüm diğer cevapların belirttiği gibi, sunucu tarafı Hashing önemlidir, ancak istemci tarafı hashing Güzel bir güvenlik özelliği ek olarak sunucu tarafı karma için eklemek istiyorum.
İstemci tarafındaki karma işleminin aşağıdaki senaryolarda faydaları vardır:
Çoğunlukla kullanıcının şifresine saygı gösterir. Kullanıcı, yazılımınıza özel olmayan bir sırrı paylaşıyor, bu nedenle bu sırra saygı duyuyorsanız, korumak için elinizden gelen her şeyi yapmalısınız.
Bir HTTPS tünelindeyseniz, şifre veya karma Ethernet gözetiminden korunmalıdır.
İstemci tarafında belki bir oturum kimliği ile karma tuz olabilir.
Kötü amaçlı Javascript'in taklit edilmesi daha zor olabilir.
Her ikisini de yapabilirsiniz, istemcide hash yaparsınız, böylece saldırgan https güvenliğinden geçebilirse düz metin şifresini göremezler. Sonra saldırgan sunucuda saklanan şifreleri alırsa, sadece sunucuya göndermek ve parolaya erişim elde edemez böylece tekrar sunucuda hash.
İstemci tarafındaki parolayı karma yapmak için Javascript gerekir. Bazı kişiler tarayıcılarında Javascript'i devre dışı bırakır. Bu senaryoyu ele almalısınız.
Istemci tarafı şifre karma gerçekleştiren forum yazılımı gördüm ve giriş mümkünse karma gönderir, aksi takdirde şifre düz metin olarak gönderilir. Yani her iki durumda da çalışır.
Https kullanacaksanız, şifreyi açık bir şekilde göndermek önemli bir sorun değildir. İdeal olarak, sunucunuz orta saldırıda insanlardan kaçınmak için http'deki sayfaları sunmayı reddetmelidir. Bunun nedeni şudur: Bir saldırgan bağlantınızı zorla https'den http'ye düşürüp trafik çekmeye başlayabilir (örneğin SSL Strip gibi bir araçla).
@ Nicole Calinoiu 'ın kabul edilen cevabı elbette doğrudur, ancak başlangıçta anlaşılması zor olabilir.
Önemli olan, kötü niyetli kişinin hesabınıza veya verilerinize erişmek için sunucudan veritabanından hacklediği karmaları kullanamaması için parolanın sunucuda karma olması gerektiğidir.
Daha önce de belirtildiği gibi, istemci tarafında karma yaparsanız ve arka uç bunu destekliyorsa, karma şifreniz olur ve karma bir saldırı yoluyla çalınırsa, bilgisayar korsanının şifresi vardır.
@ Thomas Pornin yanıtı, istemcide parolayı neden istemek için çok iyi bir noktaya geldi, ancak ilk hikayesinde açıkladığı şey, ancak sunucunun arka ucu karma şifrelerin işlenmesini destekliyorsa yapılabilir (yani, zaten karma ise şifreyi karma yapmaz, ancak biri böyle bir şeyi desteklemeye çalışırsa) ), çoğu zaman böyle olmayacak sanırım. Onun ikinci hikayesi çok iyi.