ההבדל בין TOTP ל-HOTP: עקרונות מתמטיים, אבטחה ומנגנוני פעולה

💡 עיקרי הדברים בקריפטוגרפיה (TL;DR)

הבדל הקלט הבסיסי: HOTP מחשב גיבוב (Hash) מתוך מונה C שגדל מונוטונית, בעוד ש-TOTP מחליף את C ב-צעד זמן מבוסס Epoch T (CurrentUnixTime / 30).
ירושה ישירה: מבחינה מתמטית, TOTP הוא מקרה פרטי של HOTP: TOTP(K, Time) = HOTP(K, T). שני האלגוריתמים משתמשים באותה פונקציית Dynamic Truncation בדיוק.
הגורם המכריע בארכיטקטורה: HOTP הוא בעל מצב (stateful - שרתים חייבים לנעול ולשמור מונים למסד הנתונים בכל אימות). TOTP הוא חסר מצב (stateless), מה שמאפשר למיקרו-שירותי ענן מודרניים לאמת טוקנים על פני אשכולות מבוזרים עם חלוקת עומסים ללא פעולות כתיבה למסד נתונים מרכזי.

שורשים היסטוריים: מטוקנים פיזיים קנייניים לתקני רשת פתוחים

בראשית שנות ה-2000, שוק האימות הדו-שלבי בארגונים נשלט ברובו על ידי טוקנים פיזיים קנייניים כדוגמת RSA SecurID. מכשירים סגורים ויקרים אלה הכילו גבישי קוורץ פנימיים שסונכרנו מול שרתי ארגון ייעודיים. כאשר ארגון רצה לספק אבטחת ריבוי-גורמים לאלפי עובדים, עלויות הרכש של החומרה ודמי הרישוי הקנייניים היו אסטרונומיים.

כדי לשחרר את עולם האימות מחברות קנייניות, הוקם קונסורציום OATH (Initiative for Open Authentication) על ידי מובילי תעשייה במטרה לספק תקני IETF פתוחים וללא תמלוגים, שכל מהנדס תוכנה יוכל לבחון, ליישם ולבקר באופן חופשי:

📜 2005: RFC 4226 (HOTP)

אלגוריתם סיסמה חד-פעמית מבוסס HMAC (HMAC-Based One-Time Password Algorithm). הותאם למיקרו-בקרים בעלי צריכת חשמל נמוכה עם כפתור לחיצה פיזי. לחיצה על הכפתור מקדמת מונה פנימי ומציגה קוד בן 6 ספרות על גבי מסך LCD.

📜 2011: RFC 6238 (TOTP)

אלגוריתם סיסמה חד-פעמית מבוסס זמן (Time-Based One-Time Password Algorithm). תוכנן עם העלייה המהירה באימוץ הסמארטפונים. על ידי מינוף סנכרון זמן רשתי (NTP) סלולרי, TOTP ביטל לחלוטין אי-התאמות במצב המונה עקב לחיצות על כפתורים פיזיים.

ארכיטקטורת HOTP (RFC 4226) ומכניקת הבייטים של Dynamic Truncation

ההגדרה המתמטית של HOTP היא תמציתית להפליא:

HOTP(K, C) = Truncate(HMAC-SHA-1(K, C)) mod 10^DigitCount

פירוט הפרמטרים:

K: מפתח סודי סימטרי משותף (בדרך כלל רצף בינארי מפוענח מ-Base32 של 160 ביט / 20 בייטים).
C: מונה מספר שלם של 8 בייטים (64 ביט) בפורמט Big-Endian.
HMAC-SHA-1: קוד אימות הודעות באמצעות פונקציית גיבוב המייצר תמצית קריפטוגרפית בת 20 בייטים (160 ביט).

🔍 כיצד קיטום דינמי (Dynamic Truncation - DT) ממיר 20 בייטים ל-6 ספרות:

תמצית HMAC-SHA1 מכילה 160 ביט (20 בייטים). חילוץ של 6 ספרות עשרוניות אחידות דורש מנגנון בחירה דטרמיניסטי ועמיד בפני התנגשויות המוגדר בסעיף 5.3 של RFC 4226:

// שלב 1: חישוב היסט דינמי (Dynamic Offset)

Offset = HS[19] & 0x0F

לוקחים את הבייט האחרון (אינדקס 19) של התמצית בת 20 הבייטים. מיסוך עם 0x0F מבודד את 4 הביטים הנמוכים, מה שמניב מספר שלם בין 0 ל-15 (0x0 עד 0xF). פעולה זו מבטיחה שחילוץ 4 הבייטים הבאים לעולם לא יחרוג מגבולות המאגר של 20 בייטים (מכיוון ש-15 + 4 = 19).

// שלב 2: חילוץ 4 בייטים רצופים עם מיסוך

P = ( (HS[Offset] & 0x7F) << 24 ) | ( (HS[Offset+1] & 0xFF) << 16 ) | ( (HS[Offset+2] & 0xFF) << 8 ) | ( HS[Offset+3] & 0xFF )

