Credentials

למה זה חשוב

כל מערכת שמשרתת משתמשים צריכה לדעת מי אתה (Authentication) ומה מותר לך (Authorization). בלי ניהול נכון של Credentials, כל דלת במערכת פתוחה לרווחה — וזה בדיוק מה שתוקפים מחפשים.

דליפות סיסמאות הן מהווקטורים הנפוצים ביותר לפריצות. הבנה של איך שומרים, מעבירים ומאמתים Credentials היא ידע בסיסי לכל מפתח.

רעיונות מרכזיים

מה הם Credentials?

Credentials הם כל פיסת מידע שמוכיחה זהות או מעניקה גישה:

• Username + Password — השילוב הקלאסי והנפוץ ביותר
• API Keys — מפתחות שמזהים אפליקציה (לא משתמש אנושי)
• Tokens — מחרוזות זמניות שמייצגות הרשאה (למשל JWT)
• Certificates — תעודות דיגיטליות שמבוססות על Public Key Infrastructure
• SSH Keys — זוג מפתחות (Public/Private) להתחברות מאובטחת לשרתים
• MFA Codes — קודים זמניים ממכשיר שני (TOTP, SMS, Push Notification)

Authentication vs Authorization

סוגי Authentication

Single-Factor Authentication (SFA):

• רק סיסמה — הרמה הבסיסית ביותר, הכי פגיעה

Multi-Factor Authentication (MFA):

שילוב של שניים או יותר מהגורמים הבאים:

┌──────────────────────────────────────────────────────┐
│           שלושת הגורמים של Authentication            │
│                                                      │
│  🔑 Something you KNOW     → סיסמה, PIN             │
│  📱 Something you HAVE     → טלפון, YubiKey          │
│  👆 Something you ARE      → טביעת אצבע, Face ID     │
│                                                      │
│  שילוב של 2+ = MFA                                  │
│  שימוש ב-1 בלבד = רמת סיכון גבוהה                   │
└──────────────────────────────────────────────────────┘

Passwordless Authentication:

• WebAuthn / FIDO2 — אימות באמצעות מפתח חומרה או ביומטריה
• Magic Links — קישור חד-פעמי שנשלח לאימייל
• Passkeys — הסטנדרט החדש שמחליף סיסמאות לחלוטין

Hashing סיסמאות

Hashing הוא תהליך חד-כיווני: ממירים סיסמה למחרוזת קבועה שאי אפשר (בפועל) להפוך בחזרה.

סיסמה → Hash Function → Hash Value (נשמר ב-DB)

"myP@ssw0rd" → bcrypt → "$2b$12$LJ3m4ys..."

• bcrypt — האלגוריתם המומלץ. איטי בכוונה, כדי להקשות על Brute Force
• Argon2 — הדור הבא, זוכה תחרות Password Hashing Competition. תומך בהגדרת זיכרון, CPU ומקביליות
• Salt — ערך אקראי שמתווסף לפני ה-Hashing, כך ששתי סיסמאות זהות יניבו Hash שונה
• Pepper — ערך סודי קבוע שנשמר בנפרד מה-DB (בניגוד ל-Salt שנשמר ליד ה-Hash)

import bcrypt

# יצירת Hash עם Salt
password = b"myP@ssw0rd"
salt = bcrypt.gensalt(rounds=12)
hashed = bcrypt.hashpw(password, salt)

# בדיקת סיסמה
if bcrypt.checkpw(password, hashed):
    print("Authentication successful!")

Rainbow Tables ואיך מתגוננים

Rainbow Table — טבלת Hash מוכנה מראש:
┌────────────────┬──────────────────────────┐
│ Password       │ Hash (MD5)               │
├────────────────┼──────────────────────────┤
│ 123456         │ e10adc3949ba59abbe56...  │
│ password       │ 5f4dcc3b5aa765d61d83...  │
│ qwerty         │ d8578edf8458ce06fbc5...  │
└────────────────┴──────────────────────────┘

