İstemci tarafında şifreleri karıştırmaya değer mi

Bir oturum açma sistemi kurmak istediğimde, verilen parolanın MD5'ini her zaman sunucu tarafındaki kullanıcılar tablosundaki değeriyle karşılaştırırım.

Ancak bir arkadaşım, bir ağ yazılımı tarafından "açık" bir parolanın koklanabileceğini söyledi.

Öyleyse sorum şu: İstemci tarafında şifreyi karıştırmak iyi bir fikir mi? Sunucu tarafında hashing yapmaktan daha mı iyi?

Temel olarak, arkadaşın haklı. Ama sadece istemci tarafında parola karma sadece sadece sunucuya düz metin olarak göndermeden daha iyi. Düz metin şifrelerinizi dinleyebilen bir kişi kesinlikle karma şifreleri de dinleyebilir ve bu yakalanan karmaları sunucunuza karşı kimlik doğrulaması yapmak için kullanabilir.

Bu konuda, daha güvenli kimlik doğrulama protokolleri genellikle, böyle bir tekrar saldırısının, genellikle istemcinin parola ile birlikte karma hale getirilmiş bir grup rastgele bit seçmesine izin vererek işe yaramayacağından emin olmak için birkaç çemberden geçer. ve ayrıca sunucuya açık olarak gönderilir.

Sunucuda:

• birkaç bit rastgele oluştur
• bu bitleri (açık metin olarak) müşteriye gönderin

İstemci hakkında:

• birkaç rastgele bit üret
• parolayı, sunucunun rastgele bitlerini ve istemci rastgele bitlerini birleştir
• yukarıdakinin karmasını oluştur
• rastgele bitleri (düz metin olarak) gönderin ve sunucuya karma oluşturun

Sunucu kendi rastgele bilgisinin yanı sıra müşterinin rastgele bitlerini de bildiği için (bunları açık metin olarak aldı), esasen aynı dönüşümü gerçekleştirebilir. Bu protokol, her iki taraf da her seferinde farklı "parazit bitleri" ürettiği sürece, bu konuşmayı dinleyen hiç kimsenin, kaydedilen bilgileri yanlış bir şekilde kullanarak kimlik doğrulaması yapmak için (çok zayıf bir algoritma kullanılmadıkça ...) bilgiyi kullanmamasını sağlar. el sallama gerçekleştirilir.

Düzenle Tüm bunlar hataya açık ve sıkıcıdır ve doğru yapılması biraz zordur (okuyun: güvenli). Mümkünse, zaten bilgili kişiler tarafından yazılmış kimlik doğrulama protokolü uygulamalarını kullanmayı düşünün (benden farklı olarak! Yukarıdakiler yalnızca bir süre önce okuduğum bir kitabın belleğidir.) Bunu genellikle kendiniz yazmak istemezsiniz.

Her şeyden önce, bu mu DEĞİL uygulamanızın güvenliğini artırmak (varsayarak bir webapp).

SSL kullanın (veya aslında genellikle SSL olarak adlandırılan TLS), gerçekten pahalı değil (Etrafında yollar bulmak için kullandığınız zamanı ölçün ve asgari ücretle çarpın, sertifika satın almak neredeyse her zaman kazanır).

Bunun nedeni basit. TLS, kriptografide oldukça büyük olan bir sorunu (satın alınan sertifikalarla kullanıldığında, kendinden imzalı değil) çözer: Konuştuğum sunucunun konuştuğumu düşündüğüm sunucu olduğunu nasıl anlarım? TLS Sertifikaları şunu söylemenin bir yoludur: "Tarayıcınızın güvendiği sertifika yetkilisi, [url] adresindeki web sitesinin bu genel anahtara sahip olduğunu onaylar ve buna karşılık gelen bir özel anahtara (özel anahtar) yalnızca sunucunun bildiği İmzamı belgenin her yerine imzaladım, eğer biri değiştirdiyse görebilirsin ".

TLS olmadan şifreleme anlamsız hale gelir, çünkü yanınızda bir kafede oturursam, dizüstü bilgisayarınızın / akıllı telefonunuzun sunucu olduğumu ve MiTM (Ortadaki Adam) olduğunuzu düşünmesini sağlayabilirim. TLS ile, sitenizle eşleşen sertifika yetkilisi imzalı bir sertifikam olmadığı için dizüstü bilgisayarınız / akıllı telefonunuz "GÜVENİLİR BAĞLANTI" diye bağıracak. (Şifreleme ve Kimlik Doğrulama).

Sorumluluk reddi: kullanıcılar şu uyarıları sağ tıklama eğilimindedir: "Güvenilmeyen bağlantı? Ne? Sadece kedi fotoğraflarımı istiyorum! İstisna Ekle Onayla'yı tıklayın YAY tıklayın ! Yavru kediler!"

