Недавно сам поново имао времена да размислим о томе како би функција безбедног ресетовања лозинке требало да функционише, прво када сам уграђивао ову функционалност у , а затим када је помогао другој особи да уради нешто слично. У другом случају, желео сам да му дам везу ка канонском ресурсу са свим детаљима о томе како безбедно применити функцију ресетовања. Међутим, проблем је што такав ресурс не постоји, барем не онај који описује све што ми се чини важним. Па сам одлучио да то сам напишем.
Видите, свет заборављених лозинки је заправо прилично мистериозан. Постоји много различитих, потпуно прихватљивих гледишта и доста опасних. Шансе су да сте се са сваким од њих сусрели много пута као крајњи корисник; па ћу покушати да искористим ове примере да покажем ко то ради како треба, а ко не и на шта треба да се усредсредите да бисте ову функцију добили тачно у својој апликацији.
Складиштење лозинки: хеширање, шифровање и (задах!) обичан текст
Не можемо да разговарамо о томе шта да радимо са заборављеним лозинкама пре него што разговарамо о томе како да их чувамо. Лозинке се чувају у бази података у једном од три главна типа:
- Једноставан текст. Постоји колона лозинке, која се чува у облику обичног текста.
- Шифровано. Обично се користи симетрично шифровање (један кључ се користи и за шифровање и за дешифровање), а шифроване лозинке се такође чувају у истој колони.
- Хеширано. Једносмерни процес (лозинка се може хеширати, али се не може дехеширати); Лозинка, волео бих да се надам, затим соли, а свако је у својој колони.
Хајдемо директно на најједноставније питање: Никада не чувајте лозинке у обичном тексту! Никада. Једна једина рањивост на , једна непажљива резервна копија или једна од десетина других једноставних грешака - и то је то, завршена игра, све ваше лозинке - то јест, извините, лозинке свих ваших клијената постаће јавно власништво. Наравно, то би значило велику вероватноћу да са свих њихових налога у другим системима. И то ће бити твоја кривица.
Шифровање је боље, али има своје слабости. Проблем са шифровањем је дешифровање; можемо узети ове шифре лудог изгледа и претворити их назад у обичан текст, а када се то деси враћамо се у ситуацију са лозинком читљивом за људе. Како се ово дешава? Мала грешка улази у код који дешифрује лозинку, чинећи је јавно доступном - ово је један од начина. Хакери добијају приступ машини на којој се чувају шифровани подаци - ово је други метод. Други начин је, опет, да се украде резервна копија базе података и неко такође добије кључ за шифровање, који је често веома несигурно ускладиштен.
И ово нас доводи до хеширања. Идеја иза хеширања је да је оно једносмерно; једини начин да се упореди лозинка коју је унео корисник са њеном хешираном верзијом је да се хешује унос и упореди. Да бисмо спречили нападе алата као што су дугини столови, процес солимо насумичношћу (прочитајте моје о криптографском складиштењу). Коначно, ако се правилно примени, можемо бити сигурни да хеширане лозинке никада више неће постати обичан текст (о предностима различитих алгоритама за хеширање ћу говорити у другом посту).
Брзи аргумент о хеширању у односу на шифровање: једини разлог зашто бисте икада морали да шифрујете уместо да хеширате лозинку је када морате да видите лозинку у обичном тексту, и ово никада не би требало да желиш, барем у стандардној ситуацији на веб локацији. Ако вам је ово потребно, онда највероватније нешто радите погрешно!
Упозорење!
Испод текста поста налази се део снимка екрана порнографске веб странице АлотПорн. Уредно је ошишан тако да нема ничега што не можете да видите на плажи, али ако и даље постоји вероватноћа да ће изазвати проблеме, немојте померати надоле.
Увек ресетујте лозинку никад не подсећај га
Да ли вам је икада затражено да креирате функцију подсетници Лозинка? Направите корак уназад и размислите о овом захтеву обрнуто: зашто је неопходан овај „подсетник“? Зато што је корисник заборавио лозинку. Шта заиста желимо да радимо? Помозите му да се поново пријави.
Схватам да се реч „подсетник“ користи (често) у колоквијалном смислу, али оно што ми заиста покушавамо да урадимо је безбедно помоћи кориснику да поново буде на мрежи. Пошто нам је потребна сигурност, постоје два разлога зашто подсетник (тј. слање лозинке кориснику) није прикладан:
- Е-пошта је несигуран канал. Баш као што не бисмо слали ништа осетљиво преко ХТТП-а (користили бисмо ХТТПС), не бисмо смели да шаљемо ништа осетљиво путем е-поште јер је његов транспортни слој небезбедан. У ствари, ово је много горе од једноставног слања информација преко несигурног транспортног протокола, јер се пошта често чува на уређају за складиштење, доступна администраторима система, прослеђена и дистрибуирана, доступна малверу итд. Нешифрована е-пошта је изузетно несигуран канал.
- Ионако не би требало да имате приступ лозинки. Поново прочитајте претходни одељак о складиштењу – требало би да имате хеш лозинке (са добром јаком соли), што значи да не би требало да будете у могућности да на било који начин извучете лозинку и пошаљете је поштом.
Дозволите ми да демонстрирам проблем на примеру : Ево типичне странице за пријављивање:
Очигледно, први проблем је што се страница за пријаву не учитава преко ХТТПС-а, али сајт такође тражи да пошаљете лозинку („Пошаљи лозинку“). Ово може бити пример колоквијалне употребе горе поменутог термина, па хајде да направимо корак даље и видимо шта се дешава:
Не изгледа много боље, нажалост; и имејл потврђује да постоји проблем:
Ово нам говори о два важна аспекта усоутдоор.цом:
- Сајт не хешује лозинке. У најбољем случају, они су шифровани, али је вероватно да су ускладиштени у обичном тексту; Не видимо никакве доказе за супротно.
- Сајт шаље дугорочну лозинку (можемо се вратити и користити је изнова и изнова) преко небезбедног канала.
Када ово скинемо с пута, морамо да проверимо да ли је процес ресетовања обављен на безбедан начин. Први корак да то урадите је да се уверите да подносилац захтева има право да изврши ресетовање. Другим речима, пре тога нам је потребна провера идентитета; хајде да погледамо шта се дешава када се идентитет верификује без претходног верификације да је подносилац захтева заправо власник налога.
Навођење корисничких имена и њихов утицај на анонимност
Овај проблем је најбоље илустровати визуелно. Проблем:
Видиш? Обратите пажњу на поруку „Нема регистрованог корисника са овом адресом е-поште.“ Проблем очигледно настаје ако такав сајт потврди доступност корисник регистрован са таквом адресом е-поште. Бинго – управо сте открили порно фетиш свог мужа/шефа/комшије!
Наравно, порнографија је прилично иконичан пример важности приватности, али опасности повезивања појединца са одређеним веб-сајтом су много шире од потенцијално незгодне ситуације која је горе описана. Једна опасност је друштвени инжењеринг; Ако нападач може да упореди особу са услугом, онда ће имати информације које може почети да користи. На пример, он може контактирати особу која се представља као представник веб локације и затражити додатне информације у покушају да се обавеже .
Такве праксе такође повећавају опасност од „набрајања корисничког имена“, при чему се може потврдити постојање читаве колекције корисничких имена или адреса е-поште на веб локацији једноставним постављањем групних упита и испитивањем одговора на њих. Да ли имате списак имејл адреса свих запослених и неколико минута да напишете скрипту? Онда видите у чему је проблем!
Шта је алтернатива? У ствари, прилично је једноставно и дивно је имплементирано :
Овде Ентропаи не открива апсолутно ништа о постојању адресе е-поште у свом систему некоме ко не поседује ову адресу... ако ти сопствени ову адресу и не постоји у систему, добићете е-поруку попут ове:
Наравно, могу постојати прихватљиве ситуације у којима неко мислида сте се регистровали на веб страници. али то није случај, или сам то урадио са друге адресе е-поште. Пример приказан изнад добро решава обе ситуације. Очигледно, ако се адреса подудара, добићете поруку е-поште која ће вам олакшати ресетовање лозинке.
Суптилност решења које је изабрао Ентропаи је да се провера идентификације врши према е-маил пре било какве онлајн верификације. Неки сајтови траже од корисника одговор на безбедносно питање (више о томе у наставку) до како ресетовање може да почне; међутим, проблем са овим је што морате да одговорите на питање док наведете неки облик идентификације (е-маил или корисничко име), што онда чини готово немогућим интуитивни одговор без откривања постојања налога анонимног корисника.
Са овим приступом постоји мали смањена употребљивост јер ако покушате да ресетујете непостојећи налог, нема тренутних повратних информација. Наравно, то је цела поента слања е-поште, али из перспективе стварног крајњег корисника, ако унесе погрешну адресу, знаће тек када прими е-пошту. Ово може изазвати одређену напетост са његове стране, али ово је мала цена за тако редак процес.
Још једна напомена, мало ван теме: функције помоћи при пријављивању које откривају да ли су корисничко име или адреса е-поште исправни имају исти проблем. Увек одговорите кориснику поруком „Комбинација вашег корисничког имена и лозинке је неважећа“ уместо да експлицитно потврђујете постојање акредитива (на пример, „корисничко име је тачно, али лозинка је нетачна“).
Слање лозинке за ресетовање наспрам слања УРЛ-а за ресетовање
Следећи концепт о којем треба да разговарамо је како да ресетујете лозинку. Постоје два популарна решења:
- Генерисање нове лозинке на серверу и слање путем е-поште
- Пошаљите е-поруку са јединственим УРЛ-ом да бисте олакшали процес ресетовања
Упркос , прва тачка се никада не сме користити. Проблем са овим је што то значи да постоји сачувана лозинка, на који се можете вратити и поново користити у било ком тренутку; послато је преко несигурног канала и остаје у вашем пријемном сандучету. Шансе су да се пријемни сандучићи синхронизују на мобилним уређајима и клијенту е-поште, плус могу да се чувају на мрежи у веб сервису е-поште веома дуго. Поента је у томе поштанско сандуче се не може сматрати поузданим средством за дуготрајно складиштење.
Али поред овога, прва тачка има још један озбиљан проблем - то поједностављује што је више могуће блокирање налога са злонамерном намером. Ако знам адресу е-поште некога ко поседује налог на веб локацији, могу га блокирати у било ком тренутку једноставним ресетовањем његове лозинке; Ово је напад ускраћивања услуге сервиран на сребрном послужавнику! Због тога би ресетовање требало да се изврши тек након успешне провере права подносиоца захтева на то.
Када говоримо о УРЛ адреси за ресетовање, мислимо на адресу веб локације која је јединствен за овај конкретан случај процеса ресетовања. Наравно, требало би да буде насумично, не би требало да буде лако погодити и не би требало да садржи никакве спољне везе до налога које олакшавају ресетовање. На пример, УРЛ за ресетовање не би требало да буде само путања попут „Ресет/?усернаме=ЈохнСмитх“.
Желимо да креирамо јединствени токен који може да се пошаље поштом као УРЛ за ресетовање, а затим да се упореди са записом сервера корисничког налога, чиме потврђујемо да је власник налога, у ствари, иста особа која покушава да ресетује лозинку. На пример, токен може бити „3це7854015цд38ц862цб9е14а1ае552б“ и ускладиштен у табели заједно са ИД-ом корисника који је извршио ресетовање и временом када је токен генерисан (више о томе у наставку). Када се имејл пошаље, садржи УРЛ као што је „Ресет/?ид=3це7854015цд38ц862цб9е14а1ае552б“, а када га корисник преузме, страница тражи постојање токена, након чега потврђује податке корисника и дозвољава му да промени Лозинка.
Наравно, пошто горњи процес (надамо се) омогућава кориснику да креира нову лозинку, морамо да се уверимо да се УРЛ учитава преко ХТТПС-а. Не, , овај УРЛ токена мора да користи безбедност транспортног слоја тако да се нови образац лозинке не може напасти а лозинка коју је креирао корисник је пренета преко безбедне везе.
Такође за УРЛ за ресетовање морате да додате временско ограничење токена како би процес ресетовања могао да се заврши у одређеном интервалу, рецимо у року од сат времена. Ово осигурава да је временски оквир за ресетовање минималан, тако да прималац УРЛ адресе за ресетовање може да делује само унутар тог веома малог прозора. Наравно, нападач може поново покренути процес ресетовања, али ће морати да добије још један јединствени УРЛ за ресетовање.
Коначно, морамо осигурати да овај процес буде једнократан. Када се процес ресетовања заврши, токен се мора уклонити тако да УРЛ за ресетовање више не функционише. Претходна тачка је неопходна да би се осигурало да нападач има веома мали прозор током којег може да манипулише УРЛ-ом за ресетовање. Плус, наравно, када је ресетовање успешно, токен више није потребан.
Неки од ових корака могу изгледати сувише сувишни, али не ометају употребљивост и у ствари побољшати безбедност, иако у ситуацијама за које се надамо да ће бити ретке. У 99% случајева, корисник ће омогућити ресетовање у врло кратком временском периоду и неће поново ресетовати лозинку у блиској будућности.
Улога ЦАПТЦХА
Ох, ЦАПТЦХА, безбедносна функција коју сви волимо да мрзимо! У ствари, ЦАПТЦХА није толико заштитни алат колико је алат за идентификацију - било да сте особа или робот (или аутоматска скрипта). Његова сврха је да избегне аутоматско подношење обрасца, што, наравно, моћи користити као покушај разбијања обезбеђења. У контексту ресетовања лозинке, ЦАПТЦХА значи да се функција ресетовања не може грубо присилити да кориснику пошаље нежељену пошту или покуша да утврди постојање налога (што, наравно, неће бити могуће ако следите савете у одељку о провера идентитета).
Наравно, сама ЦАПТЦХА није савршена; Постоји много преседана за његово „хаковање“ софтвера и постизање довољних стопа успеха (60-70%). Поред тога, постоји решење приказано у мом посту о , где можете да платите људима делиће цента да реше сваки ЦАПТЦХА и постигнете стопу успешности од 94%. Односно, рањиво је, али (мало) подиже баријеру уласку.
Хајде да погледамо пример ПаиПал-а:
У овом случају, процес ресетовања једноставно не може да почне док се ЦАПТЦХА не реши, дакле теоретски немогуће је аутоматизовати процес. Теоретски.
Међутим, за већину веб апликација ово ће бити превише и апсолутно у праву представља смањење употребљивости - људи једноставно не воле ЦАПТЦХА! Поред тога, ЦАПТЦХА је нешто чему се лако можете вратити ако је потребно. Ако услуга почне да буде нападнута (овде добро дође евидентирање, али више о томе касније), додавање ЦАПТЦХА не може бити лакше.
Тајна питања и одговори
Уз све методе које смо разматрали, успели смо да ресетујемо лозинку само приступом налогу е-поште. Кажем „само“, али, наравно, незаконито је добити приступ туђем налогу е-поште. треба бити сложен процес. Међутим .
У ствари, горњи линк о хаковању Иахоо-а Сарах Палин! служи у две сврхе; прво, илуструје колико је лако хаковати (неке) налоге е-поште, и друго, показује колико лоша безбедносна питања могу да се користе са злонамерним намерама. Али на ово ћемо се вратити касније.
Проблем са ресетовањем лозинке на бази 100% е-поште је тај што интегритет налога за локацију коју покушавате да ресетујете постаје 100% зависан од интегритета налога е-поште. Свако ко има приступ вашој е-пошти има приступ било ком налогу који се може ресетовати једноставним примањем е-поште. За такве налоге, е-пошта је „кључ свих врата“ вашег живота на мрежи.
Један од начина да се смањи овај ризик је да се примени образац безбедносног питања и одговора. Нема сумње да сте их већ видели: изаберите питање на које само ви можете да одговорите имати знате одговор, а онда када ресетујете лозинку од вас ће се тражити да је унесете. Ово додаје поверење да је особа која покушава да ресетује заиста власник налога.
Да се вратимо Сари Пејлин: грешка је била у томе што су се одговори на њено безбедносно питање/питања лако могли пронаћи. Нарочито када сте тако значајна јавна личност, информације о девојачком презимену ваше мајке, историји образовања или о томе где је неко можда живео у прошлости нису баш тајна. У ствари, већину тога може пронаћи скоро свако. Ево шта се догодило Сари:
Хакер Дејвид Кернел је добио приступ Пејлином налогу тако што је пронашао детаље о њеној позадини, као што су њен универзитет и датум рођења, а затим је користио Иахоо!-ову функцију за опоравак заборављене лозинке.
Пре свега, ово је грешка у дизајну од стране Иахоо! — прецизирајући тако једноставна питања, компанија је суштински саботирала вредност безбедносног питања, а самим тим и заштиту свог система. Наравно, ресетовање лозинки за налог е-поште је увек теже јер не можете да докажете власништво слањем е-поште власнику (без друге адресе), али на срећу нема много начина да се креира такав систем данас.
Вратимо се на безбедносна питања – постоји опција да се кориснику дозволи да креира своја питања. Проблем је што ће то резултирати ужасно очигледним питањима:
Које боје је небо?
Питања због којих је људима непријатно када се за идентификацију користи безбедносно питање особа (на пример, у позивном центру):
Са ким сам спавао за Божић?
Или искрено глупа питања:
Како се пише "лозинка"?
Када су у питању безбедносна питања, кориснике треба сачувати од самих себе! Другим речима, безбедносно питање треба да одреди сам сајт, или још боље, постављен serije безбедносна питања од којих корисник може да бира. И није лако изабрати један; идеално би требало да корисник изабере два или више безбедносних питања у тренутку регистрације налога, који ће се затим користити као други идентификациони канал. Поседовање више питања повећава поверење у процес верификације, а такође пружа могућност додавања случајности (не приказује увек исто питање), плус пружа мало сувишности у случају да је стварни корисник заборавио лозинку.
Шта је добро безбедносно питање? На то утиче неколико фактора:
- Треба да буде кратак — питање мора бити јасно и недвосмислено.
- Одговор мора бити специфичне — не треба нам питање на које једна особа може другачије да одговори
- Могући одговори би требали бити разнолика - постављање питања о нечијој омиљеној боји даје врло мали подскуп могућих одговора
- Претрага одговор мора бити сложен – ако се одговор може лако наћи било који (сетите се људи на високим позицијама), онда је лош
- Одговор мора бити стални на време - ако питате нечији омиљени филм, онда годину дана касније одговор може бити другачији
Како се то дешава, постоји веб локација посвећена постављању добрих питања тзв . Нека питања изгледају прилично добра, друга не пролазе неке од горе описаних тестова, посебно тест „лакоће претраживања“.
Дозволите ми да покажем како ПаиПал примењује безбедносна питања и, посебно, напоре које сајт улаже у аутентификацију. Изнад смо видели страницу за почетак процеса (са ЦАПТЦХА), а овде ћемо показати шта се дешава након што унесете своју адресу е-поште и решите ЦАПТЦХА:
Као резултат, корисник добија следеће писмо:
До сада је све било сасвим нормално, али ево шта се крије иза овог ресет УРЛ-а:
Дакле, безбедносна питања долазе у игру. У ствари, ПаиПал вам такође омогућава да ресетујете лозинку тако што ћете потврдити број ваше кредитне картице, тако да постоји додатни канал којем многе веб локације немају приступ. Једноставно не могу да променим лозинку без одговора обоје сигурносно питање (или непознавање броја картице). Чак и ако је неко отео моју е-пошту, не би могао да ресетује лозинку за мој ПаиПал налог осим ако не зна мало више личних података о мени. Које информације? Ево опција безбедносних питања које ПаиПал нуди:
Питање школе и болнице може бити мало незгодно у смислу лакоће претраживања, али остала нису тако лоша. Међутим, да би побољшао безбедност, ПаиПал захтева додатну идентификацију за Промене одговори на безбедносна питања:
ПаиПал је прилично утопијски пример безбедног ресетовања лозинке: примењује ЦАПТЦХА да смањи опасност од напада грубом силом, захтева два безбедносна питања, а затим захтева другу врсту потпуно другачије идентификације само да би променио одговоре — и то након што корисник већ се пријавио. Наравно, ми смо управо то очекиван са ПаиПал-а; је финансијска институција која послује са великим сумама новца. То не значи да свако ресетовање лозинке мора да прати ове кораке – у већини случајева то је превише – али је добар пример за случајеве у којима је безбедност озбиљан посао.
Погодност система безбедносних питања је да ако га нисте одмах применили, можете га додати касније ако ниво заштите ресурса то захтева. Добар пример за то је Аппле, који је тек недавно имплементирао овај механизам [чланак написан 2012.]. Када сам почео да ажурирам апликацију на свом иПад-у, видео сам следећи захтев:
Затим сам видео екран на коме сам могао да изаберем неколико парова безбедносних питања и одговора, као и адресу е-поште за спасавање:
Што се тиче ПаиПал-а, питања су унапред одабрана и нека од њих су прилично добра:
Сваки од три пара питања/одговора представља другачији скуп могућих питања, тако да постоји много начина за конфигурисање налога.
Још један аспект који треба размотрити у вези са одговором на ваше безбедносно питање је складиштење. Поседовање базе података у облику обичног текста у бази података представља скоро исте претње као и лозинка, наиме, откривање базе података тренутно открива вредност и доводи у опасност не само апликацију, већ и потенцијално потпуно различите апликације које користе иста безбедносна питања (ту опет ). Једна опција је безбедно хеширање (снажан алгоритам и криптографски насумична сол), али за разлику од већине случајева складиштења лозинки, може постојати добар разлог да одговор буде видљив као обичан текст. Типичан сценарио је верификација идентитета од стране телефонског оператера уживо. Наравно, хеширање је такође примењиво у овом случају (оператер може једноставно да унесе одговор који је именовао клијент), али у најгорем случају, тајни одговор мора бити лоциран на неком нивоу криптографског складиштења, чак и ако се ради само о симетричној енкрипцији . Резимирати: третирајте тајне као тајне!
Последњи аспект безбедносних питања и одговора је да су они рањивији на друштвени инжењеринг. Покушај директног издвајања лозинке на туђи налог је једно, али је потпуно друга ствар започети разговор о њеном формирању (популарно безбедносно питање). У ствари, можете врло добро да комуницирате са неким о многим аспектима њиховог живота који могу представљати тајно питање без изазивања сумње. Наравно, сама поента безбедносног питања је да се оно односи на нечије животно искуство, тако да је за памћење, и ту је проблем - људи воле да причају о својим животним искуствима! Мало тога можете да урадите у вези са овим, само ако изаберете такве опције безбедносног питања да буду мање вероватно би могао бити извучен социјалним инжењерингом.
[Наставиће се.]О правима оглашавања
ВДСина нуди поуздане , сваки сервер је повезан на интернет канал од 500 мегабита и заштићен је од ДДоС напада бесплатно!
Извор: ввв.хабр.цом