Наскоро намерих време отново да се замисля как трябва да работи функцията за безопасно нулиране на парола, първо когато я интегрирах в , а след това когато помагах на друг човек да направи нещо подобно. Във втория случай исках да му дам линк към каноничен ресурс с всички подробности за безопасната реализация на функцията за нулиране. Проблемът е, че такъв ресурс не съществува, поне не такъв, който описва всичко, което ми се струва важно. Затова реших да го напиша сам.
Виждате ли, светът на забравените пароли всъщност е доста загадъчен. Има множество различни, напълно приемливи гледни точки и много доста опасни. Вероятно сте се сблъсквали с всяка от тях многократно като крайни потребители; затова ще се опитам да използвам тези примери, за да покажа кой прави всичко правилно, а кой не, и какво трябва да се фокусира при правилната реализация на функцията в собственото си приложение.
Съхранение на пароли: хеширане, криптиране и (ох!) прост текст
Не можем да обсъждаме какво да правим със забравените пароли, преди да обсъдим начина, по който те се съхраняват. В базата данни паролите се съхраняват в един от трите основни вида:
- Обикновен текст. Има колона с паролата, която се съхранява в обикновен текстов вид.
- Криптирана. Obикновено с помощта на симетрично криптиране (един ключ се използва и за криптиране, и за декриптиране), а криптираните пароли също се съхраняват в една колона.
- Хеширана. Одностранен процес (паролата може да бъде хеширана, но не може да бъде декодирана); паролата, надявам се, се съпровожда от сол, и всяка от тях се намира в собствена колона.
Нека веднага да разгледаме най-простия въпрос: никога не съхранявайте пароли в обикновен текст! Никога. Една единствена уязвимост на , едно неопитно направено резервно копие или една от десетките други прости грешки — и всичко, гейм оувър, всички ваши пароли — тоест, извинете, паролите на всичките ви клиенти ще станат обществено достояние. Разбира се, това ще означава огромна вероятност, че обществено достояние ще станат от всичките им акаунти в други системи. И това ще бъде ваша вина.
Шифрирането е по-добро, но има своите слабости. Проблемът с шифрирането е в дешифрирането; можете да вземете тези безумно изглеждащи шифри и да ги преобразувате обратно в обикновен текст, и когато това се случи, ще се върнем към ситуация с четими пароли. Как става това? Малка уязвимост прониква в кода, отговарящ за дешифрирането на паролата, правейки я публично достъпна — това е един от начините. Хакерите получават достъп до машината, на която се съхраняват шифрованите данни — това е вторият начин. Още един начин отново е, че се краде резервно копие на базата данни, и някой също така получава ключа за шифриране, който често се съхранява много ненадеждно.
И това ни води до хеширането. Идеята на хеширането е, че то се извършва в една посока; единственият начин да сравните въведената от потребителя парола с нейната хеширана версия е да хеширате въведеното и да ги сравните. За да предотвратим атаки с инструменти като "радужни таблици", добавяме случайност в процеса с помощта на сол (за цялостност прочетете моя за криптографското съхранение). В крайна сметка, при правилна реализация можем с голяма степен на сигурност да считаме, че хешираните пароли никога повече няма да станат обикновен текст (за предимствата на различните хеширащи алгоритми ще говоря в друг пост).
Кратък аргумент за хеширането и шифрирането: единствената причина, поради която някога трябва да шифрирате, а не да хеширате паролата, е когато трябва да видите паролата в обикновен текст, а вие никога не трябва да искате това, поне в ситуация със стандартен уебсайт. Ако това ви е нужно, вероятно правите нещо нередно!
Внимание!
Няколко реда по-долу в текста на публикацията има част от скрийншота на порно уебсайта AlotPorn. Той е внимателно отрязан, и така няма нищо такова, което не може да се види на плажа, но ако все пак това може да предизвика проблеми, не превъртайте надолу.
Винаги нулирайте паролата, никога не я напомняйте
Някога искали ли са ви да създадете функция за напомняне Забравте паролата? Помислете за тази молба от противоположната страна: защо ви е нужно това „напомняне“? Защото потребителят е забравил паролата. Какво наистина искаме да направим? Да му помогнем да влезе отново в системата.
Разбирам, че думата „напомняне“ се използва (често) в разговорен смисъл, но всъщност ние се опитваме да помогнем на потребителя безопасно да се свърже отново онлайн.Тъй като ни трябва сигурност, има две причини, поради които напомнянето (т.е. изпращането на паролата на потребителя) не е подходящо:
- Електронната поща е несигурен канал. Както не бихме предавали нищо конфиденциално по HTTP (бихме използвали HTTPS), не е редно да предаваме нищо по електронна поща, защото нейният транспортен слой не е защитен. Всъщност, това е много по-лошо от простото предаване на информация по незащитен транспортен протокол, защото имейлите често се съхраняват на устройства, достъпни за системни администратори, пренасочват се и разпространяват, достъпни са за злонамерен софтуер и т.н. Незашифрованата поща е изключително несигурен канал.
- Вие по никакъв начин не трябва да имате достъп до паролата. Прочетете предишния раздел за съхранение — трябва да имате хеш на паролата (с добра чуплива сол), тоест не трябва по никакъв начин да можете да извлечете паролата и да я изпратите по имейл.
Позволете ми да илюстрирам проблема чрез примера : Ето типичната страница за вход:
Очевидно, първият проблем е, че страницата за вход не се зарежда по HTTPS, но сайтът също предлага да изпрати паролата („Изпрати парола“). Може би това е пример за споменатото по-горе разговорно употребление на термина, така че нека направим още една крачка и видим какво ще стане:
Не изглежда много по-добре, за съжаление; а електронната поща потвърдена наличието на проблема:
Това ни казва две важни аспекта на usoutdoor.com:
- Сайтът не хешира пароли. В най-добрия случай, те са криптирани, но е напълно вероятно, че са съхранявани в текстов вид; доказателства в обратна посока не виждаме.
- Сайтът изпраща дългосрочна парола (можем да се върнем и да я използваме отново и отново) по несигурен канал.
След като разгледахме това, трябва да проверим дали процедурата по нулиране се извършва безопасно. Първото нещо, което трябва да направим, е да се уверим, че лицето, което иска нулирането, има право да го извърши. С други думи, нужен ни е проверка на идентичността; нека да видим какво се случва, когато идентичността бъде потвърдена без предварителна проверка дали искателят наистина е собственик на акаунта.
Изброяване на потребителски имена и влиянието им върху анонимността
Тази проблема най-добре илюстрираме визуално. Проблем:
Видяхте ли? Обърнете внимание на съобщението „There is no user registered with this email address“ („Няма регистриран потребител с този имейл адрес“). Проблемът очевидно възниква, ако подобен сайт потвърди наличие регистрирания с този имейл адрес потребител. Бинго — току-що открихте порно-фетиша на вашия съпруг/шеф/съсед!
Разбира се, порното е доста каноничен пример за важността на конфиденциалността, но опасността от свързване на идентичността с определен уебсайт е много по-широка от описаната по-горе потенциално неловка ситуация. Една от опасностите е социалното инженерство; ако нападателят успее да свърже човек със сервиза, той ще получи информация, която може да започне да използва. Например, той може да се свърже с човека, представяйки се за представител на сайта, и да поиска допълнителна информация, опитвайки се да извърши .
Подобни практики също водят до възникване на опасността „изброяване на потребителски имена“, при която може да се провери съществуването на колекция от потребителски имена или имейл адреси на сайта чрез прости групови запитвания и изучаване на отговорите им. Имате списък с имейл адреси на всички служители и няколко минути за написване на скрипт? Тогава виждате какъв е проблемът!
Каква е алтернативата? Наистина е доста проста и е отлично реализирана на :
Тук Entropay не разкрива абсолютно нищо за съществуването на имейл адреса в системата си на никого, който не притежава този адрес. Ако вие притежавате ако този адрес не съществува в системата, ще получите подобно електронно писмо:
Разбира се, приемливи ситуации, в които някой мисли, че е регистриран на уебсайта, но не е, или го е направил с друг имейл адрес. Примерът по-горе успешно покрива и двете ситуации. Очевидно, ако адресът съвпада, ще получите имейл, улесняващ нулирането на паролата.
Финесът на избраното решение Entropay е в това, че идентификацията се извършва по електронна поща преди всяка онлайн проверка. Някои сайтове питат потребителите за отговор на секретен въпрос (повече за това по-долу) до преди да започне процесът на нулиране; обаче, проблемът е, че трябва да отговорите на въпрос, предоставяйки някаква форма на идентификация (имейл или потребителско име), което прави почти невъзможно интуитивното отговорене, без да разкривате съществуването на акаунта на анонимен потребител.
При такъв подход има малко намаление на удобството, тъй като в случай на опит за нулиране на несъществуващ акаунт няма незабавен отговор. Разбира се, в това е целият смисъл на изпращането на електронно писмо, но от гледна точка на действителния крайния потребител, ако той въведе неправилен адрес, ще узнае за това едва когато получи писмото. Такова нещо може да предизвика известна тревога от негова страна, но е малка цена за толкова рядък процес.
Още едно бележка, малко отклоняваща се от темата: функциите за помощ при влизане в системата, които разкриват правилността на потребителското име или имейл адреса, имат същия проблем. Винаги отговаряйте на потребителя с послание „Неправилна комбинация от име на потребител и парола“ (Your username and password combination is invalid), а не потвърждавайте явно съществуването на идентификационна информация (например, „потребителското име е вярно, но паролата е грешна“).
Изпращане на парола за нулиране срещу изпращане на 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! — като зададе толкова лесни въпроси, компанията по същество саботира стойността на секретния въпрос и следователно защитата на своята система. Разбира се, нулирането на пароли за акаунта на електронна поща винаги е по-трудно, защото не можете да потвърдите собствеността му, изпращайки имейл на собственика (няма да имате втори адрес), но за щастие, днес не съществуват много начин за създаване на такава система.
Да се върнем на секретните въпроси — съществува вариант да предоставите на потребителя възможност да създава собствени въпроси. Проблемът е в това, че в резултат ще получим ужасно очевидни въпроси:
Какъв е цветът на небето?
Въпросите, които поставят хората в неудобна ситуация, когато за идентификацията секретният въпрос използва човек (например, в кол център):
С кого спах на Коледа?
Или откровено глупави въпроси:
Как се пише "паралел"?
Когато става въпрос за секретни въпроси, потребителите трябва да бъдат спасени от самите себе си! С други думи, секретният въпрос трябва да бъде определен от самия сайт, а още по-добре, да задава серия секретни въпроси, от които потребителят да може да избира. И не просто да избира един; в идеалния случай потребителят трябва да избере два или повече секретни въпроса в момента на регистрация на акаунта, които впоследствие ще се използват като вторичен канал за удостоверяване. Наличието на няколко въпроса увеличава степента на сигурност в процеса на проверка, а също така дава възможност за добавяне на случайност (да не се задава винаги един и същ въпрос), плюс осигурява известна излишност в случай, че действителният потребител е забравил паролата си.
Какъв трябва да бъде добрият секретен въпрос? Това зависи от няколко фактора:
- Той трябва да бъде кратък — въпросът трябва да бъде ясен и недвусмислен.
- Отговорът трябва да бъде конкретен — не ни трябва въпрос, на който един човек може да отговори по различни начини.
- Възможните отговори трябва да бъдат разнообразни — въпрос за нечий любим цвят дава много малка подмножество от възможни отговори.
- Търсене отговорът трябва да бъде сложен — ако отговорът може лесно да бъде намерен всеки (да си спомним за хора, заемащи висока позиция), то той е лош
- Отговорът трябва да бъде постоянен в течение на времето — ако питате за нечий любим филм, то след година отговорът може да бъде различен.
Както се случва, съществува уебсайт, посветен на добри въпроси, наречен . Част от въпросите изглеждат напълно приемливи, други не преминават част от описаните по-горе тестове, особено проверката за "лесно търсене".
Позволете ми да демонстрирам как секретните въпроси се реализират в PayPal и по-специално какви усилия сайтът полага за удостоверяване. По-горе видяхме страницата, на която започва процесът (с CAPTCHA), а тук ще покажем какво се случва след като въведете имейл адреса си и решите CAPTCHA:
В резултат на това потребителят получава такова писмо:
Досега всичко е съвсем нормално, но ето какво се крие зад този URL за нулиране:
И така, в действието влизат секретните въпроси. Всъщност, PayPal също позволява нулиране на паролата, потвърдявайки номер на кредитна карта, така че съществува допълнителен канал, до който не много сайтове имат достъп. Просто не мога да променя паролата, без да отговоря на и двете секретни въпроси (или да не знам номера на картата). Дори ако някой завладее моя имейл, той не може да нулира паролата на PayPal акаунта, освен ако не знае малко повече лична информация за мен. Каква информация? Ето вариантите на секретни въпроси, предлагани от PayPal:
Въпросът за училището и болницата може да изглежда малко съмнителен по отношение на простотата на търсене, но останалите не са толкова лоши. Все пак, за повишаване на сигурността, PayPal изисква допълнителна идентификация за промени отговори на секретни въпроси:
PayPal е доста утопичен пример за безопасно възстановяване на парола: той реализира CAPTCHA за намаляване на риска от груба атака, изисква два секретни въпроса и след това иска още един вид напълно различна идентификация само за промяна на отговорите — и то след като потребителят вече е влязъл. Разбира се, именно това очаквахме от PayPal; това е финансова организация, която работи с големи суми пари. Това не означава, че всяко възстановяване на парола трябва да следва тези стъпки — в повечето случаи е прекалено сложно — обаче това е добър пример за случаи, когато сигурността е сериозен бизнес. Удобството на системата със секретни въпроси е, че ако не сте я реализирали веднага, можете да я добавите по-късно, ако това изисква нивото на защита на ресурса. Добър пример за това е Apple, която наскоро реализира този механизъм
[статията е написана през 2012 година] . Веднъж, докато актуализирах приложение на iPad, видях следната молба:След това видях екран, на който можех да избера няколко двойки секретни въпроси и отговори, както и спасяваща електронна поща:
Що се отнася до PayPal, въпросите са предварително избрани и някои от тях са всъщност доста добри:
Всяка от трите двойки въпроси и отговори представлява различен набор от възможни въпроси, така че съществува достатъчно количество начини за конфигуриране на акаунта.
Още един аспект, който трябва да се разгледа относно отговора на секретния въпрос, е съхранението. Намирането в базата данни на чист текст представлява почти същите заплахи, както случай с парола, а именно — разкритие на базата данни незабавно разкрива стойността и поставя в риск не само приложението, но и потенциално напълно различни приложения, които използват същите секретни въпроси (отново
въпросът е за ягоди асаи. ). Един от вариантите е безопасно хеширане (устойчив алгоритъм и криптографски случаен сол), но за разлика от повечето случаи на съхранение на пароли, тук може да има уважителна причина за видимостта на отговора като прост текст. Типичен сценарий е проверката на самоличността от жив оператор по телефона. Разбира се, в такъв случай хеширането също е приложимо (операторът може просто да въведе назования от клиента отговор), но в най-лошия случай секретният отговор трябва да се намира на някое ниво на криптографско хранилище, дори и да е просто симетрично шифриране. Нека обобщим: отнасяйте се със секретите като със секрети!
И последният аспект на секретните въпроси и отговори — те са по-уязвими на социален инжинеринг. Да се опитваш да извадиш паролата на чужд акаунт е едно, а да започнеш разговор за образованието му (популярен секретен въпрос) е съвсем друго. Всъщност, напълно е реалистично да комуникирате с някого за много аспекти от живота му, които могат да представляват секретен въпрос, без да предизвиквате подозрения. Разбира се, самата същност на секретния въпрос е, че той е свързан с житейския опит на някого, така че той се запомня, и именно в това се състои проблемът — хората обичат да разказват за своя житейски опит! С това малко може да се направи, освен ако не изберете такива варианти на секретни въпроси, че да ги с по-малка вероятност да бъдат извлечени чрез социален инжинеринг.
[Продължението следва.]
Реклама
VDSina предлага надеждни , всеки сървър е свързан с интернет канал от 500 мегабита и е безплатно защитен от DDoS атаки!
Източник: habr.com
