ไม่แนะนำให้ใช้ Bitwarden

 (マリウス.com)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากการใช้งานแบบโฮสต์เองมาหลายปี Bitwarden กลายเป็นตัวเลือกที่แนะนำได้ยากอีกต่อไป เพราะเซิร์ฟเวอร์ทางการมีความหนัก ทิศทางด้านโอเพนซอร์สไม่ชัดเจนขึ้น คุณภาพไคลเอนต์ต่ำ และมีประเด็นด้านความปลอดภัยเกิดซ้ำ
  • ขณะที่ Bitwarden server ทางการเป็นสแตกที่ค่อนข้างหนัก โดยมีแบ็กเอนด์ C# และยึด MSSQL Express เป็นหลัก เซิร์ฟเวอร์เข้ากันได้แบบไม่เป็นทางการที่พัฒนาด้วย Rust อย่าง Vaultwarden กลับเรียบง่ายและเบากว่า จึงมักถูกเลือกใช้ในการดีพลอยขนาดเล็กถึงขนาดกลาง
  • ไลเซนส์แบบจำกัดของ @bitwarden/sdk-internal ที่ถูกใส่เข้ามาในไคลเอนต์เมื่อปี 2024 ถูกเปลี่ยนไลเซนส์ใหม่เป็น GPLv3 หลังเกิดกระแสต่อต้าน แต่ก็ยิ่งทำให้กังวลว่าแนวทางของโครงการกำลังขยับไปเน้น SaaS subscription มากกว่าส่วนที่ฟรีและโอเพนซอร์ส
  • ในไคลเอนต์ของ Bitwarden มีปัญหาสะสมทั้งการนำเข้าวอลต์ล้มเหลว การไม่มีความสามารถย้ายรายการระหว่างวอลต์ organization กับวอลต์ individual วิธีเลี่ยงด้วยการส่งออก JSON แบบข้อความล้วน การเข้าถึงวอลต์ไม่ได้เพราะอัปเดตอัตโนมัติ รวมถึง UI ที่ช้าและ UX ของการกรอกอัตโนมัติที่ใช้งานไม่สะดวก
  • แทนที่จะฝากข้อมูลรับรองทั้งหมดไว้ในวอลต์เดียว การแยกเป็นงานสายอาชีพ/โปรเจกต์ลูกค้า บัญชีที่มี PII บัญชีที่ไม่มี PII โครงสร้างพื้นฐาน และซีเคร็ตแบบใช้ครั้งเดียว แล้วจัดการด้วยเครื่องมืออย่าง ตัวจัดการรหัสผ่านแบบ SaaS, ตระกูล KeePass, HashiCorp Vault หรือ pass จะเหมาะสมกว่า

เหตุผลเบื้องหลังที่ไม่แนะนำ Bitwarden อีกต่อไป

  • เกือบ 4 ปีก่อน ผู้เขียนเคยเผยแพร่ วิธีรันเองแบบ LastPass บน hardened OpenBSD โดยใช้ Vaultwarden บนอินสแตนซ์ OpenBSD หรือ Raspberry Pi แบบ bare metal แล้วใช้เป็นแบ็กเอนด์ให้แอปไคลเอนต์ของ Bitwarden
  • หลังจากใช้แนวทางคล้ายกันด้วยตัวเองมาหลายปี ตอนนี้จึงได้ข้อสรุปว่า ไม่แนะนำการใช้งาน Bitwarden
  • ปัญหาหลักสรุปได้เป็น ความหนักของเซิร์ฟเวอร์ทางการ ความไม่ชัดเจนของทิศทางโอเพนซอร์ส คุณภาพและ UX ของแอปไคลเอนต์ ปัญหาความปลอดภัยที่เกิดซ้ำ และความเสี่ยงของการฝากข้อมูลรับรองทั้งหมดไว้กับตัวจัดการรหัสผ่านเพียงตัวเดียว

ตัวจัดการรหัสผ่านแบบพรีเมียมและ dual-license

  • Wikipedia อธิบาย Bitwarden ว่าเป็น บริการจัดการรหัสผ่านโอเพนซอร์สแบบพรีเมียม สำหรับเก็บข้อมูลอ่อนไหว และระบุว่าเป็นของและพัฒนาโดย Bitwarden, Inc.
  • Bitwarden พัฒนาเซิร์ฟเวอร์ทางการและแอปไคลเอนต์สำหรับแทบทุกแพลตฟอร์ม พร้อมให้บริการผลิตภัณฑ์ SaaS สำหรับผู้ใช้ที่ไม่ต้องการโฮสต์เอง
  • ราคาของผลิตภัณฑ์แบบโฮสต์ใกล้เคียงกับคู่แข่ง แต่มีความต่างด้านฟีเจอร์ และไม่ว่าจะใช้แบบโฮสต์หรือโฮสต์เอง แอปไคลเอนต์ก็เป็นชุดเดียวกัน
  • Bitwarden ได้รับ เงินลงทุนเพื่อการเติบโต 100 ล้านดอลลาร์จาก PSG ในปี 2022 โดยมี Battery Ventures เข้าร่วมด้วย
  • ตัวจัดการรหัสผ่านที่พยายามรักษาความเป็นโอเพนซอร์ส กับตัวจัดการรหัสผ่านที่มีนักลงทุนในบอร์ดซึ่งคาดหวังผลตอบแทนจากเงินลงทุน 100 ล้านดอลลาร์นั้นไม่เหมือนกัน และนับจากจุดนี้ผลิตภัณฑ์ก็มีแนวโน้มจะขยับไปเพื่อนักลงทุนมากกว่าผู้ใช้ได้ง่ายขึ้น

ความต่างระหว่างเซิร์ฟเวอร์ทางการกับ Vaultwarden

  • มีความเห็นว่าหากโฮสต์ Bitwarden เอง จะเข้าสู่ นรกของซอฟต์แวร์องค์กร ได้ค่อนข้างเร็ว
  • การดีพลอย Bitwarden server มาตรฐานเป็นแบ็กเอนด์ C# ที่หนัก และมาพร้อม MSSQL Express โดยไม่ทำงานร่วมกับฐานข้อมูลที่เป็นมิตรกับ Linux อย่าง PostgreSQL หรือ MariaDB
  • ขึ้นอยู่กับขนาดของการดีพลอยและข้อกำหนดด้าน high availability อาจจำเป็นต้องใช้ Kubernetes ซึ่งเพิ่มทั้งโอเวอร์เฮดและความซับซ้อน
  • สำหรับการดีพลอยขนาดเล็กถึงขนาดกลาง หลายกรณีมักเลือก Vaultwarden
    • Vaultwarden เป็นเซิร์ฟเวอร์เข้ากันได้กับ Bitwarden แบบไม่เป็นทางการที่เขียนด้วย Rust
    • มันเรียบง่ายและเบากว่า Bitwarden server ทางการอย่างมาก ซึ่งสร้างความต่างชัดเจนสำหรับผู้ดูแลระบบ
    • การที่จำนวน GitHub star ดูมากกว่าฝั่งทางการประมาณ 3 เท่า ชวนให้คิดว่าผู้ใช้สายเทคนิคของ Bitwarden มองทิศทางของสแตกทางการในปัจจุบันอย่างไร
  • สำหรับบริษัทที่ได้รับเงินลงทุน Series B ถึง 100 ล้านดอลลาร์ ก็น่าจะพิจารณาดึงคนที่สร้างแบ็กเอนด์ซึ่งประสบความสำเร็จมากกว่ามาก เข้ามาช่วยปรับแต่งและเร่งการพัฒนาสแตกทางการได้

