4 คะแนน โดย GN⁺ 2024-09-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้ใช้บางส่วนแทนที่จะจดจำหรือจัดการรหัสผ่าน กลับใช้ขั้นตอน “ลืมรหัสผ่าน” ทุกครั้งเหมือนเป็นวิธีล็อกอิน
  • โฟลว์จริงคือรับลิงก์กู้คืนทางอีเมลจากหน้าล็อกอิน ใส่รหัสผ่านชั่วคราว แล้วเมื่อเข้ามาครั้งถัดไปก็ทำขั้นตอนเดิมซ้ำ
  • พฤติกรรมนี้ไม่ได้เป็นกลยุทธ์ด้านความปลอดภัยที่ตั้งใจไว้ แต่ใกล้เคียงกับ พฤติกรรมที่เรียนรู้มา ซึ่งฝังตัวแน่นขึ้นตามเวลา
  • แนวทางปรับปรุงอย่าง password manager และการยืนยันตัวตนแบบ 2 ขั้นตอนหรือหลายปัจจัย อาจทำให้ผู้ใช้รู้สึกว่าเป็น แรงเสียดทานที่เพิ่มขึ้น มากกว่าการเพิ่มความปลอดภัย
  • การออกแบบระบบจำเป็นต้องตั้งอยู่บนสมมติฐานว่าผู้ใช้จะมีพฤติกรรมซ้ำ ๆ และชักนำให้ย้ายไปสู่วิธีใช้งานที่ดีกว่าได้อย่างเป็นธรรมชาติ

การกู้คืนรหัสผ่านที่ถูกใช้เหมือนการล็อกอิน

  • ผู้ใช้บางส่วนเมื่อเข้าสู่ระบบบัญชีออนไลน์ จะไม่ใส่รหัสผ่าน แต่ทำ ขั้นตอนกู้คืน ซ้ำทุกครั้ง
    • มาถึงหน้าล็อกอิน
    • คลิก “I forgot my password”
    • ไปที่อีเมล
    • คลิกลิงก์กู้คืน
    • ใส่รหัสผ่านชั่วคราวที่ไม่ได้ตั้งใจจะจำ
    • จากนั้นก็ทำขั้นตอนเดิมซ้ำอีก
  • เมื่อถามว่าทำไมจึงทำเช่นนั้น บางคนตอบไม่ได้ หรือบอกว่าไม่เคยคิดถึงเหตุผลมาก่อน
  • พฤติกรรมนี้ไม่ใช่กลยุทธ์การล็อกอินที่ตัดสินใจเลือกในตอนเช้า แต่ใกล้เคียงกับ ขั้นตอนที่ทำซ้ำ ซึ่งฝังตัวแน่นขึ้นตามเวลา

แรงเสียดทานที่การปรับปรุงความปลอดภัยสร้างให้ผู้ใช้

  • วิธีนี้ทำหน้าที่เป็น ทางออกที่ใช้ความพยายามต่ำ เพราะผู้ใช้ไม่ต้องจำวลีรหัสผ่าน
  • password manager, การขโมยตัวตน, การยืนยันตัวตนแบบ 2 ขั้นตอนและหลายปัจจัย รวมถึงความล้าสมัยของวิธีชื่อผู้ใช้/รหัสผ่าน ล้วนเป็นหัวข้อที่ถูกพูดถึงกันอย่างกว้างขวางแล้ว
  • ขั้นตอนด้านความปลอดภัยที่ดีกว่ามักเพิ่มอุปสรรคและแรงเสียดทาน ทำให้ผู้ใช้ยอมรับได้ยากโดยธรรมชาติ
  • ผู้ออกแบบควรคำนึงถึง พฤติกรรมที่เรียนรู้มา ของผู้ใช้ และสร้างโฟลว์ที่ช่วยให้ค่อย ๆ ย้ายไปสู่วิธีใช้งานที่ดีกว่าเมื่อเวลาผ่านไป

