เหตุใดจึงมีความล่าช้าใหญ่หลังจากป้อนรหัสผ่านไม่ถูกต้อง

ฉันสังเกตเห็นสิ่งแปลก ๆ (ดีตามฉัน) เกี่ยวกับรหัสผ่าน ตัวอย่างเช่นถ้าฉันพิมพ์รหัสผ่านไม่ถูกต้องในระหว่างการเข้าสู่ระบบจะมีความล่าช้าไม่กี่วินาทีก่อนที่ระบบจะบอกฉัน เมื่อฉันพยายามsudoใช้รหัสผ่านผิดฉันจะต้องรอก่อนที่เชลล์จะบอกว่า "ขออภัยลองอีกครั้ง"

ฉันสงสัยว่าทำไมต้องใช้เวลา "จำ" รหัสผ่านไม่ถูกต้อง สิ่งนี้มีให้เห็นในดิสทริบิวชันต่าง ๆ ที่ฉันใช้ (และแม้กระทั่ง OSX) ดังนั้นฉันคิดว่านี่ไม่ใช่สิ่งที่เฉพาะเจาะจงในการจัดจำหน่าย

— phunehehe
แหล่งที่มา

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

— krozaine

คำตอบ:

นี่เป็นเรื่องความปลอดภัยมันใช้เวลาไม่นานในการตระหนักถึงมัน 2 ช่องโหว่นี้แก้ไขได้:

ความพยายามในการเข้าสู่ระบบ throttles นี้หมายความว่าบางคนไม่สามารถทุบระบบให้เร็วที่สุดเท่าที่จะทำได้เพื่อพยายามที่จะถอดรหัสมัน (1M พยายามเป็นวินาทีหรือไม่ฉันไม่รู้)
หากทำได้ทันทีที่ยืนยันว่าข้อมูลรับรองของคุณไม่ถูกต้องคุณสามารถใช้ระยะเวลาที่ใช้ในการทำให้ข้อมูลประจำตัวของคุณเป็นโมฆะเพื่อช่วยในการเดาว่าส่วนใดของข้อมูลรับรองถูกต้องลดเวลาในการคาดเดาอย่างมาก

เพื่อป้องกันสิ่งทั้งสองนี้ระบบใช้เวลาพอสมควรในการทำฉันคิดว่าคุณสามารถกำหนดเวลารอด้วย PAM ( ดูคำตอบของ Michaels )

วิศวกรรมความปลอดภัย ( 2ed , amazon | 1ed, ฟรี ) ให้คำอธิบายที่ดีกว่าสำหรับปัญหาเหล่านี้

— xenoterracide
แหล่งที่มา

// offtopic gมันไม่ได้เป็นข้อผิดพลาดมันเป็นคุณสมบัติ ;-)

— echox

ลิงค์พันธมิตรของคุณถูกเขียนใหม่โดยอัตโนมัติไปยัง SE ของ btw

— Gelatin

@Tshepang: ดูบทที่ 2โดยเฉพาะอย่างยิ่ง§2.4และ .32.5.3.3

— Gilles

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

— CodesInChaos

ฉันเห็นด้วยกับ CodesInChaos: จุดที่สองของคำตอบนั้นไม่ถูกต้อง สิ่งที่เกิดขึ้นจริงมีดังต่อไปนี้: 1. คำนวณการป้อนข้อมูลของคุณ 2. แฮชนั้นถูกเปรียบเทียบกับแฮชที่เก็บไว้ (ทุกไบต์ของมันแม้ว่าจะพบความแตกต่างอยู่แล้ว) โปรดสังเกตว่าสองขั้นตอนเหล่านี้ไม่ได้เร็วหรือช้าขึ้นอยู่กับว่ารหัสผ่านที่คุณป้อนนั้นถูกต้อง (และอย่างที่คนอื่น ๆ ชี้ไปแล้วการเพิ่มระยะเวลาการนอนหลับจะไม่แก้ไขการโจมตีแบบกำหนดเวลาหากเป็นไปได้)

— ตัวอย่าง