Bitwarden lite และทิศทางโอเพนซอร์ส

  • ดูเหมือนว่าแทนที่ Bitwarden จะรับ Vaultwarden เข้าเป็นโครงการทางการ บริษัทกลับจ้างนักพัฒนาหลักของ Vaultwarden แล้วเปิดตัว Bitwarden lite ซึ่งเป็นเวอร์ชันเบากว่าของแบ็กเอนด์เดิม
  • Bitwarden lite ยังเป็นบริการบน .NET ของ Microsoft และถูกมองว่ายังต้องใช้ RAM มากกว่าอินสแตนซ์ Vaultwarden ทั่วไปเกิน 3 เท่า
  • ความเป็นโอเพนซอร์สของ Bitwarden พร่ามัวลงมากในช่วงกว่าหนึ่งปีที่ผ่านมา
    • ช่วงปลายปี 2024 ผู้ใช้ พบ ว่ามีการเพิ่ม dependency ใหม่ @bitwarden/sdk-internal เข้ามาในไคลเอนต์
    • ข้อความในไลเซนส์ระบุว่า SDK นี้ห้ามนำไปใช้กับซอฟต์แวร์ที่ไม่ใช่ Bitwarden การทำ implementation ที่ไม่เข้ากันกับ Bitwarden หรือการพัฒนา SDK อื่น
  • สำหรับผลิตภัณฑ์ที่ชูตัวเองว่าโอเพนซอร์ส ข้อความในไลเซนส์ลักษณะนี้ถูกมองว่าเป็นจุดเปลี่ยนสำคัญ
  • หลังจากเกิด แรงต้านอย่างมากจากชุมชน Bitwarden เรียกเรื่องนี้ว่าเป็น “packaging bug” และสุดท้ายก็ เปลี่ยนไลเซนส์ SDK เป็น GPLv3
  • ในเชิงเทคนิคปัญหาอาจถูกแก้แล้ว แต่ในเชิงปรัชญากลับดูเหมือนว่าส่วนที่ฟรีและโอเพนซอร์สเป็นเพียงเหยื่อล่อ ขณะที่ตัวผลิตภัณฑ์จริงคือ SaaS subscription และชุมชนมีบทบาทเพียงช่วยรายงาน issue กับแปลภาษา
  • บทวิจารณ์ที่เกี่ยวข้องอีกชิ้นคือ The freeware parts are bait

แอปไคลเอนต์คือปัญหาหลัก

  • ต่อให้ไม่นับฝั่งแบ็กเอนด์ ปัญหาใหญ่ที่สุดของ Bitwarden ก็ยังถูกมองว่าเป็น แอปพลิเคชันไคลเอนต์
  • มีเสียงวิจารณ์ว่าฟีเจอร์ที่โฆษณาไว้ไม่ทำงานตามที่คาด ไม่มีฟังก์ชันพื้นฐานทั้งที่เปิดตัวมาแล้ว 10 ปี และเมื่อเทียบกับทางเลือกอื่นที่ราคาใกล้กัน ส่วนติดต่อผู้ใช้ก็ทำได้ไม่ดี
  • หาก Bitwarden เป็นความพยายามของชุมชน FOSS ล้วน ๆ ข้อบกพร่องแบบนี้อาจพอมองข้ามได้ แต่เมื่อเป็นบริษัทที่รับเงินจาก venture capital ก็ยากจะใช้มาตรฐานเดียวกัน
  • ภาพที่ชุมชนถูกผูกไว้กับกระบวนการแบบราชการยังยิ่งสะท้อนว่า Bitwarden เป็นผลิตภัณฑ์ของบริษัทมากกว่าจะเป็นความพยายามจากชุมชน

ปัญหาการย้ายวอลต์

  • ราว 1 ปีก่อน มีการช่วยผู้ใช้รายหนึ่งที่ต้องการย้ายจากผลิตภัณฑ์คู่แข่งมายัง Bitwarden ด้วยแนวคิดว่าจะสนับสนุนซอฟต์แวร์โอเพนซอร์สผ่านการสมัครสมาชิกรายปีแทนแพลตฟอร์มปิด
  • ระหว่างกระบวนการนำเข้าวอลต์จากตัวจัดการรหัสผ่านเดิมไปยังบัญชี Bitwarden ใหม่เกิดปัญหาขึ้น และตาม รายงานบั๊กบน GitHub อย่างน้อยมีหนึ่งวอลต์ที่ต้องใช้วิธีอ้อมเชิงเทคนิคมากพอสมควรจึงจะนำเข้าได้สำเร็จ
  • ฟีเจอร์ migration/การนำเข้าเป็นสิ่งที่ Bitwarden โฆษณาไว้ในสื่อการตลาดและเอกสารหลายแห่ง และก่อนหน้านั้นก็มีผู้ใช้หลายรายเจอปัญหาเดียวกันแล้ว
  • ถึงอย่างนั้น Bitwarden ก็ถูกมองว่าไม่ได้จัดการ issue นี้โดยตรง แต่กลับขอให้ไปเปิดการสนทนาอีกหัวข้อหนึ่งในฟอรัมชุมชน
  • ระบบราชการแบบองค์กร ลักษณะนี้ไม่สอดคล้องกับภาพของซอฟต์แวร์โอเพนซอร์ส และยิ่งยากจะหาเหตุผลมารองรับเมื่อฟีเจอร์ที่โฆษณาไว้ทั้งในซอฟต์แวร์โอเพนซอร์สและผลิตภัณฑ์เสียเงินกลับใช้งานจริงไม่ได้
  • เมื่อลองทดสอบการนำเข้าแบบเดียวกันกับทางเลือก proprietary ของ Bitwarden กลับทำงานได้โดยไม่มีปัญหา