Bununla birlikte, gerçekten bir sertifika satın almak istemiyorsanız, yine de istemci tarafı javascript karma oluşturma YAPIN (ve bunun için standford kitaplığını (SJCL) kullanın, KRİPTO'U KENDİNİZE ASLA UYGULAMAYIN ).

Neden? Parolanın yeniden kullanılması! HTTPS olmadan oturum tanımlama bilginizi (bu da sunucunuza sizmişim gibi davranmama izin verir) kolayca HTTPS olmadan çalabilirim (bkz. Ateş sayfası). Bununla birlikte, oturum açma sayfanıza, göndermeden önce parolanızı karma hale getiren bir javascript eklerseniz (SHA256 kullanın veya daha iyisi, SHA256 kullanın, onlara oluşturduğunuz bir genel anahtar gönderin ve ardından parolayı bununla şifreleyin, bir tuz kullanamazsınız bununla) ve ardından karma / şifrelenmiş parolayı sunucuya gönderir. Sunucunuzdaki hash'i bir tuzla YENİDEN HABERDAR EDİN ve bunu veritabanınızda depolananlarla karşılaştırın (parolayı şu şekilde saklayın:

(SHA256(SHA256(password)+salt))

(tuzu veritabanında düz metin olarak da kaydedin)). Ve şifrenizi şu şekilde gönderin:

RSA_With_Public_Key(SHA256(password))

ve şifrenizi şu şekilde kontrol edin:

if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok

