แนะนำการใช้ HTTP Public Key Pinning (HPKP) เพื่อป้องกัน Certification Authority ออก TLS Certificate ซ้ำซ้อน

กระบวนการรับรอง SSL/TLS Certificate หรือ “ใบรับรองอิเล็กทรอนิกส์” (ต่อไปจะเรียกว่า TLS Certificate) จะผ่านทาง Certificate Authority หรือ “ผู้ออกใบรับรองอิเล็กทรอนิกส์” (CA)

โดยเว็บเบราว์เซอร์หรือระบบปฏิบัติการ (ต่อไปจะเรียกว่า client) จะมีรายการที่เรียกว่า Trusted Root Certification Authorities หรือ “รายการใบรับรองอิเล็กทรอนิกส์ของผู้ออกใบรับรองอิเล็กทรอนิกส์สำหรับผู้อื่น” อยู่ภายใน โดยมากมักอ้างอิงกับตัวระบบปฏิบัติการเป็นหลัก ซึ่งจะบรรจุ Root Certificate หรือ “ใบรับรองอิเล็กทรอนิกส์ลำดับชั้นบนสุด” เพื่อให้ client สามารถเชื่อใบรับรองอิเล็กทรอนิกส์ที่ได้รับรองจาก Certificate Authority เหล่านั้น (Trust any certificates issued by the Certificate Authorities)

การที่ Certificate Authority จะสามารถอยู่ในรายการดังกล่าวได้ จะต้องผ่านการตรวจสอบคุณสมบัติตามมาตรฐานจากหน่วยงาน CA/Browser Forum เพราะผู้ผลิต client ต่างๆ จะใช้ข้อมูลจาก CA/Browser Forum ในการบรรจุ Root Certificate ลงไปในซอฟต์แวร์ของตน (สมาชิกของ CA/Browser Forum)

รูปภาพจาก Root certificate

รายการ Trusted Root Certification Authorities ภายใน operating system ของ Windows

ปัญหาที่ระดับ Trusted Root Certification Authorities

จากการรับรองข้างต้น ดูเหมือนจะไม่มีปัญหาหากเครื่องของผู้รับบริการมีความปลอดภัย ไม่ถูกเพิ่มรายชื่อ Trusted Root Certification Authorities ใหม่แทรกเข้ามาได้ แต่หากพบปัญหา โดยมากมักถูกเพิ่มเข้ามาผ่านการติดตั้งซอฟต์แวร์ตัวอื่นๆ ภายหลัง ซึ่งมักจะเป็นจุดที่เจอได้ง่าย ตัวอย่างเช่น กรณีผู้ใช้โน้ตบุ๊ก Lenovo หลายรายพบว่าถูกติดตั้ง Adware มาจากโรงงาน, ดักฟังเว็บเข้ารหัส

แต่ยังมีอีกปัจจัยเสี่ยงคือ Trusted Root Certification Authorities เจ้าใดเจ้าหนึ่งในรายการที่เครื่องของผู้รับบริการถูกแฮก หรือเลินเล่อออกใบรับรองอิเล็กทรอนิกส์ของเว็บไซต์ซ้ำซ้อน จนทำให้มี TLS Certificate ที่เหมือนกับเว็บที่เราให้บริการ โดยเราที่เป็นผู้ให้บริการไม่ทราบ จึงทำให้การสื่อสารของบริการของเราสามารถถูกถอดรหัส และดักฟังได้โดยที่เรายังคงให้บริการได้เป็นปรกติ เหตุการณ์นี้ได้เกิดขึ้นแล้วกับ Google.com ผ่าน DigiNotar (รายละเอียดดูใน แฮกเกอร์สร้างใบรับรอง SSL สำหรับโดเมนของกูเกิลได้สำเร็จ, ทุกเว็บของกูเกิลเสี่ยงต่อการถูกดักฟัง) หรือ กูเกิลเตือนใบรับรองดิจิทัลปลอมจากอินเดีย มาแล้ว

Rogue-SSL-Certificate-Authority

รูปจาก What is Certificate Transparency? How It helps Detect Fake SSL Certificates

วิธีการต่างๆ ในการป้องกัน