1 ความคิดเห็น

 
GN⁺ 2024-09-09
ความคิดเห็นบน Hacker News
  • บัญชีอีเมลคือจุดร่วมที่แพร่หลายที่สุดในการยืนยันตัวตนออนไลน์ โทรศัพท์มือถือก็มีความสามารถในการแข่งขันอยู่ แต่ทำหายได้ ส่วนหมายเลขโทรศัพท์นั้นพบได้ทั่วไปกว่าและอยู่กับเรานานกว่า แต่ระดับความปลอดภัยต่ำกว่าบัญชีกับผู้ให้บริการอีเมลรายใหญ่มาก
    ถ้าจะออกแบบ “ระบบยืนยันตัวตนในจินตนาการสำหรับอินเทอร์เน็ต” ต้องเริ่มดูจาก การกู้คืนบัญชี ก่อน ถ้าคำตอบเมื่อทำ authenticator สุดเจ๋งหายคือ “ก็เข้าไม่ได้แล้ว” หรือ “ให้คณะเพื่อนร่วมงานรับรองตัวตนให้” ระบบนั้นจะใช้ได้ก็ต่อเมื่อผู้ใช้ไม่ใช่มนุษย์ แต่เป็นสิ่งมีชีวิตทรงปัญญาในจินตนาการ

    • นี่เป็นเหตุผลใหญ่ที่สุดที่ผมคัดค้าน บล็อกเชน/คริปโทเคอร์เรนซี มาหลายปี วิธีแบบ “ถ้าทำคีย์หาย ก็เสียกระเป๋าเงินไปด้วย” โดยพื้นฐานแล้วไม่เข้ากับผู้ใช้ในโลกจริง
      มนุษย์ต้องสามารถกู้คืนจากความผิดพลาดได้
    • บัตรประจำตัวดิจิทัลที่รัฐบาลออกให้อาจแก้ปัญหาส่วนใหญ่ในเรื่องนี้ได้ แม้จะมีปัญหาในตัวเอง แต่การมอบการระบุตัวบุคคลให้รัฐบาลดูแล ดูมีคุณค่าและเสี่ยงน้อยกว่าการถูกผู้ให้บริการอย่าง Google ล็อกบัญชี
    • น่าเสียดายที่แม้แต่ผู้ให้บริการอีเมลรายใหญ่อย่าง Google รูปแบบ “ก็เข้าไม่ได้แล้ว” ก็พบได้บ่อย คนที่ทำโทรศัพท์หายหรือถูกขโมยแล้วถูกล็อกออกจากบัญชีถาวรเป็นตัวอย่างชัดเจน
    • แม้แต่ “บัญชีอีเมลกับผู้ให้บริการรายใหญ่” ก็ยังมีเงื่อนไขแฝงว่า “บัญชีถูกระงับโดยไม่มีเหตุผล ไม่มีวิธีอุทธรณ์ และไม่บอกด้วยว่าถูกระงับเพราะอะไร”
    • วิธีที่ให้คณะเพื่อนร่วมงานรับรองตัวตนของบุคคลเป็นโจทย์การออกแบบที่น่าสนใจ ถ้ามีระบบกลางที่สามารถนำความลับสำหรับการยืนยันตัวตนที่กระจายไว้อย่างเหมาะสม มาประกอบกลับได้ตามคำสั่งของฝ่ายที่เกี่ยวข้อง ก็น่าจะทำให้ค่อนข้างลื่นไหลได้
      จะทำให้ใช้ได้กับมนุษย์ทั่วไปด้วยไหม? ผมคิดว่าเรามีความคิดสร้างสรรค์พอที่จะออกแบบได้
  • บริการของเราเป็นธุรกิจที่ค่อนข้างเบา ๆ ผู้ใช้จึงใช้บัญชีเพื่อความสะดวกเท่านั้น วิธีที่ลงตัวคือแบบนี้: ผู้ใช้กรอกอีเมล เราส่งรหัสยืนยันไปทางอีเมล และเมื่อผู้ใช้กรอกรหัส ก็ออกคุกกี้อายุยาวมากที่ทำให้ ล็อกอินได้แทบไม่มีกำหนด
    ไม่สำคัญว่าจะมีบัญชีเดิมหรือไม่ ถ้าเป็นอีเมลใหม่ก็สร้างบัญชีใหม่ได้ บางครั้งผู้ใช้ที่มีหลายอีเมลเผลอสร้างบัญชีใหม่ แต่ conversion rate ของการสมัครและล็อกอินดีขึ้นมากจนคุ้มที่จะรับได้ อายุของรหัสและจำนวนครั้งที่ลองต้องมีการวิเคราะห์ความเสี่ยง และถ้าเป็นไปได้ควรใช้กลไกการล็อก ถ้าบริการไม่ได้สำคัญมากนัก ขอแนะนำกลยุทธ์นี้ ตอนนี้ iOS Mail ก็รองรับวิธีนี้แล้วเหมือนฟีเจอร์รหัสใช้ครั้งเดียวใน Messages ทำให้ค่อนข้างสะดวกสำหรับผู้ใช้บางส่วน

    • จากข้อมูลที่ผมเคยเห็น วิธีนี้ดีอย่างท่วมท้นในการเพิ่ม ยอดขายอีคอมเมิร์ซ ให้สูงสุด
      ไม่ต้องบังคับให้ผู้ซื้อมีบัญชี แค่ขอรายละเอียดก็พอ ยังไงเบราว์เซอร์ก็กรอกให้อัตโนมัติอยู่แล้ว จากนั้นส่งลิงก์ตรวจสถานะคำสั่งซื้อไปทางอีเมล และตอนสั่งครั้งถัดไปก็ค่อยถามอีเมลอีกครั้ง แรงเสียดทานเพิ่มเติมทำให้เสียยอดขายมากกว่าประโยชน์จากการได้ “ผู้ใช้ที่สมัครสมาชิก”
    • ผมกำลังดูแลแอป B2C ขนาดเล็กอยู่ ผู้ใช้สมัครด้วยที่อยู่อีเมลเท่านั้น และไม่มีช่องรหัสผ่านเลย บัญชีถูกสร้างขึ้น และบนอุปกรณ์นั้นจะ ล็อกอินได้ไม่มีกำหนด
      จะขอรหัสผ่านใหม่เฉพาะตอนที่ต้องล็อกอินจากอุปกรณ์อื่นเท่านั้น วิธีนี้ลดแรงเสียดทานในการสมัครและลดรหัสผ่านที่อ่อนแอ คนส่วนใหญ่แทบไม่มีเหตุให้ต้องล็อกอินจากอุปกรณ์อื่นอยู่แล้ว
    • ผมเคย implement วิธีล็อกอินแบบนี้มาหลายครั้ง และมันมาจากประสบการณ์ที่ต้องตัดสมมติฐานมากมายเกี่ยวกับว่า “บัญชีผู้ใช้” คืออะไรออกไป ถ้าจะให้ funnel ทำงานได้ตามที่ทั้งสองฝ่ายต้องการจริง ๆ ก็จำเป็นต้องทำให้เรียบง่ายแบบนี้
      ถ้าไม่ใช่พื้นที่ที่ต้องรักษาความเป็นนิรนาม ก็ทำแบบนี้ได้ แล้วค่อยผสาน passkey ภายหลัง ข้อเสียคือจะแชร์รหัสผ่านไม่ได้ ดังนั้นต้องคิดเรื่องการจัดการผู้ใช้หลายคนในบัญชีเดียวให้เร็วขึ้น แต่ถ้าจัดการอย่างตั้งใจ สุดท้าย funnel หรือประสบการณ์ผู้ใช้จะดีขึ้น อีกทั้งความปลอดภัยจะผูกอยู่กับระดับความปลอดภัยเฉลี่ยของผู้ให้บริการอีเมลของผู้ใช้ แต่โดยทั่วไปก็ดีกว่าระดับที่จำเป็น รหัสผ่านสามารถใช้เป็นปัจจัยที่สองภายหลังเมื่อจำเป็น หรือเพิ่มปัจจัยอื่นได้ และถ้าเป็น B2B ก็ไปที่ SAML หรือ OIDC ได้ทันที ใน B2B หรือ D2C วิธีนี้ใช้ได้ดีเสมอ และกรณียกเว้นก็คุ้มจะแก้เพราะประโยชน์ด้านการได้ผู้ใช้
    • ผมเคยเห็นวิธีล็อกอินแบบนี้ แล้วทำไมไม่ส่งลิงก์ในอีเมลที่พาไปหน้าแรกของแอปพร้อมสถานะล็อกอินแล้วเลยล่ะ?
      ขั้นตอนคัดลอกรหัส หาแท็บที่เปิดหน้าล็อกอินไว้ แล้ววางรหัส มันยุ่งยาก
    • ผมใช้วิธีนี้กับ แอป CRUD เล็ก ๆ ที่แทบจะเป็นฟอร์มเดียว และตลอดช่วงแคมเปญมีคำขอซัพพอร์ตเกือบเป็นศูนย์ จึงคุ้มค่ามากพอ
  • ถึงจุดนี้แล้ว ส่ง ลิงก์ URL ใช้ครั้งเดียว ไปยังที่อยู่อีเมล แล้วให้ล็อกอินด้วยการคลิกครั้งเดียวไม่ได้หรือ? ให้หมดอายุใน 10 นาทีและทิ้งหลังใช้ครั้งเดียวก็พอ
    แน่นอนว่าใครก็ตามที่มีลิงก์ก่อนก็สามารถล็อกอินเข้าบัญชีได้ แต่ยังไงก็เข้าถึงได้จากอีเมลเท่านั้น ความรู้สึกด้านความปลอดภัยที่เหนือกว่าบัญชีอีเมลจะหายไปหมด แต่ความจริงก็มาถึงจุดนั้นแล้ว ถ้าใช้แพตเทิร์นอย่าง “คลิกเพื่อยืนยันการล็อกอิน: www.someurl.com?p=134234535” ผ่านข้อความบนมือถือ ก็จะเป็นการยืนยันตัวตนสองขั้นตอนที่ไม่ต้องกรอกรหัสแบบโง่ ๆ

    • มีเว็บแอปหลายตัวที่ใช้วิธีนี้อยู่ แต่มันทำให้ผู้ใช้สับสน (“ทำไมฉันมีบัญชีอยู่แล้วล่ะ? ไม่เคยสมัครนะ!”) มีค่าใช้จ่ายด้วย (การส่งอีเมลไม่ได้ฟรี) และยังช้าอีก
      อีเมลอาจเข้าโฟลเดอร์สแปม หรืออาจล็อกอินไม่ได้เป็นชั่วโมงเพราะ greylisting หรือใช้เวลา 1 นาทีกว่าจะมาถึง ซึ่งบางครั้งแม้แค่นั้นก็รู้สึกนานเกินไป ผมไม่แน่ใจว่าจะแนะนำไหม
    • ผมเกลียดมากถ้าไซต์ที่มีแต่วิธีนี้ส่งอีเมลมาไม่ได้ภายใน 30 วินาที
      “คลิกเพื่อยืนยันการล็อกอิน” ที่ส่งไปมือถือควรให้ทั้งรหัสและลิงก์ ไม่ใช่ว่าอุปกรณ์ที่ใช้ล็อกอินจะเป็นมือถือเสมอไป ดังนั้นควรเป็น “กรอก 1234 หรือคลิก”
    • บางไซต์อย่าง Netdata ทำแบบนั้น
      แต่ช้ากว่าการที่ password manager กรอกคู่ชื่อผู้ใช้/รหัสผ่านให้อัตโนมัติ เพราะต้องรออีเมลแล้วกดลิงก์
    • ผมกำลังสร้างเว็บแอปด้วยขั้นตอนล็อกอินแบบนี้เป๊ะ และเจอปัญหาบนมือถือ แอปอย่าง Gmail ไม่ยอมให้คัดลอกลิงก์ไปยังเบราว์เซอร์โดยไม่แสดงตัวอย่าง และ ตัวอย่าง นั้นก็กินลิงก์ไปแล้ว (next.js auth)
      ผมไม่ได้อยากล็อกอินในเบราว์เซอร์ในแอปของ Gmail แต่อยากล็อกอินในเบราว์เซอร์ปกติ ซึ่งน่ารำคาญพอสมควร
    • ถ้าจะทำอย่างนั้น สู้ไปให้สุดด้วย single sign-on ดีกว่า ผู้ใช้ 95% ยังไงก็ใช้หนึ่งใน Gmail, Outlook, Apple อยู่แล้ว
      ปุ่ม “เข้าสู่ระบบด้วย Google” ดีกว่า “ส่งลิงก์ทางอีเมล” และไม่ว่าทางไหนก็ยังติดตามได้
  • แนวคิดที่ว่าคนเราจะสร้างและจำรหัสผ่านสำหรับบริการเล็ก ๆ น้อย ๆ ทุกอย่างนั้นไม่สมจริง การสร้างระบบยืนยันตัวตนแบบใช้รหัสผ่านขึ้นมาอีกระบบหนึ่งก็แทบจะเป็นการเล่นบทบาทสมมติแบบหนึ่ง
    โดยทั่วไปรหัสผ่านถูกใช้ในหนึ่งในสองรูปแบบ: ตัวจัดการรหัสผ่านที่ป้องกันด้วยรหัสผ่านจริงเพียงอันเดียว หรือรหัสผ่านเดียวกันที่ใช้ซ้ำในแต่ละบริการ เนื่องจากแทบทุกบริการมีการกู้คืนผ่านอีเมล ในทางปฏิบัติแล้ว อีเมลคือวิธีการยืนยันตัวตน อีเมลส่วนตัวแทบไม่ค่อยเปลี่ยน ไม่แชร์กับคนอื่น และไม่ได้ถูกใช้ซ้ำด้วย เป็นไปได้ว่าคุณใช้อีเมลส่วนตัวมานานกว่าเบอร์โทรศัพท์ด้วยซ้ำ ระหว่างที่ใช้ที่อยู่อีเมลปัจจุบัน เบอร์โทรศัพท์น่าจะเปลี่ยนไปอย่างน้อยห้าครั้งแล้ว และตอนนี้เบอร์เหล่านั้นก็มีคนอื่นใช้อยู่

    • ยังมีรหัสผ่านแบบอนุพันธ์ด้วย ซึ่งเป็นลูกผสมอย่างหนึ่ง อาจเป็นแพตเทิร์นที่คนจำเอง หรือเป็นเครื่องมือจัดการที่คำนวณให้ตามโดเมนก็ได้
      และอย่างน้อยฟังก์ชันลืมรหัสผ่านก็แจ้งทุกความพยายามให้เจ้าของที่อยู่ทราบ ส่วนการล็อกอินด้วยรหัสผ่านไม่ได้ส่งอีเมลทุกครั้งเสมอไปเมื่อมีการล็อกอินจากตำแหน่งใหม่
    • Apple ทำให้กระบวนการที่ “ไม่ใช่แค่กรอกรหัสผ่าน 1Password/Keychain ก็พอ แต่ต้องไปยุ่งยากกับอีเมล” ดีขึ้นมาก อย่างน้อยก็ตอนที่ระบบรู้จักอีเมลหรือข้อความแล้วกรอกโค้ดให้แทน
  • คำตอบนั้นเรียบง่าย โดยทั่วไปเกี่ยวข้องกับความไม่สะดวกที่ผู้ให้บริการสร้างไว้ให้ผู้ใช้ กรณีนี้ดูชัดเจน: เซสชันของผู้ให้บริการอีเมลมักแทบไม่มีวันหมดอายุ และจะยังล็อกอินอยู่ต่อไปตราบใดที่ไม่ได้ล้างแคชเบราว์เซอร์
    ก็แค่ทำให้โทเค็นยืนยันตัวตนของบริการตัวเองมีอายุเท่า Gmail และให้ทางเลือกในการล็อกอินด้วย รหัสผ่านใช้ครั้งเดียว ทุกครั้งก็พอ แต่ควรเลิกแนวปฏิบัตินอกรีตอย่างโทเค็นยืนยันตัวตนที่มีอายุ 12 ชั่วโมงเสียที แบบนั้นผู้ใช้ก็จะไม่กลับไปล็อกอินผ่านการกู้คืนรหัสผ่านอีก

    • เหตุผลจริง ๆ อาจเป็นเพราะเว็บไซต์เหล่านั้นทำงานไม่ถูกต้องก็ได้
      เคยมีปัญหากับบัญชี Epic และ Spotify มาก่อน สร้างบัญชีแล้วใช้ไปหนึ่งสัปดาห์ เซสชันก็หมดอายุและ Spotify ก็เตะออกจากบัญชี พอพยายามล็อกอินก็บอกว่ารหัสผ่านผิด ซึ่งเป็นไปไม่ได้เพราะบันทึกไว้ในตัวจัดการรหัสผ่าน สุดท้ายก็ต้องรีเซ็ตผ่านอีเมล ช่วงแรก ๆ แม้จะได้รับอีเมลและรีเซ็ตแล้ว แพตเทิร์นเดิมก็เกิดซ้ำ และพอผ่านไป 3–4 ครั้ง อีเมลก็ไม่มาด้วยซ้ำจนต้องสร้างบัญชีใหม่ ตอนนี้ใช้บัญชี Google ล็อกอินเข้า Spotify อยู่และยังไม่มีปัญหา แต่ถ้าใช้อีเมลทั่วไป ระบบยืนยันตัวตนของพวกเขาก็ใช้งานไม่ได้เลย
    • คิดว่านี่เป็นเบาะแสที่ใกล้ความจริงกว่า Gmail, Cloudflare และ “องค์กรความปลอดภัยสูง” อีกหลายแห่งมีเซสชันยืนยันตัวตนที่ยาวมาก เหตุผลคือความน่าจะเป็นที่มีใครสักคนเข้าถึงพีซีของผู้ใช้ระบบเหล่านี้ และผู้ใช้ไม่ได้ล็อกเอาต์ไว้นั้นต่ำมากจริง ๆ การแฮ็กส่วนใหญ่เล็งรหัสผ่านอ่อน ๆ จากระยะไกล
      ปัญหาคือเราขาดภาษาที่สอดคล้องกันสำหรับวัดความเสี่ยงและตัดสินว่า “ไซต์นี้จำเป็นต้องมีการยืนยันตัวตนสองขั้นตอนจริงหรือ?”, “เวลาเซสชัน 30 นาทีสมเหตุสมผลไหม?” ถ้ามีแอนตี้ไวรัสที่ทันสมัย คนส่วนใหญ่น่าจะอยากคงสถานะล็อกอินไว้ เคยถูกขอให้ล้างคุกกี้ทั้งหมดเพื่อแก้ปัญหาเว็บไซต์บางอย่างไหม? คำตอบของฉันคือปฏิเสธเสมอ เคยได้ยินคำพูดว่า “บัญชีเป็นของคุณ และถ้าคุณจะคงสถานะล็อกอินไว้แล้วรับความเสี่ยงที่จะถูกแฮ็ก นั่นคือความเสี่ยงของคุณ ไม่ใช่ของผู้ให้บริการ” และฉันก็เห็นด้วยมากขึ้นเรื่อย ๆ ถ้ามีใครลบอินสแตนซ์ EC2 ทั้งหมดตอนที่แล็ปท็อปของคุณยังล็อกอินอยู่ นั่นเป็นความผิดของคุณ ไม่ใช่ของ AWS ที่ไม่บังคับให้ล็อกเอาต์เร็วกว่านี้ AWS ทำได้ก็จริง แต่ทำไมต้องทำ? ไม่มีเหตุผลที่จะทำให้คนหนึ่งล้านคนหงุดหงิดเพื่อปกป้องคนประมาทหนึ่งคน
    • ถูกต้องเลย เบื่อแล้วกับแพลตฟอร์มที่ทำตัวเหมือนพี่เลี้ยงด้วย การจำกัดเซสชัน และการบังคับยืนยันตัวตนสองขั้นตอน แค่ใส่สวิตช์เปิด/ปิดไว้ในการตั้งค่าก็พอ
  • เคยเห็นไซต์ที่ตัดขั้นตอนลืมรหัสผ่านออกไป หรือถึงขั้นไม่มีรหัสผ่านเลย อีเมลคือการยืนยันตัวตน
    คือให้ใส่ที่อยู่อีเมล รับอีเมลที่มีโค้ด แล้วกรอกโค้ดเพื่อล็อกอิน เข้าใจว่าทำไมถึงทำแบบนี้ แต่ในฐานะคนที่ใช้อีเมลหลายบัญชี ผมค่อนข้างไม่ชอบ ต้องใส่อีเมลและบันทึกโน้ตไว้ในตัวจัดการรหัสผ่านเพื่อจำว่าควรใช้อีเมลไหน และมันก็เหลือเป็นรายการที่ไม่มีรหัสผ่าน

    • ความฝืดในการใช้ เมจิกลิงก์ สูงจนเคยมีครั้งหนึ่งไม่ยอมจ่ายเงินให้เว็บไซต์แบบนั้น แล้วไปหาทางเลือกแทน
      ถ้าทำระบบล็อกอินที่เหมาะสมยังไม่ได้ ก็มีโอกาสสูงว่าจะขาดความสามารถในการส่งมอบฟีเจอร์ที่สัญญาไว้ เมจิกลิงก์ตอนนี้ไม่ใช่แค่น่ารำคาญ แต่กลายเป็นตัวกรองไปแล้ว
    • ใน B2B SaaS ใช้วิธีนี้ ผู้ใช้แต่ละคนอาจล็อกอินแค่หนึ่งหรือสองครั้งในรอบ 6 เดือน ดังนั้น การล็อกอินแบบไม่ใช้รหัสผ่าน จึงได้เปรียบ
      ไม่มีภาระให้จำรหัสผ่านของบริการที่ไม่ได้ใช้บ่อย และการออนบอร์ดพนักงานในบริษัทก็ง่ายขึ้น บริษัทอัปโหลด CSV ผู้ใช้ แล้วผู้ใช้ก็เริ่มทำงานได้ทันทีโดยไม่ต้องสร้างรหัสผ่าน ยืนยันรหัสผ่าน และทำตามกฎต่าง ๆ ไม่ชอบลิงก์ในอีเมล เพราะพรีวิวของแอปมือถือหรือสแกนเนอร์ไวรัสขององค์กรอาจ “คลิก” ลิงก์ไปแล้ว
    • ผู้บริโภคที่ไม่ใช่สายเทคนิคจำนวนมากคงไม่ใช้ตัวจัดการรหัสผ่าน ถ้ามีแค่การสมัครด้วยรหัสผ่านและไม่มีเมจิกลิงก์หรือโค้ดให้ ก็เท่ากับทำให้ชีวิตยากขึ้นสำหรับผู้บริโภคส่วนใหญ่
      แม้จะมีให้ทั้งสองแบบ แต่ถ้าบังคับให้ใช้รหัสผ่านพร้อมกับตรวจอีเมลด้วย ก็น่าจะทำให้คนหลุดจากโฟลว์สมัครมากขึ้น แถมโค้ดก็เรียบง่ายกว่ามาก เพราะไม่ต้องจัดการทั้งรหัสผ่านและโฟลว์ล็อกอินด้วยอีเมลหลายแบบ
    • ไซต์ “ล็อกอินแบบแขก” สำหรับแลกเวาเชอร์เคยให้วิธีนี้ และคิดว่าเป็นกรณีใช้งานที่สมเหตุสมผลสำหรับคนที่อาจไม่อยากสร้างบัญชี
      เนื่องจากต้องผูกเวาเชอร์กับอีเมล จึงต้องยืนยันความเป็นเจ้าของด้วยการคลิกลิงก์ เผื่อภายหลังเกิดปัญหาซัพพอร์ตจากการทำเวาเชอร์หาย หากสร้างบัญชีในภายหลังก็จะเห็นเวาเชอร์ที่เคยได้รับด้วย
    • หมายความว่าไซต์ไม่ได้เก็บรหัสผ่านของฉันไว้ จึงมีเรื่องให้กังวลน้อยลง
  • หลังจากอ่านบทความนี้ ผมถึงเพิ่งรู้ว่าตัวเองกำลังใช้วิธีนี้กับ Best Buy อยู่พอดี
    ไม่ได้ตั้งใจหรอก รู้ว่ารหัสผ่านถูกต้องเพราะเก็บไว้ใน 1Password แต่ทุกครั้งที่พยายามซื้ออะไรบางอย่างบน bestbuy.com จะมีระบบ ป้องกันการยึดบัญชี อะไรสักอย่างทำงาน แล้วโกหกว่ารหัสผ่านผิด ผมเชื่อได้เต็มที่ว่าอาจเป็นปัญหาฝั่งผมเองก็ได้ อาจเป็นตัวบล็อกโฆษณาหรือการบล็อก DNS ในเครื่อง แต่พอเจอซ้ำหลายครั้ง แรงจูงใจที่จะดีบักก็หายไป แล้วก็แค่เลือกเส้นทางที่มีแรงต้านน้อยที่สุด

    • เป็นไปได้ไหมว่าเป็น ความยาวสูงสุดไม่ตรงกัน? กรณีที่ฟิลด์เปลี่ยนรหัสผ่านกับหน้าเข้าสู่ระบบมี maxlength ต่างกันนั้นพบได้บ่อยมาก
      เช่น ตอนเปลี่ยนรหัสผ่านใส่รหัสผ่าน 60 ตัวอักษร แต่หน้าเข้าสู่ระบบจำกัดความยาวสูงสุดไว้ที่ 40 ตัวอักษร พอเข้าสู่ระบบก็จะกลายเป็น “รหัสผ่านผิด” ดังนั้นตอนนี้ผมใช้นโยบายให้เก็บความยาวสูงสุดไว้ในการตั้งค่าของแอปพลิเคชัน แล้วกระจายไปยังฟิลด์รหัสผ่านทั้งหมด ลองตรวจดูแล้วก็พบว่ามีความยาวไม่ตรงกันจริง ๆ ฟอร์มตั้งรหัสผ่านมี maxlength เป็น 54 แต่หน้าเข้าสู่ระบบไม่มี maxlength ดังนั้นถ้ารหัสผ่านยาวเกิน 54 ตัวอักษร และ 1Password ไม่ได้ตัดรหัสผ่านที่บันทึกไว้ให้เหลือไม่เกิน 54 ตัวอักษรโดยอัตโนมัติ ก็จะเข้าสู่ระบบไม่ได้
  • สำหรับคนส่วนใหญ่ งานบนคอมพิวเตอร์คือการ ลองซ้ำแบบทื่อ ๆ จนกว่าจะพอใช้ได้ ซอฟต์แวร์ถูกสร้างโดยคนที่เข้าใจระบบระดับล่างอย่างละเอียด แต่ถูกสร้างมาเพื่อคนที่ไม่มีความเข้าใจแบบนั้น
    เมื่อผู้ใช้เจอแพตเทิร์นที่ใช้ได้สักครั้ง ก็จะอยู่กับมันต่อไป ตอนนี้โรงเรียนจำนวนมากใช้แท็บเล็ตในการศึกษา แนวโน้มนี้จึงยิ่งมากขึ้น คนไม่ค่อยจับความรู้สึกได้ว่าคอมพิวเตอร์ทำงานอย่างไร ส่วนใหญ่ก็ไม่ได้คิดลึก แค่มันอยู่ตรงนั้น และเมื่อคุ้นเคยกับของที่พังมาแต่เดิมอยู่แล้ว การคลิกเพิ่มอีกไม่กี่ครั้งจะเป็นเรื่องใหญ่อะไร

    • ในหมู่นักพัฒนาซอฟต์แวร์ คนที่เข้าใจสิ่งที่ตัวเองทำอย่างลึกซึ้งจริง ๆ อาจมีแค่ประมาณ 10% เท่านั้น กลับกัน เป็นเพราะนักพัฒนาเองก็ไม่เข้าใจสิ่งที่ทำอย่างถูกต้อง คนทั่วไปจึงต้องใช้ซอฟต์แวร์แย่ ๆ ด้วยการลองซ้ำ ๆ จนพอเอาตัวรอดได้
  • พูดแบบเกินจริง โฟลว์การล็อกอินก็เหมือนกัน
    A) เข้าเว็บไซต์ คัดลอกและวางสตริงสุ่มผ่านตัวจัดการรหัสผ่าน แล้วรับคำขอ TOTP ที่ส่งมาทางอีเมลเพื่อยืนยันตัวตน หรือ B) เข้าเว็บไซต์ กดลืมรหัสผ่าน รับลิงก์ล็อกอิน แล้วป้อนสตริงสุ่ม ในหลายกรณี B เร็วกว่าในทางปฏิบัติ และแทบจะไม่ช้ากว่าด้วยซ้ำ ช่องทำเครื่องหมาย “จดจำฉัน” ไม่มีผลอะไรเลย

    • ใครคัดลอกแล้ววางจากตัวจัดการรหัสผ่านกัน?
      ผมคิดว่าโฟลว์ของผมดีกว่าทั้งสองแบบ เข้าไซต์แล้ว Safari เสนอให้กรอกอัตโนมัติ ใช้ TouchID/FaceID แล้วถูกขอรหัสขั้นที่สอง ถ้าส่งมาทาง SMS หรืออีเมล Safari ก็เสนอให้กรอกอัตโนมัติ แม้เป็นแบบ TOTP Safari ก็กรอกอัตโนมัติให้ ง่ายมาก พาสคีย์ ง่ายกว่านั้นอีก เพราะไม่มีขั้นที่สองและไม่ต้องรอ SMS/อีเมล
    • TOTP ไม่ใช่สิ่งที่ควรส่งทางอีเมล แก่นของ TOTP คือการสร้างรหัสยืนยันได้เองจากเวลาปัจจุบันและค่าลับที่แชร์ไว้ล่วงหน้า
    • ถ้ามีเกรย์ลิสติง โฟลว์ B อาจใช้เวลาราว 10 นาที
    • วิธี B ทำได้ทุกที่ที่เข้าถึงอีเมลได้ และไม่ขึ้นกับว่าแอปหรือโทรศัพท์อยู่ในมือผมหรือไม่
    • เบราว์เซอร์ไม่ได้จำรหัสผ่านให้เหรอ?
  • เข้าใจแรงจูงใจได้ทันที การใช้ “ลืมรหัสผ่าน” ทำให้ไม่จำเป็นต้องจำรหัสผ่าน และก็ไม่ได้ทำให้ความปลอดภัยของบัญชีอ่อนลงด้วย เพราะเส้นทางนั้นเปิดให้นักโจมตีอยู่แล้วอยู่ดี
    บางเว็บไซต์ทำให้สิ่งนี้เป็นโฟลว์หลัก และโดยนัยก็อ้างว่าถ้าส่งปุ่มล็อกอินไปให้ใครทางอีเมลได้ ตัวรหัสผ่านเองก็ไร้ความหมาย โดยส่วนตัวผมไม่ชอบ ไม่ไว้ใจอีเมล และไม่ชอบให้มันกลายเป็น จุดล้มเหลวเดี่ยว ของบัญชีหลายสิบบัญชี ถ้าล็อกอินได้ด้วยปัจจัยที่สองอย่างเดียว นั่นก็ไม่ใช่การยืนยันตัวตนแบบ 2 ขั้นตอน ผมอยากล็อกอินด้วยรหัสผ่านโดยไม่มีตัวเลือกรีเซ็ต แต่ความจริงไม่เป็นแบบนั้น

    • ถ้าป้องกันอีเมลด้วย การยืนยันตัวตนแบบ 2 ขั้นตอน มันก็กลับมาเป็นการยืนยันตัวตนแบบ 2 ขั้นตอนอีกครั้ง