PSD2: การตรวจสอบลูกค้าที่แข็งแกร่งในสหภาพยุโรป

นี่เป็นชุดที่สองของโพสต์สามส่วนที่มีรายละเอียด PSD2: การรับรองความถูกต้องของลูกค้าที่แข็งแกร่งในสหภาพยุโรป (SCA)

ในงวดแรกของชุดข้อมูลสามส่วนนี้ เราได้แนะนำคำสั่ง European Banking Authority (หรือ EBA) ของสหภาพยุโรปที่เรียกว่า PSD2 (ย่อมาจาก The Second Payment Services Directive) และสรุปหลักเกณฑ์บางประการของการตรวจสอบสิทธิ์ลูกค้าอย่างเข้มงวด (หรือ SCA) .

EBA กล่าวถึง SCA: “ต้องขอบคุณ PSD2 ที่ผู้บริโภคจะได้รับการคุ้มครองที่ดีขึ้นเมื่อพวกเขาทำการชำระเงินทางอิเล็กทรอนิกส์หรือการทำธุรกรรม (เช่น การใช้ธนาคารออนไลน์หรือการซื้อทางออนไลน์) ตามที่ระบุไว้ในส่วนที่ 1 มาตรฐานทางเทคนิคด้านกฎระเบียบ (RTS) ทำให้การรับรองความถูกต้องของลูกค้า (SCA) ที่เข้มงวดเป็นพื้นฐานสำหรับการเข้าถึงบัญชีการชำระเงินของตน เช่นเดียวกับการชำระเงินออนไลน์”

ในโพสต์นี้ เราจะสำรวจข้อจำกัดของ SCA และหน่วยงานกำกับดูแลที่ผู้ดำเนินการต้องพิจารณา ขั้นแรก ให้ดูที่รหัสรับรองความถูกต้องที่สร้างขึ้น จำไว้ว่านี่คือการรับรองความถูกต้องด้วยสองปัจจัยหรือ 2FA

RTS สรุปเงื่อนไขต่อไปนี้สำหรับรหัสการตรวจสอบสิทธิ์:

• ไม่สามารถรับข้อมูลเกี่ยวกับความรู้ การครอบครอง และมรดกได้จากการเปิดเผยรหัสรับรองความถูกต้อง ซึ่งหมายความว่าถ้าคุณรู้รหัสรับรองความถูกต้อง ไม่มีทางที่จะรับความรู้อื่นใด (เช่น ID ผู้ใช้) สิ่งที่ผู้ใช้มีอยู่ในมือของเขา (เช่น โทรศัพท์มือถือ – หมายความว่าคุณไม่สามารถรับหมายเลขโทรศัพท์มือถือได้) หรือการสืบทอด – แง่มุมเกี่ยวกับตัวผู้ใช้เอง เช่น ไบโอเมตริก
• เป็นไปไม่ได้ที่จะสร้างรหัสรับรองความถูกต้องใหม่ตามความรู้ของรหัสรับรองความถูกต้องอื่นใดที่สร้างไว้ก่อนหน้านี้ สำหรับเงื่อนไขนี้ เมื่อได้รับรหัสการพิสูจน์ตัวตน ไม่มีทางที่จะสร้างรหัสการพิสูจน์ตัวตนใหม่โดยอ้างอิงรหัสการพิสูจน์ตัวตนก่อนหน้าหนึ่งหรือหลายรหัส
• รหัสการตรวจสอบไม่สามารถปลอมแปลง ได้ ผู้ดำเนินการต้องสร้างรหัสการตรวจสอบสิทธิ์เพื่อไม่ให้ตรวจสอบรหัสปลอมหรือรหัสปลอมได้สำเร็จ
• ไม่ควรพยายามตรวจสอบความถูกต้องที่ล้มเหลวมากกว่า 5 ครั้งภายในระยะเวลาที่โค้ดใช้งานได้ แต่ละรหัสที่สร้างขึ้นจะมีเวลาหมดอายุหรือ “เวลาที่จะมีชีวิตอยู่” ตัวจับเวลานี้เริ่มต้นทันทีหลังจากสร้างรหัสและรวมเวลาจัดส่ง หลักการทั่วไปที่ดีคือรหัสจะหมดอายุภายใน 15 นาทีหรือน้อยกว่านั้น บางองค์กรใช้เวลาถึง 30 นาทีหรือ 1 ชั่วโมง แต่อาจนานเกินไป หากผู้ใช้พยายามตรวจสอบสิทธิ์ด้วยรหัสและล้มเหลว 5 ครั้ง จะต้องส่งรหัสใหม่ วิธีนี้จะช่วยป้องกันไม่ให้มีความพยายามอย่างดุเดือดในการค้นหารหัส
• เวลาสูงสุดที่ไม่มีกิจกรรมโดยผู้ชำระเงินหรือผู้ใช้หลังจากผ่านการตรวจสอบสิทธิ์ในการเข้าถึงบัญชีการชำระเงินทางออนไลน์แล้วจะต้องไม่เกิน 5 นาที นี่คือตัวจับเวลาการไม่ใช้งานมาตรฐาน และแม้ว่าจะแยกจากรหัสการตรวจสอบความถูกต้อง มันเป็นตัวจับเวลาที่เริ่มต้นเมื่อผู้ใช้ได้รับการพิสูจน์ตัวตนสำเร็จและไม่ดำเนินการใดๆ