จากเหตุการณ์ข้างต้น มีวิธีหลายวิธีในการป้องกันเหตุการณ์ดังกล่าว อย่าง การทำ DNS-Based Authentication of Named Entities (DANE) บน TLSA record ที่ระดับ DNS ร่วมกับการทำ DNSSEC แต่มีความยุ่งยากที่ต้องติดตั้งและดูแลระบบ DNS ที่มีการปรับปรุงเพื่อให้รองรับ DNSSEC และ DANE เพิ่มมากขึ้น รวมไปถึง client ก็ยังไม่รองรับเป็นการทั่วไปสักเท่าไหร่

2016-06-10_020012

แต่ก็ยังมีวิธีที่ง่ายกว่า และมีการรองรับโดยเบราว์เซอร์เจ้าใหญ่อย่าง Google Chrome และ Mozilla Firefox แล้ว คือHTTP Public Key Pinning (HPKP) เป็นกลไกที่ระบุว่าจะใช้ TLS Certificate ใดบ้าง ในการเชื่อมต่อเพื่อใช้งาน โดยจะรับรองผ่าน Certificate Authority เพียงเจ้าเดียว หรือหลายเจ้าก็ได้

รู้จัก HTTP Public Key Pinning (HPKP)

ขั้นตอนการทำงานของ HPKP คือตรวจสอบจากค่าแฮชของ TLS Certificate นั้น ว่าตรงกับที่ระบุไว้ใน HTTP Header ในครั้งแรกที่ได้เข้าใช้บริการนั้นหรือไม่ (เทคนิคที่ว่าคือ Trust on First Use หรือ TOFU) เพราะหลังจากได้ข้อมูลดังกล่าวแล้ว client จะเชื่อค่าแฮชนั้นบนระยะเวลาที่กำหนดไว้ และจะอัพเดตค่าแฮชใหม่อีกครั้ง หลังจากที่ระยะเวลาดังกล่าวสิ้นสุดลง หากในระหว่างนั้นค่าแฮชของ TLS Certificate มีการเปลี่ยนแปลงไปจากที่รับรู้มาก่อนหน้านี้ จะไม่เชื่อถือ TLS Certificate ดังกล่าว

2016-06-09_230144

วิธีการเปิดใช้งานคือ เพิ่ม header ที่ชื่อ Public-Key-Pins หรือ Public-Key-Pins-Report-Only เมื่อมีการเข้าถึงผ่าน HTTPS โดยมีรูปแบบในตัวข้อมูลดังต่อไปนี้

Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]

Public-Key-Pins-Report-Only: pin-sha256="base64=="; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]

อธิบายโค้ดแต่ละส่วน

  • pin-sha256 required
    ชุดตัวอักษรแบบ Base64 ซึ่งแปลงจากชุดตัวอักษรแฮชแบบ SHA-256 โดยข้อมูลดังกล่าวได้จาก Subject Public Key Information (SPKI) fingerprint ของไฟล์ Private Key, ไฟล์ Certificate Signing Request หรือไฟล์ Certificate (ที่ได้จาก Certificate Authority)
    หมายเหตุ ในอนาคตอาจจะใช้ชุดตัวอักษรแฮชแบบอื่นๆ นอกจาก SHA-256 ก็ได้ ขึ้นอยู่กับมาตรฐานในอนาคต
  • max-age required
    ระยะเวลาที่บอก client ว่าจะจำค่าแฮชดังกล่าวไว้นานเท่าใดหน่วยเป็นวินาที
  • includeSubDomains Optional
    เป็นชุดพารามิเตอร์ที่ไว้ระบุว่าค่าแฮชดังกล่าวรวมถึง subdomain ด้วย
  • report-uri Optional
    เป็นชุดพารามิเตอร์ที่บอกว่าหากพบการตรวจสอบแล้วผิดพลาด ให้แจ้งไปยัง URL ที่ระบุไว้ โดยจะเป็นการ POST ชุดข้อมูลเป็น JSON ในรูปแบบต่อไปนี้

    {
         "date-time": date-time,
         "hostname": hostname,
         "port": port,
         "effective-expiration-date": expiration-date,
         "include-subdomains": include-subdomains,
         "noted-hostname": noted-hostname,
         "served-certificate-chain": [
           pem1, ... pemN
         ],
         "validated-certificate-chain": [
           pem1, ... pemN
         ],
         "known-pins": [
           known-pin1, ... known-pinN
         ]
    }

    ข้อมูลเพิ่มเติมอ่านต่อที่ Reporting Pin Validation Failure

