Şifreyi sunucu tarafına göndermeden önce hashlamam gerekir mi?

Çoğu sitenin şifreleri HTTPS üzerinden sunucuya düz metin olarak gönderdiğini fark ettim. Bunun yerine parola karmasını sunucuya göndermenin herhangi bir avantajı var mı? Daha güvenli olur muydu?

Bu eski bir soru, ancak bu önemli konuda kendi fikrimi belirtme ihtiyacı hissettim. Burada çok fazla yanlış bilgi var

OP, parolayı HTTP üzerinden açık olarak göndermekten hiç bahsetmedi - yalnızca HTTPS, ancak birçoğu bir nedenle HTTP üzerinden bir parola gönderme sorusuna yanıt veriyor gibi görünüyor. Bahsedilen:

Şifrelerin hiçbir zaman düz metin olarak saklanmaması (aktarılmamalı) gerektiğine inanıyorum. Bu, diskte veya hatta bellekte tutulmadığı anlamına gelir.

Burada yanıt veren insanlar, HTTPS'nin sihirli bir değnek olduğunu düşünüyor, öyle değil. Ancak kesinlikle çok yardımcı olur ve kimliği doğrulanmış herhangi bir oturumda kullanılmalıdır.

Orijinal parolanın ne olduğunu bilmenize gerek yok. Gereken tek şey, kullanıcı tarafından seçilen orijinal metne dayalı bir kimlik doğrulama "anahtarı" oluşturmanın (ve güvenilir bir şekilde yeniden oluşturmanın) güvenilir bir yoludur. İdeal bir dünyada bu metin, geri çevrilemez tuz kullanarak hashing yaparak hemen bir "anahtar" oluşturmalıdır. Bu tuz, oluşturulan kullanıcı kimlik bilgilerine özgü olmalıdır. Bu "anahtar", sistemlerinizin şifre olarak kullanacağı şey olacaktır. Bu şekilde, sistemleriniz gelecekte tehlikeye atılırsa, bu kimlik bilgileri yalnızca kendi kuruluşunuza karşı yararlı olacaktır ve kullanıcının tembel olduğu ve aynı parolayı kullandığı başka hiçbir yerde de yararlı olmayacaktır.

Yani bir anahtarımız var. Şimdi, istemcinin cihazındaki herhangi bir şifre izini temizlememiz gerekiyor.

Sonra sistemlerinize o anahtarı almamız gerekiyor. Asla bir anahtarı veya parolayı "açık" olarak iletmemelisiniz. HTTPS üzerinden bile değil. HTTPS aşılmaz değildir. Aslında, birçok kuruluş, saldırı açısından değil, kendi güvenlik politikalarını uygulamak için trafik üzerinde incelemeler yapmak için güvenilir bir MITM haline gelebilir. Bu HTTPS'yi zayıflatır ve olmasının tek yolu bu değildir (örneğin HTTP MITM saldırılarına yönlendirmeler gibi). Asla güvenli olduğunu varsaymayın.

Bunu aşmak için, anahtarı bir kereliğine hash ederiz. Bu nonce, sistemlerinize bir anahtarın her gönderimi için benzersizdir - aynı oturum sırasında birden çok kez göndermeniz gerekiyorsa aynı kimlik bilgisi için bile. Kimlik doğrulama anahtarını kurtarmak ve isteğin kimliğini doğrulamak için kendi sistemlerinize ulaştığında bu nonce'yi tersine çevirebilirsiniz.

Bu noktada, kendi sistemlerinizde kalıcı olarak depolanmadan önce onu son bir kez geri dönüşü olmayan bir şekilde hash ederim. Bu şekilde, kendi kuruluşunuzun kullanıcıyı taklit edemeyeceğini kanıtlarken, kimlik bilgilerinin tuzunu SSO ve benzeri amaçlarla ortak kuruluşlarla paylaşabilirsiniz. Bu yaklaşımın en iyi yanı, kullanıcı tarafından üretilen hiçbir şeyi yetkisi olmadan asla paylaşmamanızdır.

