มาตราฐาน MFA ใน Authenticator

มาตราฐาน MFA ที่ใช้เป็นแบบตัวเลขเปลี่ยนแปลงไปเรื่อย ๆ ตามเวลาเดินหน้า นั้นมีหลายมาตราฐาน แต่ที่นิยมใช้มี 2 ตัวคือ TOTP และ HOTP

  1. TOTP (TOTP: Time-Based One-Time Password Algorithm) RFC 6238
  2. HOTP (HOTP: HMAC-based one-time password) RFC 4226

โดย Google Authenticator และ Microsoft Authenticator รองรับทั้ง 2 รูปแบบ และในความเป็นจริง Authenticator ทางเลือกอีกหลาย ๆ เจ้าก็รองรับ TOTP และ HOTP กันเป็นปรกติ เพราะเป็นมาตราฐานกลางอยู่แล้ว ฉะนั้นจึงไม่แปลกที่เราสามารถใช้งานข้ามยี่ห้อกันได้

รายการแอปทางเลือกเท่าที่ทราบ

  • Authy (รองรับ sync และ backup/restore)
  • FreeOTP (opensource ไม่รองรับ backup/restore)
  • FreeOTP+ (opensource ที่ folk จาก FreeOTP เพื่อให้รองรับการ backup/restore)
  • 1Password (เสียเงิน และรองรับ field OTP)
  • LastPass (เสียเงิน และรองรับ field OTP)

จริง ๆ มีแอปอีกหลายตัวลองศึกษาเพิ่มเติมและดูความเสี่ยงกันได้ โดยดูว่ารองรับ TOTP/HOTP ตามาตราฐานหรือไม่เป็นอันดับแรก

สำหรับแอป Authenticator ควรจะรองรับการ backup/restore ได้หรือไม่ ก็ยังถกเถียงกันอยู่ต่อไป แต่ผู้ใช้งานต้องยอมรับคามเสี่ยงเพิ่มเติมในการรั่วไหลของข้อมูลเพิ่มเติมหากสำรองข้อมูลอย่าง QR code หรือ secret key ของ TOTP/HOTP ไว้เพื่อเรียกคืนค่าเดิมหากต้องเปลี่ยนโทรศัพท์แล้วเจน TOTP ใน Authenticator ใหม่

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

อีกวิธีก็คือใช้ Security Key เป็นอุปกรณ์อีกตัว มันสามารถเก็บ TOTP/HOTP และเป็น FIDO U2F แทนก็ได้ เพราะปรกติการเปิดใช้งาน MFA มักจะมีทางเลือกให้อย่างน้อย 2 ทางในการใช้งาน MFA อยู่เสมอ หรือถ้ายินยอมรับความเสี่ยงที่จะใช้ตัวเดียวก็จะแจ้งเตือนไว้

หมายเหตุ แม้จะยังมีตัวเลือกให้รับ OTP ผ่านมือถือเป็นทางเลือกสำรอง แต่ในระยะหลัง ก็เริ่มไม่ปลอดภัย และหลายบริการก็แจ้งเตือนความเสี่ยงไว้แล้ว

IT Security 101 ภายในบ้าน สำหรับ IoT

