Ось урок у стилі CS50, розроблений спеціально для тебе. Уяви, що ми зараз в аудиторії Sanders Theatre, я ходжу сценою, жестикулюю, а за спиною — величезний екран із кодом.

Поїхали! 🚀

🛡️ Аутентифікація: Хто ти такий?

1. 🔥 Вступ: Проблема та мотивація

Уявіть, що ви приходите в готель. Ви підходите до стійки реєстрації, показуєте паспорт, адміністратор перевіряє його і дає вам ключ-картку.

Тепер запитання: чи показуєте ви паспорт щоразу, коли хочете зайти у свій номер? Або коли замовляєте каву в барі готелю? Або коли йдете в басейн?

Звісно, ні! Це було б абсурдно незручно. Ви просто прикладаєте картку.

Але в інтернеті все трохи інакше. Протокол HTTP, на якому тримається весь веб, має одну особливість — у нього «коротка пам’ять». Він stateless. Це означає, що коли ви надсилаєте запит на сервер (наприклад, відкриваєте сторінку «Мої повідомлення»), сервер дивиться на вас як на абсолютно нового незнайомця. Він не пам'ятає, що 5 секунд тому ви ввели логін і пароль.

Проблема: Як нам переконати сервер, що ми — це ми, не вводячи пароль при кожному кліку мишкою? І головне — як зберігати ці паролі так, щоб навіть якщо хакери вкрадуть базу даних, вони не змогли зайти у ваші акаунти?

Без аутентифікації інтернет перетворився б на дошку оголошень: кожен міг би писати від імені кожного, читати чужі листи й витрачати чужі гроші. Страшно, правда?

Сьогодні ми розберемося, як працює ця магія безпеки.

2. 🧠 Теоретична база (без сухої академічності)

Давайте розставимо крапки над «і».

