Այն ամենը, ինչ ցանկանում էիք իմանալ գաղտնաբառերի անվտանգ վերակայման մասին: Մաս 2

Երկու գործոնով նույնականացում

Այն ամենը, ինչ դուք կարդում եք առաջին մասը վերաբերում է նույնականացմանը՝ դրա հիման վրա խնդրողը գիտի. Նա գիտի իր էլ.փոստի հասցեն, գիտի, թե ինչպես մուտք գործել այն (այսինքն, նա գիտի իր էլփոստի գաղտնաբառը) և գիտի իր անվտանգության հարցերի պատասխանները:

«Գիտելիքը» համարվում է վավերացման մեկ գործոն. երկու այլ ընդհանուր գործոններ են ինչ ունես, ինչպիսին է ֆիզիկական սարքը և ով ես դուօրինակ՝ մատնահետքեր կամ ցանցաթաղանթ։

Շատ դեպքերում կենսաբանական նույնականացումն իրագործելի չէ, հատկապես, երբ մենք խոսում ենք վեբ հավելվածների անվտանգության մասին, ուստի երկու գործոնով իսկությունը (2FA) սովորաբար օգտագործում է երկրորդ հատկանիշը՝ «այն ինչ ունես»: Այս երկրորդ գործոնի հանրաճանաչ փոփոխությունը ֆիզիկական նշանն է, օրինակ. RSA Secur ID:

Ֆիզիկական նշանը հաճախ օգտագործվում է կորպորատիվ VPN-ներում և ֆինանսական ծառայություններում նույնականացման համար: Ծառայության հետ իսկությունը հաստատելու համար անհրաժեշտ է օգտագործել և՛ գաղտնաբառ, և՛ ծածկագիր նշանի վրա (որը հաճախ փոխվում է)՝ PIN-ի հետ համատեղ: Տեսականորեն, նույնականացման համար հարձակվողը պետք է իմանա գաղտնաբառը, ունենա նշան, ինչպես նաև իմանա նշանի PIN կոդը: Գաղտնաբառի վերակայման սցենարում գաղտնաբառն ինքնին ակնհայտորեն անհայտ է, սակայն նշանի տիրապետումը կարող է օգտագործվել՝ ապացուցելու հաշվի սեփականությունը: Իհարկե, ինչպես ցանկացած անվտանգության իրականացման դեպքում, դա «անհիմար» չէ, բայց միանշանակ բարձրացնում է մուտքի արգելքը։

Այս մոտեցման հիմնական խնդիրներից մեկը իրականացման արժեքն ու նյութատեխնիկական ապահովումն է. մենք խոսում ենք յուրաքանչյուր հաճախորդին ֆիզիկական սարքեր հանձնելու և նոր գործընթացը սովորեցնելու մասին: Բացի այդ, օգտատերերը պետք է իրենց հետ ունենան սարքը, ինչը միշտ չէ, որ տեղի է ունենում ֆիզիկական նշանի դեպքում: Մեկ այլ տարբերակ SMS-ի միջոցով վավերացման երկրորդ գործոնի ներդրումն է, որը 2FA-ի դեպքում կարող է ծառայել որպես հաստատում, որ զրոյական գործընթացը կատարողն ունի հաշվի սեփականատիրոջ բջջային հեռախոսը: Ահա թե ինչպես է դա անում Google-ը.

Դուք նույնպես պետք է միացնեք երկքայլ ստուգում, բայց սա նշանակում է, որ հաջորդ անգամ, երբ վերակայեք ձեր գաղտնաբառը, ձեր բջջային հեռախոսը կարող է դառնալ նույնականացման երկրորդ գործոնը: Թույլ տվեք ցույց տալ սա՝ օգտագործելով իմ iPhone-ը այն պատճառներով, որոնք շուտով պարզ կդառնան.

Հաշվի էլ.փոստի հասցեն նույնականացնելուց հետո Google-ը որոշում է, որ 2FA-ն միացված է, և մենք կարող ենք վերականգնել հաշիվը՝ օգտագործելով հաստատումը, որը SMS-ի միջոցով ուղարկվում է հաշվի սեփականատիրոջ բջջային հեռախոսին.

