KeePass: ใช้ไฟล์กุญแจหรือรหัสผ่านปกติ?


17

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

โปรดทราบว่ามันน่าดึงดูดยิ่งกว่าที่จะใช้ไฟล์คีย์สำหรับฉันเพราะฉันมีช่วงเวลาที่ยากลำบากในการจดจำสิ่งที่อยู่ใกล้กับรหัสผ่านแบบสุ่ม

คำตอบ:


17

เกี่ยวกับความสามารถในการใช้' key files' กับ KeePass

เพื่อสร้างคีย์ 256- บิตสำหรับบล็อก ciphers ใช้ Secure Hash Algorithm SHA-256 อัลกอริทึมนี้บีบอัดคีย์ผู้ใช้ที่ได้รับจากผู้ใช้ (ประกอบด้วยรหัสผ่านและ / หรือไฟล์คีย์) กับคีย์ขนาดคงที่ 256 บิต การแปลงนี้เป็นทางเดียวคือมันเป็นไปไม่ได้ที่คำนวณได้เพื่อสลับฟังก์ชันแฮชหรือค้นหาข้อความที่สองที่บีบอัดไปที่แฮชเดียวกัน

การโจมตีที่ค้นพบเมื่อเร็ว ๆ นี้กับ SHA-1ไม่ได้ส่งผลกระทบต่อความปลอดภัยของ SHA-256 SHA-256 ยังถือว่าเป็นความปลอดภัยมาก

(มีการอัปเดตล่าสุดอีกครั้งแต่ฉันคิดว่าข่าวดังกล่าวไม่เกี่ยวข้องที่นี่ )
ไปยังจุดที่มือ ,