ถือเป็นโน๊ตเล็ก ๆ ในการเริ่มต้นใช้งาน IoT ในบ้านสำหรับใครหลาย ๆ คนที่ห่วงเรื่อง IT Security หลังจากติดตั้ง IoT ในบ้านก็แล้วกัน อาจจะไม่ครอบคลุมทั้งหมด แต่คิดว่าหลัก ๆ น่าจะประมาณนี้ บางอย่างก็อาจจะเวอร์ไป ก็ดู ๆ ตาม ความเหมาะสม

  1. ปรับแต่ง router gateway ของบ้านให้แน่ใจว่าไม่มี port services ที่ไม่ต้องการเปิดรับ traffic จาก internet และถ้าเป็นไปได้ให้ปิดทั้งหมด
  2. ตั้งค่า username และ password ของ router gateway ที่ไม่ใช่ค่าเริ่มต้น และควรตั้งยากๆ หน่อย (แต่ก็อย่าลืมด้วยหล่ะ)
  3. Wi-Fi ในบ้านตั้งรหัสผ่านเข้าเป็น WPA2-AES เป็นอย่างน้อย และรหัสผ่านควรตั้งยาว แต่ยังพอจำได้
  4. เป็นไปได้หา managed switch แบ่ง VLAN ออกเป็นส่วน ๆ เช่น Home, IoT และ Guest เป็นต้น
  5. ทำ monitor traffic ของ IoT ที่ติดต่อกับ internet และ block การส่งข้อมูลออกในอุปกรณ์ที่ไม่ควรจะส่งข้อมูลออก internet ให้มันอยู่ใน VLAN นั้นเท่านั้นพอ หาก allow ให้ติดต่อ internet ก็เช็ค domain หรือ IP Address ก่อนติดต่อออกไป
  6. เป็นไปได้ให้แยก VLAN อุปกรณ์ที่คาดว่าจะมีความเสี่ยงเช่น NAS, NVR หรือ CCTV ไปไว้อีก VLAN ไม่ยุ่งเกี่ยวกับใครเลย เวลาเข้าให้ตั้งค่า policy ของ firewall ให้ allow เฉพาะ mac address หรือ IP Address ที่กำหนดเท่านั้นถึงจะเข้าไปดูได้
  7. ระบบ NAS, NVR หรือ CCTV ไม่ต่อ public internet ตรง ให้ VPN เข้าไปดูผ่าน Desktop หรือ Notebook ที่ทำตัวเป็น terminal เท่านั้น เพราะอุปกรณ์เหล่านี้สุ่มเสี่ยงถูกแฮก รวมไปถึงถูกควบคุมเป็น botnet ได้ง่ายมาก เพราะผู้ใช้งานมักไม่อัพเดทตัวซอฟต์แวร์ล่าสุด หรืออุปกรณ์สิ้นสุดการสนับสนุนจากผู้ผลิตแล้ว ทำให้มีช่องโหว่ใหม่ ๆ ตามมามีความเสี่ยงมากขึ้นไปอีก
  8. เป็นไปได้ ให้แยก Wi-Fi router สำหรับแขกที่มาบ้านอีกตัว ต่อเข้า port อีกช่องบน managed switch ที่กำหนด VLAN อย่างเฉพาะก่อนต่อเข้า router gateway หรือร่วมกับ network ภายในบ้าน และ block ไม่ให้ access ข้าม VLAN แต่เพื่อความสะดวก Guest อาจจะสามารถ Cast ขึ้น Chromecast ได้เมื่อจำเป็น
  9. ถ้าคิดว่าซีเรียสเข้าไปอีก กำหนดให้หากพบ mac address ที่ไม่ได้ลงทะเบียนก่อน จะไม่สามารถต่อ internet หรือเข้าถึง network ได้ด้วย

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

เพราะใครจะไปคิดว่าแค่หลอดไฟมันจะต่อ WiFi และเชื่อมเข้า internet ได้มากขึ้น ฉะนั้นเรื่อง IT Security ภายในบ้านก็สำคัญ และควรเริ่มใส่ใจ

เมื่อข้อมูลบัตรเครดิตถูกขโมยไปใช้ทำอย่างไร

เมื่อหลายวันก่อน ถูกนำข้อมูลบัตรเครดิตไปซื้อสินค้า-บริการแปลก ๆ บน APPLE.COM จำนวน 2 ยอดในเวลา 2 นาที จำนวนเงิน 3,000 บาท แต่ยังโชคดีที่บัตรเครดิตดังกล่าว มีบริการแจ้งเตือนผ่านแอปว่ามีการซื้อสินค้า-บริการแทบจะทันที ทำให้เราทราบยอดหลังจากถูกใช้งานไปแล้วไม่นาน (หลักนาที)

พอผมเห็นยอดที่ไม่ได้ใช้งานโผล่มา ก็หงุดหงิดปนงง ๆ เพราะเป็นคนใช้งานบัตรเครดิตอย่างระมัดระวังอย่างมาก ทั้งปิดบัตรเลข CVV ด้วยการติดสติ๊กเกอร์ void หรือปิดบังเดือน-ปี หมดอายุของบัตรอย่างดี แต่เอาหล่ะ โดนเข้าให้แล้วก็ต้องแก้ปัญหา

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

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

หลังจากทำเรื่องทั้งต้นทาง และปลายทางแล้วสัก 2 วันทำการ ทางผมก็ได้ SMS แจ้งจากธนาคารผู้ออกบัตรว่าเอกสารเข้าสู่ขั้นตอนตรวจสอบเอกสารแล้ว

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

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

