Наскоро имах време да помисля отново как трябва да работи функцията за нулиране на сигурна парола, за първи път, когато вграждах тази функционалност , а след това, когато е помогнал на друг човек да направи нещо подобно. Във втория случай исках да му дам връзка към каноничен ресурс с всички подробности за безопасното прилагане на функцията за нулиране. Проблемът обаче е, че такъв ресурс не съществува, поне не такъв, който да описва всичко, което ми се струва важно. Затова реших да го напиша сам.
Виждате ли, светът на забравените пароли всъщност е доста мистериозен. Има много различни, напълно приемливи гледни точки и много доста опасни. Вероятно сте срещали всеки от тях много пъти като краен потребител; така че ще се опитам да използвам тези примери, за да покажа кой го прави правилно, кой не и върху какво трябва да се съсредоточите, за да получите функцията точно във вашето приложение.
Съхранение на пароли: хеширане, криптиране и (ахване!) обикновен текст
Не можем да обсъдим какво да правим със забравените пароли, преди да обсъдим как да ги съхраняваме. Паролите се съхраняват в базата данни в един от трите основни типа:
- Прост текст. Има колона за парола, която се съхранява в обикновен текстов вид.
- Криптиран. Обикновено се използва симетрично криптиране (един ключ се използва както за криптиране, така и за декриптиране), а криптираните пароли също се съхраняват в една и съща колона.
- Хеширани. Еднопосочен процес (паролата може да бъде хеширана, но не може да бъде дехеширана); парола, Бих искал да се надявам, последвано от сол и всеки е в собствена колона.
Нека да преминем направо към най-простия въпрос: Никога не съхранявайте паролите в обикновен текст! Никога. Една единствена уязвимост към , едно невнимателно архивиране или една от десетки други прости грешки - и това е всичко, gameover, всичките ви пароли - това е, съжалявам, пароли на всички ваши клиенти ще стане обществено достояние. Разбира се, това би означавало голяма вероятност от всички техни акаунти в други системи. И вината ще бъде ваша.
Шифроването е по-добро, но има своите слабости. Проблемът с криптирането е декриптирането; можем да вземем тези налудничаво изглеждащи шифри и да ги конвертираме обратно в обикновен текст и когато това се случи, се връщаме към ситуацията с четимата от човека парола. как става това Малък пропуск попада в кода, който декриптира паролата, което я прави публично достъпна - това е един от начините. Хакерите получават достъп до машината, на която се съхраняват криптирани данни - това е вторият метод. Друг начин отново е да откраднете резервното копие на базата данни и някой също да получи ключа за шифроване, който често се съхранява много несигурно.
И това ни води до хеширане. Идеята зад хеширането е, че то е еднопосочно; единственият начин да сравните въведената от потребителя парола с нейната хеширана версия е да хеширате входа и да ги сравните. За да предотвратим атаки от инструменти като дъговите таблици, ние солим процеса с произволност (прочетете моя относно криптографското съхранение). В крайна сметка, ако бъдат внедрени правилно, можем да бъдем уверени, че хешираните пароли никога повече няма да станат обикновен текст (ще говоря за предимствата на различните хеширащи алгоритми в друга публикация).
Бърз аргумент за хеширане срещу криптиране: единствената причина, поради която някога трябва да шифровате, а не да хеширате парола, е когато трябва да видите паролата в обикновен текст и никога не трябва да искаш това, поне в стандартна ситуация на уебсайт. Ако имате нужда от това, най-вероятно правите нещо нередно!
Внимание!
По-долу в текста на поста има част от скрийншот на порнографския сайт AlotPorn. Грижливо е подрязан, така че няма нищо, което да не видите на плажа, но ако все още има вероятност да създаде проблеми, не превъртайте надолу.
Винаги нулирайте паролата си никога не му напомняй
Били ли сте някога помолен да създадете функция напомняния парола? Направете крачка назад и помислете за това искане в обратен ред: защо е необходимо това „напомняне“? Тъй като потребителят е забравил паролата. Какво всъщност искаме да правим? Помогнете му да влезе отново.
Осъзнавам, че думата „напомняне“ се използва (често) в разговорен смисъл, но това, което всъщност се опитваме да направим, е безопасно да помогне на потребителя да бъде отново онлайн. Тъй като се нуждаем от сигурност, има две причини, поради които напомнянето (т.е. изпращането на паролата на потребителя) не е подходящо:
- Имейлът е несигурен канал. Точно както не бихме изпратили нищо чувствително по HTTP (бихме използвали HTTPS), не трябва да изпращаме нищо чувствително по имейл, защото неговият транспортен слой е несигурен. Всъщност това е много по-лошо от простото изпращане на информация през несигурен транспортен протокол, тъй като пощата често се съхранява на устройство за съхранение, достъпна е за системните администратори, препраща се и се разпространява, достъпна е за зловреден софтуер и т.н. Некриптираният имейл е изключително несигурен канал.
- Така или иначе не трябва да имате достъп до паролата. Прочетете отново предишния раздел за съхранението - трябва да имате хеш на паролата (с добра силна сол), което означава, че не трябва да можете по никакъв начин да извлечете паролата и да я изпратите по пощата.
Нека демонстрирам проблема с пример : Ето типична страница за вход:
Очевидно първият проблем е, че страницата за вход не се зарежда през HTTPS, но сайтът също ви подканва да изпратите парола („Изпращане на парола“). Това може да е пример за разговорната употреба на термина, споменат по-горе, така че нека да направим крачка напред и да видим какво ще се случи:
За съжаление не изглежда много по-добре; и имейл потвърждава, че има проблем:
Това ни казва два важни аспекта на usoutdoor.com:
- Сайтът не хеширва пароли. В най-добрия случай те са криптирани, но е вероятно да се съхраняват в обикновен текст; Не виждаме доказателства за противното.
- Сайтът изпраща дългосрочна парола (можем да се върнем и да я използваме отново и отново) през незащитен канал.
Като премахнем това, трябва да проверим дали процесът на нулиране се извършва по сигурен начин. Първата стъпка, за да направите това, е да се уверите, че заявителят има право да извърши нулирането. С други думи, преди това се нуждаем от проверка на самоличността; нека да разгледаме какво се случва, когато самоличността е потвърдена, без първо да се потвърди, че заявеният е действително собственикът на акаунта.
Изброяване на потребителски имена и влиянието му върху анонимността
Този проблем най-добре се илюстрира визуално. проблем:
Виждаш ли? Обърнете внимание на съобщението „Няма регистриран потребител с този имейл адрес.“ Проблемът очевидно възниква, ако такъв сайт потвърди наличност потребител, регистриран с такъв имейл адрес. Бинго - току-що открихте порно фетиша на вашия съпруг/шеф/съсед!
Разбира се, порнографията е доста емблематичен пример за важността на неприкосновеността на личния живот, но опасностите от свързването на самоличност с конкретен уебсайт са много по-широки от потенциално неудобната ситуация, описана по-горе. Една опасност е социалното инженерство; Ако нападателят може да свърже човек с услугата, тогава той ще има информация, която може да започне да използва. Например, той може да се свърже с лице, което се представя за представител на уебсайт и да поиска допълнителна информация в опит да се ангажира .
Подобни практики също повишават опасността от „изброяване на потребителски имена“, при което човек може да провери съществуването на цяла колекция от потребителски имена или имейл адреси на уебсайт, като просто извърши групови запитвания и прегледа отговорите към тях. Имате ли списък с имейл адреси на всички служители и няколко минути, за да напишете сценарий? Тогава виждате какъв е проблемът!
Каква е алтернативата? Всъщност е доста просто и е чудесно внедрено в :
Тук Entropay не разкрива абсолютно нищо за съществуването на имейл адрес в своята система на някой, който не притежава този адрес... Ако ти собствен този адрес и той не съществува в системата, тогава ще получите имейл като този:
Разбира се, може да има приемливи ситуации, в които някой мисличе сте се регистрирали на уебсайта. но това не е така или го направих от различен имейл адрес. Примерът, показан по-горе, се справя добре и с двете ситуации. Очевидно, ако адресът съвпада, ще получите имейл, което ще улесни повторното задаване на паролата ви.
Тънкостта на избраното от Entropay решение е, че проверката на идентификацията се извършва съгласно електронна поща преди всяка онлайн проверка. Някои сайтове искат от потребителите отговор на защитен въпрос (повече за това по-долу) до как може да започне нулирането; проблемът с това обаче е, че трябва да отговорите на въпроса, докато предоставяте някаква форма на идентификация (имейл или потребителско име), което след това прави почти невъзможно да се отговори интуитивно, без да се разкрие съществуването на акаунта на анонимния потребител.
С този подход има малък намалена използваемост, защото ако се опитате да нулирате несъществуващ акаунт, няма незабавна обратна връзка. Разбира се, това е целият смисъл на изпращането на имейл, но от реална гледна точка на крайния потребител, ако въведе грешен адрес, той ще разбере едва за първи път, когато получи имейла. Това може да предизвика известно напрежение от негова страна, но това е малка цена за такъв рядък процес.
Друга бележка, малко извън темата: функциите за помощ при влизане, които разкриват дали потребителското име или имейл адресът е правилен, имат същия проблем. Винаги отговаряйте на потребителя със съобщение „Комбинацията от потребителско име и парола е невалидна“, вместо изрично да потвърждавате съществуването на идентификационните данни (например „потребителското име е правилно, но паролата е неправилна“).
Изпращане на парола за нулиране срещу изпращане на URL за нулиране
Следващата концепция, която трябва да обсъдим, е как да нулирате паролата си. Има две популярни решения:
- Генериране на нова парола на сървъра и изпращане по имейл
- Изпратете имейл с уникален URL адрес, за да улесните процеса на нулиране
Въпреки , първата точка никога не трябва да се използва. Проблемът с това е, че означава, че има съхранена парола, към който можете да се върнете и да използвате отново по всяко време; изпратено е по незащитен канал и остава във входящата ви кутия. Вероятно входящите кутии се синхронизират между мобилни устройства и имейл клиента, освен това могат да се съхраняват онлайн в уеб услугата за електронна поща за много дълго време. Въпросът е в това пощенската кутия не може да се счита за надеждно средство за дългосрочно съхранение.
Но освен това, първата точка има и друг сериозен проблем - тя опростява максимално блокиране на акаунт със злонамерени намерения. Ако знам имейл адреса на някой, който притежава акаунт в уебсайт, мога да го блокирам по всяко време, като просто нулирам паролата му; Това е атака за отказ на услуга, поднесена на сребърен поднос! Ето защо нулирането трябва да се извършва само след успешна проверка на правата на заявителя върху него.
Когато говорим за URL адрес за нулиране, имаме предвид адреса на уебсайт, който е уникален за този конкретен случай на процеса на нулиране. Разбира се, трябва да е произволно, да не е лесно за отгатване и не трябва да съдържа никакви външни връзки към акаунта, които улесняват нулирането. Например URL адресът за нулиране не трябва да бъде просто път като „Нулиране/?username=JohnSmith“.
Искаме да създадем уникален токен, който може да бъде изпратен по пощата като URL адрес за нулиране и след това да бъде съпоставен със записа на сървъра на акаунта на потребителя, като по този начин потвърдим, че собственикът на акаунта всъщност е същото лице, което се опитва да нулира паролата. Например токенът може да бъде „3ce7854015cd38c862cb9e14a1ae552b“ и да се съхранява в таблица заедно с ИД на потребителя, извършващ нулирането, и времето, когато токенът е генериран (повече за това по-долу). Когато имейлът е изпратен, той съдържа 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! служи за две цели; първо, илюстрира колко лесно е да се хакнат (някои) имейл акаунти, и второ, показва колко лоши въпроси за сигурност могат да бъдат използвани със злонамерени намерения. Но ще се върнем към това по-късно.
Проблемът със XNUMX% нулиране на парола, базирано на имейл, е, че целостта на акаунта за сайта, който се опитвате да нулирате, става XNUMX% зависима от целостта на имейл акаунта. Всеки, който има достъп до вашия имейл има достъп до всеки акаунт, който може да бъде нулиран чрез просто получаване на имейл. За такива акаунти имейлът е „ключът към всички врати“ на вашия онлайн живот.
Един от начините за намаляване на този риск е прилагането на модел на защитен въпрос и отговор. Без съмнение вече сте ги гледали: изберете въпрос, на който само вие можете да отговорите имам знаете отговора и след това, когато нулирате паролата си, ще бъдете попитани за нея. Това добавя увереност, че лицето, което се опитва да нулира, наистина е собственикът на акаунта.
Обратно към Сара Пейлин: грешката беше, че отговорите на нейния защитен въпрос/въпроси можеха лесно да бъдат намерени. Особено когато сте толкова значима обществена фигура, информацията за моминското име на майка ви, образователната история или къде някой може да е живял в миналото не е чак толкова тайна. Всъщност повечето от тях могат да бъдат намерени от почти всеки. Ето какво се случи със Сара:
Хакерът Дейвид Кернел получи достъп до акаунта на Пейлин, като намери подробности за нейното минало, като нейния университет и дата на раждане, и след това използва функцията за възстановяване на забравена парола на Yahoo!.
На първо място, това е грешка в дизайна от страна на Yahoo! — като задава такива прости въпроси, компанията по същество саботира стойността на въпроса за сигурност и следователно защитата на своята система. Разбира се, повторното задаване на пароли за имейл акаунт винаги е по-трудно, тъй като не можете да докажете собственост, като изпратите имейл до собственика (без да имате втори адрес), но за щастие днес няма много приложения за създаване на такава система.
Да се върнем към въпросите за сигурност - има опция да позволите на потребителя да създаде свои собствени въпроси. Проблемът е, че това ще доведе до ужасно очевидни въпроси:
Какъв цвят е небето?
Въпроси, които карат хората да се чувстват неудобно, когато се използва защитен въпрос за идентифициране хора (например в кол център):
С кого спах на Коледа?
Или откровено глупави въпроси:
Как се пише "парола"?
Що се отнася до въпросите за сигурността, потребителите трябва да бъдат спасени от себе си! С други думи, защитният въпрос трябва да се определя от самия сайт или още по-добре да се задава серия въпроси за сигурност, от които потребителят може да избира. И не е лесно да се избере един; в идеалния случай потребителят трябва да избере два или повече въпроса за сигурност в момента на регистрация на акаунта, който след това ще се използва като втори канал за идентификация. Наличието на множество въпроси повишава доверието в процеса на проверка и също така предоставя възможност за добавяне на произволност (невинаги показва един и същ въпрос), плюс осигурява малко излишък, в случай че действителният потребител е забравил паролата.
Какво е добър защитен въпрос? Това се влияе от няколко фактора:
- Той трябва да бъде кратко — въпросът трябва да е ясен и недвусмислен.
- Отговорът трябва да бъде специфичен — не се нуждаем от въпрос, на който един човек може да отговори различно
- Възможните отговори трябва да бъдат разнообразни - питането за нечий любим цвят дава много малка част от възможните отговори
- Търсене отговорът трябва да е сложен - ако отговорът може лесно да се намери който и да е (спомнете си хора на високи позиции), тогава той е лош
- Отговорът трябва да бъде постоянен във времето - ако попитате любимия филм на някого, след година отговорът може да е различен
Както се случва, има уебсайт, посветен на задаването на добри въпроси, наречен . Някои от въпросите изглеждат доста добри, други не преминават някои от описаните по-горе тестове, особено теста за „лекота на търсене“.
Позволете ми да демонстрирам как PayPal прилага въпроси за сигурност и по-специално усилията, които сайтът полага за удостоверяване. По-горе видяхме страницата за стартиране на процеса (с CAPTCHA), а тук ще покажем какво се случва, след като въведете своя имейл адрес и разрешите CAPTCHA:
В резултат на това потребителят получава следното писмо:
Засега всичко е съвсем нормално, но ето какво се крие зад този URL за нулиране:
И така, въпросите за сигурността влизат в действие. Всъщност PayPal също ви позволява да нулирате паролата си, като потвърдите номера на кредитната си карта, така че има допълнителен канал, до който много сайтове нямат достъп. Просто не мога да сменя паролата си, без да отговоря и двете защитен въпрос (или непознаване на номера на картата). Дори ако някой отвлече имейла ми, той няма да може да нулира паролата на акаунта ми в PayPal, освен ако не знае малко повече лична информация за мен. Каква информация? Ето опциите за защитен въпрос, които PayPal предлага:
Въпросът за училището и болницата може да е малко съмнителен по отношение на лекотата на търсене, но другите не са толкова лоши. Въпреки това, за да подобри сигурността, PayPal изисква допълнителна идентификация за промени отговори на въпроси за сигурност:
PayPal е доста утопичен пример за нулиране на сигурна парола: той прилага CAPTCHA, за да намали опасността от атаки с груба сила, изисква два въпроса за сигурност и след това изисква друг вид напълно различна идентификация, само за да промени отговорите - и това след като потребителят вече влезе. Разбира се, това е точно това, което ние очакван от PayPal; е финансова институция, която работи с големи суми пари. Това не означава, че всяко нулиране на парола трябва да следва тези стъпки – през повечето време е излишно – но е добър пример за случаите, когато сигурността е сериозна работа.
Удобството на системата за въпроси за сигурност е, че ако не сте я внедрили веднага, можете да я добавите по-късно, ако нивото на защита на ресурса го изисква. Добър пример за това е Apple, която едва наскоро внедри този механизъм [статия, написана през 2012 г.]. След като започнах да актуализирам приложението на моя iPad, видях следната заявка:
След това видях екран, където можех да избера няколко двойки защитни въпроси и отговори, както и спасителен имейл адрес:
Що се отнася до PayPal, въпросите са предварително избрани и някои от тях всъщност са доста добри:
Всяка от трите двойки въпрос/отговор представлява различен набор от възможни въпроси, така че има много начини за конфигуриране на акаунт.
Друг аспект, който трябва да имате предвид по отношение на отговора на вашия защитен въпрос, е съхранението. Наличието на база данни с обикновен текст в базата данни крие почти същите заплахи като паролата, а именно, че разкриването на базата данни незабавно разкрива стойността и излага на риск не само приложението, но и потенциално напълно различни приложения, използващи същите въпроси за сигурност (отново ). Една опция е сигурно хеширане (силен алгоритъм и криптографски произволна сол), но за разлика от повечето случаи на съхранение на пароли, може да има добра причина отговорът да се вижда като обикновен текст. Типичен сценарий е проверка на самоличността от телефонен оператор на живо. Разбира се, хеширането също е приложимо в този случай (операторът може просто да въведе отговора, посочен от клиента), но в най-лошия случай тайният отговор трябва да се намира на някакво ниво на криптографско съхранение, дори ако е просто симетрично криптиране . Обобщете: третирай тайните като тайни!
Един последен аспект на въпросите и отговорите за сигурност е, че те са по-уязвими за социално инженерство. Опитът за директно извличане на паролата към акаунта на някой друг е едно, но започването на разговор за нейното формиране (популярен въпрос за сигурност) е съвсем различно. Всъщност можете много добре да общувате с някого относно много аспекти от живота му, които може да поставят таен въпрос, без да събуждате подозрение. Разбира се, самият смисъл на въпроса за сигурност е, че той е свързан с нечий житейски опит, така че е запомнящ се и точно там е проблемът - хората обичат да говорят за своя житейски опит! Малко можете да направите по въпроса, само ако изберете такива опции за сигурност, така че да са по-малко вероятно може да бъде изваден чрез социално инженерство.
[Следва продължение.]Относно правата на рекламата
VDSina предлага надеждни , всеки сървър е свързан към интернет канал от 500 мегабита и е защитен от DDoS атаки безплатно!
Източник: www.habr.com