עם Salt — כל Hash ייחודי, Rainbow Table חסרת תועלת:
┌────────────────┬──────────┬──────────────────┐
│ Password       │ Salt     │ Hash             │
├────────────────┼──────────┼──────────────────┤
│ 123456         │ x8k2m... │ $2b$12$x8k2m... │
│ 123456         │ p3j9f... │ $2b$12$p3j9f... │
│ (אותה סיסמה — Hash שונה!)                   │
└────────────────┴──────────┴──────────────────┘

API Keys, OAuth ו-JWT

מבנה JWT:

┌──────────┐   ┌──────────┐   ┌──────────┐
│  Header  │ . │ Payload  │ . │Signature │
│(אלגוריתם)│   │ (Claims) │   │ (חתימה)  │
└──────────┘   └──────────┘   └──────────┘

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.abc123signature

OAuth 2.0 — Flow מפורט

┌────────┐     ┌────────────┐     ┌──────────────┐
│  User  │     │  Client    │     │ Auth Server  │
│(דפדפן) │     │ (האפליקציה)│     │ (Google)     │
└───┬────┘     └─────┬──────┘     └──────┬───────┘
    │  1. Login      │                    │
    │ ──────────────>│                    │
    │                │  2. Redirect       │
    │                │ ──────────────────>│
    │  3. User Login + Consent            │
    │ ──────────────────────────────────> │
    │                │  4. Auth Code      │
    │                │ <─────────────────│
    │                │  5. Exchange Code  │
    │                │    for Token       │
    │                │ ──────────────────>│
    │                │  6. Access Token   │
    │                │ <─────────────────│
    │  7. Logged in! │                    │
    │ <──────────────│                    │

Secrets Management — ניהול סודות בייצור

כלים לניהול Secrets:

❌ שגוי — Secrets בקוד:
──────────────────────────
db_password = "SuperSecret123!"
api_key = "sk-abc123def456..."

✅ נכון — Secrets מ-Environment:
──────────────────────────────────
db_password = os.environ["DB_PASSWORD"]
api_key = os.environ["API_KEY"]

✅ אפילו יותר טוב — Secrets מ-Vault:
────────────────────────────────────────
db_password = vault.read("secret/db")["password"]

Credential Stuffing ו-Brute Force

Brute Force — ניסיון כל הסיסמאות האפשריות:

attempt 1: aaaa → ❌
attempt 2: aaab → ❌
attempt 3: aaac → ❌
...
attempt 456789: P@ss → ✅ (פרצנו!)

Credential Stuffing — שימוש בסיסמאות שדלפו מאתר אחד כדי לנסות באתרים אחרים:

נדלף מ-LinkedIn:       ניסיון ב-Gmail:
user: dana@mail.com    user: dana@mail.com
pass: MyDog2020!  →    pass: MyDog2020!
                       תוצאה: ✅ (אותה סיסמה!)

הגנות:

• Rate Limiting — הגבלת מספר ניסיונות התחברות
• Account Lockout — נעילת חשבון אחרי X ניסיונות כושלים
• CAPTCHA — אחרי מספר ניסיונות כושלים
• Credential Monitoring — בדיקה אם Credentials של עובדים דלפו (Have I Been Pwned API)
• Password Policy — דרישת סיסמה חזקה + מניעת שימוש בסיסמאות שדלפו

תרחישי תקיפה אמיתיים

בלבולים נפוצים

• "Hashing = Encryption" — לא. Encryption הוא דו-כיווני (אפשר לפענח), Hashing הוא חד-כיווני. סיסמאות עוברות Hashing, לא Encryption.
• "API Key מספיק לאבטחה" — API Key לבדו לא מזהה משתמש ולא מוגבל בזמן. כדאי לשלב אותו עם OAuth או JWT.
• "Authentication ו-Authorization זה אותו דבר" — ממש לא. אתה יכול להיות מאומת (authenticated) אבל עדיין לא מורשה (authorized) לגשת למשאב מסוים.
• "MD5 ו-SHA-1 טובים לסיסמאות" — הם מהירים מדי, מה שמקל על Brute Force. תמיד השתמשו באלגוריתם שתוכנן לסיסמאות כמו bcrypt או Argon2.
• "JWT בלי Expiration זה בסדר" — Token בלי תפוגה הוא כמו מפתח שאי אפשר להחליף. תמיד הגדירו exp Claim קצר, והשתמשו ב-Refresh Token.
• "HTTPS = אני מאובטח" — HTTPS מגן על המידע בתעבורה (In Transit), אבל לא מגן על Credentials שנשמרים בצורה לא נכונה ב-DB או בקוד.