ไม่มีความสามารถในการย้ายรายการระหว่าง vault

  • ปัญหาการย้ายข้อมูลไม่ได้จำกัดอยู่แค่การนำเข้าครั้งแรก
  • แม้จะพยายามย้ายรายการระหว่าง vault แบบ organization กับ vault แบบ individual ภายใน Bitwarden เอง ก็ยังไม่มีฟีเจอร์ที่เหมาะสมสำหรับย้ายรายการที่เลือกไปยังอีกที่หนึ่งจนถึงปัจจุบัน
  • ถ้ามีรายการล็อกอินเพียงไม่กี่รายการก็อาจคัดลอกและแก้ไขได้ แต่เมื่อเป็นสถานการณ์ที่ต้องจัดระเบียบรายการหลายร้อยรายการ ออกจากองค์กร หรือรวมหลายองค์กรเข้าด้วยกัน งานซ้ำ ๆ จะมากเกินไป
  • วิธีอ้อมอย่างเป็นทางการที่ Bitwarden support และกระทู้ชุมชนแนะนำ คือส่งออก vault ต้นทางเป็น JSON ที่ไม่ได้เข้ารหัส จากนั้นแก้ไขไฟล์แล้วนำเข้ากลับไปยัง vault ปลายทาง
  • กระบวนการนี้สร้างความเสี่ยงด้านความปลอดภัย เพราะข้อมูลรับรองมากกว่า 500 รายการอาจถูกวางไว้เป็นข้อความล้วนใน ~/Downloads หรือไดเรกทอรีซิงก์คลาวด์อย่าง Dropbox, OneDrive หรือ iCloud
  • การส่งออกจะไม่รวมไฟล์แนบ และยังไม่รวมรายการในถังขยะ ประวัติรหัสผ่าน และ timestamp
  • สำหรับองค์กรที่พึ่งพาไฟล์แนบอย่างไฟล์คีย์ SSH, license key, recovery code ในรูปภาพ หรือประวัติรหัสผ่านเพื่อการกำกับดูแลและตรวจสอบ วิธีนี้เป็นสิ่งที่ยอมรับได้ยาก
  • การที่ผลิตภัณฑ์ซึ่งควรเป็นแหล่งข้อมูลจริงเพียงหนึ่งเดียวของข้อมูลรับรอง ยังไม่มีปุ่มสำหรับย้าย 500 รายการไปยังอีก vault ได้อย่างครบถ้วนแม้เข้าสู่ปีที่ 10 แล้ว สะท้อนให้เห็นลำดับความสำคัญด้านวิศวกรรม

ปัญหาที่การอัปเดตไคลเอนต์ทำให้ฟีเจอร์พัง

  • Bitwarden ปล่อยอัปเดตไคลเอนต์ให้ผู้ใช้โดยไม่แจ้งล่วงหน้า และบางครั้งอัปเดตเหล่านี้อาจทำให้ฝั่งไคลเอนต์ไม่สามารถเข้าถึง vault ได้
  • ระหว่างเดินทาง ขณะที่เสียบชาร์จโทรศัพท์ทิ้งไว้ข้ามคืน F-Droid ได้อัปเดต Bitwarden และเช้าวันถัดมาจึงไม่สามารถเข้าถึง vault จากแอป Bitwarden ที่ต้องใช้สำหรับล็อกอินธนาคารได้
  • ใช้เวลาพอสมควรในการหาสาเหตุ และยืนยันสถานการณ์ได้ผ่านอีสชู bitwarden/androidและการพูดคุยของ Vaultwarden
  • โชคดีที่มี UPDC ซึ่งโฮสต์ Bitwarden backend อยู่ จึงหลีกเลี่ยงสถานการณ์ที่แย่กว่านี้ได้
  • วิธีการผลักอัปเดตที่ดูเหมือนมีการเปลี่ยนโปรโตคอลระหว่างไคลเอนต์กับ backend จนใช้งานร่วมกันไม่ได้ ให้ความรู้สึกว่าไร้ความรับผิดชอบ และนำไปสู่ข้อสรุปว่าไม่อาจไว้วางใจ Bitwarden สำหรับผู้ใช้ที่ต้องเชื่อถือ password manager ในโหมดออฟไลน์
  • หลังจากนั้นจึงปิดการอัปเดตอัตโนมัติของ Bitwarden client และส่งออก snapshot ล่าสุดของรหัสผ่านทั้งหมดไปเก็บเป็น local backup ที่อิงกับ KeePassChi, KeePassXC, KeePassDX
  • ปัญหานี้ดูไม่ใช่ปัญหาเฉพาะของ Vaultwarden เท่านั้น ตรงข้ามกับที่พนักงาน Bitwarden กล่าวอ้าง
    • ใน repository bitwarden/android มีรายงานลักษณะคล้ายกันหลายรายการ
    • regression ของรีลีส 2025.12.x มีรายงานว่าหลังล็อกอินแล้วแอปขอ master password สองครั้งและแอปล่ม
    • รีลีส 2025.6.0 มีรายงานว่าทำให้ผู้ใช้หลายรายแอปล่มทันทีที่เริ่มต้น
  • แอป Android ถูกเขียนใหม่ทั้งหมดในปี 2024 จาก .NET MAUI เป็น Kotlin แบบเนทีฟ และหลังการออก v2024.10.1 ก็ถูกประเมินว่ามี regression เกิดต่อเนื่องในทุกรีลีสรายไตรมาส

ประสบการณ์ผู้ใช้และคุณภาพของแอปเดสก์ท็อป·มือถือ

  • Bitwarden ถูกประเมินว่าเป็นหนึ่งในแอปที่แย่ที่สุดในเชิง UI แบบอัตวิสัย ทั้งบนโทรศัพท์และเดสก์ท็อป
  • แม้จะใช้งานมาหลายปี ก็ยังถึงขั้นรู้สึกลังเลที่จะเปิดส่วนขยาย ungoogled-chromium หรือแอปเดสก์ท็อป·มือถือ
  • การ build แอปเดสก์ท็อปที่อิงกับ Electron จากซอร์สทำได้ยุ่งยากมาก และ Flatpak ที่ build ไว้ล่วงหน้าก็ทำงานบน Wayland ได้ไม่ดี
  • ไคลเอนต์และส่วนขยายรองรับการใช้งานออฟไลน์ แต่ดูเหมือนไม่ได้ถูกออกแบบโดยมีการใช้งานออฟไลน์เป็นศูนย์กลาง
    • เมื่อเปิดแอปมือถือหรือส่วนขยายเบราว์เซอร์ จะมีอาการหน่วงราวกับกำลังพยายามเชื่อมต่อกับ backend
    • ในการตั้งค่าที่ไม่ได้เปิด backend สู่ public internet ความหน่วงนี้อาจยาวตั้งแต่ไม่กี่วินาทีไปจนถึงหลายนาที
    • ดูเหมือนจะไม่มีวิธีปิดการซิงก์ตอนปลดล็อก vault เพื่อหลีกเลี่ยงการรอที่ไม่จำเป็น
  • รายการล็อกอินใน Vault ของส่วนขยายเบราว์เซอร์ก็ใช้งานไม่สะดวก
    • โดยปกติ password manager อื่น ๆ เมื่อคลิกรายการในลิสต์จะกรอกฟอร์มล็อกอินให้
    • แต่ใน Bitwarden การคลิกทั้งรายการจะเปิดหน้ารายละเอียด และต้องกดปุ่ม Fill เล็ก ๆ ทางขวาจึงจะกรอกอัตโนมัติ
    • แม้รายการขนาดใหญ่จะถูกไฮไลต์เมื่อเอาเมาส์ไปชี้ แต่การกรอกอัตโนมัติจริง ๆ กลับผูกอยู่กับปุ่มเล็ก ๆ เท่านั้น ทำให้ใช้งานยาก
    • และก็ดูเหมือนจะไม่มีการตั้งค่าให้เปลี่ยนเป็นคลิกรายการเพื่อกรอกอัตโนมัติ และให้ปุ่มเล็กเปิดรายละเอียดแทน
  • ปัญหาในลักษณะคล้ายกันยังปรากฏซ้ำ ๆ บน Hacker News และในชุมชน
  • แม้แต่คำขอฟีเจอร์อย่างประวัติการแก้ไขแบบย่อรายรายการที่ค้างอยู่ใน community forum มาตั้งแต่ปี 2021 ก็ยังไม่ได้รับการจัดการ และผู้ค้าต่อ MSP ก็วิจารณ์ต่อสาธารณะว่าเป็น“การพัฒนาฟีเจอร์ที่ช้าราวธารน้ำแข็ง”