Ідентифікація — це коли ви кажете: «Привіт, я — David». (Ви назвали ім'я).
Аутентифікація — це коли ви доводите це: «Ось мій паспорт або секретний пароль». (Ми перевіряємо, чи це правда).
Авторизація — це те, що вам дозволено робити після входу (наприклад, студент може здати домашку, а викладач — поставити оцінку).

Сьогодні нас цікавить саме Аутентифікація.

Як це працює «під капотом»?

Тут є два головні механізми, які треба зрозуміти інтуїтивно:

1. Зберігання паролів (Хешування)

Уявіть, що у вас є яблуко 🍎. Ви кладете його в блендер і робите смузі 🥤. * З яблука легко зробити смузі. * Але зі смузі неможливо відновити яблуко.

Це і є Хеш-функція. Коли ви реєструєтесь, ми не зберігаємо ваш пароль "123456" (це злочин!). Ми проганяємо його через «блендер» (алгоритм хешування) і зберігаємо отриману «кашу» з символів. Коли ви входите, ми знову блендеримо введений пароль і порівнюємо дві «каші». Збіглися? Ласкаво просимо!

2. Сесії та Токени (Пам'ять сервера)

Пам'ятаєте аналогію з готелем? * Логін — це отримання ключ-картки (Passport Check). * Session ID / Token — це сама ключ-картка. Сервер дає вам довгий унікальний рядок (токен), який ваш браузер зберігає. При кожному наступному запиті браузер тихесенько показує цей токен серверу: «Ей, я той хлопець, що залогінився хвилину тому!».

3. 🧪 Приклади (від простого до реального)

Приклад 1: Як НЕ МОЖНА робити ❌

Уявіть, що ми пишемо код перевірки користувача. Що ви очікуєте побачити в базі даних?

# База даних (умовно)
users_db = {
    "david": "harvard123",  # ПРЯМИЙ ТЕКСТ! ЖАХ!
    "maria": "qwerty"
}

def login(username, password):
    if username in users_db:
        if users_db[username] == password:
            return "Ласкаво просимо!"
    return "Помилка входу"

Чому це погано? Якщо адмін бази даних (або хакер) відкриє таблицю, він побачить усі паролі. Люди часто використовують один пароль усюди. Вкравши базу вашого маленького форуму, хакер отримає доступ до пошти та банківських акаунтів користувачів. Ніколи так не робіть.

Приклад 2: Правильний підхід (Хешування + Сіль) ✅

Тепер зробимо як профі. Використаємо бібліотеку bcrypt. Що зміниться? Ми не зберігаємо пароль. Ми зберігаємо його відбиток.

import bcrypt

# 1. Реєстрація (Створення смузі)
password_raw = b"super_secret"
# Генеруємо "сіль" (випадкові дані, щоб однакові паролі мали різний хеш)
salt = bcrypt.gensalt()
hashed_password = bcrypt.hashpw(password_raw, salt)

print(f"Ми зберігаємо в БД це: {hashed_password}")
# Вивід: b'$2b$12$eX5...' (набір незрозумілих символів)

# 2. Вхід (Перевірка смузі)
input_password = b"super_secret" # Користувач вводить пароль
input_wrong = b"wrong_pass"

# Магія перевірки
if bcrypt.checkpw(input_password, hashed_password):
    print("✅ Доступ дозволено!")
else:
    print("❌ Пароль неправильний!")

Пояснення: Навіть якщо я бачу hashed_password, я не знаю, що це було "super_secret". Я не можу «розблендерити» його назад.

Приклад 3: Життєвий цикл (Як браузер пам'ятає вас)

Клієнт: Відправляє Логін/Пароль.
Сервер: Перевіряє хеш. Все ок? Генерує session_token = "abc-123-xyz".
Сервер: Відповідає: «Ок, тримай печиво (Cookie) з цим токеном».
Клієнт (наступний запит): «Хочу відкрити профіль». (Браузер автоматично прикріплює Cookie: session_token="abc-123-xyz").
Сервер: Дивиться в список активних сесій. «Ага, токен "abc-123" належить Девіду. Показуємо профіль Девіда».

4. 🛠 Практична частина

Час закачати рукави! Спробуйте вирішити ці завдання (можна усно або псевдокодом):

🔹 «Паперовий хакер»: У вас є база даних: User: Alex, PassHash: 987abc. Ви знаєте, що хеш-функція проста: перша літера пароля перетворюється на код ASCII, а остання додається в кінець. Чи можете ви дізнатися справжній пароль Алекса? (Підказка: це слабкість простих хешів).
🔹 Виправ помилку: Розробник-початківець написав функцію відновлення пароля: «Якщо користувач забув пароль, ми надсилаємо йому його старий пароль на пошту». Що тут не так з точки зору архітектури безпеки? Що це говорить про те, як вони зберігають паролі?
🔹 Міні-кейс «Cookie Theft»: Ви сидите в кафе, Wi-Fi відкритий. Зловмисник перехопив ваш session_token (вашу «ключ-картку» від готелю). Він не знає вашого пароля. Питання: Чи зможе він зайти у ваш акаунт? Питання з зірочкою: Як сервер може захистити користувача від цього? (Подумайте про час життя токена або прив'язку до IP).
🔹 А що, якщо... Два користувачі (Оля і Петро) мають однаковий пароль: "123456". Якщо ми просто хешуємо їх, хеші будуть однакові. Хакер побачить це і зрозуміє, що паролі однакові. Як концепція «Солі» (Salt) вирішує цю проблему?

5. 💡 Мислення як у розробника

Ось що відрізняє новачка від сеньйора в темі безпеки:

Золоте правило: Never roll your own crypto. (Ніколи не пишіть власні алгоритми шифрування). Не думайте, що ви розумніші за математиків, які розробляли AES чи RSA роками. Використовуйте готові, перевірені бібліотеки (як bcrypt, Argon2).
Параноя — це добре. Розробник думає не «як користувач увійде», а «як зловмисник спробує це зламати».
- А що, якщо переберуть усі паролі? -> Обмежимо кількість спроб.
- А що, якщо вкрадуть базу? -> Тільки хеші з сіллю.
Баланс між безпекою та зручністю. Якщо ви вимагатимете пароль із 50 символів, спецсимволів та ієрогліфів, користувач просто наклеїть стікер з паролем на монітор. Це — провал безпеки. Хороша система — непомітна.

6. 🧩 Підсумок

Отже, друзі, що ми маємо в сухому залишку?

Аутентифікація — це відповідь на питання «Хто ти?».
Паролі ми ніколи не зберігаємо у відкритому вигляді. Ми робимо з них «смузі» (хешуємо).
Щоб не вводити пароль щоразу, ми використовуємо сесії або токени (як ключ-картка в готелі).

Тепер ви вмієте: Розуміти, як сайти розпізнають вас, чому не можна відновити старий пароль (а тільки скинути його) і чому «адмін123» — це погана ідея, навіть якщо вона захешована.

Тизер наступного уроку: Добре, ми впізнали, що це саме ви зайшли на сайт банку. Але чи маєте ви право переказати мільйон доларів? Або тільки переглянути баланс? Наступного разу ми поговоримо про Авторизацію та Ролі користувачів.

А на сьогодні це все! 👋