Programing

최선의 분산 형 무차별 대입 대책은 무엇입니까?

lottogame 2020. 6. 13. 10:11
반응형

최선의 분산 형 무차별 대입 대책은 무엇입니까?


첫째, 약간의 배경 지식 : CodeIgniter에 대해 auth + auth 시스템을 구현하고 있다는 사실은 비밀이 아닙니다. 그러나 나는 매우 사소한 도전에 직면 해왔다 (대부분의 인증 라이브러리는 완전히 그리워하지만 제대로 처리해야한다고 주장한다) : 대규모의 분산 된 가변 사용자 이름 무차별 대입 공격을 지능적으로 처리하는 방법 .

나는 모든 일반적인 트릭을 알고 있습니다.

  1. IP / 호스트 당 실패한 시도 횟수 제한 및 위반자 액세스 거부 (예 : Fail2Ban)- 봇넷이 더 똑똑해 지면서 더 이상 작동하지 않습니다.
  2. 로모그래퍼 위를 결합 알려진 '나쁜'IP가 블랙리스트 / 호스트 (예를 들어 DenyHosts) - # 1 떨어지는 봇넷에 의존, 그들은 점점하지 않습니다
  3. 기존 인증과 결합 된 IP / 호스트 화이트리스트 (동적 IP 사용자와 함께 쓸모가없고 대부분의 웹 사이트에서 높은 이탈)
  4. N 분 / 시간 내에 실패한 시도 횟수에 대한 사이트 전체 제한설정하고 몇 분 / 시간 동안 그 이후의 모든 로그인 시도를 제한 (일시 중지) (DoS 공격으로 인해 봇넷 어린이 놀이가 됨)
  5. 로그인 / 암호 옵션이없는 모든 사용자에 대한 필수 디지털 서명 (공개 키 인증서) 또는 RSA 하드웨어 토큰 (단단한 솔루션은 있지만 폐쇄 된 전용 서비스에만 실용적 임)
  6. 강제 매우 강력한 암호 체계 (예를 들어> 기호 (25 개)없는 문자 - 일반 사용자를위한 다시, 너무 비현실적)
  7. 그리고 마지막으로, 보안 문자는 (대부분의 경우에 작동하지만 사용자를위한 성가신입니다 수있는 거의 쓸모 에 대한 결정, 수완 공격자 )

자, 이것들은 이론적으로 실행 가능한 아이디어 일뿐입니다. 사이트를 활짝 열어 놓는 쓰레기 아이디어 많이 있습니다 (예 : 사소한 DoS 공격). 내가 원하는 것은 더 나은 것입니다. 그리고 더 나은 의미는 다음과 같습니다.

  • DoS 및 무차별 대입 공격에 대해 안전해야하며 (+), 약간 은신 한 봇이 레이더에서 계속 작동 할 수있는 새로운 취약점을 도입하지 않아야합니다.

  • 자동화되어야합니다. 작업자가 각 로그인을 확인하거나 의심스러운 활동을 모니터링해야하는 경우 실제 시나리오에서는 작동하지 않습니다.

  • 메인 스트림 웹 사용에 적합해야합니다 (예 : 프로그래머가 아닌 사람이 수행 할 수있는 높은 이탈, 대량 및 공개 등록).

  • 일반 사용자가 짜증을 내거나 좌절을 느끼거나 사이트를 버릴 수있는 지점까지 사용자 경험을 방해 할 수는 없습니다.

  • 정말 안전한 고양이 가 아니라면 고양이와 관련이 없습니다.

(+) '안전하다'는 것은 적어도 편집증 사용자가 자신의 암호를 비밀로 유지하는 능력만큼 안전하다는 의미입니다.

그래서-들어 봅시다! 어떻게 하시겠습니까? 내가 언급하지 않은 모범 사례에 대해 알고 있습니까? 나는 내 자신의 아이디어를 가지고 있음을 인정하지만 (3과 4의 아이디어를 결합), 나는 당황하기 전에 진정한 전문가가 말하게 할 것이다. ;-)


좋아, 충분히 실속; 여기에 내가 지금까지 생각해 낸 것이 있습니다

(죄송합니다, 긴 글입니다. 용감하고 친구여, 여행은 그만한 가치가 있습니다)