Açıkladığımdan daha fazla araştırma yapın, ancak kullanıcılarınıza gerçek güvenlik sağlamak istiyorsanız, bu yöntemin şu anda buradaki en eksiksiz yanıt olduğunu düşünüyorum.

TL; DR:

HTTPS kullanın. Parola başına benzersiz bir tuzla, şifreleri geri dönüşü olmayan bir şekilde güvenli bir şekilde hashleyin. Bunu istemcide yapın - gerçek şifrelerini iletmeyin. Kullanıcıların orijinal şifresini sunucularınıza iletmek asla "Tamam" veya "İyi" değildir. Orijinal şifrenin tüm izlerini temizleyin. HTTP / HTTPS'den bağımsız olarak bir nonce kullanın . Birçok düzeyde çok daha güvenlidir. (OP'ye cevap).

HTTPS üzerinde olduğundan, şifreyi karma oluşturmadan göndermek kesinlikle iyidir (HTTPS üzerinden, düz metin değildir). Dahası, uygulamanız içeriğini güvende tutmak için HTTPS'ye bağlıysa, şifreyi HTTPS üzerinden göndermeden önce hash hale getirmek faydasızdır (yani bir saldırgan kablodaki verilerin şifresini çözebilirse, yine de mahvolursunuz)

Hayır, aslında bu bir güvenlik açığı olacaktır. Saldırgan veritabanından hash elde edebiliyorsa, onu kırmasına gerek kalmadan kimlik doğrulaması için kullanabilir. Hiçbir koşulda bir kullanıcı veya bir saldırgan bir karma şifre alamamalıdır.

Şifreleri karıştırmanın tüm amacı, fazladan bir güvenlik katmanı eklemektir. Bir saldırgan SQL Injection veya güvenli olmayan bir yedekleme kullanarak veritabanından hash ve salt elde edebiliyorsa, düz metni kaba zorlayarak bulması gerekir. John The Ripper , tuzlu parola karmalarını kırmak için yaygın olarak kullanılır.

Https kullanılmaması OWASP İlk 10: A9-Yetersiz Taşıma Katmanı Koruması'nın ihlalidir

DÜZENLEME: Uygulamanızda a'yı hesaplar sha256(client_salt+plain_text_password)ve ardından sunucu tarafında başka bir hash hesaplarsanız, sha256(server_salt+client_hash)bu ciddi bir güvenlik açığı değildir. Bununla birlikte, isteği gizlice dinlemeye ve tekrar dinlemeye hala açıktır. Bu nedenle, bu hala WASP A9'un açık bir ihlalidir. Ancak, bu hala bir güvenlik katmanı olarak bir mesaj özetini kullanmaktadır.

Gördüğüm en yakın şey, https için bir istemci tarafı değişimine javascript'te anahtar değişiminde bir diffie-hellman . Ancak, bu aktif MITM saldırılarını önler ve bu nedenle teknik açıdan OWASP A9'un ihlali anlamına gelir. Kodun Yazarları, bunun HTTPS için tam bir ikame olmadığı konusunda hemfikirdir, ancak hiçbir şeyden daha iyi ve istemci tarafı karma sistemden daha iyidir.

Kablonun üzerinden bir hash göndermek, hash'in amacını tamamen ortadan kaldırır, çünkü bir saldırgan sadece hash'i gönderebilir ve şifreyi unutabilir. Özetle, açık metinde bir karma kullanarak kimlik doğrulaması yapan bir sistem tamamen açıktır ve ağ koklamadan başka bir şeyle ödün verilebilir.

Düz metindeki şifre asla istemciden çıkmaz (HTTPS kullanırken bile). Sunucunun gerçek parolayı bilmesine gerek olmadığından, istemciden ayrılmadan önce geri çevrilemez şekilde hashing uygulanmalıdır.