จุดแตกต่างของ Public-Key-Pins และ Public-Key-Pins-Report-Only คือ

Public-Key-Pins จะตรวจสอบค่าแฮชของ TLS Certificate หากไม่ตรงตามที่กำหนดไว้จะไม่ยินยอมให้ client เข้าใช้งาน ถ้ามีการกำหนด report-uri ไว้ จะส่งรายงานไปยัง URL นั้น

Public-Key-Pins-Report-Only จะตรวจสอบค่าแฮชของ TLS Certificate หากไม่ตรงตามที่กำหนดไว้จะรายงานไปยัง URL ที่กำหนดไว้ที่ report-uri แต่ยังยินยอมให้ client เข้าใช้งาน

เมื่อทราบองค์ประกอบของตัวชุดข้อมูลบน HTTP header แล้ว ส่วนที่สำคัญคือชุดข้อมูล Base64 ที่จะใช้ใน pin-sha256 ซึ่งจะได้จากไฟล์ Private Key, ไฟล์ Certificate Signing Request หรือไฟล์ Certificate

ชุดคำสั่งที่จะได้ค่าดังกล่าวมานั้นมีดังนี้

1. ดึงค่า Base64 จาก Private Key

openssl rsa -in private.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64

2. ดึงค่า Base64 จาก Certificate Signing Request

openssl req -in cert-signing-request.csr -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

3. ดึงค่า Base64 จาก Certificate

openssl x509 -in certificate.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

ตัวอย่างเมื่อรันคำสั่งตามข้างต้น จะได้ผลดังภาพด้านล่าง

2016-06-10_003753

ค่าที่ได้จะต้องเหมือนกันทั้ง 3 คำสั่ง แล้วนำเอาข้อมูลที่ได้ไปใส่ลงใน HTTP Header

ปรกติ ก่อนใช้ Public-Key-Pins มักจะทดสอบด้วย Public-Key-Pins-Report-Only ก่อน เพื่อไม่ให้เกิดการ block การใช้งานเกิดขึ้นหากกำหนดค่า pin-sha256 ผิดพลาด เมื่อทดสอบเสร็จแล้วจึงกำหนดค่า Public-Key-Pins อีกครั้ง แต่บางคนอาจจะกำหนด Public-Key-Pins แล้วปรับ max-age ไว้ไม่เยอะก็ได้ (ตรงนี้แล้วแต่สะดวก) แล้วจึงกำหนด max-age ที่มีระยะเวลายาวนาน 1-2 เดือน เป็นอย่างน้อยที่สุด

Public-Key-Pins: max-age=5184000; 
pin-sha256="C8XLmj2eoYs1gqjNksWfsIA89sIAKNraGspBaXU/l+4="; 
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce"

Public-Key-Pins-Report-Only: max-age=5184000; 
pin-sha256="C8XLmj2eoYs1gqjNksWfsIA89sIAKNraGspBaXU/l+4="; 
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/reportOnly"

คำแนะนำเพิ่มเติม

การมีค่า pin-sha256 เพียงค่าเดียวกัน อาจจะมีปัญหาในช่วงที่ Certificate กำลังจะหมดอายุ หรือ Private Key ชุดเก่าหลุดจนเกิดปัญหา ทำให้ต้องมีการใช้ Private Key ชุดใหม่ เราจึงควรสร้าง Private Key สำรองเพื่อใช้สำหรับต่ออายุ Certificate หรือเหตุการณ์ที่ไม่คาดคิดในอนาคตไปสัก 2-3 ชุด แล้วใส่ค่า Base64 ของ Private Key ชุดดังกล่าวที่ยังไม่ได้ถูกใช้งานลงไปพร้อมกันด้วย

Public-Key-Pins: pin-sha256="pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=";
pin-sha256="IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=";
pin-sha256="Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM="; 
max-age=5184000;
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce"

Public-Key-Pins-Report-Only: pin-sha256="pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=";
pin-sha256="IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=";
pin-sha256="Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM="; 
max-age=5184000;
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/reportOnly"

การใช้งาน HPHK ในเว็บเซิร์ฟเวอร์