โดยจากทั้งหมดที่กล่าวมา ผมค่อนข้างโชคดีที่โดนกับบัตรเครดิตที่มีแอปแจ้งเตือนแทบจะทันทีที่มีการตัดเงินเข้ามาในบัตร ทำให้แก้ไขปํญหาได้เร็ว ถ้าไปเจอบัตรบางใบที่กว่าจะรู้ตัวยอดก็เรียกเก็บเข้าบัตรแล้ว 3-4 วันหลังจากโดน หรือซวยหนักกว่านั้นคือจัดยอดเงินระหว่างเดือนไปแล้ว ไม่รู้จะเรื่องยาวกว่านี้ไหม

แนะนำการใช้ HTTP Strict Transport Security (HSTS) เพื่อให้เว็บเบราว์เซอร์ติดต่อผ่านช่องทางเข้ารหัสเท่านั้น

ไม่ได้เขียนเรื่องเทคโนโลยีมานาน รอบนี้เป็นบทความที่ดองมานานมาก รอบนี้เป็นบทความที่ต่อจากเรื่อง HTTP Public Key Pinning (HPKP) เพื่อป้องกัน Certification Authority ออก TLS Certificate ซ้ำซ้อน ที่เขียนไปก่อนหน้านี้

โดย HTTP Strict Transport Security (ต่อไปจะเรียกว่า HSTS) เป็นการเพิ่มประสิทธิภาพในรักษาความปลอดภัย เพื่อบอกให้เว็บเบราว์เซอร์ที่กำลังเข้ามาใช้บริการเว็บไซต์ ต้องทำงานผ่านช่องทางเข้ารหัส Hypertext Transfer Protocol Secure เท่านั้น (ต่อไปจะเรียกว่า HTTPS)

โดยจะเพิ่มชุดคำสั่งด้านล่างลงใน HTTP Header เพื่อส่งไปบอกเว็บเบราว์เซอร์

Strict-Transport-Security: max-age=expireTime [; includeSubDomains][; preload]

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

  • max-age required
    ระยะเวลาที่บอก client ว่าจะให้จำว่าควรเข้าเว็บผ่านช่องทางเข้ารหัส HTTPS นานเท่าใด โดยหน่วยเป็นวินาที
  • includeSubDomains Optional
    ระบุว่าการใช้งาน HSTS ดังกล่าวรวมถึง subdomain ด้วย
  • preload Optional
    หากในตัว domain ข้างต้น มีการเรียกใช้ข้อมูลใด ๆ ที่โหลดมาจาก domain ที่อยู่ในรายการ HSTS preload service บน browser ให้ใช้การเชื่อมต่อผ่านช่องทางเข้ารหัส HTTPS เช่นกัน โดย HSTS preload service นี้ Google เป็นคนดูแลรายชื่อ domain ดังกล่าวผ่าน https://hstspreload.org ซึ่งตอนนี้มี Browser อย่าง Chrome, Firefox, Opera, Safari, IE 11 และ Edge ที่ใช้รายการ domain ดังกล่าวใส่ลงใน browser ตัวเอง ซึ่งมักถูกแนะนำให้ใช้เสมอหากเราใช้ 3rd party อย่าง Javascript หรือ CSS ที่โหลดผ่าน CDN ต่าง ๆ

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

พอได้ข้อมูลครบตามนี้ ก็เอาไปใส่ในเว็บเซิร์ฟเวอร์ โดยบทความจะยกตัวอย่าง 4 ตัว คือ Apache, Nginx, IIS และ .NET Core

Apache – (ต้องเปิด mod_headers ด้วย) เพิ่มในส่วนของ Web Server config อาจจะใส่ในส่วนของ vhost ก็ได้

Header always set Strict-Transport-Security: max-age=31536000

หรือหากมีเพิ่มพารามิเตอร์

Header always set Strict-Transport-Security: max-age=31536000; includeSubDomains

Nginx – (ต้องเปิด ngx_http_headers_module ด้วย) เพิ่มในส่วนของ Web Server config อาจจะใส่ในส่วนของ vhost ก็ได้

add_header Strict-Transport-Security: max-age=31536000

หรือหากมีเพิ่มพารามิเตอร์

