الدرس 43 · Web and backend

Logins: authentication and sessions

لم يُترجم بعد؛ يُعرض باللغة الإنجليزية

When you log in, a website has to answer two questions: who are you, and what may you do? Follow Ada through signing up, logging in and staying logged in. The server never keeps her password, only a salted, slow hash; after a successful login it starts a session and hands her browser a session ID in a protected cookie. Then see two common additions: signed tokens (JWT) and a second factor.

12 دقيقة11 خطوات5 أسئلةIntermediate

شكل 43 · تفاعلي

جارٍ تحميل الرسم…

أو ← →

اختبر نفسك

5 أسئلة سريعة

اختر إجابة لتعرف السبب. تُحفَظ نتيجتك مع تقدّمك.

01Ada is logged in and tries to open Ben's inbox. The server refuses. Which check said no?

The server already knows who she is (authentication). Authorization decides what she may do, and Ben's inbox is not hers.

02What should a server store so it can check Ada's password later?

A hash cannot be turned back into the password. The salt makes equal passwords hash differently, and a slow algorithm makes guessing very costly. OWASP recommends exactly this.

03At login, how does the server know the typed password is right?

Hashing works one way only. The same password with the same salt and settings always gives the same hash, so equal hashes mean the right password.

04Why is the session cookie marked HttpOnly?

HttpOnly hides the cookie from JavaScript (document.cookie). Secure is the flag that keeps it to HTTPS.

05A site uses JSON Web Tokens instead of a session table. What is one downside?

The server trusts any token with a valid signature until its expiry time, unless it also keeps a block list. A session row can simply be deleted.

المصطلحات الأساسية

المسرد

Authentication: Checking who someone is, for example by a password, and on later requests by a session cookie.
Authorization: Deciding what an authenticated user may do, such as reading only their own messages. Always checked on the server.
Hash: A one-way function: easy to compute from the input, practically impossible to turn back. The same input always gives the same hash.
Salt: Random bytes stored next to a password hash and mixed into it, so equal passwords get different hashes.
Session: The server's memory that a browser has logged in: a row with a random session ID, the user and an expiry.
Cookie: A small name=value pair a server asks the browser to keep and send back with later requests to the same site.
JSON Web Token (JWT): A signed token that carries claims such as the user and an expiry time; the server checks the signature instead of a table.
Multi-factor authentication: Logging in with two kinds of proof, such as a password (something you know) and a phone or security key (something you have).

تفاصيل إضافية

الملاحظات والمصادر

The salt in the figure is fixed so you can check the numbers; a real server draws a new random salt for every password, so two people with the same password still get different hashes.
slow_hash on the card is Python's hashlib.scrypt with OWASP's minimum settings (n=2**17, r=8, p=1), which needs 128 MiB of memory per try. That cost is small for one login and huge for someone trying billions of guesses. Argon2id is OWASP's first choice where it is available.
A real session ID comes from secrets.token_urlsafe(32): 256 random bits, written as 43 URL-safe characters. The one in the figure is a fixed example.
Passwords and cookies are only safe on the way because the connection is HTTPS. Over plain HTTP anyone on the network could read them.
Real sites add more: a new session ID right after login, limits on repeated failed logins, and checks that every request is allowed, not just logged in.

اختبار يتاح بعد الخطوة الأخيرة.