พอได้ข้อมูลครบตามนี้ ก็เอาไปใส่ในเว็บเซิร์ฟเวอร์ โดยบทความจะยกตัวอย่าง 3 ตัว คือ Apache, Nginx และ IIS โดยขออ้างอิงเพียง Public-Key-Pins ส่วน Public-Key-Pins-Report-Only ก็ใส่ไปคล้ายๆ กัน ต่างกันแค่ชื่อเริ่มต้นเท่านั้น

  1. Apache – (ต้องเปิด mod_headers ด้วย) เพิ่มในส่วนของ Web Server config อาจจะใส่ในส่วนของ vhost ก็ได้
    Header always set Public-Key-Pins "pin-sha256=\"pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=\";pin-sha256=\"IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=\";pin-sha256=\"Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM=\"; max-age=5184000;report-uri=\"https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce\""
  2. Nginx – (ต้องเปิด ngx_http_headers_module ด้วย) เพิ่มในส่วนของ Web Server config อาจจะใส่ในส่วนของ vhost ก็ได้
    add_header Public-Key-Pins 'pin-sha256="pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=";pin-sha256="IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=";pin-sha256="Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM=";max-age=5184000;report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce"';
  3. IIS – แก้ไขที่ Web.config
    <httpProtocol>
     <customHeaders>
     <add name="Public-Key-Pins" value="pin-sha256=&quot;pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=&quot;;pin-sha256=&quot;IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=&quot;;pin-sha256=&quot;Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM=&quot;;max-age=5184000;report-uri=&quot;https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce&quot;" />
     </customHeaders>
    </httpProtocol>

เมื่อตั้งค่าต่างๆ เรียบร้อยแล้ว ลองทดสอบผ่านทาง SSL Server Test เพื่อดูผลว่าตัวทดสอบสามารถตรวจจับข้อมูลที่เราได้ตั้งค่าได้หรือไม่

2016-06-10_013750

2016-06-10_150936

โดยหากเจอปัญหาค่าแฮชที่ตรวจสอบไม่ตรงตามขั้นตอนข้างต้น จะขึ้นข้อความตามด้านล่างนี้ บน Google Chrome และ Mozilla Firefox (อาจจะเปลี่ยนแปลงไปบ้างในแต่ละรุ่นที่ออกมาในอนาคต)

hpkp_test_chrome

รูปจาก What is Public Key Pinning / HPKP ? 

รูปจาก About Public Key Pinning 

ส่วนในกรณีที่ใช้การเขียนซอฟต์แวร์สำหรับเชื่อมต่อผ่าน API นั้น เราสามารถใช้การตรวจสอบในลักษณะนี้ ในการตรวจสอบความน่าเชื่อถือของการเชื่อมต่อได้ด้วยการเขียนชุดคำสั่งตรวจสอบได้เช่นกัน ตัวอย่างเช่น Designing Evolvable Web APIs with ASP.NET – Chapter 15. Security โดยเราจะใช้ลักษณะ Trust on First Use ตามแบบเว็บเบราว์เซอร์ หรือจะใช้การบันทึกค่าแฮชของ TLS Certificate ไว้ในตัวซอฟต์แวร์ก็ได้ เพราะการพัฒนาซอฟต์แวร์ที่เราควบคุมสภาพแวดล้อมได้ หากบันทึกค่าแฮชไว้ภายในตัวซอฟต์แวร์ก็จะช่วยลดความเสี่ยงในเรื่อง Trust on First Use ได้

อะไรคือความเสี่ยงของ Trust on First Use?

คำตอบคือ หากในครั้งแรกที่เข้าใช้บริการ เครื่องที่เข้าใช้งานได้รับข้อมูลที่เป็นค่าแฮชปลอมบน HTTP Header ไปก่อนแล้ว วิธีการนี้ก็จะไม่สามารถตรวจสอบได้อีกต่อไปว่าจะเชื่อค่าแฮชชุดใดกันแน่ที่เป็นค่าแฮชจริง การใช้เทคนิค Trust on First Use จึงเป็นเพียงแค่ช่วยเพิ่มความสะดวกสำหรับคนใช้งานเบราว์เซอร์ทั่วไป