Այժմ մենք պետք է ընտրենք սկսել վերակայման գործընթացը.

Այս գործողությունը հանգեցնում է գրանցված հասցեին էլ.

Այս էլ․ հասցեն պարունակում է վերակայված URL՝

Երբ մուտք եք գործում վերակայման URL, SMS է ուղարկվում, և կայքը խնդրում է ձեզ մուտքագրել այն.

Սա SMS է.

Այն զննարկիչ մուտքագրելուց հետո մենք վերադառնում ենք գաղտնաբառի վերակայման դասական տարածքում.

Սա, հավանաբար, մի փոքր երկարատև է թվում, և այդպես է, բայց ձևը հաստատում է, որ վերակայում կատարողին հասանելի է հաշվի սեփականատիրոջ էլփոստի հասցեն և բջջային հեռախոսը: Բայց դա կարող է ինը անգամ ավելի ապահով լինել, քան միայն էլփոստի միջոցով ձեր գաղտնաբառը վերականգնելը: Այնուամենայնիվ, կան խնդիրներ...

Խնդիրը կապված է սմարթֆոնների հետ։ Ստորև ներկայացված սարքը կարող է նույնականացնել միայն վավերացման մեկ գործոնով. այն կարող է ստանալ SMS, բայց ոչ էլ.

Այնուամենայնիվ, այս սարքը կարող է ստանալ SMS и ստանալ գաղտնաբառի վերակայման նամակներ.

Խնդիրն այն է, որ մենք էլփոստը դիտարկում ենք որպես նույնականացման առաջին գործոն, իսկ SMS-ը (կամ նույնիսկ նշան ստեղծող հավելվածը)՝ որպես երկրորդ, բայց այսօր դրանք միավորված են մեկ սարքի մեջ: Իհարկե, սա նշանակում է, որ եթե ինչ-որ մեկի ձեռքը ընկնի ձեր սմարթֆոնը, այս ամբողջ հարմարավետությունը կնվազեցվի նրանով, որ մենք նորից վերադառնում ենք մեկ ալիքի. այս երկրորդ գործոնը «սա, որ ունես» նշանակում է, որ դու ևս ունես առաջին գործոնը: Եվ այս ամենը պաշտպանված է մեկ քառանիշ PIN-ով... եթե հեռախոսը նույնիսկ ունի PIN и նա արգելափակվել է.

Այո, Google-ի կողմից ներդրված 2FA ֆունկցիան, անշուշտ, ապահովում է լրացուցիչ պաշտպանություն, բայց դա անխոհեմ չէ և, իհարկե, կախված չէ երկու լիովին ինքնավար ալիքներից:

Վերակայել օգտվողի անունով ընդդեմ էլփոստի հասցեի վերակայման

Արդյո՞ք պետք է թույլատրել վերակայումները միայն էլ. հասցեով: Թե՞ օգտվողը պետք է կարողանա զրոյացնել նաև անունով: Օգտատիրոջ անունով վերակայման խնդիրն այն է, որ օգտատիրոջը ծանուցելու ոչ մի միջոց չկա, որ օգտանունը սխալ է: առանց բացահայտելու որ մեկ ուրիշը կարող է ունենալ այս անունով հաշիվ: Նախորդ բաժնում էլփոստի վերակայումը երաշխավորեց, որ այդ էլփոստի օրինական սեփականատերը միշտ արձագանքներ կստանա՝ առանց հրապարակայնորեն բացահայտելու դրա գոյությունը համակարգում: Դա հնարավոր չէ անել՝ օգտագործելով միայն օգտվողի անունը:

Այսպիսով, պատասխանը կարճ է՝ միայն էլեկտրոնային փոստով: Եթե ​​փորձեք վերականգնում կատարել՝ օգտագործելով միայն օգտվողի անունը, կլինեն դեպքեր, երբ օգտատերը կմտածի, թե ինչ է տեղի ունեցել, կամ դուք կբացահայտեք հաշիվների առկայությունը: Այո, դա պարզապես օգտվողի անուն է, այլ ոչ էլփոստի հասցե, և այո, յուրաքանչյուրը կարող է ընտրել ցանկացած (մատչելի) օգտանուն, բայց դեռևս մեծ հավանականություն կա, որ դուք անուղղակիորեն կբացահայտեք օգտատերերին՝ օգտվողների կողմից անունը նորից օգտագործելու հակվածության պատճառով:

Այսպիսով, ինչ է տեղի ունենում, երբ ինչ-որ մեկը մոռանում է իր օգտվողի անունը: Ենթադրելով, որ օգտվողի անունը անմիջապես էլփոստի հասցե չէ (ինչը հաճախ այդպես է լինում), գործընթացը նման է այն բանին, թե ինչպես է սկսվում գաղտնաբառի վերակայումը. մուտքագրելով էլ. Միակ տարբերությունն այն է, որ այս անգամ հաղորդագրությունը պարունակում է միայն օգտվողի անունը, այլ ոչ թե գաղտնաբառը վերականգնելու URL-ը: Կա՛մ դա, կա՛մ էլ. նամակում գրվելու է, որ այս հասցեի համար հաշիվ չկա:

Ինքնության ստուգում և էլփոստի հասցեի ճշգրտություն

Գաղտնաբառի վերակայման հիմնական ասպեկտը, և գուցե նույնիսկ առավելագույնը Հիմնական ասպեկտը վերակայումը փորձող անձի ինքնությունը հաստատելն է: Սա իրականում հաշվի օրինական սեփականատերն է, թե՞ ինչ-որ մեկը փորձում է կոտրել այն կամ անհարմարություն պատճառել սեփականատիրոջը:

Ակնհայտ է, որ էլեկտրոնային փոստը ինքնության ստուգման ամենահարմար և ամենատարածված ալիքն է: Այն անխոհեմ չէ, և կան շատ դեպքեր, երբ պարզապես օգտատիրոջ հասցեով նամակներ ստանալը բավարար չէ, եթե պահանջվում է նույնականացման բարձր վստահություն (այդ պատճառով էլ օգտագործվում է 2FA), բայց դա գրեթե միշտ է: մեկնարկային կետի վերակայման գործընթացը:

Եթե ​​էլփոստը դեր է խաղալու երաշխիք տրամադրելու հարցում, ապա առաջին քայլն այն է, որ էլփոստի հասցեն, ըստ էության, ճիշտ է: Եթե ​​ինչ-որ մեկը սխալ նշան է արել, ապա ակնհայտորեն զրոյացումը չի սկսվի: Գրանցման պահին էլփոստի հաստատման գործընթացը հուսալի միջոց է՝ ստուգելու հասցեի ճիշտությունը: Մենք բոլորս դա տեսել ենք գործնականում. դուք գրանցվում եք, նրանք ձեզ նամակ են ուղարկում յուրահատուկ URL-ով, որի վրա սեղմում եք, ինչը հաստատում է, որ դուք իրականում այդ էլփոստի հաշվի սեփականատերն եք: Մուտք գործելու անհնարինությունը մինչև այս գործընթացի ավարտը երաշխավորում է, որ դուք մոտիվացված եք ստուգելու ձեր հասցեն:

Ինչպես անվտանգության շատ այլ ասպեկտների դեպքում, այս մոդելը վտանգում է օգտագործելիությունը՝ օգտվողի ինքնության նկատմամբ վստահության համեմատ ավելի մեծ անվտանգության ապահովման դիմաց: Սա կարող է ընդունելի լինել մի կայքի համար, որտեղ օգտատերը բարձր է գնահատում գրանցումը և հաճույքով կավելացնի գործընթացում ևս մեկ քայլ (վճարովի ծառայություններ, բանկային գործեր և այլն), բայց նման բաները կարող են անջատել օգտատերը, եթե նա հաշիվը ընկալում է որպես «մեկանգամյա օգտագործման»: » և օգտագործում է, օրինակ, պարզապես որպես գրառում մեկնաբանելու միջոց:

Բացահայտում, թե ով է նախաձեռնել վերակայման գործընթացը

Ակնհայտ է, որ վերակայման գործառույթի չարամիտ օգտագործման պատճառներ կան, և հարձակվողները կարող են այն օգտագործել տարբեր ձևերով: Մեկ պարզ հնարք, որը մենք կարող ենք օգտագործել՝ օգնելու ստուգել հարցումի ծագումը (այս հնարքը սովորաբար աշխատում) - սա ավելացվում է նամակին, որն առաջարկում է վերակայել հայցողի IP հասցեն: Այն մատակարարում է ստացողին մի քանի տեղեկատվություն՝ հայտի աղբյուրը բացահայտելու համար։

Ահա մի օրինակ վերակայման գործառույթից, որը ես ներկայումս կառուցում եմ ASafaWeb-ում.

«Իմանալ ավելին» հղումը օգտվողին տանում է կայք ip-address.com, հաղորդում է այնպիսի տեղեկատվություն, ինչպիսին է վերակայման հայտատուի գտնվելու վայրը և կազմակերպությունը.

Իհարկե, յուրաքանչյուր ոք, ով ցանկանում է թաքցնել իր ինքնությունը, ունի իր իրական IP հասցեն շղարշելու բազմաթիվ եղանակներ, բայց սա հարմար միջոց է հայտատուի մասնակի նույնականացում ավելացնելու համար, և մեծ մասը դեպքերում, սա ձեզ լավ պատկերացում կտա, թե ով կլրացնի գաղտնաբառի վերակայման հարցումը:

Փոփոխությունների մասին ծանուցում էլեկտրոնային փոստով

Այս գրառումը ներծծված է մեկ թեմայով՝ հաղորդակցություն; Հաշվի սեփականատիրոջը հնարավորինս շատ տեղեկացրեք այն մասին, թե ինչ է տեղի ունենում գործընթացի յուրաքանչյուր փուլում՝ չբացահայտելով որևէ բան, որը կարող է չարամտորեն օգտագործվել: Նույնը վերաբերում է այն իրավիճակին, երբ գաղտնաբառը իրականում փոխվել է. զեկուցեք դա սեփականատիրոջը:

Գաղտնաբառը փոխելու երկու պատճառ կարող է լինել.

1. Մուտք գործելուց հետո գաղտնաբառի փոփոխություն, քանի որ օգտվողը ցանկանում է նոր գաղտնաբառ
2. Գաղտնաբառի վերականգնում առանց մուտք գործելու, քանի որ օգտվողը մոռացել է այն

Թեև այս գրառումը հիմնականում վերակայման մասին է, նախկինին ծանուցելը նվազեցնում է գաղտնաբառի փոփոխման ռիսկը, երբ ինչ-որ մեկը փոխում է առանց օրինական սեփականատիրոջ իմացության: Ինչպե՞ս կարող է դա տեղի ունենալ: Շատ տարածված սցենարն այն է, որ ստացվում է օրինական սեփականատիրոջ գաղտնաբառը (վերօգտագործված գաղտնաբառ, որը արտահոսել է մեկ այլ աղբյուրից, մուտքագրված գաղտնաբառ, հեշտ կռահելի գաղտնաբառ և այլն), այնուհետև հարձակվողը որոշում է փոխել այն՝ այդպիսով փակելով սեփականատիրոջը: . Առանց էլփոստի ծանուցման իրական սեփականատերը չի իմանա գաղտնաբառի փոփոխության մասին:

Իհարկե, գաղտնաբառի վերակայման դեպքում սեփականատերն արդեն ինքն է նախաձեռնել գործընթացը (կամ շրջանցել վերը նկարագրված նույնականացման ստուգիչները), ուստի փոփոխությունը. չպետք է լինի կարող է անակնկալ լինել նրա համար, բայց էլփոստի հաստատումը կլինի դրական արձագանք և լրացուցիչ ստուգում: Այն նաև ապահովում է վերը նշված սցենարի համապատասխանությունը:

Օ, և եթե դա արդեն ակնհայտ չէր, Նոր գաղտնաբառ մի ուղարկեք փոստով: Սա կարող է ոմանց ծիծաղ առաջացնել, բայց այսպիսի բան է պատահում:

Տեղեկամատյաններ, տեղեկամատյաններ, տեղեկամատյաններ և մի քանի այլ տեղեկամատյաններ

Գաղտնաբառի վերակայման գործառույթը գրավիչ է հարձակվողների համար. հարձակվողը կամ ցանկանում է մուտք գործել այլ անձի հաշիվ, կամ պարզապես անհարմարություններ է պատճառում հաշվի/համակարգի սեփականատիրոջը: Վերը նկարագրված պրակտիկաներից շատերը նվազեցնում են չարաշահման հավանականությունը, բայց չեն կանխում այն, և նրանք, անշուշտ, չեն խանգարի մարդկանց փորձել օգտագործել այդ հատկանիշը չնախատեսված ձևերով:

Չարամիտ վարքագիծը ճանաչելու համար անտառահատումները բացարձակապես անգնահատելի պրակտիկա է, և ես նկատի ունեմ շատ մանրամասն անտառահատումներ. Գրանցեք մուտքի անհաջող փորձեր, գաղտնաբառի վերակայումներ, գաղտնաբառի փոփոխություններ (այսինքն, երբ օգտվողն արդեն մուտք է գործել) և գրեթե ամեն ինչ, որը կարող է օգնել ձեզ հասկանալ, թե ինչ է կատարվում. սա շատ օգտակար կլինի ապագայում: Մատյան նույնիսկ անհատական մասեր գործընթացը, օրինակ, լավ վերակայման հնարավորությունը պետք է ներառի վեբկայքի միջոցով վերակայում սկսելը (գրել վերակայման հարցումը և մուտքի փորձերը սխալ օգտանունով կամ էլփոստով), գրանցել կայք այցելությունները վերակայված URL-ով (ներառյալ սխալ նշան օգտագործելու փորձերը), և այնուհետև գրանցեք անվտանգության հարցի պատասխանի հաջողությունը կամ ձախողումը:

Երբ ես խոսում եմ լոգերի մասին, նկատի ունեմ ոչ միայն էջը բեռնված լինելու փաստի գրանցումը, այլև հնարավորինս շատ տեղեկություններ հավաքելը, եթե դա գաղտնի չէ. Տղերք, խնդրում եմ գաղտնաբառեր մի գրեք տեղեկամատյաններում: Տեղեկամատյանները պետք է գրանցեն լիազորված օգտագործողի ինքնությունը (նա լիազորված կլինի, եթե նա փոփոխությունները գոյություն ունեցող գաղտնաբառը կամ փորձում է վերականգնել ուրիշի գաղտնաբառը մուտք գործելուց հետո), օգտագործողի ցանկացած անուն կամ էլփոստի հասցե, որը նա փորձում է, գումարած ցանկացած վերակայման նշան, որը փորձում է: Բայց արժե նաև մուտքագրել այնպիսի բաներ, ինչպիսիք են IP հասցեները և, հնարավորության դեպքում, նույնիսկ վերնագրերը պահանջել: Սա թույլ է տալիս վերստեղծել ոչ միայն որ օգտագործողը (կամ հարձակվողը) փորձում է անել, բայց նաև ով նա այդպիսին է.

Պատասխանատվության պատվիրակում այլ կատարողների