원래 게시물의 방법 3과 4를 일종의 '퍼지'또는 동적 화이트리스트로 결합한 다음 , 화이트리스트에없는 IP를 차단하지 않고 단순히 지옥으로 되돌려 보내는 트릭이 있습니다.

이 법안이되어 있습니다 공격이 매우 구체적인 유형을 방해하기위한 것. 실제로, 그것은 인증에 대한 다른 모범 사례 접근 방식과 함께 작동합니다 : 고정 사용자 이름 제한, IP 당 제한, 코드 적용 강력한 암호 정책, 차단되지 않은 쿠키 로그인, 저장하기 전에 모든 암호를 해시, 절대 보안 질문 등 사용

공격 시나리오에 대한 가정

공격자가 가변 사용자 이름을 대상으로하는 경우 사용자 이름 제한이 실행되지 않습니다. 공격자가 봇넷을 사용 중이거나 넓은 IP 범위에 액세스 할 수있는 경우 IP 제한은 무력합니다. 공격자가 사용자 목록을 미리 스크랩 한 경우 (일반적으로 공개 등록 웹 서비스에서 가능) '사용자를 찾을 수 없음'오류 수에 따라 진행중인 공격을 탐지 할 수 없습니다. 또한 시스템 전체 (모든 사용자 이름, 모든 IP) 제한을 제한하는 경우 그러한 공격은 공격 기간과 제한 기간 동안 전체 사이트를 DoS합니다.

그래서 우리는 다른 것을해야합니다.

대책의 첫 번째 부분 : 화이트리스트

우리가 상당히 확신 할 수있는 것은 공격자가 수천 명의 사용자 (+)의 IP 주소를 탐지하고 동적으로 스푸핑 할 수 없다는 것입니다. 어떤하게 허용 된 사이트 목록 가능. 다시 말해, 각 사용자에 대해 사용자가 이전에 (최근에) 로그인 한 (해시 된) IP 목록을 저장합니다.

따라서 우리의 화이트리스트 체계는 잠긴 '정문'기능을하며, 로그인하려면 사용자가 인식 된 '좋은'IP 중 하나에서 연결해야합니다. 이 '정문'에 대한 무차별 대입 공격은 사실상 불가능합니다 (+).

(+) 공격자가 서버, 모든 사용자 상자 또는 연결 자체를 소유하지 않는 한-더 이상 '인증'문제가 없으면 프랜차이즈 크기의 실제 플러그 FUBAR 상황

대책의 두 번째 부분 : 인식 할 수없는 IP의 시스템 전체 조절

사용자가 컴퓨터를 자주 전환하거나 동적 IP 주소에서 연결하는 공개 등록 웹 서비스에 대한 화이트리스트 작업을 수행하려면 인식 할 수없는 IP에서 연결하는 사용자를 위해 '고양이 문'을 열어 두어야합니다. 요령은 봇넷이 막히고 합법적 인 사용자가 가능한 한 귀찮게하도록 문을 디자인하는 것 입니다.

내 계획에서 이것은 승인되지 않은 IP에 의한 매우 제한적인 최대 로그인 실패 횟수를 3 시간 (예 : 서비스 유형에 따라 더 짧거나 더 긴 기간을 사용하는 것이 더 현명 할 수 있음) 동안 설정함으로써 달성됩니다. 그 제한을 세계화하는 것 , 즉 모든 사용자 계정에 대해

이 방법을 사용하면 느린 (1 ~ 2 분 사이의) 무차별 대포도 빠르고 효과적으로 탐지 할 수 있습니다. 물론, 매우 느린 무차별 대입은 여전히 ​​눈에 띄지 않지만, 너무 느린 속도는 무차별 대입 공격의 목적을 무너 뜨립니다.

이 제한 메커니즘으로 달성하고자하는 것은 최대 한계에 도달하면 '고양이 문'슬램이 잠시 닫히지 만 정문 사용자는 일반적인 방법으로 연결하는 정식 사용자에게 열려 있다는 것입니다.

  • 인식 된 IP 중 하나에서 연결하여
  • 또는 영구 로그인 쿠키를 사용하여 (어디서나)