สุดท้าย ในปัจจุบัน (ณ วันที่ 10/6/2016) มีเบราว์เซอร์อย่าง Google Chrome และ Mozilla Firefox รองรับ และหวังว่าจะมีเบราว์เซอร์ตัวอื่นๆ ในอนาคตที่จะเพิ่มเติมการตรวจสอบนี้เข้ามาในตัวเบราว์เซอร์ น่าจะช่วยให้เราให้บริการกับลูกค้าได้ปลอดภัยมากขึ้น รวมไปถึงซอฟต์แวร์ต่างๆ ที่พัฒนาจะใช้การจดจำค่าแฮชเหล่านี้เป็นค่าเริ่มต้น เพื่อช่วยป้องกัน และควบคุมการใช้ TLS Certificate ที่เราเป็นผู้รับผิดชอบเองจริงๆ ไม่ใช่เกิดจากการสวมรอย หรือออก TLS Certificate ที่ผิดพลาดจาก Certificate Authority ที่เราไม่ได้ใช้บริการอยู่

อ้างอิงจาก

การขอข้อมูลในแอปเกินความจำเป็น และข้อมูลส่วนตัวของเรา ไม่ใช่ของนักพัฒนาแอป แม้เก็บข้อมูลไปแล้วก็ตาม

ผู้พัฒนาแอปที่มีการขอ permission จาก OS อย่าง iOS หรือ Android หรือจากบริการบนเว็บอย่าง Facebook หรือTtwitter ควรขอ permission เพียงส่วนที่จำเป็นต้องใช้ จะขอเผื่อๆ ไว้ ก็ควรยอมรับคำถามของผู้ใช้บริการด้วยว่าขอไปเผื่อทำไม จัดเก็บอย่างไร เอาไปทำอะไรบ้างอย่างชัดเจน และเป็นทางการ

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

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

แน่นอนว่า เมื่อตอบไปแบบนี้ เราก็จะเจอความคิดเห็นกลับมาเพิ่มเติมว่า “ก็เราเป็นคนกดยินยอมให้เค้าไปเอง แล้วจะบ่นอะไรอีก คงเอากลับคืนมาไม่ได้แล้ว” ซึ่งหากมองในมุมนี้ นั้นหมายถึงผู้ออกความคิดเห็นชุดนี้ มิได้ตระหนักถึงสิทธิ์ในข้อมูลส่วนบุคคลของตนเท่าใดนัก ซึ่งไม่ใช่ทุกคนที่ยอมรับได้ และเราควรสร้างความตระหนักว่า ข้อมูลส่วนบุคคลเป็นสิทธิ์ของเราที่จะให้ใครดูแล และไม่ให้ใครดูแลก็ได้ ซึ่งแอปที่ทำตามข้อเรียกร้องนี้ได้อย่าง Facebook หรือ Twitter เองมีความสามารถในการ Delete Account เพื่อลบข้อมูลส่วนบุคคลเหล่านี้ออกไปจากระบบ และบริการ social network หรือแอปรายอื่นๆ ที่มีความโปร่งใส ก็มักจะเห็นความสามารถในการ Delete Account อยู่เสมอ เพราะกฎหมายในหลายประเทศระบุให้ทำบนพื้นฐานสิทธิ์ข้างต้น หากบริการใดๆ จะแสดงออกซึ่งการควบคุมดูแลในการให้บริการที่โปร่งใส ใส่ใจต่อสิทธิ์ในข้อมูลส่วนบุคคลของผู้ใช้งาน ก็ควรจะต้องมีความสามารถดังกล่าวด้วย

สุดท้าย ในร่างกฎหมายข้อมูลส่วนบุคคลฉบับล่าสุด (เท่าที่หาได้) มีระบุไว้ชัดเจนในเรื่องราวข้างต้น และหากว่าร่างกฎหมายนี้มีการปรับแก้ และหวังว่าจะไม่มีการเปลี่ยนแปลงในส่วนนี้ มันจะถูกบังคับใช้ นั้นหมายความถึงบริการ และแอปทุกๆ ตัว ต้องรองรับการร้องขอนี้ด้วยเช่นกัน

2016-06-05_124631

หมายเหตุ
ไฟล์รูปได้มาจากส่วนหนึ่งในเอกสาร “ร่างพ.ร.บคุ้มครองข้อมูลส่วนบุคคล (ฉบับความมั่นคงดิจิทัล)”
อ้างอิงจาก http://ilaw.or.th/node/3405

ข้อมูลส่วนบุคคลเป็นสิ่งที่ควรควบคุมการเผยแพร่

