Ngày 12: Quiz Tổng Kết Tuần 2 — Authentication & Authorization | Security

Vì sao SHA-256 không phù hợp để lưu password kể cả khi có salt?

A.SHA-256 không hỗ trợ saltB.SHA-256 quá nhanh (~10 tỷ hash/giây trên GPU) — brute force khả thiC.SHA-256 chỉ hỗ trợ password tối đa 8 ký tựD.SHA-256 không có trong Node.js standard library

OWASP 2024 khuyến nghị thuật toán nào cho password hashing trong dự án mới?

A.MD5B.SHA-512 với 10,000 iterationsC.argon2id (memory-hard, winner of Password Hashing Competition)D.AES-256

Salt và pepper khác nhau cốt lõi ở điểm nào?

A.Salt là string, pepper là numberB.Salt unique per-user và lưu cùng hash (không bí mật); pepper là server-wide secret lưu tách biệt (env/KMS)C.Salt cho bcrypt, pepper cho argon2D.Không có sự khác biệt — đều là salt

Cookie chứa session id cần cờ HttpOnly để chống loại tấn công nào?

A.CSRFB.Man-in-the-middleC.XSS đọc cookie qua `document.cookie`D.SQL injection

JWT alg=none attack hoạt động khi nào?

A.Server cho phép token không signature vì đọc alg từ header thay vì whitelist algorithm khi verifyB.JWT bị hết hạnC.Network không có HTTPSD.Secret quá ngắn

Khi nào nên dùng RS256 thay vì HS256 cho JWT?

A.Khi cần token ngắn hơnB.Khi hệ thống có nhiều microservices verify token do một auth service phát hành (không muốn share secret)C.Khi không có HTTPSD.Khi user dùng password mạnh

PKCE giải quyết vấn đề gì với public clients (SPA, mobile)?

A.Cho phép OAuth2 hoạt động không có HTTPSB.Thay thế `client_secret` bằng one-time `code_verifier`/`code_challenge` để chống authorization code interceptionC.Mã hóa access tokenD.Cho phép token không hết hạn

Sự khác biệt giữa Access Token và ID Token (OIDC)?

A.Access Token dùng để gọi API (aud = resource server); ID Token dùng để client biết user là ai (aud = client app)B.Access Token luôn là JWT; ID Token luôn opaqueC.Hai cái giống nhau, chỉ khác tênD.ID Token thay thế Access Token trong OAuth 2.1

Chọn nhiều đáp án

Resource Server PHẢI verify claim nào để chống "confused deputy" attack (token cho API A bị replay sang API B)?

A.`iat`B.`jti`C.`aud`D.`nbf`

Tại sao password + TOTP vẫn không chống được phishing 100%?

A.TOTP quá ngắnB.Phishing site proxy real-time: user nhập password + TOTP code lên fake site → site forward đến site thật trong window 30sC.TOTP secret bị leakD.TOTP chỉ hoạt động khi có internet

SMS OTP yếu nhất ở threat nào?

A.Brute forceB.SIM swap — attacker social-engineer telco port số sang SIM mới, nhận mọi OTPC.SQL injectionD.CSRF

WebAuthn/Passkey chống phishing tuyệt đối vì lý do gì?

A.User phải nhập password phức tạpB.Browser bind key với origin (rpId) — key không hoạt động trên domain khác → không có gì để leak khi user vào phishing siteC.Passkey dùng AES-256D.Passkey yêu cầu HTTPS

Chọn nhiều đáp án

IDOR (Insecure Direct Object Reference) là gì?

A.User authenticated nhưng endpoint không verify ownership → User A đổi ID trong URL, xem được data của User BB.SQL injection thông qua URL parameterC.Cross-site scriptingD.Session fixation

ABAC vượt trội RBAC trong tình huống nào?

A.Khi chỉ có 3 role: admin, editor, viewerB.Khi cần authorization phụ thuộc context (thời gian, IP, MFA passed) hoặc ownership per-resource (user edit chỉ post của mình)C.Khi muốn UI quản lý dễD.Khi cần audit log đơn giản

Chọn nhiều đáp án

Pattern nào sau đây là anti-pattern trong authorization?

A.Filter `WHERE user_id = ?` trong queryB.Postgres Row-Level SecurityC.Query toàn bộ records, sau đó filter `.filter(r => r.user_id === currentUser)` ở application codeD.Middleware `requirePermission("posts:delete")` trước handler