מחולל HMAC — HMAC-SHA1, SHA256, SHA384, SHA512 מקוון

כלי זה מחשב HMAC (Hash-based Message Authentication Code) ממפתח סודי והודעה, תוך שימוש ב-SHA-1, SHA-256, SHA-384 או SHA-512 כפונקציית הגיבוב הבסיסית. בניגוד לגיבוב רגיל, HMAC דורש מפתח סודי משותף, ולכן הוא מוכיח שההודעה הגיעה ממי שמחזיק במפתח הזה ולא שונתה בדרך — וזו בדיוק הסיבה ש-API-ים משתמשים ב-HMAC כדי לחתום על בקשות ו-webhooks משתמשים בו כדי לאמת את שולח המטען. הכול פועל באופן מקומי דרך ה-Web Crypto API המובנה של הדפדפן שלכם; המפתח הסודי וההודעה שלכם לעולם לא נשלחים לשום שרת.

מהו הכלי הזה?

HMAC הוא ראשי תיבות של Hash-based Message Authentication Code. הוא משלב מפתח סודי עם הודעה ופונקציית גיבוב סטנדרטית (כמו SHA-256) כדי לייצר תקציר באורך קבוע. כל מי שמחזיק באותו מפתח והודעה יחשב בדיוק את אותו HMAC — אך ללא המפתח, בלתי אפשרי מבחינה חישובית לייצר HMAC תקף עבור הודעה, גם אם ידוע אלגוריתם הגיבוב שבו נעשה שימוש.

