ברקודים מסתובבים

מבוא

קודי מ barras בתנועה נראים כמו קודי מ barras רגילים, אבל הם משתנים מדי פעם, בדרך כלל כל דקה, והמסוף או הקורא מתוכנתים לקבל רק את הקוד העדכני ביותר. אמצעי האבטחה הזה מפחית את הסיכונים שקשורים לצילום מסך של ברקוד, במיוחד לגבי גניבת כרטיסים או מכירת כרטיסים לא מורשית. קודי מ barras מסתובבים יכולים לשמש גם כחלופה למכשירים שלא יכולים להשתמש בתכונה 'הקשה חכמה' כי הם לא תומכים ב-NFC (חוסר בחומרה או תוכנה מושבתת).

הפניית API

פרטים טכניים על קודי מ barras מסתובבים מופיעים בקטע סוג RotatingBarcode.

דוגמה למטען שימושי

JSON 
{
  "rotatingBarcode": {
    "type": "QR_CODE",
    "valuePattern": "MyRotatingBarcode-{totp_timestamp_seconds}-{totp_value_0}",
    "alternateText": "Ticket#: 1234567890",
    "totpDetails": {
      "algorithm": "TOTP_SHA1",
      "periodMillis": "3000",
      "parameters": [
        {
          "key": "3132333435363738393031323334353637383930",
          "valueLength": "8"
        }
      ]
    }
  }
}

מנגנונים חלופיים

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

  1. הקשה חכמה: אם צוין עומס עבודה של הקשה חכמה והמכשיר תומך ב-NFC/HCE
    • הערה: המשתמש יכול לשנות את ההגדרה הזו בלחיצה על 'הצגת הקוד', וכך לאלץ את הצגת הברקוד המסתובב או הברקוד הסטטי.
  2. ברקוד מסתובב: אם צוין עומס עבודה של ברקוד מסתובב
  3. ברקוד סטטי: אם צוין עומס נתונים של ברקוד

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

שמירת תהליך העבודה

ב-Google Wallet API יש כמה תהליכים, כולל:

  • יצירת קטגוריות של מועדון לקוחות בזמן השמירה או מראש
  • שליחת האובייקטים המלאים ב-JWT, או שמירת האובייקטים מראש ולאחר מכן הפניה אליהם לפי מזהה ב-JWT
  • עדכון האובייקטים אחרי שהם נשמרו

השדה proposedBarcode תואם לכל התהליכים האלה, אבל כדי לשפר את האבטחה, מומלץ:

  • קוראים ל-API של object:insert כדי להוסיף את הכרטיס לשרת של Google Wallet, ומגדירים את הלחצן 'הוספה ל-Google Wallet' כך שיפנה לאובייקט הספציפי לפי המזהה שלו ב-JWT. כך מוודאים שה-JWT שנוצר לא כולל את המפתח הסודי של הברקוד המנווט.
  • שימוש במפתח סודי מסוג OTP שמוגדרת לו היקף של כניסה אחת
  • המפתח, אלא אם הוא מתעדכן, אמור להיות תקף למשך כל משך החיים של הכרטיס. אנחנו לא צופים שהמפתח הזה יתעדכן בתדירות כלשהי במהלך הפעולה הרגילה.

תרשים התהליך הבא ממחיש את התהליך בין הגורמים השונים בשילוב אופייני:

תרשים רצף לשימוש בקודים ברצף