מחלצים 4 בייטים החל מהאינדקס Offset. המסכה 0x7F מאפסת את הביט המשמעותי ביותר (MSB) כדי למנוע גלישת מספרים שלמים בעלי סימן בארכיטקטורות מעבד שונות (ובכך מבטיחה מספר שלם חיובי נקי של 31 ביט).

// שלב 3: אריתמטיקה מודולרית עבור הספרות הסופיות

OTP = P mod 10⁶ = P mod 1000000

החלת פעולת מודולו 1,000,000 מבודדת את 6 הספרות העשרוניות הסופיות, עם ריפוד באפסים מובילים במידת הצורך (למשל 748 הופך ל-"000748").

🧪 וקטור בדיקה מוחשי מתוך נספח D של RFC 4226:

נניח שהמפתח הסודי ב-ASCII הוא "12345678901234567890" והמונה הוא C = 0. תמצית ה-HMAC-SHA1 המתקבלת בהקסדצימל היא:

cc 93 cf 18 50 8d 94 93 4c 64 b6 6d 8b fb 87 fb 23 cb 4b 71

1. הבייט האחרון הוא 0x71. מתקיים 0x71 & 0x0F = 0x01, ולכן Offset = 1.
2. בייטים 1 עד 4 הם: 93 cf 18 50. איפוס ה-MSB נותן 0x13cf1850, שערכו בעשרוני שווה ל-332,339,280.
3. 332339280 mod 1000000 = 339280. קוד ה-OTP בן 6 הספרות שמתקבל הוא 339280!

התפתחות TOTP (RFC 6238): קסם צעדי הזמן

HOTP דרש שמירה על סנכרון רציף של המונה בין הלקוח לשרת. במכשירי תוכנה, ספירת לחיצות מקשים או כפתורים יוצרת שגיאות אנוש מתמשכות.

RFC 6238 החליף את המונה C ב-צעד זמן בדיד T הנגזר ישירות משעון ה-Unix Epoch:

T = ⌊ (CurrentUnixTime - T0) / X ⌋

CurrentUnixTime: מספר השניות שחלפו מאז 1970-01-01 00:00:00 UTC.
T0: נקודת הייחוס לאתחול ה-Epoch (ברירת המחדל היא 0 בכל המערכות המודרניות).
X (חלון צעד הזמן): משך הזמן הסטנדרטי המומלץ של 30 שניות.
פונקציית רצפה ⌊ ⌋: עבור כל חותמת זמן בתוך חלון של 30 שניות, T נשאר קבוע לחלוטין. לדוגמה, בין שניות ה-Epoch 1728211200 ל-1728211229, הערך של T מחושב לאותו מספר שלם בן 64 ביט בדיוק.

סריאליזציה בינארית: לאחר חישוב T, הוא נארז למאגר בתים בינארי בן 8 בייטים בפורמט Big-Endian (זהה במבנה הזיכרון למונה C ב-HOTP). כתוצאה מכך, הנוסחה המאוחדת מתכנסת לפשטות אלגנטית:
TOTP(K, Time) = HOTP(K, T) אלגנטיות מתמטית זו מסבירה מדוע אפליקציות אימות מחליפות קודים בסנכרון מושלם מדי 30 שניות, ללא צורך בשמירת מצב או בסנכרון נתונים מקוון.

תמיכת RFC 6238 ב-SHA-256 וב-SHA-512: בעוד ש-RFC 4226 הגדיר באופן קשיח את HMAC-SHA-1 בלבד, RFC 6238 הרחיב את התמיכה ל-HMAC-SHA-256 ול-HMAC-SHA-512. ב-SHA-256 (תמצית של 32 בייטים), ההיסט נלקח מבייט 31 (HS[31] & 0x0F); ב-SHA-512 (תמצית של 64 בייטים), ההיסט נלקח מבייט 63 (HS[63] & 0x0F). עם זאת, ב-99.9% מאתרי האינטרנט המסחריים (Google, Microsoft, GitHub, AWS), SHA-1 נותר ברירת המחדל האוניברסלית בשל תאימות לאחור עם אפליקציות מובייל ישנות.

טבלת השוואה מקיפה: HOTP מול TOTP

ממד	HOTP (RFC 4226)	TOTP (RFC 6238)
משתנה קלט	מונה אירועים C (גדל באופן מונוטוני)	צעד זמן T (חלון Unix Epoch של 30 שניות)
משך חיי הטוקן	ללא הגבלת זמן (תקף עד לשימוש בכניסה הבאה)	30 שניות בלבד (פג תוקף אוטומטית)
ארכיטקטורת שרת	בעלת מצב (דרושות כתיבות אטומיות למסד נתונים בכל כניסה)	חסרת מצב (אימות עצמאי באמצעות שעון NTP)
חשיפה למתקפת שידור חוזר (Replay Attack)	בינונית (טוקן שיורט נותר תקף עד לשימוש בו)	מינימלית (מוגבל לשניות הנותרות בחלון הפעיל)
אופן כשל עיקרי	דה-סנכרון מונה (לחיצות אקראיות על כפתור)	סטיית שעון (Clock Drift בטלפון הלקוח)
פונקציות גיבוב קריפטוגרפיות נתמכות	HMAC-SHA-1 בלבד	HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512
אימוץ בתעשייה	טוקנים בנקאיים ישנים, שערים פיזיים ייעודיים	99.9% מאפליקציות האימות ברשת המודרנית