นี่คือเจตนาที่จะลองและ จำกัด การบังคับเดรัจฉาน โดยปกติคุณสามารถแก้ไขได้โดยค้นหาFAIL_DELAYรายการการกำหนดค่า/etc/login.defsและเปลี่ยนค่าของมัน (ฉันเป็น3วินาทีโดยค่าเริ่มต้น) แม้ว่าความคิดเห็นในไฟล์นั้นจะทำให้ดูเหมือนว่า PAM จะบังคับใช้อย่างน้อยหนึ่ง2วินาทีไม่ว่าอะไรก็ตาม

— Michael Mrozek
แหล่งที่มา

นี่คือการป้องกันไม่ให้เป็นมากกว่าการบังคับเดรัจฉาน แต่คะแนนโบนัสสำหรับการรู้ว่าจะกำหนดค่าได้ที่ไหน

— xenoterracide

ฉันคิดว่า fail_delay นั้นสามารถกำหนดค่า/etc/pam.d/loginได้ มองหาpam_faildelay.so delay=

— Steven D

สิ่งที่ป้องกันคุณจากการเขียนเสื้อคลุมสำหรับ sudo ที่เริ่มต้นอินสแตนซ์ sudo ใหม่เมื่อความพยายามไม่ทำงานภายในพูด 0.1 วินาที

— Janus Troelsen

บนระบบ linux ที่ทันสมัยเหตุผลก็คือ pam_unix.so กำหนดความล่าช้าดังกล่าว ในฐานะที่เป็นรายงานก่อนหน้านี้สามารถกำหนดค่าลงไปสองวินาทีโดยการเปลี่ยนแปลงในFAIL_DELAY /etc/login.defsหากคุณต้องการลดความล่าช้าอีกคุณต้องให้ pam_unix.so ตัวเลือก "nodelay" ตัวอย่างเช่นในระบบของฉันหากคุณติดตามการรวมเริ่มต้นจาก/etc/pam.d/sudoคุณจะพบว่าคุณต้องแก้ไขบรรทัดต่อไปนี้/etc/pam.d/system-auth:

auth      required  pam_unix.so     try_first_pass nullok

และเปลี่ยนเป็น:

auth      required  pam_unix.so     try_first_pass nullok nodelay

แต่น่าเสียดายที่ทาง Linux distro ของฉัน (ซุ้มประตู) กำหนดค่าสิ่งที่เดียวกันมากsystem-authไฟล์ได้รับโดยรวมsystem-remote-loginซึ่งจะถูกใช้โดย sshd

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

โดยส่วนตัวแล้วฉันคิดว่าความล่าช้าในการ sudo (และไม่สนใจ SIGINT) เป็นความผิดพลาดครั้งใหญ่ หมายความว่าผู้ใช้ที่รู้ว่าพวกเขาพิมพ์รหัสผ่านผิดพลาดจะไม่สามารถฆ่ากระบวนการและทำให้ผิดหวัง แน่นอนคุณยังสามารถหยุด sudo ด้วย Ctrl-Z ได้เนื่องจาก sudo ไม่ได้จับ SIGTSTP และหลังจากหยุดคุณสามารถฆ่ามันด้วย kill -9 (SIGKILL) มันน่ารำคาญที่จะทำ นั่นหมายความว่าการโจมตีอัตโนมัติสามารถยิงซูโดะออกไปยังเทอร์มินัลหลอกได้ในอัตราที่สูงมาก แต่ความล่าช้านั้นทำให้ผู้ใช้ที่ชอบด้วยกฎหมายและกระตุ้นให้พวกเขาหยุดการทำงานของรูทเชลล์แทนการออกจากพวกเขาเพื่อหลีกเลี่ยงการต้องทำ sudo อีกครั้ง

— user3188445
แหล่งที่มา

เช่นเดียวกับ Fedora การวิเคราะห์ที่ยอดเยี่ยม

— Freedom_Ben

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

— phil294

การตั้งค่า pam-unix เป็นnodelayจะกำหนดเวลารอเป็น 0 โดยวิธีแล้ว FAIL_DELAY จะถูกละเว้น

— phil294

ทำไมไม่ปิดใช้งานการหน่วงเวลาและจากนั้นปิดใช้งานการเข้าสู่ระบบรหัสผ่านระยะไกล (SSH- เท่านั้น) นั่นไม่ได้แก้ปัญหาโดยไม่แนะนำช่องโหว่ความปลอดภัยหรือไม่

— Radon Rosborough