อินเทอร์เฟซที่เสี่ยงอันตรายของ Bitwarden CLI

  • Bitwarden CLI ก็ถูกประเมินว่ามีส่วนติดต่อผู้ใช้ที่ไม่ดีเช่นกัน
  • คำสั่ง list ของเครื่องมือ bw จะแสดงรายละเอียดของทุกรายการ รวมถึงรหัสผ่านและโค้ด TOTP แม้ไม่มีแฟล็กเพิ่มเติมอย่าง --show-credentials
  • จึงถูกวิจารณ์ว่าเป็นการออกแบบที่ไม่ได้คำนึงเพียงพอต่อสถานการณ์ที่อาจเผลอ pipe bw list ไปยังที่อื่น แล้วเปิดเผยข้อมูลรับรองทั้งหมดโดยไม่ตั้งใจ
  • การที่ Bitwarden CLI เป็นเครื่องมือเทอร์มินัลที่สร้างด้วย TypeScript ก็ถูกมองว่าเป็นปัญหาเช่นกัน
    • ต้องพึ่งพา runtime และ dependency จำนวนมาก
    • สแต็ก JavaScript ถูกประเมินว่าไม่ใช่ตัวเลือกที่เบาใจพอสำหรับการรันแบบไม่คิดมากในสภาพแวดล้อม CI อีกต่อไป

