HTTP üzerinden güvenli bir şekilde şifre nasıl gönderilir?

Bir oturum açma ekranında kullanıcı, kullanıcı adı ve şifresiyle bir form gönderirse, şifre düz metin olarak gönderilir (POST ile bile, yanılıyorsam düzeltin).

Öyleyse soru, kullanıcıyı ve şifresini, iletişim verilerini gizlice dinleyen üçüncü şahsa karşı korumanın doğru yolu nedir?

HTTPS'nin soruna bir çözüm olduğunun farkındayım, ancak standart HTTP protokolünü (POST isteği) kullanarak en azından bir düzeyde güvenlik sağlamanın bir yolu var mı? (belki bir şekilde javascript kullanarak)

EDIT Bazı önemli şeyleri atlamış olabilirim.

Söz konusu olan bir sayfaydı - bu, elbette bir HTML dosyası olarak HTTP GET isteğinde kullanıcıya gönderilen PHP tarafından oluşturulan oturum açma sayfasıydı. Sunucu ile istemci arasında (@Jeremy Powel) bağlantı kurulmadı, bu yüzden böyle bir anlaşma protokolü oluşturamıyorum. Ve tüm sürecin kullanıcıya şeffaf olmasını istiyorum - kriptografi ile uğraşmak değil, bir şifre göndermek istiyor.

Teşekkürler.

SSL ile HTTP kullanmak hayatınızı çok daha kolay hale getirecek ve rahatça dinlenebilirsiniz çok zeki insanlar (en azından benden daha akıllı!) Bu gizli iletişim yöntemini yıllardır incelediler.

Güvenli kimlik doğrulama geniş bir konudur. Özetle, @ jeremy-powell'in bahsettiği gibi, kimlik bilgilerini her zaman HTTP yerine HTTPS üzerinden göndermeyi tercih edin. Güvenlikle ilgili birçok baş ağrısını ortadan kaldıracaktır.

TSL / SSL sertifikaları bugünlerde oldukça ucuz. Aslında hiç para harcamak istemiyorsanız, ücretsiz bir letsencrypt.org - otomatikleştirilmiş Sertifika Yetkilisi var.

Sen bir adım daha ileri gidip kullanabilirsiniz caddyserver.com aramalar arka planda letsencrypt hangi.

Şimdi, HTTPS'yi ortadan kaldırdığımızda ...

POST verisi veya GET parametreleri ile kullanıcı adı ve şifre göndermemelisiniz. Bunun yerine, aşağıdaki gibi oluşturulmuş bir Yetkilendirme başlığı (Temel erişim kimlik doğrulama şeması) kullanın:

• Kullanıcı adı ve şifre, iki nokta üst üste ile ayrılmış bir dizede birleştirilir, örneğin: kullanıcı adı: şifre
• Elde edilen dize, 76 karakter / satır ile sınırlı olmamak üzere Base64'ün RFC2045-MIME varyantı kullanılarak kodlanır.
• Yetkilendirme yöntemi ve bir boşluk, yani "Temel" kodlanmış dizeden önce yerleştirilir.

kaynak: Wikipedia: Yetkilendirme başlığı

Biraz karmaşık görünebilir ama öyle değil. Kutudan çıkar çıkmaz bu işlevselliği size sağlayacak çok sayıda iyi kitaplık var.

Yetkilendirme başlığı kullanmanız için birkaç iyi neden vardır

1. Bu bir standart
2. Basit (nasıl kullanılacağını öğrendikten sonra)
3. URL düzeyinde şu şekilde oturum açmanıza izin verir: https://user:password@your.domain.com/login(Örneğin Chrome, bunu otomatik olarak Authorizationbaşlığa dönüştürür )

ÖNEMLİ:
@zaph'ın aşağıdaki yorumunda işaret ettiği gibi, hassas bilgilerin GET sorgusu olarak gönderilmesi, büyük olasılıkla sunucu günlüklerinde sonuçlanacağından iyi bir fikir değildir.

Bir sorgulama yanıt şeması kullanabilirsiniz. İstemcinin ve sunucunun her ikisinin de gizli bir S bildiğini söyleyin. Ardından sunucu, istemcinin parolayı bildiğinden (parolayı vermeden) emin olabilir:

1. Sunucu istemciye rastgele bir sayı (R) gönderir.
2. İstemci, H (R, S) 'yi sunucuya geri gönderir (burada H, SHA-256 gibi kriptografik bir hash işlevidir)
3. Sunucu H (R, S) 'yi hesaplar ve istemcinin yanıtıyla karşılaştırır. Eşleşirlerse, sunucu istemcinin parolayı bildiğini bilir.

Düzenle:

Burada R'nin tazeliğiyle ve HTTP'nin durumsuz olmasıyla ilgili bir sorun var. Bu, sunucunun yalnızca sunucunun bildiği bir sırrı oluşturmasını sağlayarak ele alınabilir . Daha sonra protokol şöyle olur:

H (R, Q) müşteri tarafından taklit edilemeyeceğinden, H (R, Q) bir çerez görevi görür (ve bu nedenle aslında bir çerez olarak uygulanabilir).

Başka Bir Düzenleme:

Protokoldeki önceki düzenleme yanlıştır, çünkü H (R, Q) 'yu gözlemleyen herhangi biri onu doğru hash ile yeniden oynatabilir gibi görünüyor. Sunucu, hangi R'lerin artık taze olmadığını hatırlamak zorundadır. Bu cevabı CW'lıyorum, böylece siz bu konuyu düzeltip iyi bir şeyler yapabilirsiniz.

