Parola e-postası tersine çevrilebilirliği kanıtlar, bir şemayı değil

Kullanıcının mevcut parolasını e-postayla gönderen bir hizmet bir şeyi kanıtladı: bu sırrı gönderebildiği bir biçimde elde edebiliyor. Ancak onu hangi sütunun, algoritmanın veya kitaplığın ürettiğini kanıtlamadı. Bu ayrım önemlidir, çünkü bulgu gerçektir ve insanların ondan çıkardığı sonuç genellikle gereğinden fazla kesindir. Yolun bir yerindeki tersine çevrilebilirlik mekanizmadır; tahmin edilen bir saklama biçimi değildir.

Kanıtı bu düzeyde tutun, incelemenin geri kalanı doğru kalır.

Eski sırrın geri gönderilmesi neyi kanıtlar

Tek yönlü bir doğrulayıcı özgün parolayı üretemez, çünkü tersine çevrilemez olacak şekilde tasarlanmıştır. Hizmet parolayı e-postayla gönderebiliyorsa, o anda parolanın kurtarılabileceği bir malzemeyi tutuyordur ya da düz metni karma işleminden önce yakalayıp saklıyordur. Her iki durumda da kurtarma yolu tersine çevrilebilirdir ve bu gerçek bir güvenlik bulgusudur. Aynı veritabanının diğer sütunlar için maliyetli bir karma kullanıp kullanmadığı hakkında hiçbir şey söylemez.

Ara duruma da dikkat edin: uygulamanın elinde tuttuğu bir anahtarla saklanan şifrelenmiş blob pratikte tersine çevrilebilirdir, gerçi şifrelenmiş sözcüğü bir raporda güven verici kulağa gelir.

Bu neden bir tasarım bulgusu, bir saklama haritası değil

E-posta kurtarılabilirliği kanıtlar ve tam şemayı tanımlamaz. Düz metin, belirleyici şifreleme, bir satıcının gizleme rutini veya yalnızca kurtarma için kullanılan ayrı bir kimlik bilgisi deposu olabilir. Bir ürünün farklı bölümleri çoğu zaman farklı saklama kullanır. Tek bir e-postaya dayanarak algoritma atamak, bir sonraki toplantıda çöken türden bir iddiadır.

Söyleyebileceğiniz şey daha dar ve daha yararlıdır: bu yol sırrı kurtarabiliyor, dolayısıyla ürün kurtarılabilir bir kimlik bilgisi bulunmadığını iddia edemez. Bunun ötesindeki her şey işletmecinin kanıtını gerektirir.

Sıfırlamayı yetkilendirme etrafında kurun

Sıfırlama başka bir sorunu çözer: talep edenin yeni bir parola seçebileceğini kanıtlamak. OWASP'ın bu konudaki rehberi, uygun son kullanma tarihiyle güvenli biçimde üretilmiş tek kullanımlık belirteçler veya kodlar tanımlar ve talep aşamasını sayım ile taşkına karşı korunması gereken bir şey olarak ele alır. Kimliği doğrulanmamış bir talep hesabı kendi başına değiştirmemelidir. Değiştirmeyi kabul etmeden önce yetkilendirmeyi doğrulayın ve belirteci bir başarılı kullanımdan sonra kullanılamaz hale getirin.

E-posta kanalı güvenlik modelinin bir parçasıdır. Bir hesap adına sahip olmak hiçbir şeyi kanıtlamaz ve bir hesabın var olup olmadığını açığa vuran bir sıfırlama akışı saldırgana çalışacağı bir dizin verir.

Parolanın koruduğu şeyi geçersiz kılın

Parola değiştirmek, onun verdiği erişimi otomatik olarak sona erdirmez. Etkin VPN oturumları, hatırlanan cihazlar ve sunucunun verdiği belirteçlerin her birinin kendi geçersiz kılma davranışı olabilir. Hangilerinin sona ermesi gerektiğine bilinçli olarak karar verin ve uygulamanın bunu yaptığını doğrulayın, çünkü bir sıfırlamanın kendisini her yerden çıkardığını varsayan kullanıcı çoğu zaman yanılır. Bu kararı akışla birlikte kaydedin.

İşletmeciler için: talebi hangi bileşenin doğruladığını, hangisinin kimlik bilgisini değiştirdiğini ve ilgili oturumların nasıl ele alındığını belgeleyin. Kullanıcılar için: meşru kurtarma kanalını koruyun ve parola geri gönderen her iletiyi şüpheli sayın.

Kesin değerlendirme kısadır: iletinin neyi kanıtladığı, neyin bilinmez kaldığı ve kurtarmanın erişimi denetimli bir süreçle değiştirip değiştirmediği.