ประวัติด้านความปลอดภัย

  • หน้าที่หลักของตัวจัดการรหัสผ่านคือปกป้องผู้ใช้ให้ปลอดภัยและเก็บข้อมูลยืนยันตัวตนไว้อย่างปลอดภัย
  • ในฐานะผลิตภัณฑ์ที่มีมาตั้งแต่ปี 2016 Bitwarden ถูกประเมินว่าเผชิญปัญหาด้านความปลอดภัยที่ถูกนำขึ้นใช้งานจริงในโปรดักชันมาไม่น้อย
  • ไม่ได้หมายความว่าแต่ละเหตุการณ์ล้วนร้ายแรงถึงขั้นวิกฤต แต่สิ่งที่ถูกชี้เป็นปัญหาคือท่าทีด้านความปลอดภัยที่เน้นแก้หลังเกิดเหตุ การตอบสนองต่อการค้นพบที่น่าตกใจในลักษณะว่า “เป็นการทำงานตามที่ตั้งใจไว้” การพึ่งพา toolchain ของ Node.js สำหรับ CLI แกนหลักด้านความปลอดภัย และรูปแบบการจัดการปัญหาที่นักวิจัยภายนอกชี้ไว้ล่วงหน้าอย่างล่าช้า

  • 2023: KDF

    • ในเดือนมกราคม 2023 หลังเหตุละเมิดของ LastPass ไม่นาน นักวิจัยด้านความปลอดภัย Wladimir Palant ได้เผยแพร่บทวิเคราะห์ว่า การทำซ้ำ PBKDF2 ที่ Bitwarden โฆษณาว่ามี 200,001 รอบนั้น ในความเป็นจริงใกล้เคียง 100,000 รอบมากกว่า
    • สาเหตุคือรอบการทำซ้ำเพิ่มเติมฝั่งเซิร์ฟเวอร์ถูกใช้กับแฮชมาสเตอร์พาสเวิร์ดสำหรับการล็อกอินเท่านั้น แต่ไม่ได้ใช้กับคีย์เข้ารหัสที่ปกป้องข้อมูลในตู้นิรภัย
    • มีการประเมินว่า ผู้โจมตีที่เข้าถึงตู้นิรภัยที่รั่วไหลสามารถข้ามเซิร์ฟเวอร์ไปได้ทั้งหมด และระดับความปลอดภัยที่ได้จริงก็จะเทียบเท่ากับ LastPass
    • จำนวนรอบฝั่งไคลเอนต์เริ่มต้นในตอนนั้นก็อยู่ที่ 100,000 รอบ ซึ่งต่ำกว่าคำแนะนำของ OWASP ในเวลานั้น และมีการตั้งข้อกังวลนี้มาตั้งแต่ปี 2020
    • ในที่สุด Bitwarden ก็เพิ่มค่าเริ่มต้นเป็น 600,000 รอบ และเพิ่มการรองรับ Argon2 แต่การเปลี่ยนแปลงช่วงแรกมีผลกับบัญชีใหม่เท่านั้น ทำให้ผู้ใช้เดิมต้องเข้าไปเปลี่ยนการตั้งค่า KDF เอง

  • 2023: การข้าม Windows Hello

    • ในปี 2023 RedTeam Pentesting เปิดเผยช่องโหว่ของไคลเอนต์เดสก์ท็อป Windows ชื่อ “Bitwarden Heist”
    • ช่องโหว่นี้ถูกระบุเป็น CVE-2023-27706 โดยผู้โจมตีที่มีสิทธิ์ผู้ดูแลโดเมนสามารถดึงคีย์ถอดรหัสตู้นิรภัยออกจากที่เก็บ DPAPI ภายในเครื่องได้โดยไม่ต้องผ่าน Windows Hello หรือหน้าต่างถามมาสเตอร์พาสเวิร์ด
    • นักวิจัยอธิบายว่าโปรเซสใดก็ตามที่ทำงานอยู่ในเซสชันผู้ใช้สิทธิ์ต่ำสามารถขอข้อมูลยืนยันตัวตนสำหรับปลดล็อกตู้นิรภัยจาก DPAPI ได้
    • การแก้ไขถูกรวมเข้ามาในเวอร์ชัน 2023.4.0 หลายเดือนหลังการเปิดเผยครั้งแรก

  • 2023: การกรอกอัตโนมัติข้ามต้นทาง

    • ในปีเดียวกัน CVE-2023-27974 ถูกเปิดเผย
    • ส่วนขยายเบราว์เซอร์ของ Bitwarden จะเสนอการกรอกข้อมูลยืนยันตัวตนให้กับ iframe ข้ามโดเมน ที่ฝังอยู่ในหน้าที่เชื่อถือได้ หากโดเมนหลักตรงกัน
    • ตัวอย่างเช่น ถ้า trusted.com ฝัง iframe ของ attacker.trusted.com และบุคคลที่สามควบคุมซับโดเมนนั้น ก็อาจขโมยข้อมูลยืนยันตัวตนได้
    • Bitwarden ตอบว่าจำเป็นต้องจัดการ iframe แบบนี้เพื่อความเข้ากันได้ และ “Auto-fill on page load” ไม่ได้เปิดเป็นค่าเริ่มต้น
    • สำหรับผู้ใช้ที่เปิดตัวเลือกนี้อยู่ นั่นแทบไม่ใช่การปลอบใจอะไรเลย

  • 2025: DOM-based clickjacking

    • ในเดือนสิงหาคม 2025 นักวิจัยด้านความปลอดภัย Marek Tóth เปิดเผยรูปแบบการโจมตี clickjacking แบบอิง DOM ที่ทำให้ส่วนขยายเบราว์เซอร์ของ Bitwarden กรอกข้อมูลบัตรเครดิตและข้อมูลส่วนบุคคลโดยอัตโนมัติจากการคลิกเพียงครั้งเดียวบนหน้าอันตราย
    • ช่องโหว่นี้ถูกรายงานไปตั้งแต่เดือนเมษายน 2025 หรือ 4 เดือนก่อนการเปิดเผย แต่ Bitwarden จัดระดับไว้ว่าเป็น “moderate severity”
    • แพตช์ถูกรวมอยู่ในเวอร์ชัน 2025.8.2 ที่ปล่อยในวันเดียวกับที่ embargo ของนักวิจัยสิ้นสุดลง

  • 2026: Shai-Hulud

    • ไม่กี่วันก่อนเขียนบทความนี้ ไคลเอนต์ Bitwarden CLI อย่างเป็นทางการเวอร์ชัน 2026.4.0 ถูกเจาะในการโจมตีซัพพลายเชนของ Checkmarx ที่กำลังเกิดขึ้น
    • เวอร์ชันแพ็กเกจที่ได้รับผลกระทบดูเหมือนจะเป็น @bitwarden/cli2026.4.0 และโค้ดอันตรายถูกเผยแพร่ใน bw1.js ที่รวมมากับแพ็กเกจ
    • การโจมตีดูเหมือนอาศัย GitHub Action ที่ถูกเจาะใน CI/CD pipeline ของ Bitwarden และสอดคล้องกับรูปแบบความเสียหายของรีโพซิทอรีอื่น ๆ ในแคมเปญนี้
    • องค์กรที่ติดตั้งแพ็กเกจ Bitwarden npm ที่เป็นอันตรายควรปฏิบัติต่อเรื่องนี้ในฐานะเหตุข้อมูลยืนยันตัวตนรั่วไหลและการเจาะระบบ CI/CD
    • เพย์โหลด จะดาวน์โหลดรันไทม์ Bun ถอดรหัสเวิร์ม Shai-Hulud ระยะที่ 2 แล้วรวบรวมโทเคน GitHub และ npm, คีย์ SSH, ประวัติคำสั่งเชลล์, ข้อมูลยืนยันตัวตนของ AWS, GCP, Azure, ซีเคร็ตของ GitHub Actions และแม้แต่ไฟล์ตั้งค่า MCP ที่เครื่องมือ AI ใช้งาน
    • ข้อมูลที่ขโมยมาได้ถูกส่งออกโดยสร้างรีโพซิทอรีสาธารณะบน GitHub ของเหยื่อเองโดยอัตโนมัติแล้วอัปโหลดเข้าไป
    • pipeline สำหรับเผยแพร่ npm ของ Bitwarden อยู่ในสถานะถูกเจาะราว 19 ชั่วโมง และมีเวลามากพอให้ผู้พัฒนา 334 คนดาวน์โหลดแพ็กเกจอันตรายดังกล่าว
    • จุดยืนอย่างเป็นทางการของ Bitwarden เน้นว่าข้อมูลตู้นิรภัยของผู้ใช้ปลายทางไม่ได้ถูกเข้าถึง แต่ผู้ใช้ที่รัน bw ใน pipeline CI ก็เท่ากับส่งต่อความลับอื่น ๆ ที่อยู่บนเครื่องนั้นให้ผู้โจมตี
    • มีการประเมินว่า หาก bw เป็นไบนารีแบบ static link เดี่ยวที่พบได้บ่อยใน ecosystem ของ Go หรือ Rust ก็จะไม่มี blast radius แบบแพ็กเกจ npm เช่นนี้
    • แม้ใน ecosystem ของ Go และ Rust การโจมตีซัพพลายเชนจะเพิ่มขึ้นเช่นกัน แต่ก็ยังถูกประเมินว่าอุปสรรคต่อการโจมตีให้สำเร็จนั้นสูงกว่าอยู่

แนวทางต่อไป: แยกออกและกักกัน

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