Hashing daha sonra iletim, aynı parolayı birden çok yerde kullanan tembel kullanıcılar için güvenlik sorunlarını çözer (yaptığımı biliyorum). Ancak bu, uygulamanızı veritabanına erişen bir bilgisayar korsanı olarak korumaz (veya başka bir şekilde karmayı ele geçirmeyi başardı) çünkü bilgisayar korsanı karmayı iletebilir ve sunucunun bunu kabul etmesini sağlayabilir.

Bu sorunu çözmek için elbette sunucunun aldığı hash'i hash edebilir ve bir gün çağırabilirsiniz.

Oluşturduğum soket tabanlı bir web uygulamasında soruna yaklaşımım, istemciye bağlanıldığında sunucunun bir tuz oluşturması (hashing işleminden önce eklenecek rastgele dizge) ve bunu soketler değişkeninde depolaması ve ardından bu hash'i iletmesidir. Müşteriye. İstemci kullanıcı şifresini alır, şifreler, sunucudan tuzu ekler ve sunucuya iletmeden önce her şeyi hash eder. Daha sonra, bu hash'i hash ile karşılaştıran sunucuya gönderilir (DB + salt içindeki hash). Bildiğim kadarıyla bu iyi bir yaklaşım ama dürüst olmak gerekirse konu hakkında çok fazla okumadım ve herhangi bir konuda yanılıyorsam düzeltilmeyi çok isterim :)

HTTP Özetini kullanın - şifreyi http üzerinden bile korur (ancak en iyi kullanım https üzerinden http özetidir)

Wikipedia:

HTTP özet erişim kimlik doğrulaması, bir web sunucusunun bir web kullanıcısı ile kimlik bilgileri üzerinde anlaşmak için (HTTP protokolünü kullanarak) kullanabileceği kabul edilen yöntemlerden biridir. Özet kimlik doğrulamasının, Temel erişim kimlik doğrulamasının şifrelenmemiş kullanımının yerini alması amaçlanarak, ağ üzerinden düz metin olarak bir parola göndermek zorunda kalmadan kullanıcı kimliğinin güvenli bir şekilde oluşturulmasına izin verilir. Özet kimlik doğrulaması, temel olarak, kriptanalizi önlemek için nonce değerlerinin kullanımıyla MD5 kriptografik hashing uygulamasıdır.

Bağlantı: http://en.wikipedia.org/wiki/Digest_access_authentication

Bir "gerçek yaşam" kullanımı görmek istiyorsanız, http://siege.org/phpmyid.php http://siege.org/phpmyid.php adresinden http://siege.org/phpmyid.php gibi bir php openid sağlayıcısı olan phpMyID'ye bakabilirsiniz.

.. veya http://php.net/manual/en/features.http-auth.php adresindeki php kimlik doğrulama örneklerinden başlayabilirsiniz.

Http özeti rfc: http://www.faqs.org/rfcs/rfc2617

Testlerime göre tüm modern tarayıcılar bunu destekliyor ...

HTTPS üzerinden açık metin şifresini HTTP üzerinden karma bir şifre ile değiştirmek istiyorsanız, sorun istiyorsunuz. HTTPS, bir iletişim kanalını açarken rastgele, paylaşılan bir işlem anahtarı oluşturur. (Nispeten) kısa vadeli bir işlem için kullanılan paylaşılan anahtarı kaba zorlamakla oldukça sınırlı olduğunuz için, kırılması zor. Oysa hash'iniz sadece koklanabilir, çevrimdışı olarak alınabilir ve bir gökkuşağı masasında bakılabilir veya uzun bir süre boyunca zorla zorlanabilir.