การได้มาของคีย์ :
หากใช้รหัสผ่านเพียงอย่างเดียว (เช่นไม่มีไฟล์คีย์) รหัสผ่านบวกกับเกลือแบบสุ่ม 128 บิตจะถูกแฮชโดยใช้ SHA-256 เพื่อสร้างคีย์สุดท้าย (แต่โปรดทราบว่ามีการประมวลผลล่วงหน้า: การป้องกันพจนานุกรม เกลือแบบสุ่มช่วยป้องกันการโจมตีที่ยึดตามแฮชที่คำนวณล่วงหน้า

เมื่อใช้ทั้งรหัสผ่านและไฟล์คีย์คีย์สุดท้ายจะได้รับดังต่อไปนี้: SHA-256 (SHA-256 (รหัสผ่าน) เนื้อหาไฟล์คีย์) เช่นแฮชของรหัสผ่านหลักจะถูกต่อกันกับไบต์ไฟล์คีย์และไบต์ผลลัพธ์ สตริงถกกับ SHA-256 อีกครั้ง หากไฟล์คีย์ไม่มีขนาด 32 ไบต์ (256 บิต) ไฟล์เหล่านั้นจะถูกแฮชด้วย SHA-256 เช่นกันเพื่อสร้างคีย์ 256 บิต สูตรข้างต้นจะเปลี่ยนเป็น: SHA-256 (SHA-256 (รหัสผ่าน), SHA-256 (เนื้อหาไฟล์กุญแจ))

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


ฉันต้องการจะดูที่ความเห็นสตีฟกิ๊บสันในเรื่องนี้: grc.com/sn/sn-182.txt
jasonh

@jasonh ว้าว! คุณลงคะแนนให้ฉันเพื่อแนะนำการรักษาความปลอดภัยแบบสองปัจจัยโดยมีGibsonการอ้างอิงการสัมภาษณ์ที่คุณนำมาจากเว็บไซต์ของเขาเอง (ใช่ฉันเคยได้ยิน Leo มาก่อนแล้วก็ได้) โปรดเพิ่มคะแนนของคุณที่นี่เป็นคำตอบใหม่เพื่อให้ผู้คนได้รับประโยชน์
nik

7
ใช่ฉันทำ. ฉันเข้าใจว่ามีปัจจัยที่สอง แต่ไม่มีประโยชน์ที่นี่ keyfile จะถูกเก็บไว้จริงด้วยฐานข้อมูลรหัสผ่านตัวเองถ้าคุณเป็นผู้ใช้มือถือ หากคุณสูญเสียการควบคุมฐานข้อมูลคุณอาจสูญเสียการควบคุมไฟล์คีย์เช่นกัน ในฐานะที่เป็นสตีฟกิบสันบันทึกไฟล์สำคัญไม่ได้ให้ความปลอดภัยมากขึ้นถ้ามี
jasonh

2
ปัจจัยที่สองมีประโยชน์ในตัวอย่างของฟุตบอล PayPal ในกรณีนี้คุณมีอุปกรณ์จริงและรหัสผ่าน หากรหัสผ่านของคุณถูกบุกรุกไม่มีเหตุผลที่จะเชื่อว่าฟุตบอลของคุณหายไปในเวลาเดียวกันโดยค่าเริ่มต้น ในการเปรียบเทียบเมื่อสินค้าเป็นฐานข้อมูลรหัสผ่านและกลไกการรักษาความปลอดภัยเป็นเพียงไฟล์อื่นที่อยู่ข้างๆฐานข้อมูลตัวเองมันจะดีแค่ไหน? ไม่มี.
jasonh

2
+1 สำหรับไฟล์คีย์การใช้งานและรหัสผ่านหลัก ดังนั้นแม้ว่าพวกเขาจะได้รับ db และไฟล์คีย์คุณก็ต้องจำรหัสผ่านยาว 1 รายการ พวกเขาไม่สามารถแฮ็คสมองได้ดังนั้นควรฝึกซ้อมการทรมานแทน
Piotr Kula

5

ประเด็นทั้งหมดคือการรักษารหัสผ่านของคุณให้ปลอดภัยดังนั้นนี่จึงไม่ใช่เรื่องง่าย: รหัสผ่าน หากคุณใช้ไฟล์คีย์และคุณสูญเสียการควบคุมฐานข้อมูลรหัสผ่านรหัสผ่านของคุณจะถูกเปิดเผย


4
คุณจะต้องตกอยู่ในความเสี่ยงเสมอหากคุณเก็บ 'รหัสผ่าน' ไว้ที่ใดที่หนึ่ง (ไม่ว่าจะเป็นโน้ตหรือเป็นไฟล์คีย์) ตราบใดที่คุณเก็บรหัสผ่านไว้ในหัว (และมันก็ซับซ้อนพอ) จากนั้นคุณควรจะดีกว่า
Sam

1
เมื่อมีการใช้ทั้งรหัสผ่านและ ไฟล์ที่สำคัญSHA-256(SHA-256(password), key file contents)ที่สำคัญสุดท้ายที่ได้มาดังต่อไปนี้: การเข้าถึงไฟล์อย่างเดียวนั้นไร้ประโยชน์ แต่ความรู้เกี่ยวกับรหัสผ่านที่ไม่มีเนื้อหาไฟล์ทำให้การแยกรหัสทำได้ยากขึ้น และไฟล์นี้ยังเพิ่มsaltรหัสผ่านที่แข็งแกร่งให้กับคุณ
nik

1

ใช้ทั้งสองอย่าง เก็บไฟล์กุญแจของคุณไว้ในแฟลชไดรฟ์แล้วนำไปให้พร้อมกับคุณ แต่ไม่ใช่ที่ใดบนเดสก์ท็อป (เหมือนกับการเขียนรหัสผ่านบนโน้ตย่อ) ฉันใช้วิธีนี้กับพาร์ติชัน HDD ที่เข้ารหัสของฉัน (พร้อม truecrypt) ดังนั้นหากใครยังคงได้รับรหัสผ่านของคุณพวกเขาต้องการ keyfile ด้วย


1
เพียงตรวจสอบให้แน่ใจว่าได้สำรองข้อมูลไฟล์คีย์ของคุณรวมถึงฐานข้อมูลรหัสผ่านด้วย หากหนึ่งในนั้นเคยได้รับความเสียหายคุณจะต้องสำรองข้อมูลใหม่
Torbjørn

0

สำหรับการจัดการมือใหม่ถึงรหัสผ่าน:
รหัสผ่านเท่านั้น
ทำไม
มันตัดไฟล์ของคุณ (mis) เกี่ยวกับการจัดการครึ่งและ จำกัด เพียงหนึ่งไฟล์
KeepassX .kdbx db สามารถรักษาความปลอดภัยด้วยรหัสผ่าน 64 ตัวอักษรผสมกัน นั่นเป็นขอบเขตมากมายในการสร้างรหัสผ่านที่ยาวและปลอดภัย
สิ่งนี้จะช่วยเน้นย้ำว่ารหัสผ่าน (ที่แข็งแกร่ง) (ในหัวของคุณ) เป็นจุดสนใจหลักของคุณ(ไม่ใช่ที่ที่คุณเก็บคีย์ไฟล์ ฯลฯ )
หากคุณมีปัญหาในการจำรหัสผ่าน (แน่นอนเราทุกคนใช้) ใช้ตัวจัดการรหัสผ่าน (เช่น KeepassX) และคุณจะต้องจำรหัสผ่านที่ดีเท่านั้น


1
สิ่งนี้ไม่ตอบคำถาม (เฉพาะเจาะจงมาก) ที่ถูกถาม
Mokubai

-1

ฉันเลือกใช้ไฟล์คีย์ ฉันยังได้สร้างบัญชีอีเมลที่ใช้เพื่อจัดเก็บคีย์ไฟล์ของฉันโดยเฉพาะ (ฉันไม่ชอบที่จะใช้แฟลช USB ทุกครั้งที่ต้องการเข้าถึงบัญชีธนาคารอิเล็กทรอนิกส์ของฉัน)

หากคอมพิวเตอร์ที่ฉันใช้ไม่ใช่คอมพิวเตอร์ส่วนตัวฉันเพียงลงชื่อเข้าใช้บัญชีอีเมลนั้นในคอมพิวเตอร์ที่ฉันต้องการใช้ไฟล์กุญแจจากนั้นลงชื่อเข้าใช้ยังบัญชีอีเมลอื่นที่มี. kdbx รุ่นล่าสุดของฉัน ไฟล์.

สุดท้ายฉันดาวน์โหลด KeePass และติดตั้งบนพีซีใช้คีย์และ. kdbx พร้อมกับรหัสผ่านฐานข้อมูลของฉัน

แน่นอนฉันลบทั้งไฟล์. kdbx และคีย์บนพีซีที่ใช้


10
ฉันจะพิจารณาการรักษาความปลอดภัยที่ไม่ดีนี้ในหลาย ๆ ระดับ
kluka

1
ใช่สวยไร้ประโยชน์และอันตรายที่สุดอย่างแน่นอน; โดยเฉพาะอย่างยิ่งส่วนที่เกี่ยวกับการเปิดไฟล์รหัสผ่านของคุณบนคอมพิวเตอร์ว่า "ไม่ใช่ไฟล์ส่วนตัวของฉัน" Sheesh ไม่ดีอย่างที่ฉันไม่สามารถแสดงได้ว่าการปฏิบัตินี้แย่มาก ฉันมีแล็ปท็อปทำงานที่ไปได้ทุกที่พร้อมกับฉันในขณะที่สะดวกเพราะคนอื่น ๆ (เหมือนในแผนกไอที) "ดูแล" ฉันไม่ไว้ใจที่จะเก็บหรือแม้แต่เปิดรหัสผ่านส่วนตัวของฉัน
nanker

@nanker คุณจะใช้รหัสผ่านส่วนตัว db บนแล็ปท็อปที่ทำงานได้อย่างไร คุณมีทั้ง keyfile และฐานข้อมูลบน usb key หรือไม่?
RED_

2
@RED_ ฉันไม่เคยเปิดฐานข้อมูลส่วนตัวของฉันบนแล็ปท็อปที่ทำงานไม่ว่าจะสะดวกสบายแค่ไหนก็ตาม แล็ปท็อปโหลดสวยมากสำหรับกิจวัตรประจำวันของฉันและแม้ว่าฉันเคยพยายามระบุว่าบริการทั้งหมดที่ทำงานบนแล็ปท็อปคืออะไรฉันยังไม่สามารถจัดการทั้งหมดได้ ดังนั้นฉันจึงไม่สามารถและไม่ไว้ใจมันมากพอที่จะเปิดฐานข้อมูล Keepass ของฉัน โทรหาฉันหวาดระแวงฉันเดา แต่ฉันรู้สึกว่าฉันอยู่ในสถานที่ที่มีข้อมูลที่มีความสุขเท่าที่ความปลอดภัยของรหัสผ่านของฉันจะไป
nanker
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.