Եթե ​​կարծում եք, որ այս ամենը հսկայական աշխատանք է ներկայացնում, դուք միայնակ չեք: Փաստորեն, հաշիվների կառավարման հուսալի համակարգ կառուցելը հեշտ գործ չէ: Այնպես չէ, որ դա տեխնիկապես դժվար է, պարզապես այն ունի բազմաթիվ առանձնահատկություններ: Խոսքը միայն վերակայման մասին չէ, կա գրանցման մի ամբողջ գործընթաց, գաղտնաբառերի անվտանգ պահպանում, մուտքի մի քանի անհաջող փորձեր և այլն, և այլն: Չնայած նրան Ես խթանում եմ ASP.NET անդամակցության մատակարարի նման պատրաստի ֆունկցիոնալությունը օգտագործելու գաղափարը, բացի սրանից, շատ ավելին է պետք անել։

Այսօր կան բազմաթիվ երրորդ կողմի պրովայդերներ, ովքեր ուրախ են իրենց վրա վերցնել ամբողջ ցավը և վերացականացնել այդ ամենը մեկ կառավարվող ծառայության մեջ: Նման ծառայությունները ներառում են OpenID, OAuth և նույնիսկ Facebook: Որոշ մարդիկ անսահման հավատք այս մոդելին (OpenID-ը իսկապես շատ հաջողակ է Stack Overflow-ում), բայց մյուսները նրան բառացիորեն մղձավանջ են համարում.

Կասկածից վեր է, որ OpenID-ի նման ծառայությունը շատ խնդիրներ է լուծում ծրագրավորողների համար, բայց այն, անկասկած, ավելացնում է նաև նորերը: Նրանք որեւէ դեր ունե՞ն։ Այո, բայց ակնհայտորեն մենք չենք տեսնում նույնականացման ծառայություններ մատուցողների զանգվածային ընդունում: Բանկերը, ավիաընկերությունները և նույնիսկ խանութները բոլորն իրականացնում են նույնականացման իրենց մեխանիզմը, և ակնհայտորեն դրա համար շատ լավ պատճառներ կան:

Վնասակար վերականգնում

Վերոնշյալ օրինակներից յուրաքանչյուրի կարևոր կողմն այն է, որ հին գաղտնաբառը համարվում է միայն անօգուտ հաշվի սեփականատիրոջ ինքնությունը հաստատելուց հետո. Սա կարևոր է, քանի որ եթե հաշիվը հնարավոր լինի վերականգնել դեպի նույնականացման ստուգում, սա հնարավորություն կտա բոլոր տեսակի վնասակար գործողությունների համար:

Ահա մի օրինակ. ինչ-որ մեկը գնում է աճուրդի կայքում, և աճուրդի գործընթացի ավարտին մոտ նրանք արգելափակում են մրցակիցներին՝ նախաձեռնելով զրոյական գործընթաց՝ այդպիսով հեռացնելով նրանց սակարկությունից: Ակնհայտ է, որ եթե վատ մշակված վերակայման գործառույթը կարող է չարաշահվել, դա կարող է հանգեցնել լուրջ բացասական արդյունքների: Հարկ է նշել, որ անվավեր մուտքի փորձերի պատճառով հաշվի արգելափակումները նման իրավիճակ են, բայց դա մեկ այլ գրառման թեմա է:

Ինչպես ասացի վերևում, եթե դուք անանուն օգտվողներին հնարավորություն եք տալիս վերականգնել ցանկացած հաշվի գաղտնաբառը՝ պարզապես իմանալով նրանց էլ. Սա չի կարող լինել մեկը DoS, որի մասին մենք նախկինում խոսում էինք, բայց հաշիվ մուտքն արգելափակելու ավելի արագ միջոց չկա, քան վատ մշակված գաղտնաբառի վերակայման գործառույթն օգտագործելը:

Ամենաթույլ օղակը

Մեկ հաշիվը պաշտպանելու տեսանկյունից վերևում գրված ամեն ինչ հիանալի է, բայց դուք միշտ պետք է տեղյակ լինեք ձեր պաշտպանած հաշիվը շրջապատող էկոհամակարգի մասին: Թույլ տվեք ձեզ օրինակ բերել.

ASafaWeb-ը տեղակայված է AppHarbor-ի կողմից տրամադրվող զարմանալի ծառայության վրա: Հոսթինգի հաշիվը վերականգնելու գործընթացը հետևյալն է.