공격 중에 영향을받는 유일한 합법적 인 사용자, 즉 제한이 활성화 된 동안 – 알 수없는 위치에서 또는 동적 IP로 로그인 한 영구 로그인 쿠키가없는 사용자가됩니다. 스로틀 링이 종료 될 때까지 해당 사용자는 로그인 할 수 없습니다 (공격자가 스로틀 링에도 불구하고 공격자가 봇넷을 계속 실행 한 경우 시간이 걸릴 수 있음).

봇이 여전히 망치로 쳐져있는 동안에도이 작은 부분의 사용자가 그렇지 않으면 봉인 된 고양이 문을 쥐어 짜기 위해 CAPTCHA와 함께 '백업'로그인 양식을 사용합니다. 따라서 "죄송하지만 현재이 IP 주소에서 로그인 할 수 없습니다"메시지가 표시되면 " 보안 백업 로그인-휴먼 만 ( 봇 : 거짓말 없음 ) " 이라는 링크를 포함 시키십시오 . 농담은 그 링크를 클릭 할 때 사이트 전체 조절을 우회하는 재차 인증 된 로그인 양식을 제공합니다. 그들은 인간과 올바른 로그인 + 암호를 알고 (및 보안 문자를 읽을 수있는) 경우 그 방법은, 그들은 것입니다 결코 그들이 알 수없는 호스트에서 연결하고 자동 로그인 쿠키를 사용하지 않는 경우에도 서비스가 거부되지 않습니다.

아, 그리고 간단히 설명하자면 : 보안 문자가 일반적으로 악하다고 생각하기 때문에 '백업'로그인 옵션은 제한이 활성화 된 동안에 나타납니다 .

이와 같은 지속적인 공격이 여전히 DoS 공격의 한 형태를 구성한다는 것을 부인할 수는 없지만 설명 된 시스템을 사용하면 사용자의 작은 하위 집합 인 것으로 의심되는 대상, 즉 "나를 기억하십시오"쿠키가 발생하고 공격이 진행되는 동안 로그인이 발생하며 일반적인 IP 중 하나에서 로그인하지 않으며 보안 문자를 읽을 수 없습니다. 봇 공격 중에는 해당 기준 (특히 봇 및 실제로 운이 좋지 않은 장애인)에 대해 모두 거부 할 수있는 사람 만 제외됩니다.

편집 : 실제로, 나는 '잠금'중에 보안 문자 문제가있는 사용자조차 통과 할 수있는 방법을 생각했습니다. 백업 보안 문자 로그인 대신 또는 보완으로 사용자에게 일회용 옵션을 제공합니다 , 사용자 별 잠금 코드를 자신의 이메일로 전송하여 제한을 우회하는 데 사용할 수 있습니다. 이것은 내 '불쾌'임계 값을 확실히 넘어서지 만 작은 사용자 하위 집합의 최후의 수단 으로 만 사용되므로 계정에서 여전히 잠겨 있기 때문에 허용됩니다.

(또한 여기에 설명 된 불쾌한 분산 버전보다 공격이 정교하지 않은 경우에는 이러한 일이 발생 하지 않습니다 . 공격이 단지 몇 개의 IP에서 발생하거나 몇 명의 사용자 이름 만 공격하는 경우 훨씬 일찍 차단됩니다. 사이트 전체에 영향 미치지 않음 )


그것이 그것이 소리이고 내가 놓친 훨씬 더 간단한 해결책이 없다는 것을 확신하면 이것이 바로 인증 라이브러리에서 구현할 대책입니다. 사실, 안보에는 잘못된 일을하는 미묘한 방법이 많이 있으며, 허위 가정이나 절망적으로 잘못된 논리를 만드는 것은 아닙니다. 따라서 모든 피드백, 비판 및 개선, 미묘한 부분 등은 높이 평가됩니다.


몇 가지 간단한 단계 :

일반적인 사용자 이름을 블랙리스트에 등록하고 허니팟으로 사용하십시오. 관리자, 손님 등 ...이 이름으로 계정을 만들도록 허용하지 마십시오. 누군가 로그인을 시도하면 다른 사람이하지 말아야 할 일임을 알 수 있습니다.