ทั้งหมดนี้เป็นเงื่อนไขที่ค่อนข้างเป็นมาตรฐานสำหรับการสร้าง/การตรวจสอบความถูกต้องของรหัสการพิสูจน์ตัวตนที่ใช้ในสถานการณ์ 2FA

ตอนนี้ มาดูข้อกำหนด RTS ที่เรียกว่าการเชื่อมโยงแบบไดนามิกของธุรกรรมกัน ธุรกรรมทางอิเล็กทรอนิกส์ทางไกล (เช่น ทำผ่านอินเทอร์เน็ต ไม่ว่าอุปกรณ์จะเป็นเดสก์ท็อปหรืออุปกรณ์พกพา) ควรมีองค์ประกอบที่ “เชื่อมโยงธุรกรรมแบบไดนามิกกับจำนวนเงินเฉพาะ (ของการชำระเงิน) และ ผู้รับเงินเฉพาะ

ข้อกำหนด SCA นี้ระบุว่าจำนวนเงินที่ชำระของธุรกรรมพร้อมกับผู้ที่จะชำระเงินนั้นควรส่งคืนให้กับผู้ใช้ในขณะที่ทำธุรกรรม 2FA

ตัวอย่างเช่น SMS ที่ผู้ใช้ได้รับจะตรวจสอบจำนวนเงินที่ซื้อและผู้ขาย พร้อมด้วยรหัสความปลอดภัย (การตรวจสอบสิทธิ์) และข้อมูลการหมดอายุของรหัสนั้น สิ่งหนึ่งที่ควรทราบคือจำนวนเงินที่ซื้อและผู้ค้าไม่ได้รับการเข้ารหัส

อีกทางเลือกหนึ่งคือการใส่ URL พร้อมกับรหัสความปลอดภัยในข้อความ SMS URL ต้องการไปยังข้อมูลธุรกรรมที่เชื่อมโยงและเข้ารหัส ซึ่งเข้าถึงได้ผ่านบางสิ่งที่ผู้ใช้รู้ เช่นเดียวกับรหัสความปลอดภัย (ได้รับจากสิ่งที่ผู้ใช้ครอบครอง)

รหัสการตรวจสอบสิทธิ์ที่สร้างโดยแอปที่สอดคล้องกับ TOTP ของบุคคลที่สาม เช่น Google Authenticator และอื่นๆ อีกมากมายจะแยกออกจากข้อมูลการชำระเงิน/ผู้ขายโดยสิ้นเชิง ความสามารถในการเชื่อมโยงรหัสเหล่านี้กับธุรกรรมแบบไดนามิกนั้นค่อนข้างลำบาก

นอกจากนี้ แอปฟรีเหล่านี้ส่วนใหญ่อาจไม่มีมาตรการที่เหมาะสมในการสนับสนุนการเชื่อมโยงแบบไดนามิกของข้อมูลธุรกรรม และเพื่อให้แน่ใจว่าแอปเหล่านี้มีมาตรการรับมือเพื่อขัดขวางการโคลนแอป ตลอดจนการเจลเบรกและการตรวจจับรูท ที่กล่าวว่ามี SDK และ API พิเศษบางอย่างที่สามารถให้มาตรการตอบโต้เหล่านี้กับแอพมือถือที่เข้ากันได้