דוגמה קטנה

תרחיש: משתמש מתחבר לאפליקציה ומבקש לראות את הפרופיל שלו.

1. Client → Server:  POST /login  { "user": "dana", "pass": "abc123" }
   ┌─ Authentication ──────────────────────────────────────┐
   │ Server: hash("abc123") == stored_hash?  → ✅ מאומת   │
   └───────────────────────────────────────────────────────┘

2. Server → Client:  { "token": "eyJhbG..." }  (JWT)

3. Client → Server:  GET /profile  Authorization: Bearer eyJhbG...
   ┌─ Authorization ───────────────────────────────────────┐
   │ Server: האם ל-dana יש הרשאה ל-/profile? → ✅ מורשה   │
   └───────────────────────────────────────────────────────┘

4. Server → Client:  { "name": "Dana", "role": "admin" }

Refresh Token Flow

┌──────────────────────────────────────────────────────┐
│  Access Token: חיים קצרים (15 דקות)                  │
│  → משמש לכל Request                                 │
│                                                      │
│  Refresh Token: חיים ארוכים (7 ימים)                  │
│  → משמש רק לקבלת Access Token חדש                    │
│                                                      │
│  Flow:                                               │
│  1. Access Token פג → Server מחזיר 401               │
│  2. Client שולח Refresh Token ל- /token/refresh      │
│  3. Server מחזיר Access Token חדש                     │
│  4. Client ממשיך לעבוד בלי Login מחדש                 │
└──────────────────────────────────────────────────────┘

📚 לימוד אקדמי

🛤️ מאיפה מתחילים

שלב 1: הבסיס
├── להבין את ההבדל בין Authentication ל-Authorization
├── ללמוד איך Hashing עובד (bcrypt, Argon2)
└── להבין למה Salt חשוב

שלב 2: Tokens ו-Protocols
├── ללמוד מבנה JWT ואיך לאמת חתימה
├── להבין OAuth 2.0 Flow
└── להכיר OpenID Connect (OIDC)

שלב 3: הגנות מתקדמות
├── MFA — סוגים, יישום, ו-Fatigue Attack
├── Secrets Management — Vault, Secrets Manager
└── Rate Limiting ו-Account Lockout

שלב 4: ברמת Production
├── Zero Trust Architecture
├── Credential Monitoring (Have I Been Pwned)
├── Token Rotation ו-Revocation
└── RBAC / ABAC — מודלי Authorization מתקדמים

כלים מומלצים להתנסות:

• jwt.io — Debugger של JWT, מעולה להבנת המבנה
• Have I Been Pwned — בדיקה אם האימייל שלכם דלף
• CyberChef — כלי להמרות Encoding/Hashing
• Postman — בדיקת API Authentication flows

💼 שאלות לראיון עבודה

קישורים לנושאים אחרים

• Sandbox — איך מבודדים תהליכים כדי שגם אם Credentials נגנבו, הנזק מוגבל
• TCP/IP ו-HTTP — הפרוטוקולים שמעבירים את ה-Credentials ברשת (ולמה HTTPS חיוני)
• Production — ניהול Credentials בסביבת Production (Secrets Management, Environment Variables)
• Red, Blue & Purple Teams — צוותי Red Team בודקים חוזק Credentials כחלק מ-Penetration Testing
• MITRE ATT&CK — Credential Access הוא Tactic מרכזי במסגרת ATT&CK