Diyelim ki veritabanımda tuz içeren karma şifreleri oldukça pahalı bir karma (scrypt, 1000 SHA2 turu, neyse).
Giriş yaptıktan sonra, ağ üzerinden ne aktarmalıyım ve neden? Parola mı yoksa karma mı?
Bu tür bir girişi HTTP gibi şifrelenmemiş bir kanal üzerinden korumak mümkün müdür?
Karma istemciden aktarılırsa, bu hiçbir güvenlik avantajı sağlamaz ve karma değerini anlamsız hale getirir:
Bir kullanıcı hash'i sunucuya göndererek giriş yapabilirse, hash etkili bir şekilde şifredir.
Kimlik doğrulama protokolünüz sunucuya düz HTTP ile bir şifre veya şifre karması göndermekse, bu iki nedenden dolayı doğal olarak çok zayıftır:
Hatta casusluk yapan biri müşterinin ne gönderdiğini kaydedebilir. Yalnızca bu baytları göndermek erişim izni veriyorsa, saldırgan onları tekrar gönderebilir. Bu bir tekrar saldırı . Bu sorun @AviD'nin cevabında ima ettiği şeydir. Bunu hiçbir miktarda karma yapmaz. Bazı protokoller, istemcideki parola ile birlikte karmalaştırılmak üzere sunucudan bir "meydan okuma" (her bağlantı için yeniden oluşturulan rastgele bir değer) ekleyerek bu sorunu gidermeye çalışır; HTTP Özet kimlik doğrulaması işte budur.
Kimlik doğrulama işe yaramış olsa bile, bu hala düz HTTP'dir, bu nedenle hangi veriler gönderilecekse sonradan saldırganların dinlemelerine ve değişikliklerine karşı savunmasız olacaktır. Taşıma ortamı korunmuyorsa, kimlik doğrulama yalnızca saldırganların en karmaşık olmayanlarını caydırır. Burada HTTP Özeti başarısız olur.
Bu nedenle, yalnızca SSL'ye (HTTPS olarak da bilinir) ihtiyacınız vardır, sadece şifreyi veya karma değerini iletmek için değil, aynı zamanda istemci ve sunucu arasındaki konuşmanın geri kalanını da .
Bundan sonra protokolün bir SSL tüneli içinde çalıştırıldığını varsayacağım. Bcrypt veya PBKDF2 gibi bir yavaş karma kullanmak isteme hakkınız var; maliyet paylaşımını önlemek için a tuz gerektiğine dikkat edin (örn. önceden hesaplanmış tablolar). Yavaş, tuzlanmış karma, şifrelerin içsel zayıflığı ile başa çıkmak için kullanılır. Şimdi, istemcideki karma işleminin bir kısmını boşaltmak isteyebilirsiniz. Bu mayıs işe yarar, ancak bazı pratik sorunlar ortaya çıkarır:
Parola işlemenin her bir parola örneği için yeni bir tuz içermesi gerektiğinden, istemcinin gerçekleştirdiği karma işlemine dahil edebilmesi için tuz istemciye iletilmelidir. Bu, protokol karmaşıklığını artırır: istemci önce kullanıcı adını sunucuya göndermeli, sonra sunucu tuzu geri göndermelidir ve (ancak o zaman) istemci parolayı hash etmeye başlayabilir. Bu, her zamanki "kullanıcı adını ve şifreyi bir POST istek olarak gönder) ile olduğundan bir ağ gidiş dönüşüdür.
Yavaş karma, her parola için çok fazla CPU harcamayı kabul etmekle ilgilidir, böylece saldırgan ayrıca her parola için çok fazla CPU harcamak zorundadır. Ancak harcanan CPU istemcide ise, o zaman istediğimiz kadar yükseltemeziz, çünkü: 1) çok az CPU'lu (bazı ucuz akıllı telefonlar veya tabletler diyelim) ve 2) Web bağlamı Javascript kullanarak ve Javascript performansı karma söz konusu olduğunda gerçekten kötüdür (C kodundan en az 20 kat daha yavaş).
Bu nedenle her zamanki bilgelik, istemcide şifre karma işleminin bir parçasını oluşturmanın çabaya değmemesidir.
Her iki seçenek de güvensizdir.
Parolanın aktarılması protokolünüzü düz metin yapar. Karma aktarımı, tekrar saldırılara karşı savunmasız kalmanızı sağlar.
APOP, POP protokolü için bir oturum açma uygulamasıdır. Bu, protokolün ağdaki herhangi bir dinleyiciden şifreyi gizli tutmasına izin verir. Bunun bir dezavantajı, hem istemci hem de sunucunun şifreyi düz metin olarak bilmesi gerektiğidir, çünkü bu paylaşılan sırdır. Protokolden önce hem istemci hem de sunucuda <password> bulunur. Protokol iletişimi temelde şöyle:
Burada sunucu hem sihri hem de şifreyi bilir ve kullanıcının herhangi bir dinleyiciye maruz kalmadan doğru şifreyi bilip bilmediğini belirleyebilir.
En iyi uygulama, karmaları veritabanında güvenli bir şekilde saklamak ve şifreli kanallara güvenmek olacaktır.