זהו ההבדל המרכזי מגיבוב רגיל: גיבוב רגיל (MD5, SHA-256 וכו') מקבל רק את ההודעה כקלט, כך שכל אחד יכול לחשב אותו והוא לא מוכיח דבר על מי שיצר אותו. HMAC מקבל את ההודעה *וגם* מפתח סודי, כך ש-HMAC תקף מוכיח שהשולח החזיק בסוד — זהו מנגנון אימות, לא רק בדיקת שלמות.

HMAC מתוקנן רשמית על ידי NIST במסמך FIPS 198-1 ומוגדר עבור פרוטוקולי אינטרנט ב-IETF RFC 2104. כלי זה מחשב HMAC באמצעות ה-Web Crypto API הילידי של הדפדפן שלכם (`crypto.subtle.sign` עם אלגוריתם HMAC), המיישם את RFC 2104 בצורה נכונה במקום גרסת JavaScript כתובה ידנית.

למה להשתמש בו?

חתמו על בקשות API כדי שהשרת המקבל יוכל לאמת שהבקשה הגיעה ממחזיק הסוד המשותף ולא שובשה.
אמתו מטענים של webhooks (Stripe, GitHub, Shopify ושירותים דומים חותמים על גופי ה-webhook שלהם באמצעות HMAC-SHA256).
צרו אסימוני אימות או קודים חד-פעמיים התלויים בסוד משותף.
השוו את הפלט של יישום ה-HMAC שלכם מול ערך ייחוס ידוע ונכון.
100% מקומי: המפתח הסודי וההודעה שלכם לעולם לא עוזבים את הדפדפן, כך שבטוח לבדוק סודות אמיתיים.

איך להשתמש

הזינו את המפתח הסודי שלכם בשדה "Secret Key".
הזינו את ההודעה שברצונכם לאמת בשדה "Message".
תוצאות HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 ו-HMAC-SHA512 נוצרות באופן מיידי (סמנו "Uppercase output" אם המערכת שלכם מצפה לאותיות גדולות).
לחצו על "Copy" ליד ה-HMAC הרצוי.

דוגמה

קלט

Secret Key: key
Message: The quick brown fox jumps over the lazy dog

פלט

HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

זהו וקטור בדיקה סטנדרטי ומפורסם: עם המפתח "key" וההודעה המדויקת הזו, HMAC-SHA256 ו-HMAC-SHA1 תמיד מייצרים את הערכים הללו בכל יישום נכון, כך שתוכלו לאמת את הפלט של כלי זה באופן עצמאי.

HMAC לעומת גיבוב רגיל: מתי צריך מפתח

השאלה המכרעת היא: האם עליכם להוכיח מי יצר את התקציר הזה, או רק שהתוכן לא השתנה? אם סכום ביקורת ציבורי מספיק — כדי לאמת שקובץ שהורד תואם למה שהמפרסם ציין, או למניעת כפילויות ברשומות — גיבוב רגיל עובד וכל אחד יכול לבדוק אותו, ללא מפתח. אם עליכם להוכיח שהתקציר יכול היה להיווצר רק על ידי מי שמחזיק בסוד ספציפי — אימות קורא ל-API, אמון בשולח webhook — אתם זקוקים ל-HMAC, מכיוון שגיבוב רגיל מעניק לתוקף ללא סוד את אותה יכולת לזייף תקציר תקף כמו לשולח האמיתי.

→

השוואת ארבעת אלגוריתמי ה-HMAC

כל ארבעת האלגוריתמים משתמשים באותו מבנה HMAC מ-RFC 2104, ונבדלים רק בפונקציית הגיבוב הבסיסית ולכן באורך הפלט.

אלגוריתם	גודל פלט	שימוש טיפוסי
HMAC-SHA1	160 סיביות (40 תווים הקסדצימליים)	API-ים ישנים, חתימות OAuth 1.0a ישנות
HMAC-SHA256	256 סיביות (64 תווים הקסדצימליים)	חתימת בקשות API, JWT HS256, אימות webhook
HMAC-SHA384	384 סיביות (96 תווים הקסדצימליים)	חתימות בביטחון גבוה יותר כשנדרש פלט ארוך יותר
HMAC-SHA512	512 סיביות (128 תווים הקסדצימליים)	תקצירים באורך מרבי ליישומים בעלי ביטחון גבוה

מקרי שימוש נפוצים

חתימה על בקשות API יוצאות עם סוד משותף כדי שהשרת יוכל לאמת את זהות הקורא.
אימות מטענים נכנסים של webhooks (הכותרות Stripe-Signature, GitHub X-Hub-Signature-256 ודומותיהן כולן משתמשות ב-HMAC-SHA256).
יצירה ואימות של חלק החתימה ב-JWT החתום באמצעות HS256/HS384/HS512.
בדיקה שיישום ה-HMAC בצד השרת או הלקוח שלכם תואם לפלט הצפוי לפני פריסתו.

שאלות נפוצות

מהו HMAC?

HMAC (Hash-based Message Authentication Code) משלב מפתח סודי עם הודעה באמצעות פונקציית גיבוב כדי לייצר תקציר המוכיח גם את שלמות ההודעה וגם את החזקת המפתח על ידי השולח. הוא מוגדר ב-NIST FIPS 198-1 וב-IETF RFC 2104.

מה ההבדל בין HMAC לגיבוב רגיל?

גיבוב רגיל (SHA-256, MD5 וכו') מקבל רק הודעה כקלט — כל אחד יכול לחשב אותו, כך שהוא רק מוכיח שההודעה לא נפגמה, לא מי שלח אותה. HMAC מקבל הודעה בתוספת מפתח סודי: אם עליכם להוכיח שהודעה הגיעה ממי שמחזיק בסוד מסוים (חתימת API, שולח webhook), אתם זקוקים ל-HMAC. אם עליכם רק לבדוק שקובץ או הודעה לא השתנו ואינכם צריכים להוכיח את זהות היוצר, גיבוב רגיל מספיק.

האם המפתח הסודי שלי נשלח לשרת?

לא. כלי זה מחשב את ה-HMAC כולו בדפדפן שלכם באמצעות ה-Web Crypto API. המפתח וההודעה שלכם לעולם לא מועברים לשום מקום — תוכלו לבדוק בבטחה סודות ייצור אמיתיים.

באיזה אלגוריתם כדאי להשתמש — SHA-1, SHA-256, SHA-384 או SHA-512?

השתמשו ב-HMAC-SHA256 אלא אם מערכת ספציפית דורשת אחרת — זהו התקן המקובל בפועל לחתימת API (בשימוש AWS, Stripe, webhooks של GitHub ורוב ה-API-ים המודרניים) והוא מציע שולי ביטחון חזקים. HMAC-SHA1 עדיין נפוץ במערכות ישנות (כמו יישומי OAuth 1.0a ישנים) אך הגיבוב הבסיסי של SHA-1 נחשב חלש יותר; HMAC-SHA384/512 משמשים במקרים שבהם נדרש במפורש פלט ארוך יותר או שולי ביטחון נוספים.

האם HMAC-SHA1 לא בטוח, מכיוון ש-SHA-1 הרגיל נפרץ?

התקפות ההתנגשות של 2017 פרצו את SHA-1 כפונקציית גיבוב רגילה, אך HMAC-SHA1 עדיין נחשב תקין קריפטוגרפית מכיוון שביטחון HMAC אינו תלוי בעמידות בפני התנגשויות באותה צורה. עם זאת, עדיף HMAC-SHA256 ומעלה עבור מערכות חדשות — אין חיסרון מעשי וכך נמנעת השאלה כליל.

מהם שימושים נפוצים ב-HMAC בעולם האמיתי?

חתימה על בקשות REST API כדי שהשרת יוכל לאמת שהקורא מחזיק בסוד ה-API המשותף; אימות מטענים של webhooks משירותים כמו Stripe, GitHub ו-Shopify כדי לדעת שבקשה אכן הגיעה מהם ולא זויפה; יצירת סיסמאות חד-פעמיות מבוססות זמן (TOTP/HOTP) לאימות דו-שלבי; וחתימה על אסימוני JWT באמצעות אלגוריתמי HS256/HS384/HS512.