잘못된 암호를 확인하는 것이 올바른 암호를 확인하는 것보다 더 오래 걸리는 이유는 무엇입니까?

잘못된 암호를 확인하는 것이 올바른 암호를 확인하는 것보다 더 오래 걸리는 이유는 무엇입니까?

---

이 질문은 항상 저를 괴롭 혔습니다.

Linux에서 암호를 묻는 메시지가 표시되면 입력 한 내용이 맞으면 거의 지체없이 즉시 확인합니다. 그러나 반대로 잘못된 암호를 입력하면 확인하는 데 시간이 더 걸립니다. 왜 그런 겁니까?

나는 내가 시도한 모든 Linux 배포판 에서 이것을 관찰 했습니다.

---

실제로는 무차별 대입 공격이 초당 수백만 개의 암호를 시도하는 것을 방지하기위한 것입니다. 아이디어는 암호 확인 속도를 제한하는 것이며 따라야 할 규칙이 많이 있습니다.

• 성공적인 사용자 / 암호 쌍은 즉시 성공해야합니다.
• 이 없어야 더 감지 할 수 실패 이유에 식별 차이.

마지막 것이 특히 중요합니다. 다음과 같은 유용한 메시지가 없음을 의미합니다.

Your user name is correct but your password is wrong, please try again

또는:

Sorry, password wasn't long enough

"유효하지 않은 사용자 및 암호"와 "유효한 사용자이지만 유효하지 않은 암호"실패 이유 사이의 응답 시간 차이도 없습니다.

모든 오류는 텍스트 및 기타 정확히 동일한 정보를 제공해야합니다.

일부 시스템은 더 나아가서 각 실패에 대한 지연을 증가 시키거나 3 개의 실패 만 허용 한 다음 재 시도를 허용하기 전에 엄청난 지연을 갖습니다.

---

이로 인해 암호를 추측하는 데 시간이 더 오래 걸립니다.

---

확실하지 않지만 잘못된 암호를 입력 한 후 지연을 통합하여 공격을 더 어렵게 만드는 것이 일반적입니다. 이렇게하면 몇 개의 암호 만 확인하는 데 오랜 시간이 걸리므로 공격을 실질적으로 불가능하게 만듭니다.

생년월일, 고양이 이름 등 몇 가지 암호를 입력하는 것조차 재미가 없습니다.

---

기본적으로 무차별 대입 및 사전 공격을 완화합니다.

에서 리눅스-PAM 응용 프로그램 개발자 가이드 :

지연 계획

extern int pam_fail_delay(pam_handle_t *pamh, unsigned int micro_sec);

이 함수는 pam_authenticate () 호출이 실패한 후 응용 프로그램으로 제어가 반환되기 전에 시간 지연을 용이하게하기 위해 Linux-PAM에서 제공합니다. 이 기능을 사용할 때 응용 프로그램 프로그래머는 다음과 같이 사용할 수 있는지 확인해야합니다.

#ifdef PAM_FAIL_DELAY
    ....
#endif /* PAM_FAIL_DELAY */

일반적으로 응용 프로그램은 pam_authenticate () 또는 pam_chauthtok () 호출을 통해 Linux-PAM에서 사용자를 인증하도록 요청합니다. 이러한 함수는 관련 Linux-PAM 구성 파일에 나열된 각 스택 인증 모듈을 호출합니다. 이 파일의 지시에 따라 모듈 중 하나 이상이 실패하여 pam _... () 호출이 오류를 반환 할 수 있습니다. 응용 프로그램이 계속되기 전에 일시 중지하는 것이 바람직합니다. 이러한 지연의 주된 이유는 보안입니다. 지연은 주로 무차별 대입 사전 공격을 막는 역할을하지만 시간 제한 (비밀 채널) 공격을 방해하는데도 도움이됩니다.

---

보안을 크게 향상시키는 매우 간단하고 사실상 쉬운 방법입니다. 치다:

1. 시스템 A에는 지연이 없습니다. 공격자는 사용자 이름 / 암호 조합을 만드는 프로그램을 가지고 있습니다. 분당 수천 번의 시도 속도로 모든 조합을 시도하고 성공한 모든 로그인을 기록하는 데 몇 시간 밖에 걸리지 않습니다.

2. 시스템 B은 각각의 잘못된 추측 후 5 초 지연을 생성합니다. 공격자의 효율성은 분당 12 번의 시도로 감소하여 무차별 대입 공격을 효과적으로 방해합니다. 몇 시간이 아니라 유효한 로그인을 찾는 데 몇 달이 걸릴 수 있습니다. 해커가 그 환자라면 합법적 일 것입니다. :-)

---

실패한 인증 지연은 로그인 시도 비율을 줄이기 위해 존재합니다. 누군가가 사전이나 사용자 계정에 대해 무차별 대입 공격을 시도하는 경우 해당 공격자는 실패 지연을 기다려야하므로 더 많은 시간을 들여 탐지 할 수있는 기회를 더 많이 제공해야합니다.

로그인 셸로 사용하는 항목에 따라 일반적으로이 지연을 구성하는 방법이 있다는 사실을 알고 싶을 수도 있습니다.