Ancak, HTTPS üzerinden gönderilen temel bir istemci tarafı şifre gizlemesinin (karma değil) bir değeri vardır. Yanılmıyorsam bu teknik aslında bazı bankalar tarafından kullanılıyor. Bu tekniğin amacı, parolanın kabloyu koklamasını önlemek değildir. Aksine, şifrenin, gördükleri her HTTPS GET / POST isteğini yakalayan aptal casusluk araçları ve tarayıcı eklentileri tarafından kullanılmasını engellemek içindir. Kullanıcı oturumlarından yakalanan 400 MB rasgele GET / POST işlemi olan kötü amaçlı bir web sitesinden alınan bir günlük dosyası gördüm. Yalnızca HTTPS kullanan web sitelerinin günlükte açık metin şifreleri ile görüneceğini, ancak çok basit gizleme (ROT13) içeren web sitelerinin de hemen kullanılmayan şifrelerle görüneceğini hayal edebilirsiniz.

Bir https sunucusuna bağlıysanız, sunucu ile tarayıcı arasındaki veri akışı şifrelenmelidir. Veriler, gönderilmeden önce ve alındıktan sonra yalnızca düz metindir. Wikipedia makalesi

Feragatname: Kesinlikle bir güvenlik uzmanıyım - ve başkalarının durumumu aşırı temkinli veya iyileştirilebilir olarak eleştirmesi umuduyla gönderiyorum ve bundan ders alacağım. Bununla birlikte, müşterinizden ayrıldığında hash işleminin, veritabanına koymadan önce arka uca hash işlemi uygulamak zorunda kalmayacağınız anlamına gelmediğini vurgulamak istiyorum.

İkisinide yap

İkisini de yapın çünkü:

1. Devir üzerine yapılan karma, taşımanın güvenlik açıklarını kapatmaya yardımcı olur, eğer SSL bağlantısı tehlikeye atılırsa, yine de ham şifreyi göremezler. Yetkili kullanıcıların kimliğine bürünme açısından önemi olmayacak, ancak kullanıcılarınızın şifrelerinin e-postalarıyla ilişkili olarak okunmasını engelleyecektir. Çoğu kişi en iyi uygulamaları takip etmez ve birçok hesabı için aynı parolayı kullanmaz, bu nedenle bu, ziyaretçileriniz için ciddi bir güvenlik açığı olabilir.

2. Birisi, bir şekilde veritabanından şifreleri okuyabildiyse (bu olur, SQL enjeksiyonunu düşünürseniz), API'm aracılığıyla kullanıcıların kimliğine bürünen ayrıcalıklı eylemleri yine de yürütemezler. Bunun nedeni hash asimetrisidir; DB'nizde depolanan karmayı bilseler bile, onu oluşturmak için kullanılan orijinal anahtarı bilmezler ve bu, kimlik doğrulama ara yazılımınızın kimlik doğrulaması için kullandığı şeydir. Bu aynı zamanda, hash depolamanızı her zaman tuzlamanızın nedenidir.

Verilen, veritabanınızdan istediklerini okumak için özgürce dizginleri olsaydı birçok başka zarar verebilirlerdi.

