Yakın zamanda, güvenli bir parola sıfırlama özelliğinin nasıl çalışması gerektiği hakkında tekrar düşünmeye zamanım oldu; ilk olarak bu işlevi, ve sonra başka bir kişinin benzer bir şey yapmasına yardım ettiğinde. İkinci durumda, sıfırlama işlevinin güvenli bir şekilde nasıl uygulanacağına ilişkin tüm ayrıntıların yer aldığı kanonik bir kaynağa bağlantı vermek istedim. Ancak sorun şu ki, böyle bir kaynağın mevcut olmaması, en azından benim için önemli görünen her şeyi açıklayan bir kaynağın olmaması. Bu yüzden kendim yazmaya karar verdim.
Görüyorsunuz, unutulan şifrelerin dünyası aslında oldukça gizemli. Pek çok farklı, tamamen kabul edilebilir bakış açısı ve oldukça tehlikeli bakış açıları var. Muhtemelen her biriyle son kullanıcı olarak birçok kez karşılaşmışsınızdır; bu yüzden bu örnekleri kimin doğru yaptığını, kimin yapmadığını ve bu özelliği uygulamanızda doğru bir şekilde kullanmak için neye odaklanmanız gerektiğini göstermek için kullanmaya çalışacağım.
Şifre depolama: karma, şifreleme ve (nefes nefese!) düz metin
Unutulan şifreleri nasıl saklayacağımızı tartışmadan önce onlarla ne yapacağımızı tartışamayız. Parolalar veritabanında üç ana türden birinde saklanır:
- Basit metin. Düz metin biçiminde saklanan bir şifre sütunu vardır.
- Şifrelenmiş. Tipik olarak simetrik şifreleme kullanılır (hem şifreleme hem de şifre çözme için bir anahtar kullanılır) ve şifrelenmiş parolalar da aynı sütunda saklanır.
- Haşlanmış. Tek yönlü süreç (şifre karma haline getirilebilir, ancak karma işlemi kaldırılamaz); şifre, umut etmek isterim, ardından bir tuz gelir ve her biri kendi sütunundadır.
Gelelim en basit soruya: Parolaları asla düz metin olarak saklamayın! Asla. Tek bir güvenlik açığı , dikkatsiz bir yedekleme veya düzinelerce basit hatadan biri - hepsi bu, oyun bitti, tüm şifreleriniz - yani, özür dilerim, tüm müşterilerinizin şifreleri kamu malı haline gelecektir. Tabii ki, bu büyük bir olasılık anlamına gelir diğer sistemlerdeki tüm hesaplarından. Ve bu senin hatan olacak.
Şifreleme daha iyidir ancak zayıf yönleri vardır. Şifrelemeyle ilgili sorun şifre çözmedir; Bu çılgın görünümlü şifreleri alıp onları tekrar düz metne dönüştürebiliriz ve bu gerçekleştiğinde, insan tarafından okunabilen şifre durumuna geri döneriz. Bu nasıl oluyor? Şifrenin şifresini çözen ve onu herkesin kullanımına açık hale getiren koda küçük bir kusur girer - bu bir yoldur. Bilgisayar korsanları, şifrelenmiş verilerin depolandığı makineye erişim sağlar; bu ikinci yöntemdir. Başka bir yol da yine veritabanı yedeklemesini çalmaktır ve birisi genellikle çok güvenli olmayan bir şekilde saklanan şifreleme anahtarını da ele geçirir.
Bu da bizi karma işlemine getiriyor. Hashing'in arkasındaki fikir, bunun tek yönlü olmasıdır; Kullanıcı tarafından girilen şifreyi karma sürümüyle karşılaştırmanın tek yolu, girdiyi karma hale getirmek ve bunları karşılaştırmaktır. Gökkuşağı tabloları gibi araçların saldırılarını önlemek için süreci rastgelelikle tuzlarız (okuyun kriptografik depolama hakkında). Sonuçta, eğer doğru şekilde uygulanırsa, hash edilmiş şifrelerin bir daha asla düz metin haline gelmeyeceğinden emin olabiliriz (farklı hash algoritmalarının faydalarından başka bir yazıda bahsedeceğim).
Hashing ve şifreleme hakkında kısa bir tartışma: Bir şifreyi hashlemek yerine şifrelemeniz gerekmesinin tek nedeni, şifreyi düz metin olarak görmeniz gerektiği zamandır ve bunu asla istememelisinen azından standart bir web sitesi durumunda. Buna ihtiyacınız varsa, büyük olasılıkla yanlış bir şey yapıyorsunuz demektir!
Uyarı!
Gönderinin metninin altında AlotPorn pornografik web sitesinin ekran görüntüsünün bir kısmı var. Düzgünce kesilmiş olduğundan kumsalda göremeyeceğiniz hiçbir şey yok, ancak yine de sorun yaratma ihtimali varsa aşağı kaydırmayın.
Şifrenizi her zaman sıfırlayın asla ona hatırlatma
Hiç bir işlev oluşturmanız istendi mi? hatırlatıcılar şifre? Bir adım geri atın ve bu isteği tersten düşünün: Bu “hatırlatmaya” neden ihtiyaç duyuldu? Çünkü kullanıcı şifreyi unuttu. Gerçekten ne yapmak istiyoruz? Tekrar giriş yapmasına yardım edin.
"Hatırlatma" kelimesinin (çoğunlukla) günlük konuşma dilinde kullanıldığının farkındayım, ama aslında yapmaya çalıştığımız şey kullanıcının tekrar çevrimiçi olmasına güvenli bir şekilde yardımcı olun. Güvenliğe ihtiyacımız olduğundan, hatırlatmanın (yani kullanıcıya şifresinin gönderilmesi) uygun olmamasının iki nedeni vardır:
- E-posta güvensiz bir kanaldır. Tıpkı HTTP üzerinden hassas hiçbir şey göndermeyeceğimiz gibi (HTTPS kullanırdık), taşıma katmanı güvenli olmadığından e-postayla da hassas hiçbir şey göndermemeliyiz. Aslında bu, güvenli olmayan bir aktarım protokolü üzerinden bilgi göndermekten çok daha kötüdür; çünkü postalar genellikle bir depolama cihazında depolanır, sistem yöneticileri tarafından erişilebilir, iletilir ve dağıtılır, kötü amaçlı yazılımlara erişilebilir vb. Şifrelenmemiş e-posta son derece güvensiz bir kanaldır.
- Zaten şifreye erişiminiz olmamalıdır. Depolamayla ilgili önceki bölümü tekrar okuyun - şifrenin bir karmasına sahip olmalısınız (iyi ve güçlü bir tuzla), yani hiçbir şekilde şifreyi çıkarıp postayla gönderememelisiniz.
Sorunu bir örnekle göstereyim : İşte tipik bir giriş sayfası:
Açıkçası ilk sorun, giriş sayfasının HTTPS üzerinden yüklenmemesi, ancak sitenin sizden bir şifre ("Şifre Gönder") göndermenizi de istemesidir. Bu, yukarıda bahsedilen terimin günlük konuşma dilindeki kullanımına bir örnek olabilir; o halde hadi bir adım daha ileri gidelim ve ne olacağını görelim:
Maalesef pek daha iyi görünmüyor; ve bir e-posta bir sorun olduğunu doğruluyor:
Bu bize usoutdoor.com'un iki önemli yönünü anlatıyor:
- Site şifreleri karma yapmıyor. En iyi ihtimalle şifrelenirler, ancak büyük olasılıkla düz metin olarak depolanırlar; Aksini gösteren hiçbir kanıt görmüyoruz.
- Site, güvenli olmayan bir kanal üzerinden uzun vadeli bir şifre (geri dönüp tekrar tekrar kullanabiliriz) gönderiyor.
Bunu aradan çıkararak sıfırlama işleminin güvenli bir şekilde yapılıp yapılmadığını kontrol etmemiz gerekiyor. Bunu yapmanın ilk adımı, talepte bulunan kişinin sıfırlama işlemini gerçekleştirme hakkına sahip olduğundan emin olmaktır. Yani bundan önce kimlik kontrolü yapmamız gerekiyor; Önce istekte bulunanın gerçekten hesap sahibi olduğu doğrulanmadan bir kimlik doğrulandığında ne olacağına bir göz atalım.
Kullanıcı adlarının listelenmesi ve bunun anonimlik üzerindeki etkisi
Bu sorun en iyi şekilde görsel olarak gösterilmiştir. Sorun:
Görüyor musun? “Bu e-posta adresiyle kayıtlı kullanıcı yok” mesajına dikkat edin. Böyle bir site onaylarsa sorun açıkça ortaya çıkar durumu kullanıcı bu tür bir e-posta adresiyle kayıtlıdır. Bingo - kocanızın/patronunuzun/komşunuzun porno fetişini keşfettiniz!
Elbette porno, mahremiyetin öneminin oldukça ikonik bir örneğidir, ancak bir kimliği belirli bir web sitesiyle ilişkilendirmenin tehlikeleri, yukarıda açıklanan potansiyel olarak garip durumdan çok daha kapsamlıdır. Tehlikelerden biri sosyal mühendisliktir; Saldırgan bir kişiyi hizmetle eşleştirebilirse kullanmaya başlayabileceği bilgilere sahip olacaktır. Örneğin, bir web sitesinin temsilcisi gibi görünen bir kişiyle iletişime geçebilir ve taahhütte bulunmak amacıyla ek bilgi talep edebilir. .
Bu tür uygulamalar aynı zamanda "kullanıcı adı numaralandırması" tehlikesini de artırmaktadır; bu durumda kişi, bir web sitesindeki tüm kullanıcı adları veya e-posta adresleri koleksiyonunun varlığını, yalnızca grup sorguları yürüterek ve bunlara verilen yanıtları inceleyerek doğrulayabilir. Tüm çalışanların e-posta adreslerinin bir listesi ve bir senaryo yazmak için birkaç dakikanız var mı? O zaman sorunun ne olduğunu görüyorsunuz!
Alternatif nedir? Aslında oldukça basittir ve harika bir şekilde uygulanmıştır. :
Burada Entropay, sisteminde bir e-posta adresinin varlığı hakkında kesinlikle hiçbir şey açıklamamaktadır. bu adresin sahibi olmayan birine. Eğer sen kendi Bu adres sistemde mevcut değilse aşağıdaki gibi bir e-posta alacaksınız:
Elbette, birisinin kabul edilebilir olduğu durumlar olabilir. düşünürweb sitesine kaydolduğunuzu. ancak durum böyle değil ya da farklı bir e-posta adresinden yaptım. Yukarıda gösterilen örnek her iki durumu da iyi bir şekilde ele almaktadır. Açıkçası, adres eşleşirse şifrenizi sıfırlamayı kolaylaştıran bir e-posta alacaksınız.
Entropay'in seçtiği çözümün inceliği, kimlik doğrulamanın şu kurallara göre yapılmasıdır: e-posta herhangi bir çevrimiçi doğrulamadan önce. Bazı siteler kullanıcılardan bir güvenlik sorusunun yanıtını ister (bununla ilgili daha fazla bilgi aşağıdadır) karşı sıfırlama nasıl başlayabilir; ancak buradaki sorun, soruyu bir tür kimlik (e-posta veya kullanıcı adı) sağlarken yanıtlamak zorunda olmanızdır; bu da anonim kullanıcının hesabının varlığını açıklamadan sezgisel olarak yanıt vermeyi neredeyse imkansız hale getirir.
Bu yaklaşımla var küçük Kullanılabilirlik azaldı çünkü var olmayan bir hesabı sıfırlamaya çalışırsanız anında geri bildirim alınamaz. Elbette, e-posta göndermenin asıl amacı budur, ancak gerçek bir son kullanıcı açısından bakıldığında, eğer yanlış adres girerlerse, yalnızca e-postayı aldıklarında ilk kez bunu bileceklerdir. Bu onun açısından bir miktar gerginliğe neden olabilir, ancak bu, bu kadar nadir bir süreç için ödenmesi gereken küçük bir bedeldir.
Konunun biraz dışında başka bir not: Bir kullanıcı adının veya e-posta adresinin doğru olup olmadığını ortaya çıkaran oturum açma yardımı işlevleri de aynı sorunu yaşıyor. Kullanıcıya, kimlik bilgilerinin varlığını açıkça onaylamak yerine her zaman "Kullanıcı adı ve şifre kombinasyonunuz geçersiz" mesajıyla yanıt verin (örneğin, "kullanıcı adı doğru, ancak şifre yanlış").
Sıfırlama şifresi gönderme ve sıfırlama URL'si gönderme
Tartışmamız gereken bir sonraki kavram şifrenizi nasıl sıfırlayacağınızdır. İki popüler çözüm vardır:
- Sunucuda yeni bir şifre oluşturup e-postayla göndermek
- Sıfırlama işlemini kolaylaştırmak için benzersiz URL içeren bir e-posta gönderin
Rağmen , ilk nokta asla kullanılmamalıdır. Bununla ilgili sorun, bunun var olduğu anlamına gelmesidir. saklanan şifreistediğiniz zaman geri dönüp tekrar kullanabileceğiniz; güvenli olmayan bir kanal üzerinden gönderildi ve gelen kutunuzda kaldı. Gelen kutularının mobil cihazlar ve e-posta istemcisi arasında senkronize edilmesi ve ayrıca web e-posta hizmetinde çok uzun bir süre çevrimiçi olarak depolanabilmesi muhtemeldir. Önemli olan şu ki bir posta kutusu güvenilir bir uzun süreli depolama aracı olarak değerlendirilemez.
Ancak bunun yanı sıra, ilk noktanın başka bir ciddi sorunu daha var: mümkün olduğu kadar basitleştirir Bir hesabın kötü niyetle engellenmesi. Bir web sitesinde hesabı olan birinin e-posta adresini biliyorsam, onu istediğim zaman şifresini sıfırlayarak engelleyebilirim; Bu, gümüş tepside sunulan bir hizmet reddi saldırısıdır! Bu nedenle sıfırlama işlemi yalnızca talep sahibinin haklarının başarılı bir şekilde doğrulanmasının ardından gerçekleştirilmelidir.
Sıfırlama URL'sinden bahsettiğimizde, bir web sitesinin adresini kastediyoruz. sıfırlama işleminin bu özel durumuna özgü. Elbette rastgele olmalı, tahmin edilmesi kolay olmamalı ve hesaba sıfırlamayı kolaylaştıracak herhangi bir harici bağlantı içermemelidir. Örneğin, sıfırlama URL'si yalnızca "Reset/?username=JohnSmith" gibi bir yol olmamalıdır.
Sıfırlama URL'si olarak gönderilebilecek ve daha sonra kullanıcının hesabının sunucu kaydıyla eşleştirilebilecek benzersiz bir belirteç oluşturmak istiyoruz, böylece hesap sahibinin aslında parolayı sıfırlamaya çalışan kişiyle aynı kişi olduğunu doğruluyoruz. Örneğin, bir jeton "3ce7854015cd38c862cb9e14a1ae552b" olabilir ve sıfırlamayı gerçekleştiren kullanıcının kimliği ve jetonun oluşturulduğu zamanla birlikte bir tabloda saklanabilir (bununla ilgili daha fazla bilgi aşağıdadır). E-posta gönderildiğinde “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” gibi bir URL içerir ve kullanıcı bunu indirdiğinde sayfa, tokenın varlığını sorar ve ardından kullanıcının bilgilerini onaylayıp değiştirmesine olanak tanır. şifre.
Elbette yukarıdaki süreç (umarız) kullanıcının yeni bir şifre oluşturmasına izin verdiğinden, URL'nin HTTPS üzerinden yüklendiğinden emin olmamız gerekir. HAYIR, , yeni şifre formunun saldırıya uğramaması için bu belirteç URL'sinin aktarım katmanı güvenliğini kullanması gerekir ve kullanıcı tarafından oluşturulan şifre güvenli bir bağlantı üzerinden iletildi.
Ayrıca sıfırlama URL'si için, sıfırlama işleminin belirli bir aralıkta, örneğin bir saat içinde tamamlanabilmesi için bir belirteç zaman sınırı eklemeniz gerekir. Bu, sıfırlama süresi penceresinin minimumda tutulmasını ve böylece sıfırlama URL'sinin alıcısının yalnızca bu çok küçük pencere içinde işlem yapabilmesini sağlar. Elbette saldırgan sıfırlama işlemini yeniden başlatabilir ancak başka bir benzersiz sıfırlama URL'si alması gerekecektir.
Son olarak bu sürecin tek kullanımlık olmasını sağlamamız gerekiyor. Sıfırlama işlemi tamamlandıktan sonra, sıfırlama URL'sinin artık işlevsel olmaması için belirtecin kaldırılması gerekir. Önceki nokta, saldırganın sıfırlama URL'sini değiştirebileceği çok küçük bir pencereye sahip olmasını sağlamak için gereklidir. Ayrıca, elbette, sıfırlama işlemi başarılı olduğunda jetona artık ihtiyaç duyulmaz.
Bu adımlardan bazıları fazlasıyla gereksiz görünebilir ancak kullanılabilirliği etkilemez ve aslında nadir olacağını umduğumuz durumlarda da olsa güvenliği artırın. Vakaların %99'unda kullanıcı çok kısa bir süre içinde sıfırlamayı etkinleştirecek ve yakın gelecekte şifreyi tekrar sıfırlamayacaktır.
CAPTCHA'nın Rolü
Ah, CAPTCHA, hepimizin nefret etmeyi sevdiği güvenlik özelliği! Aslında, CAPTCHA bir koruma aracı olmaktan ziyade bir tanımlama aracıdır; ister insan ister robot olun (ya da otomatikleştirilmiş bir komut dosyası). Amacı otomatik form gönderimini engellemektir, ki bu da elbette kutu güvenliği kırma girişimi olarak kullanılabilir. Şifre sıfırlama bağlamında, CAPTCHA, sıfırlama işlevinin kullanıcıya spam göndermek veya hesapların varlığını belirlemeye çalışmak için kaba kuvvetle uygulanamayacağı anlamına gelir (bu, elbette, bölümdeki tavsiyeye uyduysanız mümkün olmayacaktır). Kimliklerin doğrulanması).
Tabii ki CAPTCHA'nın kendisi mükemmel değil; Yazılımının “hacklenmesi” ve yeterli başarı oranlarına (%60-70) ulaşmasının pek çok örneği var. Ek olarak, yazımda gösterilen bir çözüm var. , her CAPTCHA'yı çözmeleri ve %94'lük bir başarı oranına ulaşmaları için insanlara bir kuruşun kesirleri kadar ödeme yapabilirsiniz. Yani savunmasızdır, ancak giriş engelini (biraz) yükseltir.
PayPal örneğine bir göz atalım:
Bu durumda CAPTCHA çözülene kadar sıfırlama işlemi başlayamaz, dolayısıyla teorik süreci otomatikleştirmek imkansızdır. Teoride.
Ancak çoğu web uygulaması için bu aşırıya kaçacaktır ve kesinlikle doğru Kullanılabilirlikte bir azalmayı temsil ediyor; insanlar CAPTCHA'yı sevmiyor! Ayrıca CAPTCHA gerektiğinde kolaylıkla geri dönebileceğiniz bir şeydir. Hizmet saldırıya uğramaya başlarsa (günlüğe kaydetmenin kullanışlı olduğu yer burasıdır, ancak bu konuya daha sonra değineceğiz), CAPTCHA eklemek bundan daha kolay olamazdı.
Gizli sorular ve cevaplar
Düşündüğümüz tüm yöntemlerle, yalnızca e-posta hesabına erişerek şifreyi sıfırlamayı başardık. “Adil” diyorum ama elbette başka birinin e-posta hesabına erişim sağlamak yasa dışıdır. -meli karmaşık bir süreç olabilir. Fakat .
Aslında yukarıdaki bağlantı Sarah Palin'in Yahoo! iki amaca hizmet eder; birincisi, (bazı) e-posta hesaplarını hacklemenin ne kadar kolay olduğunu gösteriyor ve ikinci olarak, kötü güvenlik sorularının kötü niyetle kullanılabileceğini gösteriyor. Ancak bu konuya daha sonra tekrar döneceğiz.
%100 e-posta tabanlı şifre sıfırlamalardaki sorun, sıfırlamaya çalıştığınız sitenin hesabının bütünlüğünün, e-posta hesabının bütünlüğüne %100 bağlı hale gelmesidir. E-postanıza erişimi olan herkes Sadece bir e-posta alarak sıfırlanabilecek herhangi bir hesaba erişimi var. Bu tür hesaplar için e-posta, çevrimiçi yaşamınızın "tüm kapılarının anahtarıdır".
Bu riski azaltmanın bir yolu, bir güvenlik sorusu ve cevap modeli uygulamaktır. Şüphesiz bunları zaten görmüşsünüzdür: yalnızca sizin cevaplayabileceğiniz bir soru seçin sahip Cevabı bilin ve şifrenizi sıfırladığınızda sizden şifre istenecektir. Bu, sıfırlamayı deneyen kişinin gerçekten hesap sahibi olduğuna dair güveni artırır.
Sarah Palin'e dönelim: Hata, güvenlik sorusunun/sorularının yanıtlarının kolayca bulunabilmesiydi. Özellikle bu kadar önemli bir halk figürü olduğunuzda, annenizin kızlık soyadı, eğitim geçmişi veya birisinin geçmişte nerede yaşamış olabileceği hakkındaki bilgiler o kadar da gizli değildir. Aslında çoğunu hemen hemen herkes bulabilir. Sarah'nın başına gelenler şunlar:
Bilgisayar korsanı David Kernell, Palin'in üniversitesi ve doğum tarihi gibi geçmişiyle ilgili ayrıntıları bularak ve ardından Yahoo!'nun unutulan şifre kurtarma özelliğini kullanarak Palin'in hesabına erişim sağladı.
Her şeyden önce bu, Yahoo!'nun yaptığı bir tasarım hatasıdır. — Şirket, bu kadar basit sorular belirleyerek güvenlik sorusunun değerini ve dolayısıyla sisteminin korunmasını esasen sabote etti. Elbette, bir e-posta hesabının şifrelerini sıfırlamak her zaman daha zordur çünkü sahibine bir e-posta göndererek (ikinci bir adrese sahip olmadan) hesabın sahibi olduğunuzu kanıtlayamazsınız, ancak neyse ki günümüzde böyle bir sistem oluşturmanın pek fazla kullanım alanı yoktur.
Güvenlik sorularına dönelim; kullanıcının kendi sorularını oluşturmasına izin veren bir seçenek var. Sorun şu ki, bu durum son derece bariz soruların ortaya çıkmasına neden olacak:
Gökyüzü ne renktir?
Kimlik tespiti için bir güvenlik sorusu kullanıldığında insanları rahatsız eden sorular insanlar (örneğin, bir çağrı merkezinde):
Noel'de kiminle yattım?
Veya açıkçası aptalca sorular:
"Şifre" nasıl yazılır?
Güvenlik soruları söz konusu olduğunda kullanıcıların kendilerinden kurtarılması gerekiyor! Yani güvenlik sorusu sitenin kendisi tarafından belirlenmeli, daha doğrusu sorulmalıdır. bir dizi Kullanıcının seçebileceği güvenlik soruları. Ve seçmek kolay değil biri; ideal olarak kullanıcının iki veya daha fazla güvenlik sorusu seçmesi gerekir hesap kaydı sırasındadaha sonra ikinci bir tanımlama kanalı olarak kullanılacaktır. Birden fazla soruya sahip olmak, doğrulama sürecine olan güveni artırır ve aynı zamanda rastgelelik ekleme yeteneği sağlar (her zaman aynı soruyu göstermez), ayrıca gerçek kullanıcının şifreyi unutması durumunda bir miktar yedeklilik sağlar.
İyi bir güvenlik sorusu nedir? Bu, çeşitli faktörlerden etkilenir:
- O olmalı kısa bilgi - Soru açık ve net olmalıdır.
- Cevap şu olmalı özel — bir kişinin farklı yanıt verebileceği bir soruya ihtiyacımız yok
- Olası cevaplar şöyle olmalı türlü - birine en sevdiği rengi sormak, olası cevapların çok küçük bir kısmını verir
- arama Cevap karmaşık olmalı - eğer cevap kolayca bulunabiliyorsa herhangi (yüksek mevkilerdeki insanları hatırlayın), o zaman o kötüdür
- Cevap şu olmalı DC zamanla - birine en sevdiği filmi sorarsanız, bir yıl sonra cevap farklı olabilir
Aslında, iyi sorular sormaya adanmış bir web sitesi var. . Sorulardan bazıları oldukça iyi görünüyor, bazıları ise yukarıda açıklanan testlerden bazılarını, özellikle de “arama kolaylığı” testini geçemiyor.
PayPal'ın güvenlik sorularını nasıl uyguladığını ve özellikle sitenin kimlik doğrulama için gösterdiği çabayı göstermeme izin verin. Yukarıda süreci başlatmak için sayfayı gördük (CAPTCHA ile) ve burada e-posta adresinizi girip CAPTCHA'yı çözdükten sonra ne olacağını göstereceğiz:
Sonuç olarak, kullanıcı aşağıdaki mektubu alır:
Şu ana kadar her şey oldukça normal, ancak işte bu sıfırlama URL'sinin arkasında gizli olan şey:
Yani güvenlik soruları devreye giriyor. Aslında PayPal, kredi kartı numaranızı doğrulayarak şifrenizi sıfırlamanıza da olanak tanıyor, dolayısıyla birçok sitenin erişemediği ek bir kanal daha var. Cevap vermeden şifremi değiştiremiyorum her ikisi de güvenlik sorusu (veya kart numarasını bilmemek). Birisi e-postamı ele geçirse bile, benim hakkımda biraz daha kişisel bilgi sahibi olmadığı sürece PayPal hesap şifremi sıfırlayamazdı. Hangi bilgi? PayPal'ın sunduğu güvenlik sorusu seçenekleri şunlardır:
Okul ve hastane sorusu, arama kolaylığı açısından biraz şüpheli olabilir, ancak diğerleri o kadar da kötü değil. Ancak güvenliği artırmak için PayPal ek kimlik bilgileri gerektirir. değişiklikler güvenlik sorularının yanıtları:
PayPal, güvenli şifre sıfırlamanın oldukça ütopik bir örneğidir: kaba kuvvet saldırıları tehlikesini azaltmak için bir CAPTCHA uygular, iki güvenlik sorusu gerektirir ve ardından yalnızca yanıtları değiştirmek için tamamen farklı bir tür kimlik gerektirir - ve bu, kullanıcıdan sonra zaten oturum açtı. Tabii biz de tam olarak bunu yapıyoruz beklenen PayPal'dan; büyük miktarlarda parayla uğraşan bir finans kuruluşudur. Bu, her parola sıfırlama işleminin bu adımları izlemesi gerektiği anlamına gelmez (çoğu zaman bu aşırıya kaçar) ancak güvenliğin ciddi bir iş olduğu durumlar için iyi bir örnektir.
Güvenlik sorusu sisteminin rahatlığı, eğer hemen uygulamadıysanız, kaynak koruma düzeyi gerektiriyorsa daha sonra ekleyebilmenizdir. Bunun güzel bir örneği, bu mekanizmayı yakın zamanda uygulayan Apple'dır. [makale 2012'de yazılmıştır]. Uygulamayı iPad'imde güncellemeye başladığımda aşağıdaki isteği gördüm:
Ardından birkaç çift güvenlik sorusu ve cevabının yanı sıra kurtarma e-posta adresini seçebileceğim bir ekran gördüm:
PayPal'a gelince, sorular önceden seçilmiştir ve bazıları gerçekten oldukça iyidir:
Üç soru/cevap çiftinin her biri farklı olası soruları temsil eder, dolayısıyla bir hesabı yapılandırmanın birçok yolu vardır.
Güvenlik sorunuzu yanıtlarken göz önünde bulundurulması gereken diğer bir husus da depolamadır. Veritabanında düz metin veritabanına sahip olmak, parolayla hemen hemen aynı tehditleri oluşturur; yani veritabanının açığa çıkarılması, değeri anında ortaya çıkarır ve yalnızca uygulamayı değil, aynı güvenlik sorularını kullanan potansiyel olarak tamamen farklı uygulamaları da riske sokar (yine burada). ). Seçeneklerden biri güvenli karmadır (güçlü bir algoritma ve kriptografik olarak rastgele bir tuz), ancak çoğu şifre saklama durumunun aksine, yanıtın düz metin olarak görünür olmasının iyi bir nedeni olabilir. Tipik bir senaryo, canlı bir telefon operatörü tarafından kimlik doğrulamasıdır. Elbette karma bu durumda da uygulanabilir (operatör, istemci tarafından adlandırılan yanıtı girebilir), ancak en kötü durumda, gizli yanıt, yalnızca simetrik şifreleme olsa bile, belirli bir kriptografik depolama düzeyine yerleştirilmelidir. . Özetle: Sırlara sırmış gibi davran!
Güvenlik soru ve cevaplarının son bir yönü de sosyal mühendisliğe karşı daha savunmasız olmalarıdır. Şifreyi doğrudan başka birinin hesabına çıkarmaya çalışmak bir şeydir, ancak bunun oluşumu hakkında bir konuşma başlatmak (popüler bir güvenlik sorusu) tamamen farklıdır. Aslında, birisiyle hayatının gizli bir soruyu gündeme getirebilecek birçok yönü hakkında şüphe uyandırmadan çok iyi iletişim kurabilirsiniz. Elbette, bir güvenlik sorusunun asıl amacı, birinin yaşam deneyimiyle ilgili olmasıdır, dolayısıyla akılda kalıcıdır ve sorun da burada yatmaktadır - insanlar yaşam deneyimleri hakkında konuşmayı severler! Bu konuda yapabileceğiniz çok az şey vardır; yalnızca bu tür güvenlik sorusu seçeneklerini, daha az muhtemelen sosyal mühendislikle ortadan kaldırılabilir.
[Devam edecek.]Reklam gibi
VDSina güvenilir sunuyor , her sunucu 500 Megabit İnternet kanalına bağlı ve DDoS saldırılarına karşı ücretsiz korunuyor!
Kaynak: habr.com