사이트의 실제 전원을 사용하는 사람은 모두 안전한 암호를 사용해야합니다. 관리자 / 운영자가 문자, 숫자 및 기호가 혼합 된 더 긴 암호를 갖도록 요구합니다. 일반 사용자의 간단한 암호를 설명과 함께 거부하십시오.

가장 간단한 방법 중 하나는 다른 사람이 자신의 계정에 로그인하려고 할 때 사람들에게 알리고 그렇지 않은 경우 사건을보고 할 수있는 링크를 제공하는 것입니다. "누군가 수요일 오전 4시 20 분에 계정에 로그인을 시도했습니다. 그렇지 않은 경우 여기를 클릭하십시오."와 같은 간단한 메시지 공격에 대한 통계를 유지할 수 있습니다. 사기성 액세스가 갑자기 증가하는 것을 발견하면 모니터링 및 보안 조치를 강화할 수 있습니다.


무차별 대입 공격의 MO를 제대로 이해하면 하나 이상의 사용자 이름이 지속적으로 시도됩니다.

내가 아직 보지 못했다고 생각되는 두 가지 제안이 있습니다.

  • 나는 항상 표준 관행이 모든 사용자에 대한 각 잘못된 로그인 후 짧은 지연 (1 초 정도)을 갖는 것이라고 생각했습니다. 이것은 무차별 대입을 막지 만, 1 초 지연으로 사전 공격이 얼마나 오래 지속될지는 모르겠습니다. (1 만 단어 사전 == 10,000 초 == 약 3 시간. 흠. 충분하지 않습니다.)
  • 사이트 전체의 속도 저하 대신에 사용자 이름 스로틀이 아닌 이유는 무엇입니까? 각 잘못된 시도로 인해 스로틀이 점점 가혹 해집니다 (최대 한도, 실제 사용자는 여전히 로그인 할 수 있습니다)

편집 : 사용자 이름 스로틀에 대한 의견에 대한 답변 : 이것은 공격의 출처와 상관없이 사용자 이름 특정 스로틀입니다.

사용자 이름이 제한되면 조정 된 사용자 이름 공격 (멀티 IP, IP 당 단일 추측, 동일한 사용자 이름)조차도 잡힐 수 있습니다. 공격자가 시간 초과 동안 다른 사용자 / 패스를 자유롭게 시도하더라도 개별 사용자 이름은 스로틀에 의해 보호됩니다.

공격자의 관점에서 시간 초과 동안 100 개의 암호를 처음으로 추측하여 계정 당 하나의 잘못된 암호를 신속하게 발견 할 수 있습니다. 같은 기간 동안 만 50 초를 추측 할 수 있습니다.

사용자 계정 관점에서 볼 때 추측이 여러 소스에서 나온 경우에도 암호를 깨 뜨리려면 여전히 동일한 평균 추측 횟수가 필요합니다.

공격자들에게는 기껏해야 1 개의 계정과 100 개의 계정을 분리하는 것이 같은 노력이 될 것입니다. 그러나 사이트 전체를 제한하지 않기 때문에 조절판을 매우 빠르게 증가시킬 수 있습니다.

추가 개선 :

  • 여러 계정을 추측하는 IP 감지-408 요청 시간 초과
  • 같은 계정을 추측하고있는 IP를 감지합니다.-408 번의 많은 추측 후 요청 시간 초과.

위의 내용을 구체화 할 수있는 UI 아이디어 (이 맥락에서는 적합하지 않을 수 있음)

  • 비밀번호 설정을 제어하는 ​​경우 비밀번호가 얼마나 강력한 지 사용자 에게 표시하면 더 나은 비밀번호 를 선택할 수 있습니다.
  • 로그인 페이지 를 제어 하는 경우 단일 사용자 이름에 대한 작은 (예 : 10) 추측 후 CAPTCHA를 제공하십시오.

인증에는 세 가지 요소가 있습니다.

  1. 사용자 무언가를 알고 있습니다 (예 : 비밀번호)
  2. 사용자 에게는 무언가가 있습니다 (예 : 열쇠 고리)
  3. 사용자 무엇인가 (즉, 망막 스캔)

