קידוד Base64: שימושים אמיתיים, מנגנון וטעויות נפוצות
נכתב על ידי Toolsxulo Team
Base64 מופיע כל הזמן במיילים, ב-API ובקובצי קונפיגורציה, אבל הוא מובן לא נכון באופן שיטתי כצורת אבטחה במקום מה שהוא באמת - שכתוב בטוח-לטקסט של נתונים בינאריים. המדריך הזה עובר על היכן הוא באמת שימושי, מה הוא עולה לכם, ומאיפה הבלבול סביבו מגיע.
פתח את הכלי: מקודד Base64היכן Base64 באמת משמש
מייל קדם לתחבורת 8-bit-clean בהרבה מהפרוטוקולים הבסיסיים שלו, כך שקבצים מצורפים למייל השתמשו ב-Base64 (דרך MIME) מהימים הראשונים של האינטרנט כדי להבטיח שקבצים בינאריים ישרדו מערכות שמעבירות בצורה אמינה רק טקסט 7-bit. אותו צורך - הטמעת בינארי בערוץ טקסט בלבד - הוא הסיבה ש-Base64 מופיע בפיילודי JSON שנושאים נתוני תמונה, בכותרות Basic Auth (שם משתמש:סיסמה מקודדים, לא מוצפנים), ב-data: URIs שמטמיעים תמונה קטנה ישירות ב-CSS או HTML כדי לחסוך בקשת HTTP נוספת, וב-JWT tokens, שבהם כל אחד משלושת החלקים המופרדים בנקודה מקודד JSON ב-Base64url.
זו לא הצפנה, וההתייחסות אליו ככזה היא פגיעות אמיתית
קידוד ופענוח Base64 לא דורשים מפתח, סיסמה או סוד מכל סוג - זה מיפוי קבוע וידוע לציבור, כך שכל מי שרואה מחרוזת Base64 יכול לפענח אותה בשורת קוד אחת או כלי אונליין בודד. כותרת Basic Auth היא הדוגמה מהספר לטעות הזו שקורית בפועל בסביבת production: היא נראית מעורפלת כי היא לא קריאה למבט חטוף, מה שגורם לאנשים להניח שהיא מוגנת, אבל היא חשופה בדיוק כמו שליחת האישורים בטקסט רגיל, אלא אם החיבור עצמו מוצפן עם TLS.
עלות הגודל, ולמה קיים ריפוד
Base64 תמיד מגדיל את הנתונים, בכ-33% צפוי: הוא ארוז נתונים לקבוצות של 6 סיביות במקום בייטים של 8 סיביות, כך שכל 3 בייטים של קלט (24 סיביות) הופכים ל-4 תווי פלט (24 סיביות, כי 4 כפול 6 שווה 24) - הרחבה פשוטה של 4-תמורת-3. כשאורך הקלט אינו כפולה מדויקת של 3 בייטים, הקבוצה האחרונה מרופדת בתו = אחד או שניים כדי שכל בלוק מקודד יישאר באורך עקבי; הריפוד הזה הוא סמן גבול בלבד ואינו נושא מידע על הנתונים המקוריים. התקורה הזו היא הסיבה שקידוד Base64 לקבצים גדולים לתעבורה (במקום שליחתם כבינארי גולמי) נמנע בדרך כלל אלא אם ערוץ טקסט בלבד באמת נדרש.
א"ב סטנדרטי מול בטוח-ל-URL
הא"ב הסטנדרטי בן 64 התווים של Base64 כולל + ו-/, ששניהם כבר בעלי משמעות שמורה בתוך URL (רווח ומפריד נתיב, בהתאמה), כך שמחרוזת Base64 סטנדרטית שמוכנסת ישירות ל-URL עלולה לשבור את הפירוש או לדרוש percent-encoding נוסף מעליה. הגרסה הבטוחה ל-URL מחליפה את שני התווים האלה ב- - ו-_, שאין להם משמעות מיוחדת ב-URL, ובמקובל מסירה לגמרי את ריפוד ה-=, מה שהופך אותה לבחירה הנכונה ספציפית ל-Base64 שיחיה בתוך נתיב URL, פרמטר query, או שם קובץ - לא ל-Base64 בגוף JSON או מייל, שבהם הא"ב הסטנדרטי הוא הנורמה.
שאלות נפוצות
- האם קידוד סיסמה או מפתח API ב-Base64 מוסיף הגנה אמיתית?
- לא - זה מוסיף אפס אבטחה, רק עירפול הפיך. כל מי שיש לו את המחרוזת המקודדת יכול לשחזר את המקור תוך שניות ללא צורך במפתח כלשהו, אז אסור להסתמך על זה כתחליף להצפנה, hashing, או אבטחת תעבורה כמו TLS.
- למה פלט Base64 תמיד באורך כפולה של 4 תווים?
- כי הקידוד עובד בקבוצות קבועות של 3 בייטים בכניסה ו-4 תווים ביציאה, ותווי ריפוד משלימים כל קבוצה שמתחילה עם פחות מ-3 בייטי קלט - כך שאורך הפלט הכולל תמיד מתחלק ב-4 (אלא אם הריפוד הוסר, כמו בא"ב הבטוח ל-URL).
- האם Base64 זהה לדחיסה?
- לא, ולמעשה זה עושה את ההפך - Base64 מגדיל את הגודל בכשליש במקום להקטין אותו. הוא פותר בעיית תאימות (הפיכת נתונים בינאריים לבטוחים לערוצי טקסט בלבד), לא בעיית גודל; אם הגודל חשוב, דחוס קודם, ואז קודד ב-Base64 את התוצאה הדחוסה אם עדיין נדרש פורמט בטוח-לטקסט.
- האם כל קובץ בינארי אפשר לקודד ב-Base64, או רק תמונות?
- כל נתונים בינאריים בכלל - תמונות, PDF, קבצי הרצה, גופנים, בלובים מוצפנים. Base64 פועל על בייטים גולמיים ללא כל מודעות לסוג הקובץ; המקודד לא צריך ולא משתמש במידע כלשהו על מה שהבייטים מייצגים.