จากกรณีในกระทู้ กลโกงบัตรเครดิตรูปแบบใหม่เพื่อเอาเงินจากบัตรเครดิต เข้าสู่บัญชี E-Wallet ยี่ห้อหนึ่ง ส่วนที่น่าสนใจคือ ข้อมูลบุคคลของลูกค้าหลายๆ อย่าง เป็นข้อมูลที่หาได้ไม่ยากนักตาม social network ต่างๆ บางอย่างเป็นข้อมูลที่ลูกค้าเผยแพร่โดยไม่ตั้งใจ  ตัวอย่างเช่น

  • หมายเลขบัตรประจำตัวประชาชน (อยากโชว์บัตรหน้าบัตรใหม่ หรือหลุดจากการเผยแพร่ของหน่วยงานภาครัฐ และเอกชนต่างๆ)
  • วันเดือนปีเกิด (มาพร้อมๆ กับพวกชอบโชว์บัตรประจำตัวประชาชน หรือข้อมูลที่เผยแพร่ผ่าน social network หลายๆ บริการ)
  • ที่อยู่ตามภูมิลำเนา
  • ที่อยู่ในการจัดส่งเอกสารในบริการนั้นๆ (ใบแจ้งหนี้ที่มักไม่ได้ทำลายจนอ่านไม่ได้ก่อนทิ้ง)
  • หมายเลขบัตรเครดิต (ในกรณีของบริการบัตรเครดิต ในบิลแจ้งหนี้จะมีส่วนของบาร์โค้ดที่ผ่านหมายเลขบัตรเครดิตได้อยู่)
  • วงเงินที่ใช้ในบริการนั้นๆ (ในกรณีของบริการบัตรเครดิต หรือหมายเลขโทรศัพท์มือถือ ที่มักมาพร้อมๆ กับใบแจ้งหนี้เสมอ)
  • หมายเลขโทรศัพท์ที่ใช้ผูกกับบริการนั้นๆ 

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

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

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

multi-factor authentication ด้วย OTP ก็ไม่ได้ปลอดภัย 100% หากโดน intercept หมายเลขโทรศัพท์มือถือ

บริการต่างๆ ที่ให้เปิด multi-factor authentication มีจุดที่สำคัญที่มักจะให้เราจดจำ และตั้งค่าเพิ่มเติม นั้นคือ backup code และหมายเลขโทรศัพท์มือถือสำหรับรับ reset password หากตัว authenticator ใช้งานไม่ได้

แน่นอน backup code ซ่อนและเก็บได้ ตรงนี้น่าจะพออุ่นใจบ้างหากเก็บไว้ในที่ที่ลับมากๆ ส่วนหมายเลขโทรศัพท์มือถือนั้นแตกต่าง เพราะอาจโดน intercept ตัวเบอร์โทรศัพท์นั้นๆ แล้วนำ code ที่ได้จาก OTP ไปใช้งาน

ซึ่งเมื่อเร็วๆ นี้นักเคลื่อนไหวทางการเมืองถูก hack บัญชี Telegram โดยเกิดจากถูก intercept หมายเลขโทรศัพท์ เพื่อรับรหัส OTP สำหรับเข้าใช้งาน account แอพ Telegram ของเค้า ซึ่งเป็นสิ่งที่เกิดขึ้นได้จริงแล้ว

เพราะโดยปรกติ Telegram ไม่มีการให้ตั้งรหัสผ่านในครั้งแรก แต่ใช้การส่งรหัส OTP เพื่อยืนยันการใช้งานผ่านหมายเลขโทรศัพท์มือถือที่ลงทะเบียนไว้ อ้างอิง Is Telegram Really Safe for Activists Under Threat? These Two Russians Aren’t So Sure.

ทางแก้ที่ Telegram แนะนำ ณ ตอนนี้คือตั้งรหัสผ่านเพิ่มเข้ามาช่วยในการยืนยันตัวตน (ในเมนูของ Telegram มีให้ตั้ง) ทางแก้ไขนี้รวมไปถึง คำแนะนำที่ว่า ควรสื่อสารด้วย secret chat (end-to-end encryption) และตรวจสอบ fingerprints (encryption key) ของคนที่กำลังคุยด้วยเสมอ

จากเหตุการณ์ของ Telegram นี้ ก็กลับมาดูที่ประเทศไทยของเรา การออกซิมการ์ดใหม่ผ่านช่องทางที่มีการตรวจสอบไม่รัดกุม อาจจะเป็นช่องทางที่การใช้งาน multi-factor authentication ด้วย OTP นั้นมีจุดโหว่ และสร้างความไม่มั่นใจต่อหมายเลขโทรศัพท์ที่จะใช้งานควบคู่กับ multi-factor authentication ว่าจะอยู่รอดปลอดภัยได้มากแค่ไหน ตรงนี้เป็นสิ่งที่ผู้ให้บริการต้องตระหนักและช่วยเหลือผู้ใช้งานให้ได้รับความปลอดภัยสูงสุด