การจัดหมวดหมู่ข้อมูลรับรองและการเลือกเครื่องมือ

  • กลุ่ม A: โปรเจ็กต์สายอาชีพ·โปรเจ็กต์ลูกค้า

    • กลุ่ม A คือข้อมูลรับรองของโปรเจ็กต์สายอาชีพ·โปรเจ็กต์ลูกค้า เช่น การล็อกอินแพลตฟอร์ม
    • ใช้ตัวจัดการรหัสผ่านแบบ SaaS ที่ให้การแชร์ vault อย่างเหมาะสม, การผสานรวมกับเครื่องมือที่ลูกค้าใช้งานจริง, SSO, ส่วนขยายเบราว์เซอร์บนอุปกรณ์ขององค์กร, บันทึกการตรวจสอบ และไม่ต้องรับภาระเรื่องโฮสติ้ง
    • โดยปกติไม่ชอบแพลตฟอร์มที่เป็นผลิตภัณฑ์ปิด แต่ยอมรับ trade-off นี้ได้ เพราะขอบเขตของกลุ่มนี้จำกัดอยู่แค่งานของลูกค้า

  • กลุ่ม B: บัญชีที่มี PII

    • กลุ่ม B คือข้อมูลรับรองของบัญชีที่มี PII เช่น บัญชีธนาคารและร้านค้าออนไลน์
    • บัญชีเหล่านี้มีข้อมูลส่วนบุคคลอย่างชื่อ ที่อยู่ วันเกิด และข้อมูลการชำระเงินอยู่แล้ว และตัวบริการเองก็มีการรั่วไหลเป็นระยะ ๆ ซึ่งตรวจสอบได้จาก Have I Been Pwned
    • มองว่าการถูกเจาะของตัวจัดการรหัสผ่านไม่ได้ทำให้ข้อมูลที่ผู้โจมตีรู้อยู่แล้วขยายเพิ่มขึ้นอย่างมีนัยสำคัญ
    • เมื่อมีทั้ง TOTP และ Passkeys สิ่งสำคัญของกลุ่มนี้คือการใช้งานข้ามอุปกรณ์ ความน่าเชื่อถือ และความสามารถออฟไลน์
    • ใช้ตัวจัดการรหัสผ่านบนคลาวด์ตัวที่สองซึ่งเป็นของผู้ให้บริการคนละราย เพื่อไม่ให้ถูกเจาะพร้อมกับกลุ่ม A โดยอัตโนมัติ และตั้ง master password กับกลไกกู้คืนแยกกัน
    • เนื่องจากมีแผนจะรันแอปมือถือบนอุปกรณ์ GrapheneOS อย่างน้อยหนึ่งเครื่อง จึงชอบโซลูชันที่ไม่พึ่งพา Google Play Services และถ้าเป็นไปได้ควรเป็นโอเพนซอร์สหรือมีไคลเอนต์แบบ source-available

  • กลุ่ม C: บัญชีที่ไม่มี PII

    • กลุ่ม C ครอบคลุมบัญชีอย่างเว็บบอร์ด เว็บไซต์ บริการที่เคารพความเป็นส่วนตัว และบัญชีที่ไม่เก็บ PII
    • กลุ่มนี้ไม่จำเป็นต้องใช้บริการคลาวด์ และก็ไม่ต้องการด้วย
    • ใช้ KeePassChi, KeePassXC, KeePassDX และวางไฟล์ฐานข้อมูลไว้ในโฟลเดอร์ที่ซิงก์ข้ามอุปกรณ์ด้วย Syncthing
    • แนวทางนี้เคยพูดถึงไว้แล้วใน บทความสร้าง Dropbox แบบกระจายศูนย์ด้วย Syncthing
    • เนื่องจากไฟล์ .kdbx ถูกเข้ารหัสอยู่แล้ว ต่อให้ Syncthing ถูกเจาะและผู้โจมตีได้ไฟล์ไป ก็ยังต้องถอดการเข้ารหัสของ KeePassChi/KeePassXC จึงจะได้ข้อมูลที่ใช้งานได้
    • บนมือถือ KeePassDX บน Android ก็อ่านไฟล์เดียวกันนี้ได้ไม่มีปัญหา

  • กลุ่ม D: โครงสร้างพื้นฐาน

    • กลุ่ม D คือข้อมูลรับรองด้านโครงสร้างพื้นฐาน เช่น การล็อกอินเซิร์ฟเวอร์และคีย์ SSH
    • ข้อมูลรับรองส่วนตัวเก็บด้วยวิธีเดียวกับกลุ่ม C
    • ข้อมูลรับรองที่สคริปต์ งาน CI และเซิร์ฟเวอร์ระยะไกลใช้งานจริงนั้นใช้ HashiCorp Vault
    • HashiCorp Vault เป็นเครื่องมือที่ใช้งานอยู่แล้วในระบบตั้งค่า OpenBSD สำหรับงาน PKI
    • แม้จะดูเกินจำเป็นสำหรับผู้ใช้คนเดียว แต่ให้ทั้งนโยบายการเข้าถึง การยืนยันตัวตนแบบใช้โทเค็นสำหรับเอเจนต์อัตโนมัติ ข้อมูลรับรองอายุสั้นเมื่อระบบรองรับ และบันทึกการตรวจสอบ
    • กำลังพิจารณา Infisical อยู่ด้วย

  • กลุ่ม E: ข้อมูลรับรองแบบใช้ครั้งเดียว

    • กลุ่ม E คือ API key, personal access token และ secret จิปาถะที่ใช้เฉพาะบนบรรทัดคำสั่ง
    • ใช้ยูทิลิตี pass รุ่นเก่า
    • pass จะเก็บแต่ละ secret เป็นไฟล์เข้ารหัส GPG แยกไฟล์ภายใน Git repository
    • โครงสร้างเรียบง่าย ตรวจสอบได้ง่าย และเข้ากันได้ดีกับเชลล์สคริปต์และ dotfiles
    • Git repository ไม่ได้อยู่บน GitHub แต่อยู่บนโครงสร้างพื้นฐานของตนเอง และจะซิงก์ด้วยตนเองก็ต่อเมื่อต้องเข้าถึงจากเครื่องอื่นจริง ๆ เท่านั้น

บทสรุปจากการย้ายจาก vault เดียวไปสู่หลายเครื่องมือ

  • สำหรับผู้ใช้ที่มาจากโลกของ vault เดียว อาจดูเป็นชุดระบบที่มีชิ้นส่วนเคลื่อนไหวเยอะและซับซ้อนเกินไป
  • หลังจากใช้ Bitwarden เป็นโซลูชันครอบจักรวาลมาหลายปี ก็ได้ข้อสรุปว่า one size fits all ในความเป็นจริงคือ one size fits poorly
  • การแยกข้อมูลรับรองออกไปหลายเครื่องมือเจ็บปวดน้อยกว่าที่คาดไว้มากในตอนแรก เพราะแต่ละเครื่องมือเหมาะกับงานเฉพาะด้านมากกว่า
  • ต่อให้มีเครื่องมือใดเครื่องมือหนึ่งถูกเจาะ รัศมีความเสียหายก็จะถูกจำกัดอยู่ที่หมวดหมู่ของ secret เพียงหมวดเดียว ไม่ใช่ข้อมูลรับรองทั้งหมด

คำตัดสินสุดท้าย

  • หลังจาก self-host Bitwarden มาหลายปี มองว่าผลิตภัณฑ์นี้ค่อย ๆ ห่างออกไปจากทิศทางที่คาดหวังไว้ในตอนแรก
  • สถาปัตยกรรมที่ให้ความสำคัญกับองค์กรเป็นหลักจนแทบจะยัดลง Raspberry Pi ได้พอดี ความพยายามครึ่ง ๆ กลาง ๆ ในการทำแบ็กเอนด์แบบเบา ข้อถกเถียงเรื่องไลเซนส์ของ SDK ความช้าในการจัดการฟีเจอร์ ปัญหา UX ที่ไม่ถูกแก้มาหลายปี และประเด็นความปลอดภัยที่ไม่ควรถูกปล่อยออกมาตั้งแต่แรก ทั้งหมดนี้รวมกันเป็นภาพที่ไม่สอดคล้องกับเรื่องเล่าว่าเป็น “ตัวจัดการรหัสผ่านโอเพนซอร์สสำหรับทุกคน”
  • ไม่ได้หมายความว่าทางเลือกอื่นดีกว่าโดยทั่วไปเสมอไป หรือไม่มีปัญหา
  • โดยเนื้อแท้แล้วตัวจัดการรหัสผ่านเป็นเรื่องยาก และผู้เล่นทุกรายในพื้นที่นี้ต่างก็มีปัญหาเป็นของตัวเอง
  • ควรตรวจสอบอย่างเข้มงวดว่าเรากำลังฝากความไว้วางใจไว้กับซอฟต์แวร์เพียงตัวเดียวมากแค่ไหนสำหรับข้อมูลรับรองทั้งหมด และการเดิมพันนั้นยังถูกต้องอยู่หรือไม่ และในกรณีนี้ก็ได้ข้อสรุปว่าไม่ใช่ทางเลือกที่ถูกต้องอีกต่อไป