일반적으로 웹 사이트는 정책 # 1 만 시행합니다. 대부분의 은행조차 정책 1 만 시행합니다. 대신 2 단계 인증에 "다른 것을 알고 있습니다"접근 방식을 사용합니다. (IE : 사용자는 자신의 암호와 어머니의 성함을 알고 있습니다.) 가능하다면 두 번째 인증 요소를 추가하는 방법은 그리 어렵지 않습니다.

256 자 정도의 임의성을 생성 할 수 있으면 16x16 테이블에서이를 구성한 다음 사용자에게 A-14 셀 테이블의 값을 제공하도록 요청할 수 있습니다. 사용자가 가입하거나 비밀번호를 변경하면 표를주고 인쇄하여 저장하도록 지시하십시오.

이러한 접근 방식의 어려움은 사용자가 비밀번호를 잊어 버린 경우 표준 "이 질문에 대답하고 새 비밀번호를 입력"할 수 없다는 것입니다. 이는 무차별 대입에 취약하기 때문입니다. 또한 이메일이 손상 될 수 있으므로 재설정하거나 새 이메일로 이메일을 보낼 수 없습니다. (Makeuseof.com 및 도난당한 도메인 참조)

새끼 고양이와 관련된 또 다른 아이디어는 BOA가 SiteKey라고 부르는 것입니다. 간단히 말해, 사용자가 등록 할 때 이미지를 업로드하도록하고 로그인을 시도 할 때 8 개 또는 15 개 이상의 임의의 이미지 중에서 이미지를 선택하도록 요청하십시오. 따라서 사용자가 새끼 고양이의 사진을 업로드하면 이론적으로 다른 새끼 고양이 (또는 꽃 등)에서 어떤 사진이 있는지 정확히 알 수 있습니다. 이 접근 방식의 유일한 실제 취약점은 MITM (Man-in-the-Middle) 공격입니다.

새끼 고양이가없는 또 하나의 아이디어는 사용자가 시스템에 액세스하는 IP를 추적하고 그들이 가지고있는 주소에서 로그인 할 때 추가 인증 (captcha, 키티 선택,이 테이블에서 키 선택)을 수행하도록 요구하는 것입니다. 아니에요 또한 Gmail과 마찬가지로 사용자가 최근에 로그인 한 위치를 볼 수 있습니다.

새로운 아이디어 편집 :

로그인 시도를 확인하는 다른 방법은 사용자가 로그인 페이지에서 왔는지 여부를 확인하는 것입니다. 리퍼러는 쉽게 위조 될 수 있으므로 확인할 수 없습니다. 사용자가 로그인 페이지를 볼 때 _SESSION var에 키를 설정 한 다음 로그인 정보를 제출할 때 키가 있는지 확인해야합니다. 봇이 로그인 페이지에서 제출하지 않으면 로그인 할 수 없습니다. 쿠키를 사용하여 쿠키를 설정하거나 양식에로드 된 후 정보를 추가하여 프로세스에 javascript를 포함시켜이를 촉진 할 수도 있습니다. 또는 양식을 두 개의 다른 제출로 나눌 수 있습니다 (예 : 사용자가 사용자 이름을 입력하고 제출 한 다음 새 페이지에서 비밀번호를 입력 한 후 다시 제출).

이 경우 키가 가장 중요한 측면입니다. 이를 생성하는 일반적인 방법은 사용자 데이터, IP 및 제출 시간의 조합입니다.


이 문제에 대한 비용-편익 분석을 수행했는지 여부를 문의해야합니다. 많은 암호를 추측하기에 충분한 웹 존재를 가진 공격자로부터 자신을 보호하려고하는 것처럼 들립니다 (IP 조절을 기각 한 이후). 이런 종류의 공격 비용은 (거의) 얼마입니까? 보호하려는 계정의 가치보다 더 비쌉니까? 얼마나 많은 gargantuan 봇넷이 당신이 원하는 것을 원하십니까?

대답은 '아니오'일 수도 있지만, 그렇다면, 보안 전문가로부터 도움을 받으시기 바랍니다. 프로그래밍 기술 (및 StackOverflow 점수)은 보안 노하우와 밀접한 관련이 없습니다.


