איך אנחנו מגנים על הסיסמאות שלך

בכתבות הקודמות דיברנו על איך HTTPS מגן על המסלול בין האפליקציה שלך לשרת שלנו, ואיך SSH מאבטח את השרת עצמו. עכשיו הגיע הזמן להציץ פנימה לשרת — איך Splync שומרת על הסיסמה שלך כשהיא מגיעה לשם. אם מישהו היה משיג את הסיסמה שלך, הוא יכול היה להיכנס לחשבון שלך ולגשת למידע רגיש, כולל דוחות הוצאות. זו הסיבה ש-Splync לעולם לא שומרת סיסמאות בטקסט רגיל. במקום זאת, כל סיסמה מומרת לגרסה מוצפנת לפני שהיא נשמרת במסד הנתונים. מה זה אומר בדיוק? הצפנה היא המרה חד-כיוונית — לאחר ההמרה, אי אפשר להחזיר את הסיסמה למקורית שלה. שיטה זו היא סטנדרטית ברחבי האינטרנט, מבנקים ועד לשירותי ענן מרכזיים, ועדיין רבים אינם יודעים כיצד זה פועל בדיוק. בואו נחקור את זה דרך אנלוגיה יומיומית פשוטה.

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

SHA-256 הוא אחד האלגוריתמים הנפוצים ביותר להצפנה. לדוגמה, הוא מצפין את הסיסמה "splync1234" ל-“9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41”. במילי-שניות, בכל פעם שמשתמש קיים מכניס סיסמת כניסה, SHA-256 תמיד מייצר את אותה סיסמה מוצפנת. האפליקציה פשוט מצפינה מחדש את הסיסמה המוכנסת ובודקת אם היא תואמת להצפנה השמורה. בשום שלב המערכת לא יודעת את הסיסמה המקורית של המשתמש. אבל מה אם תוקף מחשב מראש רשימת סיסמאות נפוצות וההצפנות שלהן (מה שנקרא התקפת לוח קשת) כדי לנחש סיסמאות במהירות? זהו חשש אמיתי. זו הסיבה שמערכות מודרניות, כולל Splync, אינן מסתמכות על SHA-256 פשוט.

Bcrypt משתמש במלח אקראי לכל משתמש ומקודד את המלח (וגם את גורם העלות) ישירות במחרוזת ההצפנה השמורה. תחשבו על bcrypt כעל בלנדר עם תבלין סודי (מלח) ומנוע איטי (גורם עבודה) — זה עושה כל תערובת ייחודית וקשה להעתקה. מכיוון שהמלח הוא 128 ביטים (≈3×10³⁸ אפשרויות), אותה סיסמה יכולה להתאים למספר אסטרונומי של הצפנות שמורות שונות. זה הופך לוחות קשת מחושבים מראש לחסרי תועלת בקנה מידה. במהלך כניסה, Splync קוראת את המלח והעלות ממחרוזת bcrypt השמורה, מריצה שוב את bcrypt על הסיסמה שהוכנסה עם אותם פרמטרים ומשווה את התוצאה להצפנה השמורה. אם הן תואמות, הסיסמה נכונה — אבל מכיוון ש-bcrypt איטי בכוונה והמלחים הם ייחודיים, התקפות כוח גס הופכות להרבה יותר יקרות לתוקף.

בואו נראה איך זה נראה בפועל. אם תצפינו את הסיסמה "splync1234" עם bcrypt (באמצעות עלות 12), ייתכן שתקבלו מחרוזת כזו: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. במחרוזת bcrypt זו, `$2b` מסמן את גרסת האלגוריתם, `$12` מציין את גורם העלות (כמה פעמים הסיסמה מעובדת), `gBeouKYdue9uvvuV0HtGgeV` הוא המלח האקראי הייחודי, ו-`PymnrojMqP/wcRw28HFlGEGIQbyw7O` היא הסיסמה המוצפנת הסופית. מכיוון שההצפנה עצמה מכילה את המלח והעלות, Splync יכולה לשחזר את אותו תהליך הצפנה לאימות על ידי חילוץ הערכים האלו מהמחרוזת השמורה והשוואת התוצאה. מצד שני, אם לתוקף אין את המלח והעלות, הוא לא יכול לבנות לוח קשת אחד שמתאים לכל משתמש.

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