Վերջերս ես ժամանակ ունեցա նորից մտածելու այն մասին, թե ինչպես պետք է աշխատի անվտանգ գաղտնաբառի վերակայման գործառույթը, նախ, երբ ես կառուցեցի այս գործառույթը , իսկ հետո, երբ նա օգնեց մեկ այլ անձի նման բան անել: Երկրորդ դեպքում ես ուզում էի նրան հղում տալ կանոնական ռեսուրսի բոլոր մանրամասներին, թե ինչպես ապահով կերպով իրականացնել վերակայման գործառույթը: Սակայն խնդիրն այն է, որ նման ռեսուրս գոյություն չունի, գոնե այնպիսի ռեսուրս, որը նկարագրում է այն ամենը, ինչ ինձ թվում է կարևոր։ Ուստի որոշեցի ինքս գրել:
Տեսեք, մոռացված գաղտնաբառերի աշխարհն իրականում բավականին առեղծվածային է: Կան բազմաթիվ տարբեր, միանգամայն ընդունելի տեսակետներ և շատ բավականին վտանգավոր։ Հավանական է, որ դուք բազմիցս հանդիպել եք դրանցից յուրաքանչյուրին որպես վերջնական օգտագործող. այնպես որ ես կփորձեմ օգտագործել այս օրինակները՝ ցույց տալու համար, թե ով է դա անում ճիշտ, ով ոչ, և ինչի վրա պետք է կենտրոնանաք՝ հնարավորությունը ձեր հավելվածում ճիշտ տեղադրելու համար:
Գաղտնաբառերի պահպանում՝ հեշինգ, գաղտնագրում և պարզ տեքստ
Մենք չենք կարող քննարկել, թե ինչ անել մոռացված գաղտնաբառերի հետ, նախքան դրանք պահելու մասին քննարկելը: Գաղտնաբառերը պահվում են տվյալների բազայում երեք հիմնական տեսակներից մեկով.
- Պարզ տեքստ. Կա գաղտնաբառի սյունակ, որը պահվում է պարզ տեքստի տեսքով:
- Կոդավորված: Սովորաբար օգտագործվում է սիմետրիկ գաղտնագրում (մեկ բանալի օգտագործվում է ինչպես կոդավորման, այնպես էլ վերծանման համար), իսկ կոդավորված գաղտնաբառերը նույնպես պահվում են նույն սյունակում:
- Հաշված: Միակողմանի գործընթաց (գաղտնաբառը կարող է հաշվել, բայց չի կարող ջնջվել); գաղտնաբառը, Ես կցանկանայի հուսալ, որին հաջորդում է աղը, և յուրաքանչյուրն իր սյունակում է։
Եկեք անմիջապես անցնենք ամենապարզ հարցին. Երբեք մի պահեք գաղտնաբառերը պարզ տեքստով: Երբեք: Մեկ խոցելիություն դեպի , մեկ անզգույշ կրկնօրինակում կամ տասնյակ այլ պարզ սխալներից մեկը, և վերջ, gameover, ձեր բոլոր գաղտնաբառերը, այսինքն՝ կներեք, ձեր բոլոր հաճախորդների գաղտնաբառերը կդառնա հանրային սեփականություն: Իհարկե, սա կնշանակի մեծ հավանականություն, որ այլ համակարգերում նրանց բոլոր հաշիվներից: Եվ դա կլինի ձեր մեղքը:
Կոդավորումը ավելի լավ է, բայց ունի իր թույլ կողմերը: Գաղտնագրման խնդիրը վերծանումն է. մենք կարող ենք վերցնել այս խելահեղ տեսք ունեցող գաղտնագրերը և դրանք նորից վերածել պարզ տեքստի, և երբ դա տեղի ունենա, մենք վերադառնում ենք մարդու կողմից ընթեռնելի գաղտնաբառի իրավիճակին: Ինչպե՞ս է դա տեղի ունենում: Մի փոքր թերություն է հայտնվում ծածկագրի մեջ, որը վերծանում է գաղտնաբառը՝ այն դարձնելով հանրությանը հասանելի. սա ճանապարհներից մեկն է: Հաքերները մուտք են ստանում այն մեքենան, որի վրա պահվում են կոդավորված տվյալները. սա երկրորդ մեթոդն է: Մեկ այլ միջոց, կրկին, տվյալների բազայի կրկնօրինակը գողանալն է, և ինչ-որ մեկը ստանում է նաև գաղտնագրման բանալին, որը հաճախ շատ անապահով պահվում է:
Եվ սա մեզ բերում է հաշման: Հեշինգի գաղափարն այն է, որ այն միակողմանի է. օգտատիրոջ մուտքագրած գաղտնաբառն իր հեշացված տարբերակի հետ համեմատելու միակ միջոցը մուտքագրումը հաշելն ու համեմատելն է: Ծիածանի աղյուսակների նման գործիքների հարձակումները կանխելու համար մենք գործընթացը աղում ենք պատահականորեն (կարդալ իմ ծածկագրային պահպանման մասին): Ի վերջո, եթե ճիշտ իրականացվի, մենք կարող ենք վստահ լինել, որ հեշավորված գաղտնաբառերն այլևս երբեք չեն դառնա պարզ տեքստ (հեշինգի տարբեր ալգորիթմների առավելությունների մասին ես կխոսեմ մեկ այլ գրառման մեջ):
Արագ վեճ հաշինգի և գաղտնագրման վերաբերյալ. միակ պատճառը, որ դուք երբևէ պետք է գաղտնագրեք, այլ ոչ թե գաղտնաբառ հաշելու, դա այն է, երբ դուք պետք է տեսնեք գաղտնաբառը պարզ տեքստով, և դուք երբեք չպետք է դա ցանկանաք, գոնե ստանդարտ վեբկայքի իրավիճակում: Եթե դա ձեզ անհրաժեշտ է, ապա, ամենայն հավանականությամբ, ինչ-որ բան սխալ եք անում:
Զգուշացում!
Ստորև գրառման տեքստում կա AlotPorn պոռնոգրաֆիկ կայքի սքրինշոթի մի մասը: Այն կոկիկորեն կտրված է, այնպես որ լողափում ոչինչ չտեսնեք, բայց եթե այն դեռ կարող է որևէ խնդիր առաջացնել, մի ոլորեք ներքև:
Միշտ վերականգնել ձեր գաղտնաբառը երբեք մի հիշեցրու նրան
Ձեզ երբևէ խնդրել են ստեղծել գործառույթ հիշեցումներ գաղտնաբառը? Մի քայլ հետ գնացեք և հակառակը մտածեք այս խնդրանքի մասին. ինչո՞ւ է անհրաժեշտ այս «հիշեցումը»: Քանի որ օգտվողը մոռացել է գաղտնաբառը: Ի՞նչ ենք մենք իրականում ուզում անել: Օգնեք նրան նորից մուտք գործել:
Ես հասկանում եմ, որ «հիշեցում» բառը (հաճախ) օգտագործվում է խոսակցական իմաստով, բայց այն, ինչ մենք իրականում փորձում ենք անել, դա է. ապահով կերպով օգնեք օգտվողին կրկին առցանց լինել. Քանի որ մենք անվտանգության կարիք ունենք, կա երկու պատճառ, թե ինչու հիշեցումը (այսինքն՝ օգտվողին իր գաղտնաբառը ուղարկելը) տեղին չէ.
- Էլփոստը անապահով ալիք է: Ինչպես որ մենք HTTP-ով ոչ մի զգայուն բան չենք ուղարկի (մենք կօգտագործեինք HTTPS), մենք չպետք է որևէ զգայուն բան ուղարկենք էլփոստով, քանի որ դրա տրանսպորտային շերտն անապահով է: Իրականում, սա շատ ավելի վատ է, քան պարզապես տեղեկատվություն ուղարկելը անապահով տրանսպորտային արձանագրության միջոցով, քանի որ փոստը հաճախ պահվում է պահեստավորման սարքում, հասանելի է համակարգի ադմինիստրատորներին, փոխանցվում և բաշխվում, հասանելի է չարամիտ ծրագրերին և այլն: Չկոդավորված էլփոստը չափազանց անապահով ալիք է:
- Դուք, այնուամենայնիվ, չպետք է մուտք ունենաք գաղտնաբառը: Կրկին կարդացեք պահեստավորման վերաբերյալ նախորդ բաժինը. դուք պետք է ունենաք գաղտնաբառի հեշ (լավ ուժեղ աղով), այսինքն, դուք չպետք է կարողանաք որևէ կերպ հանել գաղտնաբառը և ուղարկել այն փոստով:
Թույլ տվեք ցույց տալ խնդիրը օրինակով Ահա տիպիկ մուտքի էջ.
Ակնհայտ է, որ առաջին խնդիրն այն է, որ մուտքի էջը չի բեռնվում HTTPS-ով, սակայն կայքը նաև ձեզ հուշում է գաղտնաբառ ուղարկել («Ուղարկել գաղտնաբառը»): Սա կարող է լինել վերը նշված տերմինի խոսակցական օգտագործման օրինակ, ուստի եկեք մի քայլ առաջ գնանք և տեսնենք, թե ինչ է տեղի ունենում.
Ցավոք, դա շատ ավելի լավ տեսք չունի. և էլփոստը հաստատում է, որ խնդիր կա.
Սա մեզ պատմում է usoutdoor.com-ի երկու կարևոր ասպեկտների մասին.
- Կայքը չի հեշավորում գաղտնաբառերը: Լավագույն դեպքում դրանք կոդավորված են, բայց հավանական է, որ դրանք պահվում են պարզ տեքստով. Մենք հակառակի ապացույց չենք տեսնում:
- Կայքն ուղարկում է երկարաժամկետ գաղտնաբառ (մենք կարող ենք վերադառնալ և օգտագործել այն նորից ու նորից) չապահովված ալիքով:
Եթե դա դուրս է եկել ճանապարհից, մենք պետք է ստուգենք, թե արդյոք վերակայման գործընթացը կատարվում է ապահով կերպով: Դա անելու առաջին քայլը համոզվելն է, որ հայցողն իրավունք ունի կատարել վերակայումը: Այսինքն՝ մինչ այս մեզ անհրաժեշտ է ինքնության ստուգում. եկեք տեսնենք, թե ինչ է տեղի ունենում, երբ ինքնությունը հաստատվում է առանց նախապես ստուգելու, որ հայտատուն իրականում հաշվի սեփականատերն է:
Օգտագործողի անունների ցուցակագրում և դրա ազդեցությունը անանունության վրա
Այս խնդիրը լավագույնս պատկերված է տեսողականորեն: Խնդիր.
Տեսնու՞մ ես։ Ուշադրություն դարձրեք «Այս էլփոստի հասցեով գրանցված օգտվող չկա»: Խնդիրն ակնհայտորեն առաջանում է, եթե նման կայքը հաստատի մատչելիություն օգտատերը, որը գրանցված է նման էլ.փոստի հասցեով: Բինգո - դուք հենց նոր հայտնաբերեցիք ձեր ամուսնու/շեֆի/հարևանի պոռնո ֆետիշը:
Իհարկե, պոռնոգրաֆիան գաղտնիության կարևորության բավականին խորհրդանշական օրինակ է, սակայն ինքնությունը կոնկրետ կայքի հետ կապելու վտանգները շատ ավելի լայն են, քան վերը նկարագրված հնարավոր անհարմար իրավիճակը: Վտանգներից մեկը սոցիալական ճարտարագիտությունն է. Եթե հարձակվողը կարող է մարդուն համապատասխանեցնել ծառայությանը, ապա նա կունենա տեղեկատվություն, որը կարող է սկսել օգտագործել: Օրինակ, նա կարող է կապվել մի անձի հետ, ով ներկայանում է որպես կայքի ներկայացուցիչ և պահանջել լրացուցիչ տեղեկություններ՝ փորձելով պարտավորվել .
Նման գործելակերպը նաև բարձրացնում է «օգտանունների թվարկման» վտանգը, որով կարելի է ստուգել օգտատերերի անունների կամ էլփոստի հասցեների ամբողջ հավաքածուի առկայությունը վեբկայքում՝ պարզապես խմբային հարցումներ կատարելով և դրանց պատասխանները ուսումնասիրելով: Ունե՞ք բոլոր աշխատակիցների էլփոստի հասցեների ցանկը և մի քանի րոպե սցենար գրելու համար: Հետո տեսնում եք, թե որն է խնդիրը։
Ո՞րն է այլընտրանքը։ Իրականում, դա բավականին պարզ է և հիանալի կերպով իրականացվում է :
Այստեղ Entropay-ը բացարձակապես ոչինչ չի հայտնում իր համակարգում էլփոստի հասցեի առկայության մասին մեկին, ով այս հասցեն չունի... Եթե դու սեփական այս հասցեն և այն գոյություն չունի համակարգում, ապա դուք կստանաք այսպիսի էլ.
Իհարկե, կարող են լինել ընդունելի իրավիճակներ, երբ ինչ-որ մեկը կարծում էոր դուք գրանցվել եք կայքում։ բայց դա այդպես չէ, կամ ես դա արել եմ այլ էլփոստի հասցեից: Վերևում ներկայացված օրինակը լավ է լուծում երկու իրավիճակները: Ակնհայտ է, որ եթե հասցեն համընկնում է, դուք կստանաք նամակ, որը կհեշտացնի ձեր գաղտնաբառը վերականգնելը:
Entropay-ի կողմից ընտրված լուծման նրբությունն այն է, որ նույնականացման ստուգումն իրականացվում է ըստ էլ ցանկացած առցանց ստուգումից առաջ: Որոշ կայքեր օգտատերերին խնդրում են անվտանգության հարցի պատասխանը (այս մասին ավելին ստորև) դեպի ինչպես կարող է սկսվել վերականգնումը; Այնուամենայնիվ, սրա խնդիրն այն է, որ դուք պետք է պատասխանեք հարցին՝ տրամադրելով նույնականացման ինչ-որ ձև (էլ․ փոստ կամ օգտվողի անուն), որն այնուհետև գրեթե անհնար է դարձնում ինտուիտիվ պատասխանելը՝ առանց բացահայտելու անանուն օգտատիրոջ հաշվի գոյությունը։
Այս մոտեցմամբ կա փոքր նվազեցված օգտագործման հնարավորությունը, քանի որ եթե փորձեք վերականգնել գոյություն չունեցող հաշիվը, անմիջապես արձագանք չկա: Իհարկե, նամակ ուղարկելու ողջ իմաստը դա է, բայց իրական վերջնական օգտագործողի տեսանկյունից, եթե նրանք սխալ հասցե մուտքագրեն, նրանք կիմանան միայն առաջին անգամ, երբ ստանան նամակը: Սա կարող է որոշակի լարվածություն առաջացնել նրա կողմից, բայց սա չնչին գին է նման հազվագյուտ գործընթացի համար:
Մեկ այլ նշում, թեթևակի շեղված թեմայից. մուտքի աջակցության գործառույթները, որոնք ցույց են տալիս, թե արդյոք օգտվողի անունը կամ էլփոստի հասցեն ճիշտ են, նույն խնդիրն ունեն: Միշտ պատասխանեք օգտատիրոջը «Ձեր օգտանունը և գաղտնաբառի համակցությունը անվավեր է» հաղորդագրությամբ, այլ ոչ թե բացահայտորեն հաստատելով հավատարմագրերի առկայությունը (օրինակ՝ «օգտանունը ճիշտ է, բայց գաղտնաբառը սխալ է»):
Վերակայման գաղտնաբառ ուղարկելն ընդդեմ վերակայման URL ուղարկելու
Հաջորդ հայեցակարգը, որը մենք պետք է քննարկենք, այն է, թե ինչպես վերականգնել ձեր գաղտնաբառը: Գոյություն ունեն երկու հանրաճանաչ լուծում.
- Սերվերի վրա նոր գաղտնաբառի ստեղծում և այն էլփոստով ուղարկելը
- Ուղարկեք եզակի URL-ով նամակ՝ վերակայման գործընթացը հեշտացնելու համար
Չնայած , առաջին կետը երբեք չպետք է օգտագործվի։ Սրա խնդիրն այն է, որ դա նշանակում է, որ կա պահված գաղտնաբառը, որը կարող եք վերադառնալ և նորից օգտագործել ցանկացած ժամանակ; այն ուղարկվել է անապահով ալիքով և մնում է ձեր մուտքի արկղում: Հավանական է, որ մուտքի արկղերը համաժամացվում են բջջային սարքերի և էլփոստի հաճախորդի միջև, բացի այդ, դրանք կարող են շատ երկար ժամանակ պահվել առցանց էլփոստի վեբ ծառայության մեջ: Բանն այն է, որ փոստարկղը չի կարող դիտարկվել որպես երկարաժամկետ պահպանման հուսալի միջոց.
Բայց բացի սրանից, առաջին կետն ունի մեկ այլ լուրջ խնդիր հնարավորինս պարզեցնում է արգելափակել հաշիվը վնասակար դիտավորությամբ. Եթե ես գիտեմ որևէ մեկի էլ.փոստի հասցեն, ով վեբկայքում հաշիվ ունի, ապա ես կարող եմ ցանկացած պահի արգելափակել նրան՝ պարզապես վերականգնելով նրա գաղտնաբառը; Սա արծաթե սկուտեղի վրա մատուցվող ծառայության մերժման հարձակում է: Ահա թե ինչու վերակայումը պետք է կատարվի միայն դրա նկատմամբ հայտատուի իրավունքների հաջող ստուգումից հետո:
Երբ մենք խոսում ենք վերակայված URL-ի մասին, մենք նկատի ունենք կայքի հասցեն, որը կա եզակի է վերակայման գործընթացի այս կոնկրետ դեպքի համար. Իհարկե, այն պետք է լինի պատահական, չպետք է լինի հեշտ կռահելը և չպետք է պարունակի որևէ արտաքին հղում դեպի հաշիվ, որը հեշտացնում է վերակայումը: Օրինակ, վերակայման URL-ը պարզապես չպետք է լինի այնպիսի ուղի, ինչպիսին է «Reset/?username=JohnSmith»:
Մենք ցանկանում ենք ստեղծել եզակի նշան, որը կարող է փոստով ուղարկվել որպես վերակայման URL, այնուհետև համընկնել օգտատիրոջ հաշվի սերվերի գրառումների հետ՝ դրանով իսկ հաստատելով, որ հաշվի սեփականատերը, փաստորեն, նույն անձն է, ով փորձում է վերականգնել գաղտնաբառը: Օրինակ՝ նշանը կարող է լինել «3ce7854015cd38c862cb9e14a1ae552b» և պահվել աղյուսակում՝ վերակայումն իրականացնող օգտատիրոջ ID-ի և նշանի ստեղծման ժամանակի հետ միասին (այս մասին ավելին ստորև): Երբ նամակն ուղարկվում է, այն պարունակում է URL, ինչպիսին է «Reset/?id=3ce7854015cd38c862cb9e14a1ae552b», և երբ օգտագործողը ներբեռնում է այն, էջը հուշում է նշանի առկայության մասին, որից հետո այն հաստատում է օգտատիրոջ տվյալները և թույլ է տալիս փոխել գաղտնաբառը։
Իհարկե, քանի որ վերը նշված գործընթացը (հուսով ենք) թույլ է տալիս օգտվողին ստեղծել նոր գաղտնաբառ, մենք պետք է ապահովենք, որ URL-ը բեռնված է HTTPS-ով: Ոչ, , այս նշանի URL-ը պետք է օգտագործի տրանսպորտային շերտի անվտանգությունը, որպեսզի նոր գաղտնաբառի ձևը չհարձակվի և օգտագործողի կողմից ստեղծված գաղտնաբառը փոխանցվել է անվտանգ կապով:
Նաև վերակայման URL-ի համար դուք պետք է ավելացնեք նշանային ժամանակի սահմանափակում, որպեսզի վերակայման գործընթացը կարողանա ավարտվել որոշակի ընդմիջումով, ասենք մեկ ժամվա ընթացքում: Սա ապահովում է, որ վերակայման ժամանակի պատուհանը պահվում է նվազագույնի, որպեսզի վերակայման URL-ի ստացողը կարողանա գործել միայն այդ շատ փոքր պատուհանում: Իհարկե, հարձակվողը կարող է նորից սկսել վերակայման գործընթացը, բայց նրանք պետք է ստանան մեկ այլ եզակի վերակայման URL:
Ի վերջո, մենք պետք է ապահովենք, որ այս գործընթացը մեկանգամյա օգտագործման է: Վերակայման գործընթացն ավարտվելուց հետո նշանը պետք է հեռացվի, որպեսզի վերակայման URL-ն այլևս չգործի: Նախորդ կետը անհրաժեշտ է ապահովելու համար, որ հարձակվողն ունի շատ փոքր պատուհան, որի ընթացքում նա կարող է շահարկել վերակայման URL-ը: Գումարած, իհարկե, երբ վերականգնումը հաջող է, նշանն այլևս անհրաժեշտ չէ:
Այս քայլերից որոշները կարող են չափազանց ավելորդ թվալ, բայց դրանք չեն խանգարում օգտագործելիությանը և փաստորեն բարելավել անվտանգությունը, թեև այն իրավիճակներում, որոնք, հուսով ենք, հազվադեպ կլինեն: 99% դեպքերում օգտատերը շատ կարճ ժամանակահատվածում միացնելու է վերակայումը և մոտ ապագայում այլևս չի վերականգնի գաղտնաբառը։
CAPTCHA-ի դերը
Օ՜, CAPTCHA, անվտանգության այն հատկանիշը, որը մենք բոլորս սիրում ենք ատել: Իրականում, CAPTCHA-ն ոչ այնքան պաշտպանության գործիք է, որքան նույնականացման գործիք՝ անկախ նրանից՝ մարդ եք, թե ռոբոտ (կամ ավտոմատացված սցենար): Դրա նպատակն է խուսափել ավտոմատ ձևի ներկայացումից, ինչը, իհարկե, կարող օգտագործվել որպես անվտանգությունը խախտելու փորձ։ Գաղտնաբառի վերակայման համատեքստում CAPTCHA նշանակում է, որ վերակայման գործառույթը չի կարող կոպիտ կերպով ստիպել օգտատիրոջը սպամ ուղարկել կամ փորձել որոշել հաշիվների առկայությունը (ինչը, իհարկե, հնարավոր չի լինի, եթե հետևեք բաժնում տրված խորհուրդներին: ինքնության ստուգում):
Իհարկե, CAPTCHA-ն ինքնին կատարյալ չէ. Կան բազմաթիվ նախադեպեր նրա ծրագրային ապահովման «կոտրման» և հաջողության բավարար ցուցանիշների (60-70%) հասնելու համար: Բացի այդ, կա լուծում, որը ցույց է տրված իմ մասին գրառման մեջ , որտեղ դուք կարող եք մարդկանց վճարել ցենտի ֆրակցիաներ յուրաքանչյուր CAPTCHA-ի լուծման համար և հասնել հաջողության 94%-ի։ Այսինքն՝ խոցելի է, բայց (մի փոքր) բարձրացնում է մուտքի արգելքը։
Եկեք նայենք PayPal-ի օրինակին.
Այս դեպքում վերակայման գործընթացը պարզապես չի կարող սկսվել մինչև CAPTCHA-ն չլուծվի, ուստի տեսականորեն անհնար է ավտոմատացնել գործընթացը. Տեսականորեն.
Այնուամենայնիվ, վեբ հավելվածների մեծ մասի համար սա չափազանց մեծ կլինի և բացարձակապես ճիշտ ներկայացնում է օգտագործելիության նվազում. մարդիկ պարզապես չեն սիրում CAPTCHA: Բացի այդ, CAPTCHA-ն մի բան է, որին անհրաժեշտության դեպքում հեշտությամբ կարող եք վերադառնալ: Եթե ծառայությունը սկսում է հարձակման ենթարկվել (այստեղ է մուտքագրումը օգտակար, բայց դրա մասին ավելի ուշ), ապա CAPTCHA ավելացնելը չի կարող ավելի հեշտ լինել:
Գաղտնի հարցեր և պատասխաններ
Մեր դիտարկած բոլոր մեթոդներով մենք կարողացանք վերականգնել գաղտնաբառը՝ պարզապես մուտք ունենալով էլփոստի հաշիվ: Ես ասում եմ «պարզապես», բայց, իհարկե, անօրինական է մուտք գործել ուրիշի էլ.փոստի հաշիվ: պետք է լինել բարդ գործընթաց: Այնուամենայնիվ .
Փաստորեն, վերը նշված հղումը Սառա Փեյլինի Yahoo!-ի կոտրման մասին: ծառայում է երկու նպատակի. նախ, այն ցույց է տալիս, թե որքան հեշտ է կոտրել (որոշ) էլփոստի հաշիվները, և երկրորդը, ցույց է տալիս, թե որքան վատ անվտանգության հարցերը կարող են օգտագործվել չարամիտ նպատակներով: Բայց մենք կվերադառնանք սրան ավելի ուշ:
Էլփոստի վրա հիմնված գաղտնաբառի XNUMX% վերակայման խնդիրն այն է, որ այն կայքի ամբողջականությունը, որը փորձում եք վերականգնել, XNUMX% կախված է էլփոստի հաշվի ամբողջականությունից: Յուրաքանչյուր ոք, ով մուտք ունի ձեր էլ ունի մուտք դեպի ցանկացած հաշիվ, որը կարող է վերականգնվել՝ պարզապես նամակ ստանալով. Նման հաշիվների համար էլփոստը ձեր առցանց կյանքի «բոլոր դռների բանալին» է:
Այս ռիսկը նվազեցնելու ուղիներից մեկը անվտանգության հարց ու պատասխանի օրինակի ներդրումն է: Անկասկած, դուք արդեն տեսել եք դրանք. ընտրեք մի հարց, որին միայն դուք կարող եք պատասխանել ունենալ իմացեք պատասխանը, այնուհետև, երբ վերակայեք ձեր գաղտնաբառը, ձեզնից կպահանջվի այն: Սա վստահություն է ավելացնում, որ այն անձը, ով փորձում է վերակայել, իսկապես հաշվի սեփականատերն է:
Վերադարձ դեպի Սառա Փեյլին. սխալն այն էր, որ նրա անվտանգության հարցի/հարցերի պատասխանները հեշտությամբ կարելի էր գտնել։ Հատկապես, երբ դուք այդքան նշանակալից հասարակական գործիչ եք, ձեր մոր օրիորդական ազգանվան, կրթության պատմության կամ նախկինում ինչ-որ մեկի ապրելու մասին տեղեկությունները այնքան էլ գաղտնիք չեն: Իրականում, դրա մեծ մասը կարող է գտնել գրեթե բոլորը: Ահա թե ինչ եղավ Սառայի հետ.
Հաքեր Դեյվիդ Քերնելը մուտք է գործել Փեյլինի հաշիվ՝ գտնելով նրա ծագման մասին մանրամասներ, ինչպես օրինակ՝ համալսարանը և ծննդյան ամսաթիվը, այնուհետև օգտագործելով Yahoo!-ի մոռացված գաղտնաբառի վերականգնման հնարավորությունը:
Նախ, սա դիզայնի սխալ է Yahoo!-ի կողմից: — նշելով նման պարզ հարցեր, ընկերությունը, ըստ էության, սաբոտաժի ենթարկեց անվտանգության հարցի արժեքը, հետևաբար՝ իր համակարգի պաշտպանությունը: Իհարկե, էլփոստի հաշվի գաղտնաբառերի վերակայումը միշտ էլ ավելի դժվար է, քանի որ դուք չեք կարող սեփականատիրոջը նամակ ուղարկելով (առանց երկրորդ հասցե ունենալու) ապացուցել սեփականության իրավունքը, բայց, բարեբախտաբար, այսօր նման համակարգ ստեղծելու շատ օգուտներ չկան:
Եկեք վերադառնանք անվտանգության հարցերին. կա տարբերակ, որը թույլ է տալիս օգտվողին ստեղծել սեփական հարցերը: Խնդիրն այն է, որ սա կհանգեցնի սարսափելի ակնհայտ հարցերի.
Ինչ գույն է երկինքը:
Հարցեր, որոնք մարդկանց անհարմարություն են պատճառում, երբ նույնականացման համար օգտագործվում է անվտանգության հարց անձը (օրինակ, զանգերի կենտրոնում).
Ո՞ւմ հետ եմ քնել Սուրբ Ծնունդին:
Կամ անկեղծորեն հիմար հարցեր.
Ինչպե՞ս եք գրում «գաղտնաբառ»:
Երբ խոսքը վերաբերում է անվտանգության հարցերին, օգտվողները պետք է փրկվեն իրենցից: Այլ կերպ ասած, անվտանգության հարցը պետք է որոշի հենց կայքը, կամ ավելի լավ է հարցնել շարք անվտանգության հարցեր, որոնցից օգտվողը կարող է ընտրել: Եվ դա հեշտ չէ ընտրել մեկ; Իդեալում օգտագործողը պետք է ընտրի երկու կամ ավելի անվտանգության հարցեր հաշվի գրանցման պահին, որն այնուհետեւ կօգտագործվի որպես երկրորդ նույնականացման ալիք: Բազմաթիվ հարցեր ունենալը մեծացնում է վստահությունը ստուգման գործընթացում, ինչպես նաև հնարավորություն է տալիս պատահականություն ավելացնելու (միշտ չէ, որ նույն հարցը ցույց է տալիս), գումարած՝ ապահովում է մի փոքր ավելորդություն, եթե իրական օգտատերը մոռացել է գաղտնաբառը:
Ո՞րն է լավ անվտանգության հարցը: Սա ազդում է մի քանի գործոնների վրա.
- Նա պետք է լինի կարճ — հարցը պետք է լինի պարզ և միանշանակ։
- Պատասխանը պետք է լինի կոնկրետ — մեզ պետք չէ հարց, որին մեկ մարդ կարող է տարբեր կերպ պատասխանել
- Հնարավոր պատասխանները պետք է լինեն բազմազան - ինչ-որ մեկի սիրելի գույնը հարցնելը տալիս է հնարավոր պատասխանների շատ փոքր ենթաբազմություն
- Որոնել պատասխանը պետք է բարդ լինի, եթե պատասխանը կարելի է հեշտությամբ գտնել որեւէ (հիշեք բարձր պաշտոնների մարդկանց), ուրեմն նա վատն է
- Պատասխանը պետք է լինի մշտական ժամանակին, եթե հարցնեք ինչ-որ մեկի սիրելի ֆիլմին, ապա մեկ տարի անց պատասխանը կարող է տարբեր լինել
Ինչպես պատահում է, կա մի կայք, որը նվիրված է լավ հարցեր տալուն, որը կոչվում է . Հարցերից մի քանիսը բավականին լավ են թվում, մյուսները չեն անցնում վերը նկարագրված որոշ թեստեր, հատկապես «որոնման հեշտության» թեստը:
Թույլ տվեք ցույց տալ, թե ինչպես է PayPal-ն իրականացնում անվտանգության հարցերը և, մասնավորապես, այն ջանքերը, որոնք կայքը դնում է նույնականացման համար: Վերևում մենք տեսանք գործընթացը սկսելու էջը (CAPTCHA), և այստեղ մենք ցույց կտանք, թե ինչ է տեղի ունենում այն բանից հետո, երբ մուտքագրեք ձեր էլփոստի հասցեն և լուծեք CAPTCHA:
Արդյունքում օգտվողը ստանում է հետևյալ նամակը.
Մինչ այժմ ամեն ինչ միանգամայն նորմալ է, բայց ահա թե ինչ է թաքնված այս վերակայման URL-ի հետևում.
Այսպիսով, անվտանգության հարցերը հայտնվում են խաղի մեջ: Փաստորեն, PayPal-ը նաև թույլ է տալիս վերականգնել ձեր գաղտնաբառը՝ հաստատելով ձեր կրեդիտ քարտի համարը, այնպես որ կա լրացուցիչ ալիք, որից շատ կայքեր մուտք չունեն: Ես պարզապես չեմ կարող փոխել իմ գաղտնաբառը առանց պատասխանելու երկուսն էլ անվտանգության հարց (կամ չիմանալով քարտի համարը): Նույնիսկ եթե ինչ-որ մեկն առևանգեր իմ էլփոստը, նրանք չեն կարողանա վերականգնել իմ PayPal հաշվի գաղտնաբառը, քանի դեռ չեն իմացել մի փոքր ավելի անձնական տեղեկատվություն իմ մասին: Ի՞նչ տեղեկություն: Ահա անվտանգության հարցերի տարբերակները, որոնք առաջարկում է PayPal-ը.
Դպրոցի և հիվանդանոցի հարցը կարող է փոքր-ինչ անհանգիստ լինել որոնման հեշտության առումով, բայց մյուսներն այնքան էլ վատ չեն: Այնուամենայնիվ, անվտանգությունն ուժեղացնելու համար PayPal-ը պահանջում է լրացուցիչ նույնականացում փոփոխություններ անվտանգության հարցերի պատասխանները.
PayPal-ը անվտանգ գաղտնաբառի վերակայման բավականին ուտոպիստական օրինակ է. այն իրականացնում է CAPTCHA՝ բիրտ ուժային հարձակումների վտանգը նվազեցնելու համար, պահանջում է անվտանգության երկու հարց, և այնուհետև պահանջում է մեկ այլ տեսակի բոլորովին այլ նույնականացում՝ պարզապես պատասխանները փոխելու համար, և դա օգտվողից հետո: արդեն մուտք է գործել։ Իհարկե, սա հենց այն է, ինչ մենք ակնկալվում է PayPal-ից; ֆինանսական հաստատություն է, որը զբաղվում է մեծ գումարներով: Սա չի նշանակում, որ յուրաքանչյուր գաղտնաբառի վերակայում պետք է հետևի այս քայլերին, որոնց մեծ մասը չափազանցված է, բայց դա լավ օրինակ է այն դեպքերի համար, երբ անվտանգությունը լուրջ խնդիր է:
Անվտանգության հարցերի համակարգի հարմարավետությունն այն է, որ եթե դուք անմիջապես չեք իրականացրել այն, կարող եք այն ավելացնել ավելի ուշ, եթե դա պահանջում է ռեսուրսների պաշտպանության մակարդակը: Դրա լավ օրինակ է Apple-ը, որը միայն վերջերս է ներդրել այս մեխանիզմը [հոդվածը գրված է 2012 թվականին]. Երբ ես սկսեցի թարմացնել հավելվածը իմ iPad-ում, տեսա հետևյալ հարցումը.
Այնուհետև ես տեսա էկրան, որտեղ կարող էի ընտրել մի քանի զույգ անվտանգության հարցեր և պատասխաններ, ինչպես նաև փրկարար էլ.
Ինչ վերաբերում է PayPal-ին, ապա հարցերը նախապես ընտրված են, և դրանցից մի քանիսը իրականում բավականին լավն են.
Հարց/պատասխան երեք զույգերից յուրաքանչյուրը ներկայացնում է հնարավոր հարցերի տարբեր շարք, ուստի հաշիվը կարգավորելու բազմաթիվ եղանակներ կան:
Մեկ այլ ասպեկտ, որը պետք է հաշվի առնել ձեր անվտանգության հարցին պատասխանելիս, պահեստավորումն է: Տվյալների բազայում պարզ տեքստային տվյալների բազա ունենալը ներկայացնում է գրեթե նույն սպառնալիքները, ինչ գաղտնաբառը, այն է, որ տվյալների բազայի բացահայտումն անմիջապես բացահայտում է արժեքը և վտանգի տակ է դնում ոչ միայն հավելվածը, այլև պոտենցիալ բոլորովին այլ հավելվածներ՝ օգտագործելով նույն անվտանգության հարցերը (նորից. ) Ընտրանքներից մեկը անվտանգ հեշինգն է (ուժեղ ալգորիթմ և գաղտնագրության պատահական աղ), բայց ի տարբերություն գաղտնաբառի պահպանման դեպքերի մեծ մասի, պատասխանը որպես պարզ տեքստ տեսանելի կարող է լավ պատճառ լինել: Տիպիկ սցենարը ինքնության ստուգումն է կենդանի հեռախոսային օպերատորի կողմից: Իհարկե, հեշինգը կիրառելի է նաև այս դեպքում (օպերատորը կարող է պարզապես մուտքագրել հաճախորդի կողմից նշված պատասխանը), բայց վատագույն դեպքում գաղտնի պատասխանը պետք է գտնվի կրիպտոգրաֆիկ պահպանման ինչ-որ մակարդակում, նույնիսկ եթե դա պարզապես սիմետրիկ կոդավորում է։ . Ամփոփել. վերաբերվեք գաղտնիքներին գաղտնիքների պես:
Անվտանգության հարցերի և պատասխանների վերջին ասպեկտն այն է, որ նրանք ավելի խոցելի են սոցիալական ճարտարագիտության նկատմամբ: Ուրիշի հաշվի գաղտնաբառը ուղղակիորեն հանելու փորձը մի բան է, բայց դրա ձևավորման մասին խոսակցություն սկսելը (անվտանգության հանրաճանաչ հարց) բոլորովին այլ է: Իրականում, դուք կարող եք շատ լավ շփվել ինչ-որ մեկի հետ նրա կյանքի շատ ասպեկտների մասին, որոնք կարող են գաղտնի հարց առաջացնել՝ առանց կասկածներ առաջացնելու: Իհարկե, անվտանգության հարցի բուն իմաստն այն է, որ այն առնչվում է ինչ-որ մեկի կյանքի փորձին, ուստի այն հիշարժան է, և հենց այստեղ է խնդիրը. մարդիկ սիրում են խոսել իրենց կյանքի փորձի մասին: Դուք քիչ բան կարող եք անել այս մասին, միայն այն դեպքում, եթե ընտրեք անվտանգության հարցերի նման տարբերակներ, որպեսզի դրանք լինեն ավելի քիչ հնարավոր է, որ դուրս բերվի սոցիալական ճարտարագիտության միջոցով:
[Շարունակելի.]Գովազդի իրավունքների մասին
VDSina առաջարկում է հուսալի , յուրաքանչյուր սերվեր միացված է 500 Մեգաբիթանոց ինտերնետ ալիքին և անվճար պաշտպանված է DDoS հարձակումներից:
Source: www.habr.com