Փուլ 1:

Փուլ 2:

Փուլ 3:

Փուլ 4:

Նախորդ բոլոր տեղեկությունները կարդալուց հետո արդեն հեշտ է հասկանալ, թե իդեալական աշխարհում որ ասպեկտները մի փոքր այլ կերպ կկիրառեինք։ Այնուամենայնիվ, այն, ինչ ես ասում եմ այստեղ, այն է, որ եթե ես հրապարակեմ ASafaWeb-ի նման կայք AppHarbor-ում, և հետո հայտնեմ անվտանգության մեծ հարցեր և պատասխաններ, ավելացնեմ վավերացման երկրորդ գործոնը և մնացած ամեն ինչ անեմ ըստ կանոնների, ապա դա չի փոխվի: այն, որ ամբողջ գործընթացի ամենաթույլ օղակը կարող է կոտրել այդ ամենը։ Եթե ​​ինչ-որ մեկը հաջողությամբ նույնականացնի AppHarbor-ում՝ օգտագործելով իմ տվյալները, նա կկարողանա փոխել ցանկացած ASafaWeb հաշվի գաղտնաբառը, որն իրեն անհրաժեշտ է:

Բանն այն է, որ անվտանգության ներդրման ուժը պետք է դիտարկել ամբողջականորեն. համակարգում յուրաքանչյուր մուտքի կետի սպառնալիքը պետք է մոդելավորվի, նույնիսկ եթե դա մակերեսային գործընթաց է, ինչպիսին է AppHarbor համակարգ մուտք գործելը: Սա պետք է ինձ լավ պատկերացում տա, թե որքան ջանք պետք է գործադրեմ ASafaWeb գաղտնաբառի վերակայման գործընթացում:

Բոլորը միասին դնելով

Այս գրառումը պարունակում է շատ տեղեկատվություն, ուստի ես ուզում եմ այն ​​խտացնել պարզ տեսողական ուրվագծի մեջ.

Հիշեք, որ այս տարրերից յուրաքանչյուրի համար հնարավորինս մանրամասն գրանցվեք: Դա այն է, դա պարզ է:

Արդյունքները

Թվում է, թե իմ գրառումը ընդգրկուն է, այնուամենայնիվ, կան բազմաթիվ լրացուցիչ նյութեր, որոնք ես կարող էր ներառել, բայց հակիրճության համար որոշել է չանել. փրկարար էլ. հասցեի դերը, իրավիճակը, երբ դուք կորցնում եք մուտքը ձեր հաշվի հետ կապված էլ. Ինչպես ավելի վաղ ասացի, վերակայման գործառույթն այնքան էլ բարդ չէ, բայց դրան նայելու բազմաթիվ եղանակներ կան:

Թեև վերակայումն այնքան էլ բարդ չէ, այն հաճախ սխալ է իրականացվում: Վերևում մենք տեսանք մի քանի օրինակ, երբ իրականացումը կարող հանգեցնում են խնդիրների, և շատ ավելի շատ նախադեպեր կան, որտեղ սխալ վերակայումը իրականում խնդիրներ առաջացրեց. Վերջերս պարզվեց, որ գաղտնաբառի վերականգնումն օգտագործվել է 87 դոլար արժողությամբ բիթքոյններ գողանալու համար. Սա լուրջ բացասական արդյունք է։

Այսպիսով, զգույշ եղեք ձեր վերակայման գործառույթների հետ, մոդելային սպառնալիքներ տարբեր կետերում, և ֆունկցիա նախագծելիս մի հանեք ձեր սև գլխարկը, քանի որ մեծ հավանականություն կա, որ ուրիշը այն դնի:

Գովազդի իրավունքների մասին

VDSina առաջարկում է էժան սերվերներ վարձով Ամենօրյա վճարումով յուրաքանչյուր սերվեր միացված է 500 Մեգաբիթանոց ինտերնետ ալիքին և անվճար պաշտպանված է DDoS հարձակումներից:

Source: www.habr.com