GDM에서 지연은 gdm.conf 파일 (일반적으로 /etc/gdm/gdm.conf에 있음)에 설정됩니다. RetryDelay = x를 설정해야합니다. 여기서 x는 초 단위의 값입니다.

오늘날 대부분의 리눅스 배포판은 /etc/login.defs에 정의 된 FAIL_DELAY를 지원하므로 로그인 시도 실패 후 대기 시간을 설정할 수 있습니다.

마지막으로 PAM을 사용하면 인증 라인에 nodelay 속성을 설정하여 실패 지연을 우회 할 수 있습니다. ( 여기 PAM 및 Linux에 대한 기사입니다 )

---

나는 그것이 응답이 제안하는 것처럼 간단 할 수 있다고 보지 않는다.

올바른 암호에 대한 응답이 (일부 값) 즉각적인 경우 암호가 잘못되었음을 알기 위해 해당 값보다 오래 기다릴 필요가 없습니까? (적어도 확률 적으로 알고 있습니다. 크래킹 목적으로는 괜찮습니다.) 어쨌든이 공격을 병렬로 실행할 것입니다.이 모든 것이 하나의 큰 DoS 환영 매트입니까?

---

이전에 시도한 것은 작동하는 것처럼 보였지만 실제로는 작동하지 않았습니다. 관심이 있다면 위키 편집 기록을 검토해야합니다 ...

What does work (for me) is, to both lower the value of pam_faildelay.so delay=X in /etc/pam.d/login (I lowered it to 500000, half a second), and also add nodelay (preceded by a space) to the end of the line in common-auth, as described by Gabriel in his answer.

auth [success=1 default=ignore] pam_unix.so nullok_secure nodelay

At least for me (debian sid), only making one of these changes will not shorten the delay appreciably below the default 3 seconds, although it is possible to lengthen the delay by only changing the value in /etc/pam.d/login.

This kind of crap is enough to make a grown man cry!

---

On Ubuntu 9.10, and I think new versions too, the file you're looking for is located on

/etc/pam.d/login

edit the line:

auth optional pam_faildelay.so delay=3000000

changing the number 3 with another you may want.

Note that to have a 'nodelay' authentication, I THINK you should edit the file

/etc/pam.d/common-auth

too. On the line:

auth [success=1 default=ignore] pam_unix.so nullok_secure

add 'nodelay' to the final (without quotes). But this final explanation about the 'nodelay' is what I think.

---

I would like to add a note from a developers perspective. Though this wouldn't be obvious to the naked eye a smart developer would break out of a match query when the match is found. In witness, a successful match would complete faster than a failed match. Because, the matching function would compare the credentials to all known accounts until it finds the correct match. In other words, let's say there are 1,000,000 user accounts in order by IDs; 001, 002, 003 and so on. Your ID is 43,001. So, when you put in a correct username and password, the scan stops at 43,001 and logs you in. If your credentials are incorrect then it scans all 1,000,000 records. The difference in processing time on a dual core server might be in the milliseconds. On Windows Vista with 5 user accounts it would be in the nanoseconds.

---

I agree. This is an arbitrary programming decision. Putting the delay to one second instead of three doesn't really hurt the crackability of the password, but makes it more user-friendly.

---

Technically, this deliberate delay is to prevent attacks like the "Linearization attack" (there are other attacks and reasons as well).

To illustrate the attack, consider a program (without this deliberate delay), which checks an entered serial to see whether it matches the correct serial, which in this case happens to be "xyba". For efficiency, the programmer decided to check one character at a time and to exit as soon as an incorrect character is found, before beginning the lengths are also checked.

The correct serial length will take longer to process than an incorrect serial length. Even better (for attacker), a serial number that has the first character correct will take longer than any that has an incorrect first character. The successive steps in waiting time is because each time there's one more loop, comparison to go through on correct input.

• So, attacker can select a four-character string and that the string beginning with x takes the most time. (by guess work)
• Attacker can then fix character as x and vary the second character, in which case they will find that y takes the longest.
• Attacker can then fix the first two characters as xy and vary the third character, in which case they will find that b takes the longest.
• Attacker can then fix the first three character as xyb and vary the fourth character,in which case they will find that a takes the longest.

Hence, the attackers can recover the serial one character at a time.

Linearization.java.

Linearization.docx, sample output

The serial number is four characters long ans each character has 128 possible values. Then there are 128⁴ = 2²⁸ = 268,435,456 possible serials. If attacker must randomly guess complete serial numbers, she would guess the serial number in about 2²⁷ = 134,217,728 tries, which is an enormous amount of work. On the other hand, by using the linearization attack above, an average of only 128/2 = 64 guesses are required for each letter, for a total expected work of about 4 * 64 = 2⁸ = 256 guesses, which is a trivial amount of work.

Much of the written martial is adapted from this (taken from Mark Stamp's "Information Security: Principles and Practice"). Also the calculations above do not take into account the amount of guesswork needed to to figure out the correct serial length.

참고URL : https://stackoverflow.com/questions/712339/why-should-checking-a-wrong-password-take-longer-than-checking-the-right-one