สร้าง HMAC เซ็น signature

เพราะ HMAC ไม่ได้ทำงานกับตัวอักษร แต่ทำงานกับไบต์ของกุญแจ สมมติ gateway ให้กุญแจมาเป็นเลขฐานสิบหก 64 ตัว ถ้าเราเอาไปใช้แบบข้อความ สิ่งที่เข้าอัลกอริทึมคือ 64 ไบต์ของตัวอักษร 0 ถึง f ไม่ใช่ 32 ไบต์ที่เจ้าของกุญแจหมายถึง ค่า signature ที่ได้จะผิดทั้งหมด แต่หน้าตายังดูปกติดีทุกอย่าง จึงไม่มีอะไรบอกว่าผิดตรงไหน เครื่องมือทั่วไปที่ไม่มีตัวเลือกนี้คือสาเหตุที่หลายคนนั่งไล่โค้ดทั้งวันแล้วไม่เจอ ถ้าเอกสารเขียนว่ากุญแจเป็น hex หรือ Base64 ให้กดเลือกให้ตรงเสมอ ถ้าเอกสารไม่ได้บอกอะไรเลย แปลว่าเป็นข้อความธรรมดา (UTF-8)

2C2P ใช้ HMAC-SHA256 แล้วส่งเป็นเลขฐานสิบหกตัวพิมพ์ใหญ่ ส่วน Omise ใช้ HMAC-SHA256 เป็นเลขฐานสิบหกตัวพิมพ์เล็กในเฮดเดอร์ และ LINE Messaging API ใช้ HMAC-SHA256 แล้วเข้ารหัสเป็น Base64 เครื่องมือนี้มีปุ่มตั้งค่าสำเร็จรูปของทั้งสามแบบให้กดทีเดียว สิ่งที่ต้องระวังที่สุดคือ “ข้อความที่เซ็น” ต้องเป็นข้อความดิบตัวต่อตัวตามที่เอกสารกำหนด ห้ามจัดรูป JSON ใหม่ ห้ามสลับลำดับฟิลด์ และห้ามมีช่องว่างหรือบรรทัดว่างเกินท้ายสุด เพราะทุกไบต์มีผลต่อค่าที่ออกมา

ต่างกันเรื่องความปลอดภัย การเอากุญแจมาต่อหน้าข้อความแล้วแฮชตรง ๆ เปิดช่องให้ผู้โจมตีต่อข้อมูลเพิ่มท้ายข้อความแล้วคำนวณค่าใหม่ได้โดยไม่ต้องรู้กุญแจ (เรียกว่า length extension attack) HMAC ตามมาตรฐาน RFC 2104 แก้ปัญหานี้ด้วยการแฮชสองรอบ โดยผสมกุญแจกับค่าคงที่คนละชุดในแต่ละรอบ ระบบรับชำระเงินและ webhook จึงกำหนดให้ใช้ HMAC ไม่ใช่แฮชเปล่า ๆ และด้วยเหตุผลเดียวกันนี้ HMAC-MD5 กับ HMAC-SHA-1 ยังถือว่าใช้ได้อยู่ในทางปฏิบัติแม้ตัวแฮชเปล่า ๆ จะถูกเจาะไปแล้ว แต่ถ้าเลือกเองได้สำหรับงานใหม่ ให้ใช้ SHA-256 เป็นค่ามาตรฐาน

ไม่ถูกส่งไปไหนเลย การคำนวณทั้งหมดเกิดขึ้นในเบราว์เซอร์ของคุณด้วยจาวาสคริปต์ ไม่มีการอัปโหลด ไม่เข้าคิว ไม่นับโควตา และใช้ได้ไม่จำกัดจำนวนครั้ง ปิดหน้าเว็บเมื่อไหร่ทั้งกุญแจและข้อความก็หายไปพร้อมกัน ไม่มีอะไรค้างอยู่ที่เรา ข้อนี้สำคัญเป็นพิเศษกับเครื่องมือ HMAC เพราะกุญแจที่ใช้เซ็น payment gateway คือกุญแจที่สั่งเงินได้จริง ไม่ควรวางลงเว็บที่ส่งข้อมูลขึ้นเซิร์ฟเวอร์เด็ดขาด