잘못된 비밀번호를 입력 한 후 왜 큰 지연이 발생합니까?


89

암호에 대해 이상한 점이 있습니다. 예를 들어, 로그인 중에 잘못된 비밀번호를 입력하면 시스템에서 알려주기까지 몇 초 지연 될 수 있습니다. sudo잘못된 암호 를 사용 하려고 할 때 쉘에 "죄송합니다. 다시 시도하십시오"라고 말하기 전에 기다려야합니다.

잘못된 비밀번호를 "인식"하는 데 왜 그렇게 오래 걸립니까? 이것은 내가 사용하는 여러 배포판 (그리고 심지어 OSX)에서도 보였으므로 배포 관련 내용이 아니라고 생각합니다.


터미널뿐만 아니라 시작 후 또는 랩톱이 절전 모드 인 경우 초기 세션 로그인 에서도이 사실을 알았습니다. 올바른 암호를 잠금 해제,하지만이 질문 :) 제기 볼 행복한 순간입니다
krozaine

답변:


92

이것은 보안상의 문제이며 실제로 그것을 깨닫는 데 오랜 시간이 걸리지 않습니다. 2 가지 취약점으로 해결 :

  1. 이것은 로그인 시도를 스로틀합니다. 이는 누군가가 시스템을 부수려고 시도하는 것만 큼 빨리 파운드를 낼 수 없다는 것을 의미합니다.

  2. 신임 정보가 올바르지 않은 것으로 확인 된 즉시 신임 정보를 무효화하는 데 걸리는 시간을 사용하여 신임 정보의 일부가 올바른지 추측하여 추측 시간을 크게 줄일 수 있습니다.

이 두 가지를 시스템이 수행하는 데 특정 시간이 걸리는 것을 막기 위해 PAM으로 대기 시간을 구성 할 수 있다고 생각합니다 ( Michaels 답변 참조 ).

보안 공학 ( 2ed , amazon | 1ed, free )은 이러한 문제에 대해 훨씬 더 잘 설명합니다.


4
// offtopic g 버그가 아니라 기능 ;-)
echox

2
귀하의 제휴사 링크는 자동으로 SE의 btw로 다시 작성되었습니다.
젤라틴

1
@Tshepang : 2 장 , 특히 §2.4 및 §2.5.3.3을 참조하십시오 .
Gilles

4
암호 해시를 비교하는 동안 초기 실패와 늦은 실패의 차이는 나노초 단위로 측정됩니다. 적절한 코딩 (일정 시간 메모리 비교)을 사용하면 전혀 차이가 없습니다. 지연을 추가하는 것은 정당화되지 않습니다.
코드 InChaos

2
CodeInChaos에 동의합니다. 두 번째 답변이 잘못되었습니다. 실제로 일어나고있는 일은 다음과 같습니다. 1. 입력 해시가 계산됩니다. 2. 해시가 저장된 해시와 비교됩니다 (차이가 이미 발견 되었더라도 모든 바이트). 입력 한 암호가 올바른지 여부에 따라이 두 단계는 더 빠르거나 느리지 않습니다. (다른 사람들이 이미 지적했듯이, 수면 시간을 추가해도 가능하다면 타이밍 공격을 수정하지는 않습니다)

41

이것은 무차별 강제를 시도하고 제한하려는 의도적 인 것입니다. 일반적으로 FAIL_DELAY구성 항목 을 찾아서 /etc/login.defs값을 변경하여 값을 수정할 수 있습니다 ( 3기본적으로 광산은 초입니다). 파일의 주석은 PAM이 2무엇이든 상관없이 적어도 두 번째 지연을 강제하는 것처럼 들립니다.


9
이것은 단순한 강제 이상의 것을 방지하기위한 것입니다. 어디에 구성해야하는지에 대한 보너스 포인트.
xenoterracide

5
fail_delay도에서 구성 할 수 있다고 생각합니다 /etc/pam.d/login. 찾으십시오pam_faildelay.so delay=
Steven D

8
시도가 0.1 초 이내에 작동하지 않으면 새 sudo 인스턴스를 시작하는 sudo에 대한 래퍼를 작성하지 못하게하는 것은 무엇입니까?
야누스 트롤

11

현대 리눅스 시스템에서 그 이유는 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

불행히도 내 리눅스 배포판 (아치)이 구성 하는 방식은 sshd가 사용 하는 매우 동일한 system-auth파일이 포함됩니다 system-remote-login.

sudo에 대한 지연을 제거하는 것이 안전하지만 로컬 사용자 만 사용하고 로컬 공격자가 우회 할 수 있기 때문에 원격 로그인에 대한 지연을 제거하고 싶지 않을 것입니다. 물론 공유 시스템 인증 파일 만 포함하지 않은 사용자 정의 sudo를 작성하여 문제를 해결할 수 있습니다.

개인적으로 sudo 지연 (SIGINT 무시)은 큰 실수라고 생각합니다. 암호를 잘못 입력했다는 것을 알고있는 사용자는 프로세스를 종료하고 좌절 할 수 없습니다. 물론 sudo는 SIGTSTP를 포착하지 않기 때문에 Ctrl-Z를 사용하여 sudo를 중지 할 수 있으며, 중지 한 후에 kill -9 (SIGKILL)로 죽일 수 있습니다. 그냥 짜증나. 즉, 자동 공격은 의사 터미널의 sudos를 초고속으로 발사 할 수 있음을 의미합니다. 그러나 지연은 합법적 인 사용자를 좌절시키고 다시 sudo를 피하기 위해 루트 쉘을 종료하지 않고 일시 중단하도록 권장합니다.


1
Fedora와 동일합니다. 멋진 분석
Freedom_Ben

훌륭한 답변. 또한 FAIL_DELAY는 최신 데스크탑 시스템에서 더 이상 사용되지 않는다고 생각했습니다. 파티션 / 하드 드라이브 암호화에만 의존해야합니다. 일반적으로 강제 루트 암호를 무차별 적으로 사용하려는 두 번째 사용자는 없습니다. 그러나 잠재적 인 악성 프로그램 안전하지 않은 FAIL_DELAY를 악용하여 루트 액세스 권한을 얻을 수 있습니다.
phil294

pam-unix를 nodelay설정하면 대기 시간이 0으로 설정되고 FAIL_DELAY가 무시됩니다.
phil294

지연을 비활성화 한 다음 원격 비밀번호 로그인을 비활성화하지 않는 이유는 무엇입니까 (SSH 전용)? 보안 취약점이 없으면 문제가 해결되지 않습니까?
라돈 로스 버러
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.