Bu yaxınlarda mən bu funksiyanı ilk olaraq qurarkən təhlükəsiz parol sıfırlama funksiyasının necə işləməsi barədə yenidən düşünməyə vaxtım oldu. , və sonra başqa bir insana oxşar bir şey etməyə kömək etdikdə. İkinci halda, mən ona sıfırlama funksiyasının təhlükəsiz şəkildə həyata keçirilməsinin bütün təfərrüatları olan kanonik mənbəyə keçid vermək istədim. Ancaq problem ondadır ki, belə bir resurs yoxdur, ən azı mənə vacib görünən hər şeyi təsvir edən bir resurs yoxdur. Ona görə də özüm yazmağa qərar verdim.
Görürsünüz, unudulmuş parollar dünyası əslində olduqca sirli bir dünyadır. Çox fərqli, tamamilə məqbul nöqteyi-nəzərdən və bir çox olduqca təhlükəli olanlar var. Çox güman ki, siz onların hər biri ilə son istifadəçi kimi dəfələrlə qarşılaşmısınız; buna görə də kimin bunu düzgün etdiyini, kimin etmədiyini və funksiyanı tətbiqinizdə düzgün əldə etmək üçün nəyə diqqət etməli olduğunuzu göstərmək üçün bu nümunələrdən istifadə etməyə çalışacağam.
Parolun saxlanması: hashing, şifrələmə və (nas!) düz mətn
Onları necə saxlamağı müzakirə etməzdən əvvəl unudulmuş parollarla nə edəcəyimizi müzakirə edə bilmərik. Parollar verilənlər bazasında üç əsas növdən birində saxlanılır:
- Sadə mətn. Düz mətn şəklində saxlanılan parol sütunu var.
- Şifrələnmiş. Tipik olaraq simmetrik şifrələmədən istifadə edilir (bir açar həm şifrələmə, həm də şifrənin açılması üçün istifadə olunur) və şifrələnmiş parollar da eyni sütunda saxlanılır.
- Hashed. Birtərəfli proses (parol hashing edilə bilər, lakin silinə bilməz); parol, ümid etmək istərdim, sonra bir duz və hər biri öz sütunundadır.
Gəlin birbaşa ən sadə suala keçək: Heç vaxt parolları düz mətndə saxlamayın! Heç vaxt. Bir tək zəiflik , bir ehtiyatsız ehtiyat nüsxəsi və ya onlarla başqa sadə səhvlərdən biri - və bu, oyun bitdi, bütün parollarınız - yəni üzr istəyirik, bütün müştərilərinizin parolları ictimai sahəyə çevriləcək. Təbii ki, bu, böyük ehtimal demək olardı digər sistemlərdəki bütün hesablarından. Və bu sizin günahınız olacaq.
Şifrələmə daha yaxşıdır, lakin zəif cəhətləri var. Şifrələmə ilə bağlı problem şifrənin açılmasıdır; biz bu çılğın görünən şifrələri götürüb onları yenidən düz mətnə çevirə bilərik və bu baş verdikdə biz insan tərəfindən oxuna bilən parol vəziyyətinə qayıdırıq. Bu necə baş verir? Parolun şifrəsini açan koda kiçik bir qüsur daxil olur və onu ictimaiyyətə təqdim edir - bu, bir yoldur. Hakerlər şifrələnmiş məlumatların saxlandığı maşına giriş əldə edirlər - bu, ikinci üsuldur. Başqa bir yol, yenə verilənlər bazası ehtiyat nüsxəsini oğurlamaqdır və kimsə çox vaxt çox etibarlı şəkildə saxlanılan şifrələmə açarını da alır.
Və bu bizi hashingə gətirir. Hashing arxasında ideya birtərəfli olmasıdır; istifadəçinin daxil etdiyi parolu onun heşlənmiş versiyası ilə müqayisə etməyin yeganə yolu girişi hash etmək və onları müqayisə etməkdir. Göy qurşağı cədvəlləri kimi alətlərdən hücumların qarşısını almaq üçün prosesi təsadüfiliklə duzlayırıq (mənim kriptoqrafik saxlama haqqında). Nəhayət, düzgün tətbiq olunarsa, biz əmin ola bilərik ki, hashed parollar bir daha heç vaxt düz mətnə çevrilməyəcək (başqa bir yazıda müxtəlif hashing alqoritmlərinin faydaları haqqında danışacağam).
Şifrələmə ilə hashing haqqında qısa mübahisə: parolu hesh etməkdənsə, şifrələməyinizə ehtiyac duyduğunuz yeganə səbəb parolu düz mətndə görməli olduğunuz zamandır və bunu heç vaxt istəməməlisən, ən azı standart veb-sayt vəziyyətində. Buna ehtiyacınız varsa, çox güman ki, səhv bir şey edirsiniz!
Diqqət!
Yazının mətninin altında AlotPorn pornoqrafik saytının skrinşotunun bir hissəsi var. O, səliqəli şəkildə işlənmişdir, ona görə də çimərlikdə görmədiyiniz heç nə yoxdur, lakin hələ də hər hansı problem yarada bilərsə, aşağı sürüşdürməyin.
Həmişə parolunuzu sıfırlayın heç ona xatırlatma
Sizdən heç bir funksiya yaratmağı xahiş ediblərmi? xatırlatmalar parol? Bir addım geri çəkin və bu sorğu haqqında tərsinə düşünün: bu “xatırlatma” nə üçün lazımdır? Çünki istifadəçi parolu unutmuşdur. Biz həqiqətən nə etmək istəyirik? Ona yenidən daxil olmağa kömək edin.
Mən başa düşürəm ki, "xatırlatma" sözünün danışıq mənasında (tez-tez) istifadə olunur, amma əslində etməyə çalışdığımız şey budur istifadəçiyə təhlükəsiz şəkildə yenidən onlayn olmağa kömək edin. Təhlükəsizliyə ehtiyacımız olduğundan öyüd-nəsihətin (məsələn, istifadəçiyə parolunu göndərməsi) uyğun olmamasının iki səbəbi var:
- E-poçt etibarsız kanaldır. HTTP üzərindən həssas heç nə göndərmədiyimiz kimi (HTTPS-dən istifadə edərdik), e-poçt vasitəsilə də həssas heç nə göndərməməliyik, çünki onun nəqliyyat təbəqəsi etibarsızdır. Əslində, bu, sadəcə olaraq təhlükəsiz olmayan nəqliyyat protokolu üzərindən məlumat göndərməkdən daha pisdir, çünki poçt tez-tez yaddaş qurğusunda saxlanılır, sistem administratorları üçün əlçatandır, yönləndirilir və paylanır, zərərli proqramlar üçün əlçatan olur və s. Şifrələnməmiş e-poçt son dərəcə etibarsız bir kanaldır.
- Onsuz da parola girişiniz olmamalıdır. Saxlama ilə bağlı əvvəlki bölməni yenidən oxuyun - parolun hashinə (yaxşı güclü duzlu) sahib olmalısınız, yəni heç bir şəkildə parolu çıxarıb poçtla göndərə bilməməlisiniz.
İcazə verin, problemi bir nümunə ilə nümayiş etdirim : Budur tipik bir giriş səhifəsi:
Aydındır ki, birinci problem giriş səhifəsinin HTTPS üzərindən yüklənməməsidir, lakin sayt sizdən parol göndərməyi təklif edir (“Parol Göndər”). Bu, yuxarıda qeyd olunan terminin danışıq dilində istifadəsinə bir nümunə ola bilər, ona görə də gəlin onu bir qədər də irəli aparaq və nə baş verdiyini görək:
Təəssüf ki, daha yaxşı görünmür; və e-poçt problemin olduğunu təsdiqləyir:
Bu usoutdoor.com-un iki mühüm aspektini izah edir:
- Sayt parolları hash etmir. Ən yaxşı halda, onlar şifrələnir, lakin çox güman ki, onlar düz mətndə saxlanılır; Bunun əksini göstərən heç bir dəlil görmürük.
- Sayt təhlükəsiz olmayan kanal üzərindən uzunmüddətli parol göndərir (geri qayıdıb onu təkrar-təkrar istifadə edə bilərik).
Bununla, sıfırlama prosesinin təhlükəsiz şəkildə həyata keçirildiyini yoxlamaq lazımdır. Bunu etmək üçün ilk addım tələb edənin sıfırlamanı həyata keçirmək hüququna malik olduğundan əmin olmaqdır. Başqa sözlə, bundan əvvəl şəxsiyyət yoxlamasına ehtiyacımız var; Gəlin sorğu edənin əslində hesab sahibi olduğunu doğrulamadan şəxsiyyət təsdiqləndikdə nə baş verdiyinə nəzər salaq.
İstifadəçi adlarının siyahısı və onun anonimliyə təsiri
Bu problem ən yaxşı şəkildə əyani şəkildə göstərilir. Problem:
Siz görürsünüz? “Bu e-poçt ünvanında qeydiyyatdan keçmiş istifadəçi yoxdur” mesajına diqqət yetirin. Belə bir sayt təsdiq edərsə, problem açıq şəkildə ortaya çıxır mövcudluğu belə e-poçt ünvanı ilə qeydiyyatdan keçmiş istifadəçi. Bingo - ərinizin/bosunuzun/qonşunuzun porno fetişini yeni kəşf etdiniz!
Əlbəttə ki, porno məxfiliyin əhəmiyyətinin kifayət qədər simvolik nümunəsidir, lakin fərdin müəyyən bir veb-saytla əlaqələndirilməsinin təhlükələri yuxarıda təsvir edilən potensial yöndəmsiz vəziyyətdən daha genişdir. Bir təhlükə sosial mühəndislikdir; Təcavüzkar bir şəxsi xidmətlə uyğunlaşdıra bilsə, o zaman istifadə etməyə başlaya biləcəyi məlumatlara sahib olacaq. Məsələn, o, özünü veb-saytın nümayəndəsi kimi təqdim edən şəxslə əlaqə saxlaya bilər və törətmək cəhdi üçün əlavə məlumat tələb edə bilər .
Bu cür təcrübələr həm də “istifadəçi adının sadalanması” təhlükəsini artırır, bununla da sadəcə qrup sorğuları aparmaq və onlara verilən cavabları yoxlamaq yolu ilə vebsaytda istifadəçi adlarının və ya e-poçt ünvanlarının bütün kolleksiyasının mövcudluğunu yoxlamaq olar. Bütün işçilərin e-poçt ünvanlarının siyahısı və skript yazmaq üçün bir neçə dəqiqəniz varmı? Sonra problemin nə olduğunu görürsən!
Alternativ nədir? Əslində, bu, olduqca sadədir və gözəl şəkildə həyata keçirilir :
Burada Entropay öz sistemində e-poçt ünvanının mövcudluğu ilə bağlı heç nə açıqlamır bu ünvana sahib olmayan birinə... Əgər sən sahibi bu ünvan sistemdə mövcud deyilsə, belə bir e-poçt alacaqsınız:
Təbii ki, kiminsə içində olduğu məqbul vəziyyətlər ola bilər düşünürsaytda qeydiyyatdan keçmisiniz. amma bu belə deyil, ya da mən bunu başqa e-poçt ünvanından etmişəm. Yuxarıda göstərilən nümunə hər iki vəziyyəti yaxşı idarə edir. Aydındır ki, ünvan uyğun gələrsə, parolunuzu sıfırlamağı asanlaşdıran e-poçt məktubu alacaqsınız.
Entropay tərəfindən seçilən həllin incəliyi ondan ibarətdir ki, identifikasiya yoxlaması ona uyğun həyata keçirilir e-poçt hər hansı onlayn yoxlamadan əvvəl. Bəzi saytlar istifadəçilərdən təhlükəsizlik sualının cavabını soruşur (aşağıda bu barədə ətraflı) üzrə sıfırlama necə başlaya bilər; lakin bununla bağlı problem ondan ibarətdir ki, siz müəyyən formada identifikasiya (e-poçt və ya istifadəçi adı) təqdim edərkən suala cavab verməlisiniz ki, bu da anonim istifadəçinin hesabının mövcudluğunu aşkar etmədən intuitiv cavab verməyi demək olar ki, qeyri-mümkün edir.
Bu yanaşma ilə var kiçik istifadə qabiliyyəti azaldı, çünki mövcud olmayan hesabı sıfırlamağa cəhd etsəniz, dərhal geribildirim olmayacaq. Əlbəttə, bu, e-poçt göndərməyin bütün nöqtəsidir, lakin həqiqi son istifadəçinin nöqteyi-nəzərindən, əgər onlar səhv ünvanı daxil edərlərsə, onlar yalnız ilk dəfə e-poçtu aldıqları zaman biləcəklər. Bu, onun tərəfində müəyyən gərginliyə səbəb ola bilər, lakin bu, belə nadir proses üçün kiçik bir qiymətdir.
Mövzudan bir qədər kənar olan başqa bir qeyd: istifadəçi adının və ya e-poçt ünvanının düzgün olub-olmadığını aşkar edən giriş yardımı funksiyalarında da eyni problem var. Etibarnamələrin mövcudluğunu açıq şəkildə təsdiqləmək əvəzinə istifadəçiyə həmişə “Siz istifadəçi adı və parol kombinasiyası etibarsızdır” mesajı ilə cavab verin (məsələn, “istifadəçi adı düzgündür, lakin parol səhvdir”).
Sıfırlama parolunun göndərilməsi ilə sıfırlama URL-nin göndərilməsi
Müzakirə etməli olduğumuz növbəti konsepsiya parolunuzu necə sıfırlamaqdır. İki məşhur həll yolu var:
- Serverdə yeni parolun yaradılması və e-poçt vasitəsilə göndərilməsi
- Sıfırlama prosesini asanlaşdırmaq üçün unikal URL ilə e-poçt göndərin
Rəğmən , birinci nöqtə heç vaxt istifadə edilməməlidir. Bunun problemi var deməkdir saxlanılan parol, istənilən vaxt qayıdıb yenidən istifadə edə biləcəyiniz; o, etibarsız kanal vasitəsilə göndərilib və gələnlər qutunuzda qalır. Çox güman ki, gələn qutular mobil cihazlar və e-poçt müştərisi arasında sinxronlaşdırılır, üstəlik, onlar çox uzun müddət veb e-poçt xidmətində onlayn olaraq saxlanıla bilər. Məsələ ondadır ki poçt qutusu uzunmüddətli saxlama üçün etibarlı vasitə hesab edilə bilməz.
Ancaq bundan başqa, birinci məqamın başqa bir ciddi problemi var - o mümkün qədər sadələşdirir zərərli niyyətlə hesabı bloklamaq. Əgər veb-saytda hesabı olan birinin e-poçt ünvanını bilirəmsə, o zaman sadəcə parolunu sıfırlamaqla onları istənilən vaxt blok edə bilərəm; Bu, gümüş nimçədə xidmət edilən xidmətin rədd edilməsi hücumudur! Buna görə də sıfırlama yalnız sorğuçunun ona olan hüquqlarının uğurla yoxlanılmasından sonra həyata keçirilməlidir.
Sıfırlama URL-i haqqında danışarkən, veb saytın ünvanını nəzərdə tuturuq sıfırlama prosesinin bu xüsusi halına xasdır. Əlbəttə ki, bu, təsadüfi olmalıdır, onu təxmin etmək asan olmamalıdır və sıfırlamağı asanlaşdıran hesaba hər hansı xarici bağlantılar olmamalıdır. Məsələn, sıfırlama URL sadəcə olaraq "Reset/?username=JohnSmith" kimi bir yol olmamalıdır.
Biz sıfırlama URL-i kimi poçtla göndərilə bilən və daha sonra istifadəçi hesabının server qeydinə uyğunlaşdırıla bilən unikal nişan yaratmaq istəyirik və bununla da hesab sahibinin əslində parolu sıfırlamağa çalışan eyni şəxs olduğunu təsdiqləyirik. Məsələn, token "3ce7854015cd38c862cb9e14a1ae552b" ola bilər və sıfırlamanı həyata keçirən istifadəçinin identifikatoru və işarənin yaradıldığı vaxtla birlikdə cədvəldə saxlanıla bilər (aşağıda bu barədə ətraflı). E-poçt göndərildikdə, o, “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” kimi bir URL ehtiva edir və istifadəçi onu endirdikdə, səhifə işarənin mövcudluğunu soruşur, bundan sonra o, istifadəçinin məlumatını təsdiqləyir və onlara e-poçt ünvanını dəyişdirməyə imkan verir. parol.
Təbii ki, yuxarıdakı proses (inşallah) istifadəçiyə yeni parol yaratmağa imkan verdiyi üçün URL-in HTTPS üzərindən yüklənməsini təmin etməliyik. Yox, , bu token URL-i nəqliyyat qatının təhlükəsizliyindən istifadə etməlidir ki, yeni parol formasına hücum edilməsin və istifadəçi tərəfindən yaradılmış parol təhlükəsiz əlaqə vasitəsilə ötürülür.
Həmçinin sıfırlama URL-i üçün bir işarə vaxt məhdudiyyəti əlavə etməlisiniz ki, sıfırlama prosesi müəyyən bir intervalda, məsələn, bir saat ərzində tamamlana bilsin. Bu, sıfırlama vaxtı pəncərəsinin minimum səviyyədə saxlanmasını təmin edir ki, sıfırlama URL-nin alıcısı yalnız həmin çox kiçik pəncərədə fəaliyyət göstərə bilsin. Əlbəttə ki, təcavüzkar yenidən sıfırlama prosesinə başlaya bilər, lakin onlar başqa unikal sıfırlama URL-i əldə etməlidirlər.
Nəhayət, bu prosesin birdəfəlik olmasını təmin etməliyik. Sıfırlama prosesi başa çatdıqdan sonra, sıfırlama URL-nin artıq işləməməsi üçün nişan silinməlidir. Əvvəlki məqam, təcavüzkarın sıfırlama URL-ini manipulyasiya edə biləcəyi çox kiçik bir pəncərəyə sahib olmasını təmin etmək üçün lazımdır. Üstəlik, əlbəttə ki, sıfırlama uğurlu olduqdan sonra token artıq lazım deyil.
Bu addımların bəziləri həddindən artıq lazımsız görünə bilər, lakin onlar istifadəyə mane olmur və əslində Nadir olacağını ümid etdiyimiz vəziyyətlərdə də təhlükəsizliyi yaxşılaşdırın. 99% hallarda istifadəçi çox qısa müddət ərzində sıfırlamağa imkan verəcək və yaxın gələcəkdə parolu yenidən sıfırlamayacaq.
CAPTCHA-nın rolu
Oh, CAPTCHA, hamımızın nifrət etdiyimiz təhlükəsizlik xüsusiyyəti! Əslində, CAPTCHA bir insan və ya robot (və ya avtomatlaşdırılmış skript) olmağınızdan asılı olmayaraq identifikasiya vasitəsi olduğu qədər qoruma vasitəsi deyil. Onun məqsədi avtomatik forma təqdim etmənin qarşısını almaqdır, bu, əlbəttə ki, can təhlükəsizliyi pozmağa cəhd kimi istifadə oluna bilər. Parolun sıfırlanması kontekstində CAPTCHA o deməkdir ki, sıfırlama funksiyası nə istifadəçiyə spam göndərməyə, nə də hesabların mövcudluğunu müəyyən etməyə cəhd etməyə məcbur edilə bilməz (əlbəttə ki, bu bölmədəki tövsiyələrə əməl etsəniz, bu mümkün olmayacaqdır. şəxsiyyətlərin yoxlanılması).
Əlbəttə, CAPTCHA özü mükəmməl deyil; Proqram təminatının "sındırılması" və kifayət qədər müvəffəqiyyət dərəcələrinə (60-70%) nail olmaq üçün bir çox presedentlər var. Bundan əlavə, mənim yazımda göstərilən bir həll var , burada hər bir CAPTCHA həll etmək və 94% müvəffəqiyyət nisbətinə nail olmaq üçün insanlara bir sentin fraksiyalarını ödəyə bilərsiniz. Yəni, həssasdır, lakin (bir az) giriş maneəsini qaldırır.
PayPal nümunəsinə nəzər salaq:
Bu halda, sıfırlama prosesi sadəcə CAPTCHA həll olunana qədər başlaya bilməz nəzəriyyədə prosesi avtomatlaşdırmaq mümkün deyil. Nəzəriyyədə.
Bununla birlikdə, əksər veb tətbiqləri üçün bu, həddindən artıq olacaq və tamamilə doğru istifadə qabiliyyətinin azaldığını göstərir - insanlar sadəcə CAPTCHA-nı sevmirlər! Bundan əlavə, CAPTCHA lazım olduqda asanlıqla qayıda biləcəyiniz bir şeydir. Əgər xidmət hücuma məruz qalmağa başlayırsa (bu, girişin lazımlı olduğu yerdir, lakin bu barədə daha sonra), onda CAPTCHA əlavə etmək asan ola bilməz.
Gizli suallar və cavablar
Nəzərdən keçirdiyimiz bütün üsullarla yalnız e-poçt hesabına daxil olmaqla parolu sıfırlaya bildik. Mən “sadəcə” deyirəm, amma təbii ki, başqasının e-poçt hesabına giriş əldə etmək qanunsuzdur. olmalıdır mürəkkəb proses olmalıdır. Lakin .
Əslində, yuxarıdakı link Sarah Palin-in Yahoo! iki məqsədə xidmət edir; birincisi, (bəzi) e-poçt hesablarını sındırmağın nə qədər asan olduğunu, ikincisi, pis təhlükəsizlik suallarının zərərli niyyətlə necə istifadə oluna biləcəyini göstərir. Ancaq bu mövzuya daha sonra qayıdacağıq.
XNUMX% e-poçt əsaslı parol sıfırlama ilə bağlı problem sıfırlamağa çalışdığınız sayt üçün hesabın bütövlüyünün e-poçt hesabının bütövlüyündən XNUMX% asılı olmasıdır. E-poçtunuza girişi olan hər kəs sadəcə e-poçt almaqla sıfırlana bilən istənilən hesaba girişi var. Bu cür hesablar üçün e-poçt onlayn həyatınızın “bütün qapılarının açarıdır”.
Bu riski azaltmağın bir yolu təhlükəsizlik sualı və cavab modelini tətbiq etməkdir. Şübhəsiz ki, siz onları artıq görmüsünüz: yalnız sizin cavab verə biləcəyiniz sual seçin olmaq cavabı bilin, sonra parolunuzu sıfırladığınız zaman sizdən bunu tələb edəcəklər. Bu, sıfırlamağa cəhd edən şəxsin həqiqətən hesab sahibi olduğuna əminlik əlavə edir.
Sarah Palinə qayıt: səhv onun təhlükəsizlik sualına/suallarına cavabların asanlıqla tapılması idi. Xüsusilə belə əhəmiyyətli ictimai xadim olduğunuzda, ananızın qız soyadı, təhsil tarixi və ya kiminsə keçmişdə harada yaşamış ola biləcəyi haqqında məlumat o qədər də sirr deyil. Əslində, çoxunu demək olar ki, hər kəs tapa bilər. Saranın başına gələn budur:
Haker David Kernell, universitet və doğum tarixi kimi keçmişi ilə bağlı təfərrüatları taparaq, daha sonra Yahoo!-nun unudulmuş parol bərpa funksiyasından istifadə etməklə Palinin hesabına daxil olub.
Əvvəla, bu Yahoo!-nun dizayn xətasıdır! — belə sadə sualları dəqiqləşdirməklə şirkət təhlükəsizlik sualının dəyərini və buna görə də onun sisteminin qorunmasını mahiyyətcə sabotaj etdi. Əlbəttə ki, bir e-poçt hesabı üçün parolların sıfırlanması həmişə daha çətindir, çünki sahibinə e-poçt göndərməklə (ikinci ünvan olmadan) sahib olduğunuzu sübut edə bilməzsiniz, lakin xoşbəxtlikdən bu gün belə bir sistem yaratmaq üçün çox istifadə yoxdur.
Gəlin təhlükəsizlik suallarına qayıdaq - istifadəçiyə öz suallarını yaratmağa imkan verən bir seçim var. Problem ondadır ki, bu, olduqca açıq suallarla nəticələnəcək:
Göy hansı rəngdədir?
Müəyyən etmək üçün təhlükəsizlik sualından istifadə edildikdə insanları narahat edən suallar şəxs (məsələn, zəng mərkəzində):
Miladda kiminlə yatdım?
Və ya açıqcası axmaq suallar:
"parol"u necə yazırsınız?
Təhlükəsizlik suallarına gəldikdə, istifadəçilər özlərindən xilas olmalıdırlar! Başqa sözlə, təhlükəsizlik sualını saytın özü müəyyən etməli və ya daha yaxşısı soruşulmalıdır seriya istifadəçinin seçə biləcəyi təhlükəsizlik sualları. Və seçmək asan deyil bir; ideal olaraq istifadəçi iki və ya daha çox təhlükəsizlik sualı seçməlidir hesabın qeydiyyatı zamanı, daha sonra ikinci identifikasiya kanalı kimi istifadə olunacaq. Çoxlu sualların olması doğrulama prosesinə inamı artırır, həmçinin təsadüfilik əlavə etmək imkanı verir (həmişə eyni sualı göstərmir), üstəlik faktiki istifadəçi parolu unutduqda bir az artıqlıq təmin edir.
Yaxşı təhlükəsizlik sualı nədir? Buna bir neçə amil təsir edir:
- Bu olmalıdır qısa - sual aydın və birmənalı olmalıdır.
- Cavab olmalıdır spesifik - bir insanın fərqli cavab verə biləcəyi suala ehtiyacımız yoxdur
- Mümkün cavablar olmalıdır müxtəlif - kiminsə sevimli rəngini soruşmaq mümkün cavabların çox kiçik bir hissəsini verir
- Axtar cavab mürəkkəb olmalıdır - cavabı asanlıqla tapmaq olarsa hər hansı bir (yüksək vəzifələrdə olan insanları xatırlayın), onda o, pisdir
- Cavab olmalıdır daimi vaxtında - kiminsə sevimli filmini soruşsanız, bir ildən sonra cavab fərqli ola bilər
Olduğu kimi, adlı yaxşı suallar verməyə həsr olunmuş bir veb sayt var . Sualların bəziləri kifayət qədər yaxşı görünür, digərləri yuxarıda təsvir edilən bəzi testlərdən, xüsusən də “axtarış asanlığı” testindən keçmir.
İcazə verin, PayPal-ın təhlükəsizlik suallarını necə həyata keçirdiyini və xüsusən də saytın autentifikasiya üçün göstərdiyi səyləri nümayiş etdirim. Yuxarıda prosesə başlamaq üçün səhifəni gördük (CAPTCHA ilə) və burada e-poçt ünvanınızı daxil etdikdən və CAPTCHA-nı həll etdikdən sonra nə baş verdiyini göstərəcəyik:
Nəticədə istifadəçi aşağıdakı məktubu alır:
İndiyə qədər hər şey olduqca normaldır, lakin bu sıfırlama URL-nin arxasında nə gizlənir:
Beləliklə, təhlükəsizlik sualları işə düşür. Əslində, PayPal da kredit kartı nömrənizi təsdiq edərək parolunuzu sıfırlamağa imkan verir, ona görə də bir çox saytların girişi olmayan əlavə kanal var. Cavab vermədən parolumu dəyişə bilmərəm həm də təhlükəsizlik sualı (və ya kartın nömrəsini bilməmək). Kimsə e-poçtumu oğurlasa belə, mənim haqqımda bir az daha şəxsi məlumatı bilməsələr, PayPal hesabımın parolunu sıfırlaya bilməyəcəklər. Hansı məlumat? PayPalın təklif etdiyi təhlükəsizlik sualı seçimləri bunlardır:
Məktəb və xəstəxana sualı axtarış asanlığı baxımından bir az zərif ola bilər, lakin digərləri çox da pis deyil. Bununla belə, təhlükəsizliyi artırmaq üçün PayPal üçün əlavə identifikasiya tələb olunur dəyişikliklər təhlükəsizlik suallarına cavablar:
PayPal təhlükəsiz parol sıfırlamasının olduqca utopik bir nümunəsidir: o, kobud güc hücumlarının təhlükəsini azaltmaq üçün CAPTCHA tətbiq edir, iki təhlükəsizlik sualı tələb edir və sonra sadəcə cavabları dəyişdirmək üçün başqa cür tamamilə fərqli identifikasiya tələb edir - və bu, istifadəçidən sonra artıq daxil olub. Təbii ki, bizdə məhz bu belədir gözlənilir PayPal-dan; külli miqdarda pulla məşğul olan maliyyə qurumudur. Bu o demək deyil ki, hər bir parol sıfırlama bu addımları yerinə yetirməlidir – əksər hallarda bu, həddindən artıq olur – lakin bu, təhlükəsizliyin ciddi iş olduğu hallar üçün yaxşı nümunədir.
Təhlükəsizlik sualı sisteminin rahatlığı ondan ibarətdir ki, əgər siz onu dərhal tətbiq etməmisinizsə, resursun mühafizəsi səviyyəsi bunu tələb edərsə, onu daha sonra əlavə edə bilərsiniz. Bunun yaxşı nümunəsi bu mexanizmi yenicə tətbiq edən Apple-dır [2012-ci ildə yazılmış məqalə]. Tətbiqi iPad-də yeniləməyə başladıqdan sonra aşağıdakı sorğunu gördüm:
Sonra bir neçə cüt təhlükəsizlik sualı və cavabını, həmçinin xilasetmə e-poçt ünvanını seçə biləcəyim bir ekran gördüm:
PayPal-a gəldikdə, suallar əvvəlcədən seçilir və onlardan bəziləri əslində olduqca yaxşıdır:
Üç sual/cavab cütünün hər biri müxtəlif mümkün suallar toplusunu təmsil edir, ona görə də hesabı konfiqurasiya etməyin bir çox yolu var.
Təhlükəsizlik sualınıza cavab verməklə bağlı nəzərə alınmalı başqa bir aspekt yaddaşdır. Verilənlər bazasında düz mətn verilənlər bazasına malik olmaq, parol ilə demək olar ki, eyni təhlükələri yaradır, yəni verilənlər bazasını ifşa etmək dəyəri dərhal aşkar edir və təkcə tətbiqi deyil, eyni təhlükəsizlik suallarından istifadə edən potensial tamamilə fərqli proqramları risk altına qoyur (yenidən orada ). Seçimlərdən biri təhlükəsiz hashingdir (güclü alqoritm və kriptoqrafik cəhətdən təsadüfi duz), lakin əksər parol saxlama hallarından fərqli olaraq, cavabın düz mətn kimi görünməsi üçün yaxşı səbəb ola bilər. Tipik bir ssenari canlı telefon operatoru tərəfindən şəxsiyyətin yoxlanılmasıdır. Əlbəttə ki, bu halda heşinq də tətbiq olunur (operator sadəcə müştəri tərəfindən göstərilən cavabı daxil edə bilər), lakin ən pis halda, gizli cavab sadəcə simmetrik şifrələmə olsa belə, kriptoqrafik yaddaşın müəyyən səviyyəsində yerləşməlidir. . Ümumiləşdirin: sirləri sirr kimi qəbul edin!
Təhlükəsizlik sualları və cavablarının son cəhətlərindən biri onların sosial mühəndisliyə daha həssas olmasıdır. Şifrəni başqasının hesabına birbaşa çıxarmağa çalışmaq bir şeydir, lakin onun formalaşması (məşhur təhlükəsizlik sualı) haqqında söhbətə başlamaq tamam başqadır. Əslində, kimsə ilə həyatının bir çox aspektləri haqqında çox yaxşı ünsiyyət qura bilərsiniz ki, bu da şübhə doğurmadan gizli sual yarada bilər. Əlbəttə ki, təhlükəsizlik sualının mahiyyəti ondan ibarətdir ki, o, kiminsə həyat təcrübəsi ilə bağlıdır, ona görə də yaddaqalandır və problem də elə buradadır - insanlar öz həyat təcrübələri haqqında danışmağı sevirlər! Bununla bağlı edə biləcəyiniz çox az şey var, yalnız belə təhlükəsizlik sualı variantlarını seçsəniz, onlar olmalıdır az yəqin ki, sosial mühəndislik tərəfindən çıxarıla bilər.
[Ardı var.]Reklam Hüquqları haqqında
VDSina etibarlı təklif edir , hər bir server 500 Meqabitlik İnternet kanalına qoşulub və pulsuz olaraq DDoS hücumlarından qorunur!
Mənbə: www.habr.com