Burada vurgulamak istiyorum ki, müşterilerinizden ayrılmadan önce anahtara hashing uygulamasına karar verirseniz, bu yeterli değildir - arka uç hashlemesi çok daha önemlidir ve bu nedenle: Birisi sizin trafiğinizden müşteri, daha sonra passwordalanın içeriğini göreceklerdir . Bunun bir karma veya düz metin olması fark etmez - yetkili bir müşteriyi taklit etmek için harfi harfine kopyalayabilirler. (@ User3299591'in ana hatlarını çizdiği adımları izlemediğiniz sürece ve yapmanızı tavsiye ederim). Öte yandan, DB sütununun özetlenmesi bir gerekliliktir ve uygulanması hiç de zor değildir.

SSL / TLS nonce'nin yerini almıyor mu? SSL / TLS aynı zamanda Tekrar Saldırılarına karşı da koruma sağladığından bunun katma değerini görmüyorum.

Ref. https://en.wikipedia.org/wiki/Cryptographic_nonce

Şifreye hashing uygulamak ve şifrelenmemiş bir kanal üzerinden göndermek aslında daha az güvenli olacaktır. Karma algoritmanızı istemciye ifşa edeceksiniz. Bilgisayar korsanları, şifrenin karmasını koklayabilir ve daha sonra onu hacklemek için kullanabilir.

HTTPS kullanarak, bir bilgisayar korsanının parolayı tek bir kaynaktan almasını engellersiniz, çünkü HTTPS her ikisi de şifreli olmak üzere iki kanal kullanır.

Bir avantaj olup olmadığı ve daha fazla (veya daha az) güvenli olup olmadığı gerçekten uygulamaya bağlıdır. Muhtemelen bir avantajı var, ancak bunu kötü bir şekilde uygularsanız, düz metinli bir şifre bile geçmekten daha az güvenli olan bir çözüm kesinlikle yaratabilirsiniz.

Buna iki tür saldırı perspektifinden bakılabilir - biri ağ trafiğine erişim, diğeri veri tabanına erişim.

Saldırganınız ağ trafiğinin düz metin sürümünü yakalayabilirse, parolanın karmasını görmek, parolayı düz metin olarak görmekten daha güvenlidir. Saldırgan, bu karmayı kullanarak sunucunuzda yine de oturum açabilse de, diğer sistemlerde yararlı olabilecek parolayı belirlemek için bu karmanın kaba kuvvetle kırılması (bazen önceden hesaplanmış) gerekir. İnsanlar farklı sistemlerde farklı parolalar kullanmalıdır, ancak çoğu zaman kullanmaz.

Bir saldırgan veritabanına, belki de bir yedeğin kopyası yoluyla erişim sağladıysa, yalnızca bu bilgiyle oturum açamayacağından emin olmak istersiniz. Örneğin, oturum açma adı ile tuzlanmış bir karma sakladıysanız hash(login_name+password)ve aynı karmayı istemciden doğrudan karşılaştırma için ilettiyseniz, saldırgan rastgele bir kullanıcı seçebilir, karma değerini veri tabanından gönderebilir ve şu şekilde oturum açabilir: bu kullanıcı şifreyi bilmeden ihlalin kapsamını artırır. Bu durumda, parolayı düz metin olarak göndermek daha güvenli olurdu çünkü saldırganın, veritabanının bir kopyasına sahip olsa bile oturum açmak için düz metni bilmesi gerekirdi. Uygulamanın anahtar olduğu yer burasıdır. İster düz metin parolası ister bu parolanın istemci tarafı karmasını gönderin, sunucu tarafında bu değeri karma hale getirmeli ve bu karmayı kullanıcı kaydında depolanan karma ile karşılaştırmalısınız.

Unutulmaması gereken kavramlar:

• Karma değerinize, tipik olarak satıra özgü olmak üzere, kapsama özgü bir değer katarak bir karmayı "tuzlarsınız". Amacı, temsil ettikleri düz metin değerleri aynı olsa bile birbirlerinden gelen karmaların benzersizliğini garanti etmektir, böylece aynı parolaya sahip iki kullanıcı yine de farklı karmalara sahip olacaktır. Bir tuzu sır olarak ele almak gereksizdir.
• Kimlik doğrulaması yaparken, istemciden bir parola olarak ilettiğiniz değeri her zaman sunucu tarafında hashleyin (zaten karma hale getirilmiş olsa bile) ve veritabanında depolanan önceden karma bir değerle karşılaştırın. Bu, orijinal şifrenin çift karma bir versiyonunun saklanmasını gerektirebilir.
• Bir karma oluşturduğunuzda, arama tablolarında önceden hesaplanmış karmalarla eşleşmeye karşı koruma sağlamak için karmaya sunucuya / kümeye özgü bir tuzun yanı sıra satıra özgü bir tuz eklemeyi düşünün.