add_header Strict-Transport-Security: max-age=31536000; includeSubDomains

IIS – แก้ไขที่ Web.config

<httpProtocol>
 <customHeaders>
 <add name="Strict-Transport-Security" value="max-age=31536000" />
 </customHeaders>
</httpProtocol>

หรือหากมีเพิ่มพารามิเตอร์

<httpProtocol>
 <customHeaders>
 <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
 </customHeaders>
</httpProtocol>

ASP.NET Core 2.1 หรือมากกว่า เพิ่มเติมดังนี้

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    ...
    app.UseHsts();
    ...
}

การแก้ไขพารามิเตอร์ทำผ่าน method ชื่อ ConfigureServices ได้ตามด้านล่าง

public void ConfigureServices(IServiceCollection services)
{
    ...
    services.AddHsts(options =>
    {
        options.Preload = true;
        options.IncludeSubDomains = true;
        options.MaxAge = TimeSpan.FromDays(365);
    });
    ...
}

จากข้อมูลการใช้งาน และตัวอย่างทั้งหมด การเพิ่มเติมดังกล่าวมีประโยชน์ในการช่วยให้ผู้ใช้งาน เข้าเว็บผ่าน HTTPS ได้ปลอดภัยขึ้น หากในครั้งแรกที่เข้าเว็บได้รับ HTTP Header ข้างต้นอย่างถูกต้อง ในครั้งต่อไปตัวเว็บเบราว์เซอร์จะเข้าผ่าน URL protocal “https://” ทันที โดยไม่ต้องผ่าน “http://” อีก ทำให้ลดการถูก man-in-the-middle attacker เพื่อดังฟังข้อมูลอื่น ๆ ระหว่างการเปลี่ยนผ่านจาก URL protocal “http://” ไปยัง “https://” ได้ รวมไปถึงการโดน intercept traffic เพื่อให้เรารับ Certificate ที่ไม่ถูกต้องระหว่างการเข้าถึงหน้า HTTPS ได้

multi-factor authentication (MFA) ของ Google account และ Microsoft account ไม่บังคับใช้หมายเลขโทรศัพท์มือถือเพื่อรับ OTP ผ่าน SMS

การเปิดใช้ multi-factor authentication (MFA) ของ Google account และ Microsoft account ตอนนี้ไม่บังคับว่าจะต้องใช้หมายเลขโทรศัพท์มือถือในการรับ OTP ผ่าน SMS แล้ว

โดยแนวทางอื่นๆ ในการทำ MFA คือ

  1. ใช้ TOTP ผ่าน Authenticator app
  2. ใช้การยืนยัน push notification ผ่าน Authenticator app (Google เรียก Google prompt)
  3. ใช้ backup code หรือ recovery code ผ่านการจดหรือบันทึกไว้ในที่ที่ปลอดภัย

ส่วนที่ต่างของ Microsoft account มีเพิ่มเติมให้คือ
– ใช้ alternative E-mail ในการรับ OTP ได้ด้วย (ของ Google ไม่มี)

ส่วนที่ต่างของ Google account มีเพิ่มเติมให้คือ
– ใช้ USB FIDO Universal 2nd Factor (U2F) มาใช้ร่วมกับการเข้าระบบ

สำหรับความสามารถ Sign in Without Password ผ่าน Authenticator ที่เป็นการกดยืนยันเข้าระบบโดยไม่ต้องใช้ password ใดๆ ผ่านตัวแอป Authenticator ของทั้งสองค่ายนั้น มีจุดที่แตกต่างคือ Microsoft account ยินยอมให้เปิด MFA ไปพร้อมๆ กันได้ แต่ถ้าเป็น Google จะไม่ยอม จะต้องเลือกอย่างใดอย่างหนึ่ง

สำหรับผู้ให้บริการค่ายอื่นๆ ก็มีแนวทางประมาณนี้เยอะขึ้น ซึ่งส่วนใหญ่จะใช้ backup code เป็นตัวทดแทนการรับรหัส OTP ผ่าน SMS

เหตุผลที่ถอด SMS ออกจากการรับ OTP เพราะช่องโหว่บนระบบ Signalling System No. 7 (SS7) ในระบบสื่อสารผ่านโทรศัพท์ที่สามารถถูกดังฟังได้ อ้างอิง (1), (2) และ (3)