ซึ่งหมายความว่ารหัสการตรวจสอบความถูกต้องที่สร้างโดยแอปที่สอดคล้องกับ TOTP ของบุคคลที่สาม เช่น Google Authenticator นั้นถูกสร้างขึ้นแยกจากข้อมูลการชำระเงิน/ผู้ขาย ดังนั้นจึงไม่สามารถเชื่อมโยงแบบไดนามิกได้

ข้อกำหนด Channel Independence ระบุว่า “ผู้ให้บริการชำระเงินจะต้องนำมาตรการความปลอดภัยมาใช้ โดยองค์ประกอบใด ๆ ของการรับรองความถูกต้องของลูกค้าที่แข็งแกร่งหรือรหัสการตรวจสอบความถูกต้องนั้นถูกใช้ผ่านอุปกรณ์อเนกประสงค์ เพื่อลดความเสี่ยงที่จะเป็นผลจาก อุปกรณ์วัตถุประสงค์ถูกบุกรุก”

อุปกรณ์อเนกประสงค์อาจเป็นอุปกรณ์พกพา แท็บเล็ต หรือแล็ปท็อป อันที่จริง อาจมีสถานการณ์ที่แอปธนาคาร/การชำระเงินและแอปการตรวจสอบสิทธิ์อยู่ในอุปกรณ์เดียวกัน ในบางกรณี พวกเขาอาจเป็นส่วนหนึ่งของแอปเดียวกัน อีกทางหนึ่ง แอปการชำระเงินอาจใช้ช่องทางการตรวจสอบสิทธิ์แบบนอกแบนด์ (เช่น SMS)

ช่อง หมายถึงวิธีการโต้ตอบกับผู้ใช้ ช่องทางสำหรับการชำระเงินออนไลน์ของผู้ใช้ (หรือการเข้าถึงบัญชีการชำระเงิน) และช่องทางที่ใช้สำหรับการตรวจสอบสิทธิ์จะต้องไม่เหมือนกัน ในแง่ของการผสมผสานอุปกรณ์ที่มีอยู่ซึ่งอยู่ในตลาดปัจจุบัน ความเป็นอิสระของช่องทำให้เกิดปัญหาหลายประการ การพิสูจน์ตัวตนแบบ out-of-band ผ่าน SMS มีการใช้งานอย่างกว้างขวาง ใช้งานง่าย และเป็นที่นิยมในหมู่ผู้บริโภค อย่างไรก็ตาม มีปัญหาด้านความปลอดภัยบางอย่างที่รับรู้

นอกจากโซลูชันนอกวงเช่น SMS แล้ว อีกช่องทางหนึ่งที่ดีคือช่องทางอิสระและโซลูชันที่ใช้งานได้คือการใช้ข้อความพุชผ่านโซลูชันการตรวจสอบสิทธิ์บนคลาวด์ที่แยกต่างหากไปยังแอปตรวจสอบสิทธิ์มือถือ หรือแม้แต่แอปธนาคาร/การชำระเงิน/ผู้ค้าที่มีข้อมูลการชำระเงินเป็น รวมทั้งรหัสเฉพาะ

แอปตรวจสอบสิทธิ์แยกต่างหากที่รวมเอามาตรการรับมือที่เหมาะสม การรับข้อมูลที่เชื่อมโยงแบบไดนามิกผ่านช่องทางอิสระที่เข้ารหัสลับเป็นอีกวิธีหนึ่งที่เป็นไปได้ในการปฏิบัติตามข้อกำหนดเหล่านี้

ในส่วนที่ 3 ของชุดข้อมูลสามส่วน นี้ เราจะสรุปตัวเลือกการใช้งาน SCA บางอย่างที่ควรเป็นไปตามข้อกำหนดที่ระบุไว้ใน RTS รวมถึงตำแหน่งอื่นๆ เพื่อค้นหาข้อมูลเพิ่มเติม

โปรดติดตามฉันทาง Twitter: @wdudley2009

เรียนรู้ว่าวิกฤตสุขภาพในปัจจุบันอาจมีผลกระทบอย่างไรต่อกลยุทธ์ทางธุรกิจ การเปลี่ยนแปลงทางดิจิทัล และอนาคตของอีคอมเมิร์ซที่นี่