การอภิปรายที่เกี่ยวข้อง

บทความที่เกี่ยวข้อง

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

 
GN⁺ 2 시간 전
ความเห็นจาก Lobste.rs

  • ข้อความแฟลช ปิด JavaScript ที่เด้งขึ้นมาหลังเปลี่ยนแท็บก็น่ารำคาญ และชื่อแท็บที่เปลี่ยนไปก็น่ารำคาญด้วย
    ฉันคงไม่ปิด JavaScript เป็นค่าเริ่มต้น เพราะมีหลายเว็บเกินไปที่จะพัง
    ปกติเว็บส่วนใหญ่ที่เข้าเป็นประจำ แค่ตัวบล็อกโฆษณาก็พอแล้ว และใช้ NoScript กับบางเว็บแย่ ๆ เท่านั้น ซึ่งดูเหมือนเว็บนี้ก็เข้าข่ายนั้นด้วย

    • ฉันเกลียดมากที่การอ่านบทความบนอินเทอร์เน็ตกลับคาดหวังให้ รันโค้ดตามอำเภอใจ เป็นค่าปริยาย
      เห็นด้วยนะ แต่ก็ต้องมีใครทำอะไรสักอย่าง อย่างที่พูดไว้ ความสะดวกจากการเปิด JavaScript ไว้ทุกที่ยังมีมากกว่าเว็บนี้เว็บเดียว แต่สักวันหนึ่งความสะดวกนั้นก็คงจะข้ามจุดวิกฤต
    • ฉันตั้งใจเลี่ยงเว็บนั้นหลังจากมันแสดง <title> ตลก ๆ ว่า “steve ballmer nude pics” ตอนอยู่ที่ออฟฟิศ
    • พูดง่าย ๆ คือฉันไม่ชอบ สไตล์การเขียน แบบนั้น
    • ฉันเข้าใจว่าหมายถึงอะไร และจริง ๆ ก็เห็นด้วยเพราะฉันเองก็เปิด JavaScript ไว้เป็นค่าเริ่มต้น
      แต่ฉันจะไม่เพิ่มข้อยกเว้นให้เว็บแย่ ๆ แค่ลบออกจากประวัติการเข้าชมแล้วไม่กลับไปอีก
      ในขณะเดียวกันก็เข้าใจเจตนาของผู้เขียนด้วย ดูไม่ใช่การปั่นเล่นเฉย ๆ แต่เหมือนกำลังจะบอกว่า “ใช่ นี่มันเป็นพฤติกรรมแย่ ๆ แต่บนเว็บ การที่ เว็บไหนก็ได้โดยปริยาย จะทำแบบนี้หรือทำอะไรที่แย่กว่านี้ได้ มันสมเหตุสมผลแล้วหรือ?”
      JavaScript ทำให้อาชีพการงานของฉันแทบทั้งหมดเกิดขึ้นได้ แต่ฉันก็ยังคิดว่าการที่หน้าเว็บที่มีแค่ข้อความหรือรูปภาพจะรันโค้ดตามอำเภอใจได้โดยไม่มีคำเตือนหรือสัญญาณใด ๆ และใช้ CPU, แบนด์วิดท์ และทรัพยากรอื่น ๆ ได้ไม่จำกัดนั้น ค่อนข้างบ้าดีเหมือนกัน

  • ฉันก็ยังรู้สึกไม่ค่อยสบายใจกับ KeePassXC อยู่บ้าง
    กังวลว่าการใช้เครื่องมือ AI จะเร่งการเพิ่มฟีเจอร์ที่ไม่ต้องการและไม่จำเป็นเข้าไปในตัวจัดการรหัสผ่าน ตอนนี้ดูเหมือนจะใช้หลัก ๆ กับการแก้บั๊ก แต่พอแก้บั๊กส่วนใหญ่หมดแล้ว ขั้นต่อไปจะเป็นอะไรก็คงเดาไม่ยาก สิ่งล่อตาล่อใจมันมากเกินไป
    ไม่นานมานี้ยังเพิ่ม “รองรับไฟล์เพิ่มเติมในตัวดูไฟล์แนบแบบอินไลน์ (รูปภาพ, HTML, Markdown) และฟังก์ชันแก้ไขไฟล์แนบข้อความ” ซึ่งฉันไม่อยากมีโค้ดแบบนั้นอยู่ในตัวจัดการรหัสผ่าน มีทั้งโปรแกรมแก้ไขข้อความและแอปดูไฟล์อยู่แล้ว
    แค่โฟกัสกับประสบการณ์ผู้ใช้ที่ดีที่สุดเท่าที่ทำได้เพื่อแข่งกับ 1Password อย่างจริงจังก็พอ ฉันยังไม่พร้อมจะไว้ใจนักพัฒนา KeePassX? KeePassChi? ChiPass? เลยด้วยซ้ำ

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

    • ฉันเคยเป็นแฟนตัวยงของ 1Password มาก่อน และใช้มานานกว่า 10 ปี
      จุดที่ทนไม่ไหวครั้งสุดท้ายคือเมื่อพวกเขาแทบจะปิดกั้นการ นำวิธีซิงก์ของคุณเองมาใช้ แทนการเก็บข้อมูลของฉันไว้บนเซิร์ฟเวอร์ของพวกเขา
      ตอนนั้นไคลเอนต์ที่ไม่ใช่ของ Apple ก็ไม่ค่อยดีอยู่แล้ว และการที่ฉันเริ่มใช้แพลตฟอร์มที่ไม่ใช่ Apple มากขึ้นเรื่อย ๆ ก็มีผลด้วย ช่วงไม่กี่ปีมานี้เหมือนทางนั้นจะดีขึ้นแล้ว แต่ฉันก็ยังไม่ได้กลับไปลองอีก
      เหตุผลที่ฉันเลิกใช้ไม่ใช่เรื่องเงิน ตอนนี้ฉันจ่ายเงินให้ Bitwarden แต่โฮสต์ที่เก็บข้อมูลเองด้วย VaultWarden
      แม้จะชอบซอฟต์แวร์เสรีและโอเพนซอร์ส แต่สำหรับเครื่องมือแบบนี้ สิ่งตัดสินเด็ดขาดคือ ควบคุมได้ว่าข้อมูลถูกเก็บไว้ที่ไหน
    • ในบางสถานการณ์ การซิงก์ก็ยังล้มเหลวอยู่
      ถ้าคุณเปลี่ยนข้อมูลรับรองจากที่อื่นที่ไม่ใช่อุปกรณ์ Android ตอนที่ใช้ 1Password บน Android ครั้งแรกหลังจากนั้น มันจะกรอก ข้อมูลรับรองเก่า ก่อนที่ค่าที่อัปเดตจะซิงก์มา
      การล็อกอินครั้งแรกจึงล้มเหลว แล้วพอรู้ตัวและลองครั้งที่สอง ถึงตอนนั้นการซิงก์ก็มักจะเสร็จพอดีและจึงเข้าได้ มันน่าหงุดหงิดทุกครั้ง

  • โดยรวมฉันเห็นด้วยกับข้อโต้แย้งคัดค้าน Bitwarden แต่หลายประเด็นที่ยกมาดูไม่ใช่ปัญหาใหญ่อะไรนัก และบางส่วนก็ดูเหมือนจะมาจาก การตั้งค่าเฉพาะทาง อย่าง VaultWarden หรือ GrapheneOS
    ฉันใช้ Bitwarden มาประมาณ 5–6 ปีแล้ว และปัญหาเดียวที่เคยเจอก็คือ ความช้าช่วงหนึ่งหลังปรับ UI ของส่วนขยายเบราว์เซอร์ ซึ่งแก้โดยย้อนกลับไปใช้ส่วนขยายเวอร์ชันเก่าจาก GitHub releases อยู่สองสามเดือน
    ถ้าจะเขียนยาวขนาดนั้น ก็น่าจะพูดถึงทางเลือก SaaS ที่จะย้ายไปจริง ๆ ด้วย ผู้อ่านไปค้นเองแล้วเลือกตัวจัดการรหัสผ่านแบบ SaaS ที่เหมาะกับตัวเองได้ก็คงดีในแง่ผลลัพธ์ แต่ก็ยังน่ารำคาญอยู่ดี
    ฉันอยากได้ยินว่ามีตัวจัดการรหัสผ่านตัวอื่นไหมที่มีโฮสติ้งฟรี รองรับออฟไลน์ ซิงก์คลาวด์อัตโนมัติ ส่วนขยายเบราว์เซอร์ที่มีคีย์ลัดกรอกอัตโนมัติ แอปมือถือ และถ้าเป็นไปได้ก็อยากได้ตัวเลือกโอเพนซอร์สด้วย
    ค้นดูนิดหน่อยแล้วสำหรับคนที่มองหาทางเลือก Proton Pass ดูเหมือนจะตรงตามเงื่อนไขพวกนี้ทั้งหมด สักวันฉันอาจจะลอง แต่ตอนนี้ Bitwarden ยังเหมาะกับฉันดี

    • ฉันใช้แต่การตั้งค่า Bitwarden แบบทางการมาตลอด และมีอยู่ข้อหนึ่งที่ดูจะจริง
      การจัดระเบียบรายการภายใน Bitwarden นั้นแทบไม่ต่างจากความบ้าคลั่ง
      แค่มีฟังก์ชันลากคอลัมน์เพื่อย้ายรายการข้ามองค์กรได้ก็คงยอดเยี่ยมแล้ว แต่ตอนนี้เหลือแค่ระบบที่มีข้อจำกัด
      มันตลกดีที่ซอฟต์แวร์แบบเสียเงินกลับมีทางแก้จริง ๆ แค่การสร้างเครื่องมือจัดการขึ้นมาใช้เอง
    • บน Firefox มันยังช้ามากอยู่ดี จนฉันทิ้งส่วนขยายไปใช้แอปเดสก์ท็อปแทน
    • ปัญหาเกี่ยวกับบรรทัดคำสั่งแก้ได้หมดด้วย rbw
      ฉันเพิ่งเจอมันไม่นานนี้และย้ายไปใช้เต็มตัวแล้ว

  • pass “ตัวจัดการรหัสผ่านมาตรฐานของ UNIX” ก็ดีเหมือนกัน ฉันใช้มานานกว่า 10 ปีแล้ว
    https://www.passwordstore.org/

    • น่าเสียดายที่ แอป Android ที่เกี่ยวข้องหยุดพัฒนาแล้ว ทำให้ใช้งานทุกที่ได้ยากขึ้น: https://github.com/android-password-store/Android-Password-Store/…
      ดูเหมือนจะมีฟอร์กที่ยังแอ็กทีฟอยู่ แต่ฉันยังไม่ได้ลองเช็ก และดูเหมือนจะไม่มีใน Google Play แต่มีใน F-Droid

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

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

  • ในฐานะผู้ใช้ Bitwarden ฉันขอแนะนำมัน
    มันราคาถูก มีฟีเจอร์ที่ต้องใช้ครบ และเป็นซอฟต์แวร์เสรีและโอเพนซอร์ส
    ฉันไม่มีเวลาจะใช้โซลูชันจัดการรหัสผ่าน 5 ตัว เครื่องมือบรรทัดคำสั่ง 4 ตัว และมาสเตอร์พาสเวิร์ด 3 ชุด Bitwarden ดีมากทีเดียว
    สำหรับฉัน 1Password ให้ความรู้สึกชั่วร้ายแบบเต็ม ๆ จนไม่อยากไปยุ่งด้วย

    • ผ่าน Chrome, การซิงก์ KeePass แบบโฮสต์เอง, Firefox แล้วตอนนี้ก็มาจบที่ Bitwarden
      มันเป็นตัวที่ย้ายมาใช้และแชร์กับครอบครัวได้ง่ายที่สุดอย่างชัดเจน ค่าสมาชิกก็ถูกมาก

  • มีโซลูชันโอเพนซอร์สตัวอื่นที่รองรับ การแชร์ข้อมูลรับรอง แบบ Bitwarden ไหม?
    ฉันใช้ KeePass/KeePassXC มานานกว่า 15 ปีแล้ว แต่เวลาอยากแชร์ชุดข้อมูลรับรองกับเพื่อนร่วมทีมหรือคนในครอบครัวที่ไม่ใช่นักพัฒนา ฉันยังหาอะไรที่ดีกว่า Bitwarden ไม่เจอ
    ฉันไม่เคยชอบ Bitwarden เป็นพิเศษ แต่ในแง่ที่เก็บข้อมูลรับรองกับการแชร์/ซิงก์ มันก็เป็นตัวเลือกที่แย่น้อยที่สุดมาโดยตลอด

    • ฉันเพิ่งเจอ Passbolt[0] ไม่นานนี้
      มันให้ความรู้สึกเชิงองค์กรแบบ Bitwarden แต่ก็ดูน่าสนใจ ไม่รู้ว่าใช้งานดีจริงไหม แต่ก็ดูเหมือนพอจะเป็นทางเลือกแทน Bitwarden ได้
      [0]: https://www.passbolt.com/
    • คุณอาจย้ายรหัสผ่านทั้งหมดไปไว้ในตัวจัดการรหัสผ่านตัวอื่นที่ชอบ แล้วคงไว้แค่ข้อมูลรับรองที่แชร์ร่วมกันบน Bitwarden ก็ได้

  • ฉันใช้ keepassXC กับ keepassDX มาสักพักแล้ว ชื่อมันดูงี่เง่าจริง ๆ
    หวังว่าสักวันจะได้ย้ายไป ChiPass

  • ถ้าเป็น GPG ก็... น่าจะเป็นการเข้ารหัสให้ตัวเองด้วย RSA ล่ะมั้ง?
    ใช้ age จะดีกว่า