פתרונות הנדסיים לדה-סנכרון וסטיית שעון

בסביבות ייצור מבוזרות, לקוחות ושרתים חווים בהכרח פערים בסנכרון. קריפטוגרפים תכננו חלונות פיצוי מפורשים לשמירה על אמינות תפעולית:

⚙️ מנגנון פיצוי ב-HOTP: חלון אימות מקדים (Look-Ahead Verification Window s)

אם משתמש לוחץ על כפתור הטוקן שלו 5 פעמים מבלי לשלוח את הקוד, מונה הלקוח מגיע ל-C+5 בעוד שרת האימות נשאר ב-C.
תקן RFC 4226 קובע כי בעת האימות, השרת מחשב חלון מקדים המשתרע על פני [C+1, C+s] (בדרך כלל s=20). אם מזוהה התאמה, השרת מקדם את המונה C מיד ומסתנכרן מחדש.

⏱️ מנגנון פיצוי ב-TOTP: סבילות לסטיית שעון (חלון של 1±)

עקב השהיות רשת או סטיית שעון במכשיר הלקוח (כגון שעון טלפון המפגר ב-10 שניות), טוקנים עשויים להגיע בצעדי זמן סמוכים.
שרתי ייצור בודקים מערך של 3 חלונות: [T-1, T, T+1], מה שמרחיב בפועל את חלון קבלת הקוד ל-90 שניות.

כלל חובה למניעת שידור חוזר (Anti-Replay Rule): כדי למנוע מתקפות שידור חוזר בתוך חלון הסטייה של 90 השניות, שרתים חייבים לשמור בזיכרון מטמון מהיר (כגון Redis) את הקודים שכבר נוצלו למשך 90 שניות, ולדחות הגשות כפולות.

🛡️ השוואת מחרוזות בזמן קבוע (הגנה מפני מתקפת תזמון - Timing Attack):

כאשר שרתים מוודאים האם הקוד שהזין המשתמש תואם לקוד שחושב, בדיקת שוויון מחרוזות נאיבית (כגון userOtp === serverOtp) עוצרת בתו הראשון שאינו תואם. תוקף המודד זמני תגובה רשתיים מיקרוסקופיים יכול לשחזר את הספרות בהדרגה. מערכות קצה ארגוניות אוכפות השוואת שוויון בזמן קבוע (למשל crypto.timingSafeEqual ב-Node.js) כדי לסכל ניתוח תזמון בערוץ צדדי.

מדוע TOTP כבש את האינטרנט המודרני

ניצחונו המכריע של TOTP על פני HOTP ברחבי הרשת הונע על ידי שלושה יתרונות ארכיטקטוניים מרכזיים:

☁️ סקיילביליות בענן ללא שמירת מצב (Stateless)

במיקרו-שירותים מבוזרים הפרוסים במספר אזורים בעולם, כל מופע שרת בעל שעון מסונכרן NTP יכול לאמת קודי TOTP ללא צורך בשאילתות או נעילת רשומות במסד נתונים מרכזי.

📱 סינרגיה עם המערכת האקולוגית של המובייל

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

🛡️ חלון תקיפה צר של 30 שניות בלבד

קודי HOTP נותרים תקפים ללא הגבלת זמן עד לשימוש בהם. לעומת זאת, קודי TOTP פוקעים תוך 30 שניות, ובכך מנטרלים אוטומטית סכנה מלוגים שנחשפו או מיירוט תעבורה פסיבי.

🧮 מנוע RFC 6238 מלא בצד הלקוח

התנסו בחישובי TOTP בזמן אמת ב-2FA-Tool

ראו כיצד מחרוזת ה-Base32 הסודית שלכם הופכת לקודים דינמיים של 6 ספרות באמצעות Dynamic Truncation של HMAC-SHA1. 100% לא מקוון בדפדפן שלכם.

פתח מחולל מקוון

📚 מדריכי אבטחה קשורים

מדריך העברת Google Authenticator ←

כיצד להעביר חשבונות 2FA בין סמארטפונים באמצעות קודי QR לא מקוונים וסנכרון ענן.

מדריך אימות דו-שלבי וקודי שחזור ב-GitHub ←

כללי תאימות, שמירת קודי שחזור, שילוב מפתחות SSH ותהליכי שחזור חשבון.

איבדתם את הטלפון עם ה-2FA? מדריך שחזור חירום ←

כיצד לשחזר גישה לחשבונות Google, Microsoft, Steam, Binance, Apple ו-Discord.