Çünkü EĞER Birisi müşteri koklama edilir, bunlar istemci (oturum kaçırma) olarak giriş mümkün olacak ama olacak ASLA (düz metin parolası bkz onlar javascript değiştirmek sürece, ancak, bir korsan muhtemelen belgede; anlayamayacaksınız / ilgi Starbucks Bu yüzden web uygulamanıza erişecekler, ancak e-postalarına / facebook / vb. (kullanıcılarınız muhtemelen aynı parolayı kullanacaktır). (E-posta adresi ya giriş adı olacaktır ya da web uygulamanızdaki profillerinde / ayarlarında bulunacaktır).

Muhtemelen bu konuda endişelenmenize gerek yok - çünkü Dirk, şifreleri karma haline getirseniz bile kötü niyetli bir kullanıcı bir ağda olabilir ve karmanın gönderildiğini görebilir ve aynı karmayı kendileri gönderebilir.

Öyle biraz o şifre ne olduğunu bilen kötü niyetli kullanıcının önlediğini de, daha iyi, ama yine de giriş (veya potansiyel beri orijinal şifreyi yeniden ), bu yararlı olmadığını.

Genel olarak, kullanıcı şifrelerinin ve verilerinin güvenliği konusunda endişeleriniz varsa (ve olmalısınız!), Güvenli bir SSL sunucusu kullanmak isteyeceksiniz. Bu sizin için herhangi bir sebepten endişe duymuyorsa, hashing ile uğraşmayabilirsiniz; sadece belirsizlik yoluyla güvenlik .

Ağustos 2014'ü Düzenleyin: Google, web sitelerinin her yerde HTTPS'ye geçmesi için gittikçe daha güçlü bir şekilde baskı yapıyor , çünkü iletişimin güvenliğini sağlamak ağ koklama saldırılarını önlemenin tek yoludur. Aktarılan verileri gizleme girişimleri, adanmış bir saldırganı durdurmaz, yalnızca engeller ve geliştiricilere tehlikeli ve yanlış bir güvenlik hissi verebilir.

Aslında, bu durumda istemci tarafında hashing işleminin daha güvenli olduğuna katılmıyorum. Sanırım daha az güvenli.

Veritabanınızda gerçek parola (veya hatta şifrelenmiş bir parola) yerine parolanın bir karmasını depolamanın tüm amacı, orijinal parolayı bir hash'den elde etmenin matematiksel olarak imkansız olmasıdır (teorik olarak bir çarpışmayı elde etmek mümkün olsa da karma girdisi, zorluğu karma algoritmanın güvenlik gücüne bağlıdır). Buradaki olası saldırı vektörü, potansiyel bir saldırganın parola depolama veritabanınızı bir şekilde tehlikeye atması durumunda, kullanıcılarınızın orijinal parolalarını yine de alamayacağıdır.

Kimlik doğrulama mekanizmanız parola için bir karma gönderirse, bu durumda bu güvenlik ihlali senaryosunda, saldırganın gerçek parolayı bilmesine gerek yoktur - yalnızca sahip oldukları hash'i gönderir ve en önemlisi, belirli bir kullanıcının hesabına erişebilirler, ve uzantı olarak, tüm sisteminiz. Bu, ilk etapta karma bir şifre saklama noktasını tamamen ortadan kaldırır!

Bunu yapmanın gerçekten güvenli yolu, istemciye parolayı şifrelemesi için tek seferlik bir genel anahtar göndermektir, ardından da şifresini çözer ve sunucu tarafında yeniden hash hale getirirsiniz.

Bu arada, bu tür sorular muhtemelen Güvenlik StackExchange'de daha fazla uzman yanıtı alacaktır.

Şifreleri üçüncü şahıslara karşı güvende tutmanın tek anlamı olmadığını unutmayın.

En kısa sürede olarak gizlilik ilgilenmektedir (ve bunu olmadığında hiç bu günlerde?) Eğer şifreyi bilmek istemiyorum. Sen istismar ya da yoktur ne sızdıramam sahip Hiç onların düz metin şifreleri hiç görmesem hem sizin hem de müşterilerine daha iyi uyuyabilir.

Bu nedenle, istemci tarafında hashing / şifreleme mantıklıdır.

Değişir, istemci tarafı hashing kullanabilirsiniz, ancak sunucu tarafında tuz mümkün olmayacaktır.

İstemci tarafındaki Parola şifreleme bağlantısına bir göz atın

Son zamanlarda bunun üzerinde çok çalışma yapıyorum, IRL'nin istemci tarafı hash / simetrik şifrelemeyle ilgili iki sorunu var ve bu fikri gerçekten öldürüyor: 1. Tuzu BAZEN sunucuya geri getirmelisin ... ve şifrelemelisin İstemci tarafında, amacı geçersiz kılan bir şifreye ihtiyacınız olacaktır. 2. Hashing uygulamanızı açığa çıkarırsınız (çoğu site 3 veya 4 hashing algosundan birini kullandığından BÜYÜK bir anlaşma değildir), bu da saldırıyı kolaylaştırır (n yerine birini denemek gerektiği gibi).

Nihayetinde OpenPGP.js veya benzerini kullanarak istemcide asimetrik şifrelemeye gittim ... Bu, istemcide içe aktarılan veya istemci tarafında üretilen bir anahtara ve sunucunun açık anahtarı göndermesine dayanır. Yalnızca istemcinin genel anahtarı sunucuya geri gönderilebilir. Bu, MIM saldırılarına karşı koruma sağlar ve cihaz kadar güvenlidir (şu anda istemcinin özel anahtarını varsayılan olarak localStore'da saklıyorum, bu bir demo).

Bunun en önemli avantajı, kullanıcı verilerinin hiçbir zaman sunucumda / veri depomda şifrelenmemiş bellekte saklanması gerekmemesidir (ve sunucumun özel anahtarı fiziksel olarak ayrıdır)

Bunun temeli, insanlara HTTPS'nin kısıtlandığı yerlerde (örn. İran / K. Kore ...) güvenli bir şekilde iletişim kurmanın bir yolunu ve aynı zamanda sadece eğlenceli bir deney sağlamaktı.

Bunu ilk düşünen ben UZAK, http://www.mailvelope.com/ bunu kullanıyor

Birisi bağlantınızdaki verileri girip çıkarsa, kimlik doğrulaması sizi kurtarmaz. Bunun yerine, süper gizli şeyler için aşağıdakileri yapardım.

Parolalar sunucuya gönderilmeden önce istemci tarafında önceden karıştırılır. (Sunucu, tarayıcıdan gönderilen bu hash'in başka bir karma ve tuzlanmış değerini depolar).

Bu nedenle, bir orta adam saldırısı, kendileriyle aynı karma değeri oturum açmak için göndermelerine izin verebilir, ancak kullanıcı şifresi bilinmeyecektir. Bu, başka bir yerde oturum açmak için aynı kimlik bilgilerine sahip diğer hizmetleri denemelerini engelleyecektir.

Kullanıcı verileri tarayıcı tarafında da şifrelenir.

Ah, yani bir orta adam saldırısı şifrelenmiş verileri alır, ancak oturum açmak için kullanılan gerçek şifre olmadan şifresini çözemez. (oturum açtıklarında tarayıcıdaki DOM'da saklanan kullanıcı şifresi). Böylece gerçek kullanıcı şifresi çözülen içeriği görebilir, ancak aracı göremez. Bu aynı zamanda herhangi bir NSA veya başka bir ajansın sizden / şirketten / barındırma sağlayıcısından bu verilerin şifresini çözmesini talep edemeyeceği anlamına gelir, çünkü onlar için de bunu yapmaları imkansızdır.

Bu iki yöntemin bazı küçük örnekleri blogumda http://glynrob.com/javascript/client-side-hashing-and-encryption/

Son zamanlarda hem GitHub hem de Twitter, şifrelerin dahili günlüklerde depolandığını duyurdu. Hata raporlarında ve diğer günlüklerde farkında olmadan böyle bir durum yaşadım. Twitter için, Trump'ın şifresi oradaysa, bir yöneticinin "görmesi" büyük bir sorun olabilirdi, muhtemelen diğer siteler için Yöneticilerin buna pek bir faydası olmayacağından büyük bir anlaşma. Yöneticiler olarak biz şifreleri görmekten hoşlanmayız.

Yani asıl soru, gerçekten de güvenlik için hashing işleminin istemci tarafında gerçekleşmesi gerekip gerekmediğidir, ancak nihayetinde hash işlemi uygulanmadan ve sunucu tarafında karşılaştırılmadan önce parolayı nasıl koruyabiliriz ki bir şekilde günlüğe kaydedilmez.

Şifreleme kötü bir fikir değildir çünkü geliştiriciler en azından bazı çemberlerden geçmek zorundadır ve eğer şifrelerin günlüklere girdiğini fark ederseniz, şifreleme anahtarını değiştirebilir, orijinali yok edebilirsiniz ve bu veriler işe yaramaz hale gelir. Daha da iyisi, tuşları her gece döndürürseniz, pencereler büyük ölçüde küçülebilir.

Ayrıca kullanıcı kaydınızda bir karma hash uygulayabilirsiniz. Sızan şifreler, hash edilmiş düz metin şifreler olacaktır. Sunucu, karmanın karma bir sürümünü depolar. Elbette karma parola olur, ancak fotoğrafik bir belleğiniz yoksa 60 karakterlik bir bcyrpt hatırlamayacaksınız. Kullanıcı adıyla tuzlayın. Giriş işlemi sırasında kullanıcı hakkında bir şeyler toplayabilirseniz (kullanıcı kaydının var olduğunu ifşa etmeden), bunun yanı sıra siteler arasında paylaşılamayan daha sağlam bir hash oluşturabilirsiniz. Ortadaki hiçbir adam, yakalanan hash'i siteler arasında kesip yapıştıramaz.

Sunucuya geri gönderilmeyen bir çerezle birleştirin ve bir şeyle karşılaşabilirsiniz. İlk talepte, müşteriye bir anahtarla birlikte bir çerez gönderin, ardından çerezin oturum açma hizmetine geri dönmediğinden emin olun, bu kadar az şansla oturum açın. Anahtarı bir oturum deposunda saklayın ve oturum açtıktan hemen sonra veya oturum sona erdiğinde silin ... bu sizin için durum gerektirir JWT adamları, ancak bunun için sadece bir nosql hizmeti kullanın.

Böylece, yolun aşağısında bir yönetici, splunk veya bir hata raporlama aracında bu karma ve şifrelenmiş parolalardan birine rastlar. Artık şifreleme anahtarını bulamadıklarından ve bulsalar bile bir hash'i kaba kuvvetle zorlamaları gerektiğinden, onlar için faydasız olmalı. Ek olarak, son kullanıcı hat boyunca herhangi bir düz metin göndermedi, bu yüzden ortadaki herhangi bir adam en azından daha zor anlar yaşar ve başka bir siteye atlayıp oturum açamazsınız.

Bunu düşün:-

İstemci, "Doğrulamak için bir parolam var" sunucusuna istek gönderir.

Sunucu, istemciye yalnızca bir kerelik rastgele bir dize gönderir. R $

Müşteri, kullanıcının parolasını bu dizeye yerleştirir (uygulamak istediğiniz (değişken) kurallara göre).

İstemci dizeyi sunucuya gönderir ve şifre uygunsa, sunucu kullanıcının oturum açmasını sağlar.

Sunucu, R $ kullanarak başka bir oturum açma isteği alırsa, kullanıcının oturumu kapatılır ve hesap, inceleme için dondurulur.

Açıkçası, diğer tüm (normal) güvenlik önlemleri alınacaktır.

Bu istemci tarafı hashing fikri sitenizi değil kullanıcıyı korumaktır. Daha önce birçok kez belirtildiği gibi, düz metin veya karma şifreler sitenize eşit şekilde erişebilir. Bir güvenlik avantajı almazsınız.

Ancak kullanıcılarınızın gerçek, düz metin, şifresi yalnızca onlar tarafından bilinmelidir. Parola olarak neyi seçtiklerini bilmek, diğer sitelerde ve sistemlerde kendilerine karşı kullanılabilecek bilgilerdir. Parola seçimlerinin sunucu geliştiricileriniz veya üçüncü taraflarca keşfedilmesini önleyerek müşteri odaklı bir site oluyorsunuz.