ตู้ Service Vending ออก SIM ไม่มีขั้นตอนยืนยันตัวตนที่รัดกุม เบอร์มือถือที่แจ้งรับ OTP จาก internet banking มีความเสี่ยง

อัพเดทเพิ่มเติม 4/5/2016 19:25
1. ทาง blognone.com ได้ติดต่อสอบถามกับทาง AIS เพื่อแจ้งปัญหาแล้ว และมีจดหมายชี้แจ้งมาแล้วเช่นกัน
2. ผมได้รับการติดต่อจากทาง PR ของ AIS เป็นการส่วนตัวเพื่อแจ้งให้ทราบว่า ทาง AIS กำลังปรับปรุงขั้นตอนเหล่านี้ให้รัดกุมมากขึ้น

เมื่อวันเสาร์ผมเจอประเด็นน่าสนใจในงาน MiSS Day เรื่องขอ SIM card ใหม่จากตู้ Service Vending (ตู้ออก SIM card อัตโนมัติมีคนรีวิวไว้เผื่อนึกภาพไม่ออก) ของค่ายมือถือรายหนึ่ง (ในงานไม่ได้ระบุว่าค่ายไหน) แต่แน่นอน ผมจำค่ายดังกล่าวได้ เพราะโฆษณาไว้นานพอสมควร โดยระบุไว้ว่า เพียงแค่เสียบบัตรประชาชนก็ออก SIM card ใหม่ได้เลย ซึ่งทางวิทยากรมองว่า เป็นช่องโหว่ที่สามารถขโมยหมายเลขโทรศัพท์มือถือของเราได้ง่ายมากหากบัตรประชาชนผู้ใช้งานถูกขโมย หรือสูญหาย รวมไปถึงหากผู้ใช้งานเป็นเป้าหมายในในการแฮกระบบอื่นๆ ก็อาจเป็นช่องทางที่จดขโมยช่องทางรับ OTP ของบริการอย่าง internet banking หรือบริการ online ที่ใช้ความสามารถยืนยันตัวหลายหลายปัจจัย (2-factor authentication) ที่ใช้หมายเลขโทรศัพท์ดังกล่าวในการผูกระบบ OTP กับเบอร์มือถือนั้น ซึ่งถือเป็นสิ่งที่ซีเรียสมาก

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

เมื่อเป็นเช่นนั้น คำแนะนำในตอนนี้สำหรับทุกคนที่ใช้ค่ายมือถือดังกล่าวในการรับ OTP เพื่อทำธุรกรรมทางการเงิน หรือบริการออนไลน์ต่างๆ ควรเก็บบัตรประจำตัวประชาชนของท่านไว้ให้ดี เพราะบัตรประชาชนที่ใช้กับตู้ดังกล่าว ไม่ได้ใช้การยืนยันความเป็นเจ้าของบัตรผ่านรหัส PIN แบบเดียวกับบัตรเครดิตหรือบัตรเอทีเอ็ม ทำให้เพียงแค่มีบัตรประชาชนก็เพียงพอในการออก SIM card ได้ทันทีตามที่ได้กล่าวข้างต้น ซ้ำร้ายกว่านั้น การที่ไม่มีการยืนยันความเป็นเจ้าของบัตรผ่านรหัส PIN แม้ว่าจะมีการแจ้งหายกับทางเจ้าหน้าที่ตำรวจไว้ ก็ไม่มีระบบอายัดบัตรดังกล่าวที่สามารถทำให้บัตรที่สูญหายไปนั้น ระงับการใช้งานผ่านบัตรดังกล่าวได้แบบเดียวกับบัตรเครดิตหรือบัตรเอทีเอ็ม นั้นหมายความว่า ณ ตอนนี้เราไม่สามารถปิดการใช้งานบัตรที่สูญหาย และสามารถนำบัตรนั้นไปออก SIM card ได้แม้จะมีการแจ้งความหมายและออกบัตรใหม่ไปแล้วก็ตามที

อ้างอิง