I had previously answered a very similar question over at How can I throttle user login attempts in PHP. I'll reiterate the proposed solution here as I believe many of you will find it informational and useful to see some actual code. Please bare in mind that using a CAPTCHA might not be the best solution due to the increasingly accurate algorithms being used in CAPTCHA busters nowadays:

You cannot simply prevent DoS attacks by chaining throttling down to a single IP or username. Hell, you can't even really prevent rapid-fire login attempts using this method.

Why? Because the attack can span multiple IPs and user accounts for the sake of bypassing your throttling attempts.

I have seen posted elsewhere that ideally you should be tracking all failed login attempts across the site and associating them to a timestamp, perhaps:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Decide on certain delays based on the overall number of failed logins in a given amount of time. You should base this on statistical data pulled from your failed_logins table as it will change over time based on the number of users and how many of them can recall (and type) their password.


10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Query the table on every failed login attempt to find the number of failed logins for a given period of time, say 15 minutes:


SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

If the number of attempts over the given period of time is over your limit, either enforce throttling or force all user's to use a captcha (i.e. reCaptcha) until the number of failed attempts over the given time period is less than the threshold.

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Using reCaptcha at a certain threshold would ensure that an attack from multiple fronts would be minimized and normal site users would not experience a significant delay for legitimate failed login attempts. I can't gaurantee prevention, as it's already been expanded upon that CAPTCHA's can be busted. There are alternative solutions, perhaps a variant of "Name this animal", which could work quite well as a substitute.