Web barındırıcınız izin veriyorsa veya hassas verilerle uğraşmanız gerekecek, o zaman HTTPS'yi kullanın. (Genellikle afaik yasa gereği).

Aksi takdirde, HTTP üzerinden bir şey yapmak istiyorsanız. Böyle bir şey yapardım.

1. Sunucu, genel anahtarını oturum açma sayfasına yerleştirir.
2. Müşteri, giriş formunu doldurur ve gönder düğmesine tıklar.
3. AJAX isteği, sunucudan geçerli zaman damgasını alır.
4. İstemci tarafı komut dosyası, kimlik bilgilerini, zaman damgasını ve bir tuzu birleştirir (analog verilerden karma hale getirilir, örn. Fare hareketleri, tuşa basma olayları), açık anahtarı kullanarak şifreler.
5. Ortaya çıkan hash'i gönderir.
6. Sunucu karmanın şifresini çözer
7. Zaman damgasının yeterince güncel olup olmadığını kontrol eder (yalnızca 5-10 saniyelik kısa bir pencereye izin verir). Zaman damgası çok eskiyse oturumu reddeder.
8. Hash'i 20 saniye saklar. Bu aralıkta oturum açma için aynı karmayı reddeder.
9. Kullanıcının kimliğini doğrular.

Bu şekilde parola korunur ve aynı kimlik doğrulama hashı tekrar oynatılamaz.

Oturum jetonunun güvenliği hakkında. Bu biraz daha zor. Ancak çalınan bir oturum jetonunu yeniden kullanmayı biraz daha zor hale getirmek mümkündür.

1. Sunucu, rastgele bir dizge içeren fazladan bir oturum tanımlama bilgisi ayarlar.
2. Tarayıcı, bir sonraki talepte bu çerezi geri gönderir.
3. Sunucu tanımlama bilgisindeki değeri kontrol eder, eğer farklıysa, oturumu yok eder, aksi takdirde her şey yolundadır.
4. Sunucu, çerezi farklı bir metinle yeniden ayarlar.

Dolayısıyla, oturum jetonu çalınırsa ve başka biri tarafından bir istek gönderilirse, orijinal kullanıcının bir sonraki isteğinde oturum yok edilir. Dolayısıyla, kullanıcı siteye aktif olarak göz atıyorsa, bağlantılara sık sık tıklarsa, hırsız çalınan jetonla fazla ileri gitmez. Bu şema, hassas işlemler için (hesap silme gibi) başka bir kimlik doğrulaması gerektirerek güçlendirilebilir.

DÜZENLEME: Saldırganın kendi sayfasını farklı bir genel anahtarla kurması ve sunucuya proxy istekleri yapması durumunda, bunun MITM saldırılarını engellemediğini lütfen unutmayın. Buna karşı korunmak için genel anahtar, tarayıcının yerel depolama alanına veya bu tür hileleri algılamak için uygulama içine sabitlenmelidir.

Uygulama hakkında: RSA muhtemelen en bilinen algoritmadır, ancak uzun anahtarlar için oldukça yavaştır. Bir PHP veya Javascript uygulamasının ne kadar hızlı olacağını bilmiyorum. Ama muhtemelen daha hızlı algoritmalar var.

İnternette iyi bir uygulama görmeme rağmen, AJAX veya çoklu form gönderimiyle sunucu tarafı ve istemci tarafı Diffie-Hellman anahtar değişim sistemi kullanırdım (ilkini öneririm). Bir JS kitaplığının her zaman MITM tarafından bozulabileceğini veya değiştirilebileceğini unutmayın. Yerel depolama, bununla bir dereceye kadar mücadele etmek için kullanılabilir.

Güvenli olmayan bir kanal üzerinden güvenli parolalar kullanmak için SRP'yi kullanabilirsiniz. Bunun avantajı, bir saldırgan trafiği koklasa veya sunucuyu tehlikeye atsa bile, parolaları farklı bir sunucuda kullanamamasıdır. https://github.com/alax/jsrp , tarayıcıda veya sunucu tarafında (düğüm yoluyla) HTTP üzerinden güvenli şifreleri destekleyen bir javascript kitaplığıdır.

HTTPS çok güçlüdür çünkü asimetrik kriptografi kullanır. Bu tür bir kriptografi yalnızca şifrelenmiş bir tünel oluşturmanıza izin vermekle kalmaz, aynı zamanda bir bilgisayar korsanıyla değil, doğru kişiyle konuştuğunuzu doğrulayabilirsiniz.

İletişim için asimetrik şifreleme RSA'yı (PGP tarafından kullanılan) kullanan Java kaynak kodu: http://www.hushmail.com/services/downloads/

barındırıcınız için ssl kullanabilirsiniz, letencrypt https://letsencrypt.org/ gibi ssl için ücretsiz proje vardır.

Https kullanmak en iyi seçenek burada (sertifikalar günümüzde o kadar pahalı değil). Bununla birlikte, http bir gereklilikse, bazı kodlama kullanabilirsiniz - bunu sunucu tarafında enkript edin ve kullanıcıların tarayıcısında decript (anahtarı ayrı olarak gönderin).

Safevia.net'i uygularken bunu kullandık - şifreleme istemciler (gönderen / alıcı) tarafında yapılır, bu nedenle kullanıcı verileri ağda veya sunucu katmanında mevcut değildir.