() translation by (you can also view the original English article)
На переважній більшості сайтів ви зустрічаєте різні сторінки (домашню, профіль користувача, сторінку адміністратора тощо), де одні з них є публічними, а до інших мають доступ тільки окремі користувачі. Часто вам хотілося б точно визначати відвідувачів сайту для надання персоніфікованого контенту і щоб отримувати специфічну інформацію від користувача. Багато сайтів також потребують захисту певної частини свого контенту, наприклад, адміністративну інформацію, щоб зберігати і оновлювати наповнення сайту. В CMS сайтах деякі користувачі можуть створювати контент, проте на інших спочатку необхідно пройти перевірку і отримати дозвіл на публічну публікацію.
Захист імені і паролю користувача
Якою б не була потреба, обмеження або кастомізація потребують ідентифікації кожного користувача, який заходить на сайт. Для Інтернет-сайтів для загальних користувачів ім'я і пароль користувача є найбільш вживаними, оскільки немає кращої опції. Є деякі інші опції, якщо ви працюєте в спеціальному середовищі, такі як Intranet для компаній, де у вас є певний контроль над відвідувачами сайту.
Хоча це залишається спільною потребою, логінами і паролями часто управляють так, що вони залишаються вразливими до атак в питанні безпеки. Слідуючи деяким рекомендаціям, ви можете краще захистити ваш сайт від атак з боку хакерів. Наслідки від слабкого захисту можуть бути серйозними. Уявіть собі сайт, на якому будь-хто міг би розміщувати контент від імені компанії (завдяки слабкому управлінню захистом паролю), або інтернет-магазин, де будь-який користувач міг би переглядати всі замовлення, які на ньому розміщуються.
Давайте розглянемо деякі пропозиції щодо безпеки логінів і паролів на ваших сайтах.
Імена користувачів: Email чи специфічне ім'я
Логін складається з імені користувача, яке вас ідентифікує, і паролю, що підтверджує що ви саме той користувач. Часто веб-сайти пропонують відвідувачам використовувати специфічне ім'я користувача, або ж використовувати в його якості свій email.
Переваги
Адреси електронної пошти змінюються не часто і більшість сайтів уже мають цю інформацію, а також і користувач менш здатний забути свій email, ніж ім'я користувача, яке він створив.
Недоліки
З іншого боку, люди, які діляться email, не можуть мати окремі акаунти. Крім того, якщо сайт має легітимний дозвіл на те, щоб одна особа мала декілька акаунтів, - це буде неможливим з email, а тільки з іменами користувачів. Також email легше зламати, оскільки зазвичай користувачі користуються тим самим email на кожному сайті, проте більшість імен користувачів зламати не так просто, оскільки користувачі схильні повторно використовувати ім'я користувача не більше, ніж користуватись одним і тим же паролем.
Якщо у вас немає специфічних причин, щоб уникати email, використовуйте останній в якості імені користувача. Використання електронної пошти на сайтах стало нормою. Все ж не забудьте, що ви можете надавати логін на основі email, як спосіб змінити останній. Без цієї функції користувачу доведеться створювати новий акаунт і він втратить всю минулу історію просто тому, що змінився Інтернет-провайдер або загубився попередній акаунт із-за закінчення вузу чи зміни роботи, чому, власне, старий акаунт вже не потрібний.
Завжди будьте обережними, коли використовуєте email в якості логіну: він не повинен бути всім видимим і публічним, щоб уникнути спам, а також заради безпеки.
Логіни можуть надавати надто багато інформації
Сторінка входу на вашому сайті буде пунктом номер один для хакера. Хакер робитиме спробу визначити, які акаунти на сайті є дійсними. Якщо управління сторінкою входу здійснюється як належно, робота хакера ускладниться. Для початку, ви повинні мінімізувати об'єм введеної інформації (хакером), яка виявиться неправильною. Перше, що потрібно зробити, коли хтось вводить ім'я користувача, яке не можна ідентифікувати, це вивести допоміжне повідомлення з проханням перевірити ім'я користувача. Ви можете надати більш захищену сторінку, показавши те ж повідомлення, якщо користувача не знайдено і пароль не відповідає паролю для цього користувача. Повідомлення повинно вказати, що комбінація імені користувача та паролю була невірною, щоб користувач зрозумів, чи потрібно йому підтвердити обидва пункти інформації, чи тільки щось одне.
Якщо ваш сайт використовує email в якості імені користувача, зловмисник може легко визначити, чи має користувач акаунт на вашому сервісі в тому разі, якщо ви надаєте різні повідомлення для невідомого логіну. Якщо ви повідомлюєте тільки про невірну комбінацію імені користувача і паролю, це дещо ускладнить життя для користувача, проте так краще з точки зору безпеки.
Як зазначалося, відсутність спеціальних повідомлень щодо невірного імені користувача підвищує безпеку і зменшує UX. Повідомлення про те, що логін не існує, допоможе користувачу швидше помітити опечатки на зразок: john замість jon. Таке повідомлення також допомагає користувачу, якщо він не пам'ятає, яке ім'я користувача використовував на вашому сайті. Проте майте на увазі, що такі типи повідомлень - це легкий і простий спосіб для хакерів дізнатися, чи існує такий користувач на вашому сайті.
Ви також можете зірвати хакерські плани шляхом управляння кількістю спроб вводити логін. Опечатка в імені користувача або паролі більш, ніж один раз, зустрічається досить частіше, ніж невірний символ, їх перестановка, або використання замість вірного, паролю з іншого сайту. Можливість вводити логін необмежену кількість разів відкриває двері для жорстких атак, аж поки не будуть виявлені вірні ім'я користувача і пароль. Автоматизовані інструменти і скрипти прискорюють цей процес, дозволяючи хакеру методично працювати з багатьма потенційними паролями, поки не буде знайдено вірний логін.
Запровадження і збільшення часового інтервалу після кожного невірного логіну також допомагає завадити хакерам. Перша помилка в логіні сприймається нормально. Друга спроба ввести логін затримується на долі секунди. Подальші спроби затримуються значно довше, поки буде отримана відповідь сайту. Така затримка буде мінімально турбувати легітимного користувача, але дещо затримає хакера, який намагається зламати сайт.
Для захисту більш важливих даних, можна застосувати сильніший підхід: блокування акаунту після певної кількості спроб введення невірного логіну. Блокування акаунту може бути тимчасовим або постійним. Блокування акаунту захищає від жорстких атак хакерів, оскільки логін не працює. Якщо це тимчасово, ефект на користувача біде мінімальний, тим більше, якщо буде показано повідомлення з причиною блокування. Постійне блокування вимагає від користувача зв'язатися зі службою підтримки для вирішення проблеми, а також краще відповідає потребам захисту логінів і важливої інформації.
Забезпечення безпеки паролів
Паролі - найбільш вразливий елемент логіну. Ніколи не зберігайте паролі, написані прямим текстом. Ніколи. Взагалі ніколи. Якщо ви так зробите, це означатиме, що будь-які проблеми безпеки можуть розкрити інформацію логіну. Слід уникати навіть зашифрованих паролів, наче хакер отримав до них доступ. Процес розшифровки може бути значно легшим. Будь-який сервіс, де ви зберігаєте/відновлюєте паролі, може полегшити хакеру роботу зробити те саме.
Сіль (криптографія) і хешування
Паролі, які ви зберігаєте слід "посолити" і хешувати. Сіль - це випадково згенероване, унікальне значення, яке зберігається для кожного логіна і додається перед хешуванням. Це запобігає отриманню ідентичними паролями одинакового хешу і хакери не можуть побудувати список результату хешу можливих комбінацій паролів. Додаючи випадковий хеш, пароль аbc123 (будь ласка ніколи не використовувати щось подібне в якості справжнього паролю) матиме різний хеш для кожного користувача.
Хеш-функція перетворює пароль в значення фіксованої довжини. Є спеціально розроблені для паролів опції, такі як PBKDF2 або Bcrypt. GPU-процесори в сучасних графічних картах можуть виконувати необхідний хеш і багато простих алгоритмів досить швидко. Механізм, призначений для злому паролів може визначити будь-які вісім або менше символів менше, ніж за шість годин.
Користувачі часто схильні використовувати ті ж самі паролі для більшості сайтів, на яких у них є акаунти. Багато сайтів почали тестування виявлених облікових даних, які піддаються атакам хакерів, і зв'язуються з такими користувачами, чиї комбінації імені користувача і пароля співпадають. Evernote і Facebook недавно розглянули облікові дані від Adobe і попередили користувачів, які використовували ті ж облікові дані.
Найпростіший спосіб коректно управляти паролями, це використовувати інструменти вашого фреймворка. Безпека паролю досить складна і якщо ви хоча б щось одне зробите невірно, ви залишаєте ваш пароль відкритим для атак. pH pass надає публічну бібліотеку доменів для PHP, використовуючи Вrypt. Більш старше вбудоване членство провайдерів .NET використовує слабкіші хеші, але новий Universal Providers користується PBKDF2. Rails також забезпечує Bcrypt gem.
Скасування паролів
Коли ви належним чином захищаєте паролі, так що їх не можна відновити, ви залишаєте користувача без можливості надати йому забутий пароль. Тому вам потрібно запровадити альтернативний варіант для користувача, який насправді забув пароль: скасувати пароль безпечним способом.
Сторінка скасування паролю.
Хороша сторінка скасування паролю дозволяє користувачу змінювати пароль без знання поточного паролю. Традиційний метод дозволяє користувачу ввести свій email, на який надсилається посилання на сторінку, де можна скасувати пароль. Відправлення посилання більш надійне, ніж відправлення паролю, оскільки новий пароль не створюється поки користувач не перейде на сторінку. Відправлення нового паролю на email створить нові облікові дані, які будь-хто, хто перехопить email матиме змогу використовувати без відома користувача. Якщо хтось перехоплює електронну пошту і робить скасування паролю, користувач дізнається про це, коли вони ввійдуть і намагатимуться змінити пароль.
Хороша сторінка скидання паролю також не повинна надавати підтвердження, що акаунт існує. Тут логіка така ж сама, як і коли ми обговорювали, що при спробі ввійти в акаунт не потрібно надавати зворотний зав'язок, що він існує. Навіть якщо такого логіна не існує в системі. Найкращий варіант в даному випадку - вивести повідомлення, що на відповідний email був надісланий файл з вказівками. Все ж вам слід відправити лист на введений email, оскільки це може бути то випадок, коли легітимний користувач забув, якою електронною адресою він користувався для цього акаунту, можливо, він ввів робочий email замість свого особистого.
Посилання для скасування паролю
Посилання для відновлення паролів створені так, що можуть бути дійсними тільки певний період часу і використовуватися тільки один раз. Створіть унікальний маркер для кожного запиту, прикріплений до акаунту, який запитується, і зберігайте в базі даних. Цей маркер стає частиною URL, який відправляється на email для скидання паролю. Маркер також повинен мати термін дії і видалятися після завершення зміни паролю. Якщо хтось намагається використовувати маркер, який вже використовувався, або з закінченим терміном дії, такий запит не виконуватиметься. Термін дії повинен бути достатньо довгим, щоб email було отримано і користувач завершив дію, проте не настільки, щоб використовуватися і в далекому майбутньому.
Скидання паролю за допомогою електронної пошти
Скидання паролю за допомогою email також робить питання безпеки вашого сайту залежним від цілісності email користувача. Якщо хтось може зайти на email, він може змінити і пароль. Сайти можуть задавати контрольні питання, на які потрібно дати відповідь перед тим, як змінити пароль. Контрольні питання забезпечують незначну безпеку, якщо відповіді можна легко знайти/здогадатись. Контрольне питання на зразок "Моє рідне місто?" надають низький рівень безпеки, якщо відповідь можна знайти в профілі Facebook користувача. Для забезпечення хороших питань, перейдіть по посиланні http://goodsecurityquestions.com/.
Двоетапна ідентифікація
Логін і пароль потребують тільки одну пару інформації для входу на сайт. Коли ця інформація надана, користувач приймається за вірну особу. Щоб ускладнити крадіжку персональних даних, ви можете встановити процес двоетапної ідентифікації. Помимо того, що користувач знає (ім'я користувача і пароль) він також повинен щось мати в своєму розпорядженні, зазвичай, мобільний телефон, функцію смс або додаток для цієї цілі.
Банки, ймовірно, були першими, хто запровадив процес використання пристроїв користувачів для генерації коду з терміном дії. Google популяризував текстові повідомлення смс або додаток в якості другого етапу. Зараз багато сайтів використовують логіни, сумісні з інтеграцією Google RFC 6238. Ви можете знайти бібліотеки, які вже запровадили ці техніки, серед них такі популярні фреймворки, як ASP.NET, ASP.NET #2, Ruby on Rails, PHP, і Django.
Зовнішня ідентифікація
Щоб уникнути цих проблем, у вас є ще одна опція: дозвольте комусь іншому цим всім перейматися, залучаючи для ідентифікації інші сторони, такі як Twitter, Facebook чи OpenID. Такий варіант має і переваги, і недоліки. Він вирішує всі питання безпеки, про які ми вели мову вище, оскільки цим займається хтось інший. Хоча, подібні сайти можуть бути навіть більш привабливою ціллю для хакерів, ніж ви самі. Якщо ви користуєтесь іншим сайтом для управління ідентифікації, тоді, якщо логін компрометовано, хакери мають доступ до вашого сайту.
Використання відомих третіх сторін може як допомогти, так і зашкодити з точки зору репутації і суспільного погляду. Перевага можливості входу через свій акаунт Facebook або Twitter в тому, що їх мають дуже багато користувачів, які були б раді скористатися такою можливістю. Інші відвідувачі сайтів можуть розглядати інтеграцію з цими сайтами як негативну опцію і не користуватися вашим сайтом по цій причині, або ж якщо це єдина функція, яка їм надається.
Висновок
Ваш логін для веб-додатків відіграє життєво важливу роль в питанні безпеки сайту. Турбота про захист вашого логіну в широкому значенні захистить відвідувачів вашого сайту і їх персональні дані. Щоб безпечно працювати з логінами, мінімізуйте об'єм інформації, яку можуть надати хакерам сторінки входу і зміни паролю. Також застосовуйте заходи безпеки, щоб було якнайважче вгадати пароль користувача агресивними методами атаки.
Захист паролів - це критичне питання для будь-якого сайту. Слабозахищені паролі роблять роботу хакера легшою і це може закінчитися тим, що облікові дані вашого сайту можуть стати доступними будь-кому. Використання хешованих і "посолених" паролів значно ускладнює роботу хакера. Також, додаткове запровадження другого етапу в процесі входу на сайт може забезпечити більше захисту для користувачів вашого сайту. Ви також можете обрати послуги третіх сторін для управління вашим сайтом.