To summarize Jens' scheme into a pseudo state transition diagram/rulebase:

  1. user + password -> entry
  2. user + !password -> denied
  3. user + known_IP(user) -> front door, // never throttle
  4. user + unknown_IP(user) -> catflap
  5. (#denied > n) via catflaps(site) -> throttle catflaps(site) // slow the bots
  6. catflap + throttle + password + captcha -> entry // humans still welcome
  7. catflap + throttle + password + !captcha -> denied // a correct guess from a bot

Observations:

  • Never throttle the front door. The Elbonian state police have your computer, in your house, but are unable to interrogate you. Brute force is a viable approach from your computer.
  • If you provide a "Forgetten your password?" link, then your email account becomes part of the attack surface.

These observations cover a different type of attack to the ones you are trying to counter.


Looks like you are trying to defend against slow distributed brute force. Not that much you can do about it. We are using a PKI and no password logins. It helps, but if your clients chance workstations every once in a while, this is not very applicable.


Disclaimer: I work for a two-factor company, but am not here to plug it. Here're some observations.

Cookies can be stolen with XSS and browser vulns. Users commonly change browsers or clear their cookies.

Source IP addresses are simultaneously dynamically variable and spoofable.

Captcha is useful, but doesn't authenticate a specific human.

Multiple methods can be combined successfully, but good taste is certainly in order.

Password complexity is good, anything password-based critically depends on passwords having sufficient entropy. IMHO, a strong password written down in a secure physical location is better than a weak password in memory. People know how to evaluate the security of paper documents much better than they know how to figure the effective entropy in their dog's name when used as a password for three different websites. Consider giving users the ability to print out a big or small page full of one-time use pass codes.

Security questions like "what was your high-school mascot" are mostly another lousy form of "something you know", most of them are easily guessable or outright in the public domain.

As you noted, throttling back failed login attempts is a trade-off between preventing brute-force attacks and ease of DoSing an account. Aggressive lockout policies may reflect a lack of confidence in password entropy.

I personally don't see the the benefit to enforcing password expiration on a website anyway. Attacker gets your password once, he can change it then and comply with that policy just as easily as you can. Perhaps one benefit is that the user might notice sooner if the attacker changes the account password. Even better would be if the the user were somehow notified before the attacker gained access. Messages like "N failed attempts since last login" are useful in this respect.

The best security comes from a second factor of authentication which is out-of-band relative to the first. Like you said, hardware tokens in the "something you have" are great, but many (not all) have real admin overhead associated with their distribution. I don't know of any biometric "something you are" solutions good for websites. Some two-factor solutions work with openid providers, some have PHP/Perl/Python SDKs.


My highest recommendation is to simply make sure that you keep users informed of bad login attempts to their accounts-- Users will likely take the strength of their password much more seriously if they are presented with evidence that somebody is actually trying to get into their account.

I actually caught somebody that hacked into my brother's myspace account because they had tried to get into the gmail account I setup for him and used the 'reset my password by email' feature... which went to my inbox.


  1. What about requiring a one-time-password before entering their normal password? That would make it very obvious that someone was attacking before they got many opportunities to guess the main password?

  2. Keep a global count/rate of login failures - this is the indicator for an attack - during an attack be stricter about login failures e.g. ban IPs more rapidly.


I don't believe there is a perfect answer but I would be inclined to approach it on a basis of trying to confound the robots if an attack is sensed.

Off the top of my mind:

Switch to an alternate login screen. It has multiple username and password blanks which really do appear but only one of them is in the right place. The field names are RANDOM--a session key is sent along with the login screen, the server can then find out what fields are what. Succeed or fail it's then discarded so you can't try a replay attack--if you reject the password they get a new session ID.

Any form that is submitted with data in a wrong field is assumed to be from a robot--the login fails, period, and that IP is throttled. Make sure the random field names never match the legit field names so someone using something that remembers passwords isn't mislead.

Next, how about a different sort of captcha: You have a series of questions that won't cause problems for a human. However, they are NOT random. When the attack starts everyone is given question #1. After an hour question #1 is discarded, never to be used again and everyone gets question #2 and so on.

The attacker can't probe to download the database to put into his robot because of the disposable nature of the questions. He has to send new instructions out to his botnet within an hour to have any ability to do anything.


Since several folks included CAPTCHA as a fallback human mechanism, I'm adding an earlier StackOverflow question and thread on CAPTCHA's effectiveness.

Has reCaptcha been cracked / hacked / OCR’d / defeated / broken?

Using CAPTCHA doesn't limit improvements from your throttling and other suggestions, but I think the number of answers that include CAPTCHA as a fallback should consider the human-based methods available to people looking to break security.


You could also throttle based on the strength of a users password.

When a user registers or changes their password you calculate a strength rating for their password, say between 1 and 10.

Something like "password" scores a 1 whereas "c6eqapRepe7et*Awr@ch" might score a 9 or 10 and the higher the score the longer it takes for throttling to kick in.


The first answer I've usually heard when asking this question is to change ports, but forget about that and just disable IPv4. If you only allow clients from IPv6 networks you'r no longer pray for simple network scanning and attackers will resort to DNS lookups. Don't run on the same address as your Apache(AAAA)/Sendmail(MX->AAAA)/what have you given out to everybody(AAAA). Make sure your zone can't be xferd, wait you'r allowing your zone to be downloaded by anybody?

If the bots find your server setup new hostnames, just prepend some gibberish to your hostnames, and change your address. Leave the old names and even setup **honeypot names for the bot net to timeout on.

** Test your reverse(PTR) records(under ip6.arpa.) to see if they can be used to zero in on /4's that have records VS /4s that don't. I.E. Typically ip6.arpa would have ~32 "."s in an address but trying with the last few missing might elude the network blocks that have records VS others that don't. If you take that further it becomes possible to skip large portions of the address space.

In the worst case users will have to setup an IPv6 tunnel, it's not like they'd have to go as far as VPNing into a DMZ... Though one wonders why that's not the first option.

Also Kerberos is cool, but IMHO LDAP blows(What's technically wrong with NISPlus? I've read that Sun decided that users wanted LDAP and because of this they dropped NIS+). Kerberos does work fine without LDAP or NIS, just have to manage users on a host by host basis. Using Kerberos gives you an easy to use, if not automated, PKI.


Bit late here but I was thinking, assuming a hard case - the attacker uses a lot of random IPs, random user names and a random password selected from say a list of the 10,000 most popular.

One thing you could do, especially if the system seems under attack in that there are a lot of wrong password attempts on the system and especially if the password is low entropy is to ask a secondary question like what are your parents first names, for example. If an attacker hits a million accounts trying the password 'password1' there's a good chance they'll get a lot but their odds of also getting the names right would reduce successes dramatically.

참고URL : https://stackoverflow.com/questions/479233/what-is-the-best-distributed-brute-force-countermeasure

반응형