LastBrowser เผยเบื้องหลังปัญหาระบบเก็บรหัสผ่านบน Linux
ทีมพัฒนา LastBrowser เผยเหตุผลที่ฟังก์ชัน isEncryptionAvailable บน Electron ยังไม่เพียงพอสำหรับการใช้งานบน Linux เนื่องจากการตกหล่นไปใช้ basic_text
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- LastBrowser พัฒนาเบราว์เซอร์เดสก์ท็อปบน Electron พร้อมระบบเก็บรหัสผ่าน
- Linux ไม่มีระบบจัดเก็บความลับหลักเพียงระบบเดียว ทำให้ต้องพึ่งพาแบ็กเอนด์ที่แตกต่างกัน
- ฟังก์ชัน isEncryptionAvailable ไม่สามารถบอกประเภทของคีย์เข้ารหัสได้
- ทีมพัฒนาต้องสร้างเกณฑ์ตรวจสอบและจัดการสถานะไม่ทราบค่า (unknown) ในระหว่างเริ่มต้นระบบ
การพัฒนาเบราว์เซอร์เดสก์ท็อปบน Electron มักจะมีการจัดเก็บรหัสผ่านที่ถูกเข้ารหัสด้วยโมดูล safeStorage ของ Electron ก่อนที่จะถูกเขียนลงในไฟล์ JSON ประจำโปรไฟล์บนดิสก์ โดยในระบบปฏิบัติการ Windows จะใช้ DPAPI ส่วนบน macOS คีย์จะถูกเก็บไว้ใน Keychain ซึ่งเป็นค่าเริ่มต้นที่สมเหตุสมผลสำหรับการใช้งานในพื้นที่
อย่างไรก็ตาม บนระบบปฏิบัติการ Linux กลับมีความซับซ้อนมากกว่า เนื่องจากไม่มีที่เก็บความลับของระบบปฏิบัติการเพียงระบบเดียว โดย Electron จะเลือกแบ็กเอนด์ตามสภาพแวดล้อมเดสก์ท็อป เช่น gnome_libsecret สำหรับ GNOME, Cinnamon, XFCE และ kwallet สำหรับ KDE sessions แต่หากไม่สามารถจดจำสภาพแวดล้อมได้ หรือมีการรันแอปพลิเคชันด้วยคำสั่ง --password-store="basic" ระบบจะตกลงไปใช้ basic_text ทันที
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
จุดที่นักพัฒนาหลายคนมักมองข้ามคือ เอกสารของ Electron ระบุไว้ว่าหากไม่มีที่เก็บความลับ รายการที่จัดเก็บผ่าน safeStorage API จะไม่มีการป้องกันเนื่องจากถูกเข้ารหัสด้วยรหัสผ่านแบบ plaintext ที่ถูกฮาร์ดโค้ดไว้ โดยสามารถตรวจจับเหตุการณ์นี้ได้เมื่อ safeStorage.getSelectedStorageBackend() คืนค่าเป็น basic_text ซึ่งหมายความว่าฟังก์ชัน encryptString() บน Linux จะยังคงทำงานได้ตามปกติโดยไม่มีการแจ้งเตือนใดๆ แม้ว่าคีย์ที่ใช้ป้องกันข้อมูลนั้นจะไม่ใช่ความลับจริงๆ ก็ตาม
ในมุมมองด้านความปลอดภัย การที่ซอฟต์แวร์จัดเก็บข้อมูลความลับโดยใช้คีย์ที่ไม่ปลอดภัยแต่แสดงผลว่าเข้ารหัสแล้ว ถือเป็นความเสี่ยงที่ร้ายแรงยิ่งกว่าการไม่มีระบบเข้ารหัสเสียอีก เนื่องจากมันสร้างความรู้สึกปลอดภัยจอมปลอมให้กับผู้ใช้งาน ทำให้ผู้พัฒนาแอปพลิเคชันประเภท Password Manager ต้องระมัดระวังเป็นพิเศษในการตรวจสอบสภาพแวดล้อมของระบบปฏิบัติการก่อนตัดสินใจจัดเก็บข้อมูลสำคัญ
นอกจากนี้ยังมีปัญหาเรื่องจังหวะเวลา (timing issue) เพิ่มเติม เนื่องจากฟังก์ชัน getSelectedStorageBackend() จะมีความหมายก็ต่อเมื่อผ่านเหตุการณ์ app ready ของ Electron ไปแล้วเท่านั้น หากมีการเรียกใช้งานก่อนหน้านี้ ระบบจะคืนค่าเป็น unknown ซึ่งทีมพัฒนาได้ตัดสินใจกำหนดให้สถานะ unknown มีผลปฏิบัติเช่นเดียวกับสถานะไม่ได้รับอนุญาต เพื่อป้องกันการตัดสินใจด้านความปลอดภัยบนข้อมูลที่ไม่ครบถ้วน
"A vault that silently writes 'encrypted' passwords with a known key gives users a false sense of safety, which we consider worse than no vault at all."
LastBrowser Team
แนวทางแก้ไขในพูลรีเควส (pull request) ของทีมพัฒนาประกอบด้วยการสร้างตัวกรองเพื่อตรวจสอบว่าแบ็กเอนด์ของระบบปฏิบัติการนั้นยอมรับได้หรือไม่ การรวมการตรวจสอบความพร้อมของแอปพลิเคชันเข้ากับการตรวจสอบความพร้อมของห้องนิรภัย รวมถึงการเพิ่มไฟล์ทดสอบที่จำลองการทำงานของ safeStorage เพื่อครอบคลุมตารางการตัดสินใจทั้งหมด อย่างไรก็ตาม ทีมพัฒนายังคงต้องเตรียมรับมือกับการเปลี่ยนแปลงครั้งใหญ่เมื่อ Electron 45 และ 46 เตรียมถอดฟังก์ชันซิงโครนัสเดิมออก เพื่อเปลี่ยนไปใช้ API แบบอะซิงโครนัสในอนาคต
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น