Неодамна имав време повторно да размислам за тоа како треба да функционира безбедната функција за ресетирање лозинка, прво кога ја вградував оваа функционалност , а потоа и кога му помогнал на друго лице да направи нешто слично. Во вториот случај, сакав да му дадам врска до канонски ресурс со сите детали за тоа како безбедно да се имплементира функцијата за ресетирање. Сепак, проблемот е што таков ресурс не постои, барем не таков што опишува се што ми изгледа важно. Затоа решив сам да го напишам.
Гледате, светот на заборавените лозинки е всушност доста мистериозен. Има многу различни, сосема прифатливи гледишта и многу доста опасни. Шансите се дека сте се сретнале со секој од нив многу пати како краен корисник; па ќе се обидам да ги користам овие примери за да покажам кој го прави тоа правилно, кој не и на што треба да се фокусирате за да ја вклучите функцијата правилно во вашата апликација.
Складирање на лозинки: хаширање, шифрирање и (здив!) обичен текст
Не можеме да разговараме што да правиме со заборавените лозинки пред да разговараме како да ги складираме. Лозинките се чуваат во базата на податоци во еден од трите главни типа:
- Едноставен текст. Постои колона за лозинка, која се чува во форма на обичен текст.
- Шифрирана. Обично се користи симетрично шифрирање (еден клуч се користи и за шифрирање и за дешифрирање), а шифрираните лозинки исто така се складираат во истата колона.
- Хаширан. Еднонасочен процес (лозинката може да се хашира, но не може да се откине); лозинка, Би сакал да се надевам, проследено со сол, и секој е во својата колона.
Да преминеме директно на наједноставното прашање: Никогаш не чувајте лозинки во обичен текст! Никогаш. Една единствена ранливост на , една невнимателна резервна копија или една од десетиците други едноставни грешки - и тоа е тоа, играње, сите ваши лозинки - тоа е, извинете, лозинки на сите ваши клиенти ќе стане јавен домен. Се разбира, ова би значело огромна веројатност дека од сите нивни сметки во други системи. И тоа ќе биде твоја вина.
Енкрипцијата е подобра, но има свои слабости. Проблемот со шифрирањето е дешифрирањето; можеме да ги земеме овие шифри со луд изглед и да ги претвориме во обичен текст, а кога тоа ќе се случи, се враќаме на ситуацијата со лозинка читлива од човек. Како се случува ова? Мала грешка се навлегува во кодот што ја дешифрира лозинката, правејќи ја јавно достапна - ова е еден начин. Хакерите добиваат пристап до машината на која се чуваат шифрирани податоци - ова е вториот метод. Друг начин, повторно, е да се украде резервната копија од базата на податоци и некој исто така да го добие клучот за шифрирање, кој често е многу несигурно зачуван.
И ова нè доведува до хаширање. Идејата зад хаширањето е дека тоа е еднонасочно; единствениот начин да се спореди лозинката внесена од корисникот со нејзината хеширана верзија е да се хашира влезот и да се споредат. За да спречиме напади од алатки како што се табелите на виножитото, го посолуваме процесот случајно (прочитајте ја мојата за криптографското складирање). На крајот на краиштата, ако се имплементира правилно, можеме да бидеме уверени дека хашираните лозинки никогаш повеќе нема да станат обичен текст (ќе зборувам за придобивките од различните алгоритми за хеширање во друг пост).
Брз аргумент за хаширање наспроти шифрирање: единствената причина зошто некогаш би требало да шифрирате наместо да ја хаширате лозинката е кога треба да ја видите лозинката во обичен текст и никогаш не треба да го сакате ова, барем во стандардна ситуација на веб-страница. Ако ви треба ова, тогаш најверојатно правите нешто погрешно!
Предупредување!
Подолу во текстот на објавата има дел од скриншот на порнографската веб-страница 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 не може да биде полесно.
Тајни прашања и одговори
Со сите методи што ги разгледавме, успеавме да ја ресетираме лозинката само со пристап до сметката за е-пошта. Велам „само“, но, се разбира, нелегално е да се добие пристап до туѓата е-пошта сметка. треба биде сложен процес. Сепак .
Всушност, врската погоре за хакирањето на Јаху на Сара Пејлин! служи за две цели; прво, илустрира колку е лесно да се хакираат (некои) сметки за е-пошта, и второ, покажува како лошите безбедносни прашања може да се користат со злонамерна намера. Но, ние ќе се вратиме на ова подоцна.
Проблемот со XNUMX% ресетирање на лозинка базирана на е-пошта е тоа што интегритетот на сметката за страницата што се обидувате да ја ресетирате станува XNUMX% зависен од интегритетот на сметката за е-пошта. Секој кој има пристап до вашата е-пошта има пристап до која било сметка што може да се ресетира со едноставно примање е-пошта. За такви сметки, е-поштата е „клучот за сите врати“ на вашиот онлајн живот.
Еден начин да се намали овој ризик е да се имплементира шема на безбедносни прашања и одговори. Без сомнение дека веќе сте ги виделе: изберете прашање на кое само вие можете да одговорите имаат знајте го одговорот, а потоа кога ќе ја ресетирате лозинката ќе ви биде побарано. Ова додава доверба дека лицето кое се обидува да го ресетира е навистина сопственик на сметката.
Назад на Сара Пејлин: грешката беше што лесно можеше да се најдат одговорите на нејзиното безбедносно прашање/прашања. Особено кога сте толку значајна јавна личност, информациите за моминското презиме на вашата мајка, образовната историја или каде некој можеби живеел во минатото не се толку тајна. Всушност, поголемиот дел од него може да го најде речиси секој. Еве што и се случи на Сара:
Хакерот Дејвид Кернел доби пристап до сметката на Пејлин со тоа што пронашол детали за нејзиното потекло, како што се нејзиниот универзитет и датум на раѓање, а потоа ја искористил функцијата за враќање на заборавената лозинка на Yahoo!.
Како прво, ова е дизајнерска грешка од страна на Yahoo! — со наведување на такви едноставни прашања, компанијата во суштина ја саботира вредноста на безбедносното прашање, а со тоа и заштитата на својот систем. Се разбира, ресетирањето на лозинките за сметката за е-пошта е секогаш потешко бидејќи не можете да ја докажете сопственоста со испраќање е-пошта до сопственикот (без да имате втора адреса), но за среќа денес нема многу намени за создавање таков систем.
Да се вратиме на безбедносните прашања - постои опција да му се овозможи на корисникот да креира свои прашања. Проблемот е што ова ќе резултира со ужасно очигледни прашања:
Каква боја е небото?
Прашања што ги прават луѓето да се чувствуваат непријатно кога безбедносното прашање се користи за идентификација лице (на пример, во центар за повици):
Со кого спиев на Божиќ?
Или искрено глупави прашања:
Како се пишува „лозинка“?
Кога станува збор за безбедносни прашања, корисниците треба да се спасат од себе! Со други зборови, безбедносното прашање треба да го определи самиот сајт, или уште подобро, да го постави серија безбедносни прашања од кои корисникот може да избира. И не е лесно да се избере една; идеално корисникот треба да избере две или повеќе безбедносни прашања во моментот на регистрација на сметката, кој потоа ќе се користи како втор канал за идентификација. Имањето повеќе прашања ја зголемува довербата во процесот на верификација, а исто така обезбедува можност за додавање случајност (не секогаш го прикажува истото прашање), плус обезбедува малку вишок во случај вистинскиот корисник да ја заборави лозинката.
Што е добро безбедносно прашање? Ова е под влијание на неколку фактори:
- Тоа треба да биде краток - Прашањето мора да биде јасно и недвосмислено.
- Одговорот мора да биде специфични - Не ни треба прашање на кое еден човек може да одговори поинаку
- Можни одговори треба да бидат разновидна - прашувањето на нечија омилена боја дава многу мала подгрупа на можни одговори
- Барај одговорот мора да биде сложен - ако одговорот може лесно да се најде било (запомнете луѓе на високи позиции), тогаш тој е лош
- Одговорот мора да биде постојан со време - ако прашате нечиј омилен филм, тогаш една година подоцна одговорот може да биде различен
Како што се случува, постои веб-страница посветена на поставување добри прашања наречена . Некои од прашањата изгледаат доста добри, други не поминуваат некои од тестовите опишани погоре, особено тестот „леснотија на пребарување“.
Дозволете ми да покажам како PayPal ги имплементира безбедносните прашања и, особено, напорот што го вложува страницата за автентикација. Погоре ја видовме страницата за започнување на процесот (со CAPTCHA), а овде ќе покажеме што се случува откако ќе ја внесете вашата адреса за е-пошта и ќе го решите CAPTCHA:
Како резултат на тоа, корисникот го добива следново писмо:
Досега сè е сосема нормално, но еве што се крие зад овој ресетиран URL:
Значи, безбедносните прашања влегуваат во игра. Всушност, PayPal исто така ви овозможува да ја ресетирате лозинката со потврдување на бројот на вашата кредитна картичка, така што има дополнителен канал до кој многу сајтови немаат пристап. Едноставно не можам да ја сменам лозинката без да одговорам и двајцата безбедносно прашање (или не знаејќи го бројот на картичката). Дури и некој да ми ја киднапира е-поштата, нема да може да ја ресетира лозинката на мојата сметка на PayPal освен ако не знае малку повеќе лични информации за мене. Кои информации? Еве ги опциите за безбедносни прашања што ги нуди PayPal:
Прашањето за училиштето и болницата можеби е малку незгодно во однос на леснотијата на пребарување, но другите не се премногу лоши. Сепак, за да се подобри безбедноста, PayPal бара дополнителна идентификација за промени одговори на безбедносни прашања:
PayPal е прилично утописки пример за безбедно ресетирање на лозинката: тој имплементира CAPTCHA за да ја намали опасноста од напади со брутална сила, бара две безбедносни прашања, а потоа бара друг вид на сосема поинаква идентификација само за да ги промени одговорите - и ова по корисникот веќе е пријавен. Се разбира, тоа е токму она што ние очекувано од PayPal; е финансиска институција која се занимава со големи суми на пари. Ова не значи дека секое ресетирање на лозинката мора да ги следи овие чекори - најчесто тоа е претерано - но тоа е добар пример за случаи кога безбедноста е сериозна работа.
Практичноста на системот за безбедносни прашања е тоа што ако не сте го имплементирале веднаш, можете да го додадете подоцна ако нивото на заштита на ресурсите го бара тоа. Добар пример за ова е Apple, кој неодамна го имплементира овој механизам [напис напишан во 2012 година]. Откако почнав да ја ажурирам апликацијата на мојот iPad, го видов следново барање:
Потоа видов екран каде што можев да изберам неколку пара безбедносни прашања и одговори, како и адреса на е-пошта за спасување:
Што се однесува до PayPal, прашањата се претходно избрани и некои од нив се всушност прилично добри:
Секој од трите парови прашања/одговори претставува различен сет на можни прашања, така што има многу начини за конфигурирање на сметката.
Друг аспект што треба да се земе предвид во однос на одговорот на вашето безбедносно прашање е складирањето. Имањето база на податоци со обичен текст во базата на податоци ги претставува речиси истите закани како лозинката, имено дека изложувањето на базата на податоци веднаш ја открива вредноста и ја става не само апликацијата во ризик, туку потенцијално сосема различни апликации кои користат исти безбедносни прашања (повторно ). Една опција е безбедно хаширање (силен алгоритам и криптографски случајна сол), но за разлика од повеќето случаи за складирање лозинки, може да има добра причина одговорот да биде видлив како обичен текст. Типично сценарио е проверка на идентитетот од телефонски оператор во живо. Се разбира, хаширањето е исто така применливо во овој случај (операторот може едноставно да го внесе одговорот именуван од клиентот), но во најлош случај, тајниот одговор мора да се наоѓа на некое ниво на криптографско складирање, дури и ако тоа е само симетрично шифрирање . Резимирај: третирајте ги тајните како тајни!
Еден последен аспект на безбедносните прашања и одговори е дека тие се поранливи на социјалниот инженеринг. Обидот директно да се извлече лозинката на туѓа сметка е една работа, но започнувањето разговор за нејзиното формирање (популарно безбедносно прашање) е сосема поинакво. Всушност, можете многу добро да комуницирате со некого за многу аспекти од неговиот живот кои би можеле да постават тајно прашање без да предизвикаат сомнеж. Се разбира, самата поента на безбедносното прашање е тоа што се однесува на нечие животно искуство, па затоа е незаборавно, и тука лежи проблемот - луѓето сакаат да зборуваат за нивните животни искуства! Има малку што можете да направите за ова, само ако изберете такви опции за безбедносни прашања така што тие се помалку веројатно би можеле да бидат извлечени со социјален инженеринг.
[Продолжува.]За правата на рекламирање
ВДСина нуди сигурен , секој сервер е поврзан на интернет канал од 500 мегабити и е заштитен од DDoS напади бесплатно!
Извор: www.habr.com