Şu anda HTTPS (dolayısıyla SSL şifreli) üzerinden çalışacak bir PHP OpenID sağlayıcısı üzerinde çalışıyorum. Şifreyi düz metin olarak iletmem yanlış
mı ? Teoride HTTPS durdurulamaz, bu yüzden yanlış bir şey görmüyorum. Yoksa bu bir düzeyde güvensiz mi ve bunu göremiyor muyum?
Yanıtlar:
Güvenli. Tüm web böyle çalışır. Formlardaki tüm parolalar her zaman düz metin olarak gönderilir, bu nedenle güvenliğini sağlamak HTTPS'ye bağlıdır.
Yine de GET ile değil, POST isteği ile gönderdiğinizden emin olmanız gerekir. GET isteği ile gönderirseniz, kullanıcının tarayıcı geçmişi günlüklerine veya web sunucusunun erişim günlüklerine düz metin olarak kaydedilebilir.
HTTP devre dışı bırakılmışsa ve yalnızca HTTPS kullanıyorsanız, parolayı zaten düz metin olarak iletmiyorsunuz demektir.
Hash istemci tarafı. Neden? Size küçük bir deneyden bahsedeyim. Şirket kafeteryasında bilgisayara doğru yürüyün. Tarayıcıdan şirket web sitesine giriş sayfası (https) açın. F12'ye basın, ağ sekmesine tıklayın, kalıcı günlüğü işaretleyin, konsolu simge durumuna küçültün ancak web sayfasını oturum açma sayfasına açık bırakın. Otur ve öğle yemeği ye. Çalışan şirketin web sitesinde oturum açtıktan ve işiniz bittiğinde iyi bir küçük işçi olarak oturumu kapattıktan sonra çalışan olarak izleyin. Öğle yemeğini bitirin, bilgisayarda oturup ağ sekmesini açın ve her bir kullanıcı adı ve parolayı düz metin olarak bodys biçiminde görün.
Özel araçlar yok, özel bilgi yok, süslü bilgisayar korsanlığı donanımı yok, tuş kaydediciler yok sadece eski güzel F12.
Ama hey, tek ihtiyacın olanın SSL olduğunu düşünmeye devam et. Kötü adamlar bunun için seni sevecek.
Önceki cevaplara bazı notlar alalım.
İlk olarak, karma algoritmaları istemci tarafında kullanmak muhtemelen en iyi fikir değildir. Parolanız sunucu tarafında korunursa, hash'leri karşılaştıramazsınız (en azından istemci hashini veritabanında şifrenin hashing katmanlarından birinde depolamazsanız, ki bu aynı veya daha da kötüsü). Ve veritabanı tarafından kullanılan hash algoritmasını istemci tarafında uygulamak istemezsiniz, bu aptalca olur.
İkinci olarak, kriptografik anahtarların ticareti de ideal değildir. MITM teorik olarak (istemcide kurulu bir kök sertifikasına sahip olduğu düşünüldüğünde) şifreleme anahtarlarını değiştirebilir ve kendi anahtarlarıyla değişebilir:
Anahtarları değiştiren teorik bir sunucudan orijinal bağlantı (tls dikkate alınmadan):
İstemci genel anahtarlar ister> sunucu özel anahtarları tutar, istemciye genel anahtarlar oluşturur> sunucu müşteriye genel anahtarlar gönderir
Şimdi, teorik bir MITM saldırısında:
İstemci genel anahtarlar ister> MITM sahte özel anahtarlar üretir > Sunucu özel anahtarları tutar, istemciye genel anahtarlar oluşturur> MITM genel anahtarları orijinal sunucudan alır, artık sahte genel anahtarlarımızı istemciye göndermekte özgürüz ve İstemciden bir talep geldiğinde, müşteri verilerinin şifresini sahte anahtarlarla çözeceğiz, yükü değiştireceğiz (veya okuyacağız) ve orijinal genel anahtarlarla şifreleyeceğiz > MITM, istemciye sahte genel anahtarlar gönderir.
Bu, TLS'de güvenilir CA sertifikasına sahip olmanın amacıdır ve bu, sertifika geçerli değilse tarayıcıdan bir uyarı mesajı alırsınız.
OP'ye yanıt olarak: Benim düşünceme göre bunu yapamazsınız, çünkü er ya da geç, birisi hizmetinizden bir kullanıcıya saldırmak isteyecek ve protokolünüzü bozmaya çalışacaktır.
Bununla birlikte, yapabileceğiniz şey, insanların aynı şifre ile oturum açmaya çalışmasını önlemek için 2FA uygulamaktır. Yine de tekrar saldırıların farkında.
Kriptografide pek iyi değilim, lütfen yanılıyorsam düzeltin.
Diğer posterler doğrudur. Artık şifrenin aktarımını şifrelemek için SSL kullandığınıza göre, iyi bir algoritma ve tuzla şifrelediğinizden emin olun, böylece hareketsizken de korunur ...
@CodeDog örneğinde sorunlar var ..
Evet, kullanıcıların bir kafeterya kutusuna giriş yapacağına inanabilirim. Kurumsal bir kafeteryadan günlükleri kaydediyorsanız, güvenlik ihlali sizsiniz demektir . Kurumsal kahve kutuları devre dışı bırakılmalıdır, örn. Terim yok, kaydedici yok, uzaktan erişim yok, vb. Sizi, içerideki hacker'ı önlemek için.
Örnek, bilgisayar erişim güvenliğinin iyi bir örneğidir ve gerçekten ağ güvenliğiyle ilgili değildir. İstemci tarafında hashing için gerekçe olarak sağlanmıştır, ancak eğer bilgisayar erişiminiz varsa, sadece bir tuş vuruşu kaydedici kullanabilir ve bunu atlayabilirsiniz. İstemci tarafındaki hash yine alakasız. @CodeDog'un örneği bir bilgisayar erişim saldırısıdır ve ağ katmanı saldırılarından farklı teknikler gerektirir.
Ayrıca, yukarıda belirtildiği gibi, halka açık bir bilgisayar saldırısı, sistemi tehditlere karşı sakatlayarak korunur. örneğin, halka açık bir kafeterya bilgisayarı için bir chromebook kullanın. Ancak bu fiziksel bir hack tarafından atlanır . Mesai saatleri dışında, kafeteryaya gidin ve kullanıcıların klavye basışlarını kaydetmek için gizli bir kamera kurun. O zaman kafeterya bilgisayarının sakat olup olmadığı veya ne tür bir şifreleme kullanıldığı önemli değildir.
fiziksel katman -> bilgisayar katmanı -> istemci katmanı -> ağ katmanı -> sunucu katmanı
Ağ iletişimi için, istemci tarafında karma oluşturup oluşturmamanız önemli değildir, çünkü https / ssl katmanı düz passwd'yi şifreler. Diğerlerinin de belirttiği gibi, TLS güvenliyse istemci karması gereksizdir.