Нядаўна ў мяне з'явілася час зноў паразважаць над тым, як павінна працаваць функцыя бяспечнага скіду пароля, спачатку калі я ўбудоўваў гэтую функцыянальнасць у , а потым калі дапамагаў зрабіць нешта падобнае іншаму чалавеку. У другім выпадку я жадаў даць яму спасылку на кананічны рэсурс са ўсімі падрабязнасцямі бяспечнай рэалізацыі функцыі скіду. Аднак праблема ў тым, што такога рэсурсу не існуе, прынамсі, такога, у якім апісваецца ўсё, што мне падаецца важным. Таму я вырашыў напісаць яго сам.
Ці бачыце, мір забытых пароляў насамрэч даволі загадкавы. Існуе мноства розных, зусім прымальных кропак гледжання і куча даволі небяспечных. Ёсць верагоднасць, што з кожнай з іх вы шмат разоў сутыкаліся як канчатковы карыстач; таму я паспрабую скарыстацца гэтымі прыкладамі, каб паказаць, хто робіць усё правільна, а хто не, і на чым трэба засяродзіцца для правільнай рэалізацыі функцыі ў сваім дадатку.
Захоўванне пароляў: хэшаванне, шыфраванне і (ох!) просты тэкст
Мы не можам абмяркоўваць, што рабіць з забытымі паролямі, перш чым не абмяркуем спосаб іх захоўвання. У базе дадзеных паролі захоўваюцца ў адным з трох асноўных відаў:
- Просты тэкст. Ёсць слупок з паролем, які захоўваецца ў звычайным тэкставым выглядзе.
- Зашыфраваны. Звычайна з дапамогай сіметрычнага шыфравання (адзін ключ выкарыстоўваецца і для шыфравання і для дэшыфроўкі), а зашыфраваныя паролі таксама захоўваюцца ў адным слупку.
- Хэшаваны. Аднабаковы працэс (пароль можна хэшаваць, але нельга дэхэшаваць); пароль, хацелася б спадзявацца, суправаджаецца соллю, і кожны з іх знаходзіцца ва ўласным слупку.
Давайце адразу разбярэмся з самым простым пытаннем: ніколі не захоўвайце паролі ў простым тэксце! Ніколі. Адна адзіная ўразлівасць да , адна неабачліва зробленая рэзервовая копія або адна з дзясяткаў іншых простых памылак - і ўсё, геймовер, усе вашыя паролі - гэта значыць, прабачце, паролі ўсіх вашых кліентаў стануць грамадскім здабыткам. Зразумела, гэта будзе азначаць вялікую верагоднасць таго, што грамадскім набыткам стануць ад усіх іх уліковых запісаў у іншых сістэмах. І гэта будзе вашай віной.
Шыфраванне лепш, але мае свае слабыя бакі. Праблема шыфравання - у дэшыфроўцы; можна ўзяць гэтыя шалёна выглядаюць шыфры і пераўтварыць іх зваротна ў просты тэкст, а калі гэта адбудзецца, мы вернемся да сітуацыі з чытэльнымі паролямі. Як гэта адбываецца? Невялікі загана пранікае ў код, які займаецца дэшыфроўкай пароля, робячы яго публічна даступным – гэта адзін са спосабаў. Доступ да машыны, на якой захоўваюцца зашыфраваныя дадзеныя, атрымліваюць узломшчыкі - гэта другі спосаб. Яшчэ адзін спосаб ізноў-ткі складаецца ў тым, што выкрадаюць рэзервовую копію базы дадзеных, і нехта таксама атрымлівае ключ шыфравання, якія часта захоўваюцца вельмі ненадзейна.
І гэта прыводзіць нас да хэшавання. Ідэя хэшавання заключаецца ў тым, што яно выконваецца ў адзін бок; адзіны спосаб параўнання ўведзенага карыстальнікам пароля з яго хэшаванай версіяй - хэшаванне ўведзенага і іх параўнанне. Каб прадухіліць напады пры дапамозе прылад накшталт «вясёлкавых табліц», мы пры дапамозе солі дадаем у працэс выпадковасць (для паўнаты карціны прачытайце мой. аб крыптаграфічным захоўванні). У канчатковым выніку, пры правільнай рэалізацыі мы можам з вялікай дзеллю ўпэўненасці лічыць, што хэшаваныя паролі больш ніколі не стануць простым тэкстам (пра перавагі розных алгарытмаў хэшавання я распавяду ў іншым пасце).
Кароткі аргумент аб хэшавання і шыфраванні: адзіная прычына, па якой вам калі-небудзь спатрэбіцца зашыфраваць, а не хэшаваць пароль - гэта калі вам трэба ўбачыць пароль у простым тэксце, а вам гэтага ніколі не павінна хацецца, па меншай меры, у сітуацыі са стандартным вэб-сайтам. Калі вам гэта трэба, то, хутчэй за ўсё, вы робіце нешта не так!
Увага!
Крыху ніжэй у тэксце паста ёсць частка скрыншота парнаграфічнага вэб-сайта AlotPorn. Ён акуратна абрэзаны, і так няма нічога такога, чаго нельга ўбачыць на пляжы, але калі гэта ўсё роўна можа выклікаць нейкія праблемы, то не пракручвайце старонку ўніз.
Заўсёды скідайце пароль, ніколі яго не нагадвайце
Вас калі-небудзь прасілі стварыць функцыю напамінкі пароля? Зрабіце крок назад і падумайце аб гэтай просьбе ў зваротны бок: навошта трэба гэты «напамін»? Таму што карыстач забыўся пароль. Што мы на самой справе хочам зрабіць? Дапамагчы яму зноў увайсці ў сістэму.
Я разумею, слова «напамін» выкарыстоўваецца (часта) у размоўным сэнсе, але насамрэч мы спрабуем бяспечна дапамагчы карыстачу зноў быць анлайн. Так як нам патрэбна бяспека, ёсць дзве прычыны, па якіх напамін (г.зн. адпраўка карыстачу яго пароля) не падыходзіць:
- Электронная пошта - небяспечны канал. Гэтак жа, як мы не сталі б перадаваць нічога канфідэнцыйнага па HTTP (мы б выкарыстоўвалі HTTPS), не варта перадаваць нічога па электроннай пошце, таму што яе транспартны пласт небяспечны. Насамрэч, гэта нашмат горш, чым простая перадача інфармацыі па неабароненым транспартным пратаколе, таму што пошта часта захоўваецца на назапашвальніку, даступная сістэмным адміністратарам, перасылаецца і распаўсюджваецца, даступная шкоднаснаму ПА, і гэтак далей. Незашыфраваная пошта - надзвычай неабаронены канал.
- Вы ў любым выпадку не павінны мець доступ да пароля. Перачытайце папярэднюю частку аб захоўванні — у вас павінен быць хэш пароля (з добрай устойлівай соллю), гэта значыць вы ніякай выявай не павінны мець магчымасці выцягнуць пароль і адправіць яго па пошце.
Дазвольце мне прадэманстраваць праблему на прыкладзе : Вось тыповая старонка лагіна:
Відавочна, першая праблема складаецца ў тым, што старонка ўваходу ў сістэму не загружаецца па HTTPS, але сайт да таго ж яшчэ і прапануе адправіць пароль ("Send Password"). Магчыма, гэта прыклад згаданага вышэй гутарковага ўжывання дадзенага тэрміна, таму давайце зробім яшчэ адзін крок і паглядзім, што адбудзецца:
Выглядае ненашмат лепш, нажаль; і электронная пошта пацвярджае наяўнасць праблемы:
Гэта кажа нам пра два важныя аспекты 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! служыць двум мэтам; па-першае, яна ілюструе, наколькі лёгка можна ўзломваць (некаторыя) паштовыя акаўнты, па-другое, яна паказвае, як можна са злым намерам выкарыстоўваць дрэнныя сакрэтныя пытанні. Але мы вернемся да гэтага пазней.
Праблема са скідам пароляў са стоадсоткавай залежнасцю ад электроннай пошты складаецца ў тым, што цэласнасць уліковага запісу сайта, пароль якога вы спрабуеце скінуць, становіцца стоадсоткава залежным ад цэласнасці ўліковага запісу электроннай пошты. Любы, хто мае доступ да вашай электроннай пошце, мае доступ да любога акаўнта, які можна скінуць простым атрыманнем электроннага ліста. Для такіх акаўнтаў электронная пошта з'яўляецца "ключом ад усіх дзвярэй" вашага жыцця анлайн.
Адзін са спосабаў зніжэння гэтай рызыкі - рэалізацыя патэрна сакрэтнага пытання і адказу. Без сумневаў, вы ўжо бачылі іх: выбіраеце пытанне, на якое толькі вы павінны ведаць адказ, пасля чаго пры скідзе пароля вам яго задаюць. Гэта дадае ўпэўненасці ў тым, што чалавек, які спрабуе выканаць скід і на самой справе з'яўляецца ўладальнікам акаўнта.
Вернемся да Сары Пэйлін: памылка была ў тым, што адказы на яе сакрэтнае пытанне/пытанні лёгка можна было знайсці. У прыватнасці, калі ты такая значная грамадская фігура, інфармацыя пра дзявочае прозвішча маці, гісторыю навучання ці пра тое, дзе нехта мог жыць у мінулым, не такая ўжо і сакрэтная. Насамрэч, большая яе частка можа быць знойдзена практычна любым. Так і адбылося з Сарай:
Хакер Дэвід Кернэл атрымаў доступ да ўліковага запісу Пэйлін, знайшоўшы падрабязнасці яе біяграфіі, такія як яе ВНУ і дату нараджэння, а затым выкарыстаўшы функцыю аднаўлення забытых пароляў да ўліковых запісаў Yahoo!.
У першую чаргу гэта памылка праектавання са боку Yahoo! - указаўшы такія простыя пытанні, кампанія па сутнасці сабатавала каштоўнасць сакрэтнага пытання, а значыць, і абарону сваёй сістэмы. Зразумела, скід пароляў да ўліковага запісу электроннай пошты заўсёды складаней, бо вы не можаце пацвердзіць яе валоданне, даслаўшы ўладальніку электронны ліст (не маючы другога адраса), але, на шчасце, сёння для стварэння такой сістэмы не так ужо шмат спосабаў ужывання.
Вернемся да сакрэтных пытанняў - існуе варыянт падаць карыстачу магчымасць стварэння ўласных пытанняў. Праблема ў тым, што ў выніку будуць атрымлівацца жудасна відавочныя пытанні:
Якога колеру неба?
Пытанні, якія ставяць людзей у нязручнае становішча, калі для ідэнтыфікацыі сакрэтнае пытанне выкарыстоўвае чалавек (напрыклад, у кол-цэнтры):
З кім я пераспаў на Каляды?
Або адкрыта дурныя пытанні:
Як пішацца "пароль"?
Калі справа дакранаецца сакрэтных пытанняў, карыстачоў трэба выратаваць ад саміх сябе! Іншымі словамі, сакрэтнае пытанне павінна вызначаць сам сайт, а яшчэ лепш, задаваць серыю сакрэтных пытанняў, з якіх можа выбіраць карыстач. І не проста выбіраць 1; у ідэале карыстач павінен абраць два ці больш сакрэтных пытанняў у момант рэгістрацыі акаўнта, Якія затым будуць выкарыстоўвацца як другі канал ідэнтыфікацыі. Наяўнасць некалькіх пытанняў павялічвае ступень упэўненасці падчас праверак, а таксама дае магчымасць дадання выпадковасці (не заўсёды паказваць аднолькавае пытанне), плюс забяспечвае трохі надмернасці на выпадак, калі сапраўдны карыстач забыўся пароль.
Якім жа павінна быць добрае сакрэтнае пытанне? На гэта ўплывае некалькі фактараў:
- Ён павінен быць кароткім - пытанне павінна быць выразным і недвухсэнсоўным.
- Адказ павінен быць канкрэтным - нам не патрэбнае пытанне, на якое адзін чалавек можа адказаць па-рознаму
- Магчымыя адказы павінны быць разнастайнымі - пытанне аб чыімсьці каханым колеры дае вельмі малое падмноства магчымых адказаў
- Пошук адказу павінен быць складаным - калі адказ з лёгкасцю можа знайсці любы (успомнім аб людзях, якія займаюць высокае становішча), то ён дрэнны
- Адказ павінен быць пастаянным у часе - калі пытаць чый-небудзь каханы фільм, то праз год адказ можа быць іншым
Як гэта бывае, існуе вэб-сайт, прысвечаны добрым пытанням, які завецца . Частка пытанняў здаецца цалкам нядрэннай, іншыя не праходзяць частку апісаных вышэй тэстаў, асабліва праверку "прастаты пошуку".
Дазвольце мне прадэманстраваць, як сакрэтныя пытанні рэалізаваны ў PayPal і, у прыватнасці, якія намаганні сайт прыкладае для ідэнтыфікацыі. Вышэй мы бачылі старонку пачатку працэсу (з CAPTCHA), а тут мы пакажам, што адбываецца пасля таго, як вы ўводзіце адрас пошты і вырашаеце CAPTCHA:
У выніку карыстач атрымлівае такі ліст:
Пакуль усё цалкам звычайна, але вось што хаваецца за гэтым URL скіду:
Такім чынам, у справу ўступаюць сакрэтныя пытанні. Насамрэч, PayPal таксама дазваляе скінуць пароль, пацвердзіўшы нумар крэдытнай карты, таму існуе дадатковы канал, да якога не маюць доступу мноства сайтаў. Я проста не магу змяніць пароль, не адказаўшы на абодва сакрэтных пытання (ці не ведаючы нумар карты). Нават калі хтосьці захопіць маю электронную пошту, ён не зможа скінуць пароль уліковага запісу PayPal, калі не ведае пра мяне крыху больш асабістай інфармацыі. Які інфармацыі? Вось варыянты сакрэтных пытанняў, прапанаваныя PayPal:
Пытанне аб школе і бальніцы можа быць злёгку сумнеўным з пункту гледжання прастаты пошуку, але астатнія не так дрэнныя. Аднак для павышэння бяспекі PayPal патрабуе дадатковай ідэнтыфікацыі для змены адказаў на сакрэтныя пытанні:
PayPal – даволі ўтапічны прыклад бяспечнага скіду пароля: ён рэалізуе CAPTCHA для зніжэння небяспекі грубага перабору, патрабуе два сакрэтных пытання, а затым патрабуе яшчэ адзін выгляд зусім іншай ідэнтыфікацыі толькі для змены адказаў – і гэта пасля таго, як карыстач ужо выканаў уваход. Зразумела менавіта гэтага мы і чакалі б ад PayPal; гэта фінансавая арганізацыя, якая працуе з вялікімі сумамі грошай. Гэта не азначае, што кожны скід пароля павінен прытрымлівацца гэтых этапаў - у большасці выпадкаў гэта перабор - аднак гэта добры прыклад для выпадкаў, калі бяспека - сур'ёзны бізнэс.
Выгода сістэмы сакрэтных пытанняў у тым, што калі вы не рэалізавалі яе адразу, то яе можна дадаць пазней, калі гэтага патрабуе ўзровень абароны рэсурсу. Добрым прыкладам гэтага служыць Apple, толькі нядаўна рэалізавалая гэты механізм [артыкул напісаны ў 2012 годзе]. Пачаўшы аднойчы абнаўляць дадатак на iPad, я ўбачыў наступны запыт:
Затым я ўбачыў экран, на якім можна было абраць некалькі пар сакрэтных пытанняў і адказаў, а таксама выратавальны адрас электроннай пошты:
Што да PayPal, то пытанні абраныя загадзя і некаторыя з іх насамрэч даволі нядрэнныя:
Кожная з трох пар пытанняў і адказаў прадстаўляе асобнае мноства магчымых пытанняў, таму існуе дастатковая колькасць спосабаў канфігуравання ўліковага запісу.
Яшчэ адным аспектам, які трэба разгледзець адносна адказу на сакрэтнае пытанне, з'яўляецца захоўванне. Знаходжанне ў ДБ простага тэксту ўяўляе амаль тыя ж пагрозы, што і ў выпадку пароля, а менавіта - раскрыццё базы дадзеных імгненна раскрывае значэнне і падвяргае рызыцы не толькі прыкладанне, але і патэнцыйна зусім іншыя прыкладанні, якія выкарыстоўваюць тыя ж сакрэтныя пытанні (гэта зноў ). Адным з варыянтаў з'яўляецца бяспечнае хэшаванне (устойлівы алгарытм і крыптаграфічна выпадковая соль), аднак у адрозненне ад большасці выпадкаў захоўвання пароляў, тут можа быць уважлівая прычына бачнасці адказу як простага тэксту. Тыповым сцэнарам з'яўляецца праверка асобы жывым аператарам па тэлефоне. Зразумела, у гэтым выпадку хэшаванне таксама дастасавальна (аператар можа проста ўвесці названы кліентам адказ), але ў самым горшым выпадку сакрэтны адказ павінен знаходзіцца на якім-небудзь узроўні крыптаграфічнага сховішча, нават калі гэта проста сіметрычнае шыфраванне. Падвядзем вынік: звяртайцеся з сакрэтамі як з сакрэтамі!
І апошні аспект сакрэтных пытанняў і адказаў - яны больш уразлівыя для сацыяльнага інжынірынгу. Спрабаваць наўпрост выпытваць пароль да чужога акаўнта - гэта адна справа, а завязаць размову аб яго адукацыі (папулярнае сакрэтнае пытанне) - зусім іншае. Насамрэч, вы цалкам рэальна можаце мець зносіны з кімсьці пра шматлікія аспекты яго жыцця, якія могуць уяўляць сакрэтнае пытанне, і не выклікаць пры гэтым падазронаў. Зразумела, сама сутнасць сакрэтнага пытання ў тым, што ён звязаны з нечым жыццёвым вопытам, таму ён запамінаецца, і менавіта ў гэтым заключаецца праблема. людзі любяць расказваць пра свой жыццёвы вопыт! З гэтым мала што можна зрабіць, толькі калі выбраць такія варыянты сакрэтных пытанняў, каб іх з меншай верагоднасцю можна было б выцягнуць сацыяльным інжынірынгам.
[Працяг будзе.]На правах рэкламы
VDSina прапануе надзейныя , кожны сервер падлучаны да інтэрнэт-каналу ў 500 Мегабіт і бясплатна абаронены ад DDoS-нападаў!
Крыніца: habr.com