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

첫째, 약간의 배경 지식 : 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 주소에서 로그인 할 수 없습니다"메시지가 표시되면 " 보안 백업 로그인-휴먼 만 ( 봇 : 거짓말 없음 ) " 이라는 링크를 포함 시키십시오 . 농담을 제외하고는 해당 링크를 클릭하면 사이트 전체 조절을 우회하는 reCAPTCHA 인증 로그인 양식을 제공합니다. 그들은 인간과 올바른 로그인 + 암호를 알고 (및 보안 문자를 읽을 수있는) 경우 그 방법은, 그들은 것입니다 결코 그들이 알 수없는 호스트에서 연결하고 자동 로그인 쿠키를 사용하지 않는 경우에도 서비스가 거부되지 않습니다.

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

이와 같은 지속적인 공격이 여전히 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 및 제출 시간의 조합입니다.

이전에 PHP에서 사용자 로그인 시도를 조절할 수 있는 방법 에서 매우 비슷한 질문에 답변했습니다 . 많은 사람들이 정보를 얻고 실제 코드를 보는 것이 유용하다고 생각하기 때문에 여기에서 제안 된 솔루션을 반복하겠습니다. 요즘에는 보안 문자 버스터에서 점점 더 정확한 알고리즘이 사용되고 있기 때문에 보안 문자를 사용하는 것이 최선의 해결책이 아닐 수도 있습니다.

제한을 단일 IP 또는 사용자 이름으로 연결하여 DoS 공격을 막을 수는 없습니다. 이 방법을 사용하면 빠른 로그인 시도를 막을 수조차 없습니다.

왜? 스로틀 링 시도를 우회하기 위해 공격이 여러 IP 및 사용자 계정으로 확장 될 수 있기 때문입니다.

나는 다른 곳에서 게시 된 것을 보았는데 이상적으로는 사이트 전체에서 실패한 모든 로그인 시도를 추적하고 타임 스탬프와 관련이 있어야합니다.

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;

주어진 시간 동안 로그인에 실패한 전체 횟수 에 따라 특정 지연을 결정하십시오 . 사용자 수와 암호를 기억 (및 입력) 할 수있는 사용자 수에 따라 시간이 지남에 따라 변경 되므로 failed_logins테이블 에서 가져온 통계 데이터를 기반으로해야합니다.

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

실패한 로그인 시도마다 테이블을 쿼리하여 주어진 시간 동안 실패한 로그인 수를 찾으십시오 (예 : 15 분).

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

주어진 시간 동안 시도 횟수가 제한을 초과하는 경우 제한을 적용하거나 주어진 시간 동안 실패한 시도 횟수가 임계 값보다 작을 때까지 모든 사용자가 보안 문자 (예 : reCaptcha)를 사용하도록합니다.

// 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;
    }
}

특정 임계 값에서 reCaptcha를 사용하면 여러 전선에서의 공격이 최소화 되고 정상적인 사이트 사용자는 합법적 인 로그인 시도 실패에 대해 상당한 지연이 발생하지 않습니다. CAPTCHA가 파열 될 수 있다는 점에서 이미 확장되었으므로 보장을받을 수 없습니다. 대안으로, 대체로 잘 작동 할 수있는 "이 동물 이름 지정"의 변형이있을 수 있습니다.

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

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

Jens의 체계를 의사 상태 전이 다이어그램 / 규칙베이스로 요약하려면 :

1. 사용자 + 비밀번호-> 항목
2. 사용자 +! password-> 거부
3. 사용자 + known_IP (사용자)-> 정문, // never throttle
4. 사용자 + unknown_IP (사용자)-> catflap
5. (#denied> n) catflaps (site)-> throttle catflaps (site)를 통해 // slow the bots
6. catflap + 스로틀 + 비밀번호 + 보안 문자-> 항목 // humans still welcome
7. catflap + 스로틀 + 비밀번호 +! captcha-> 거부 // a correct guess from a bot

관찰 :

• 전면 도어를 조절하지 마십시오. 엘보 니아 주 경찰은 집에 컴퓨터를 가지고 있지만 심문 할 수는 없습니다. 무차별 대입은 컴퓨터에서 실행 가능한 접근 방식입니다.
• "비밀번호를 잊어 버리셨습니까?" 링크를 클릭하면 이메일 계정이 공격 영역의 일부가됩니다.

이러한 관찰에는 대응하려는 공격에 대한 다른 유형의 공격이 포함됩니다.

느리게 분산 된 무차별 대항으로부터 방어하려고하는 것 같습니다 . 그렇게 할 수있는 일은 많지 않습니다. PKI를 사용하고 있으며 비밀번호 로그인이 없습니다. 도움이되지만 클라이언트가 가끔씩 워크 스테이션을 사용할 수있는 경우에는 적용 할 수 없습니다.

면책 조항 : 저는 이중 회사에서 일하지만 플러그를 꽂으려고 여기에 없습니다. 여기 몇 가지 관찰 사항이 있습니다.

쿠키는 XSS 및 브라우저 취약점으로 도난 당할 수 있습니다. 사용자는 일반적으로 브라우저를 변경하거나 쿠키를 지 웁니다.

소스 IP 주소는 동시에 동적으로 가변적이며 스푸핑 가능합니다.

보안 문자는 유용하지만 특정 사람을 인증하지는 않습니다.

여러 가지 방법을 성공적으로 결합 할 수 있지만 맛이 좋은 것은 확실합니다.

암호 복잡성은 양호합니다. 암호 기반의 모든 것은 엔트로피가 충분한 암호에 달려 있습니다. 안전한 실제 위치에 기록 된 강력한 암호 인 IMHO는 메모리의 취약한 암호보다 낫습니다. 사람들은 세 가지 다른 웹 사이트의 암호로 사용될 때 개 이름에 효과적인 엔트로피를 계산하는 방법을 아는 것보다 종이 문서의 보안을 훨씬 잘 평가하는 방법을 알고 있습니다. 사용자에게 일회용 패스 코드로 가득 찬 크거나 작은 페이지를 인쇄 할 수있는 기능을 제공하십시오.

"고등학교 마스코트는 무엇 이었습니까?"와 같은 보안 문제는 대부분 "알고있는 것"의 또 다른 형편없는 형태이며, 대부분 공개 도메인에서 쉽게 추측 할 수 있습니다.

앞에서 언급했듯이, 로그인 시도 실패를 억제하는 것은 무차별 대입 공격 방지와 DoSing 계정 용이성 간의 절충입니다. 공격적인 잠금 정책은 암호 엔트로피에 대한 신뢰 부족을 반영 할 수 있습니다.

나는 개인적으로 웹 사이트에서 암호 만료를 시행하는 이점을 보지 못합니다. 공격자는 비밀번호를 한 번 받으면 비밀번호를 변경하고 최대한 쉽게 해당 정책을 준수 할 수 있습니다. 공격자가 계정 암호를 변경하면 사용자가 더 빨리 알 수 있다는 이점이있을 수 있습니다. 침입자가 액세스하기 전에 사용자에게 어떻게 든 통지를받는 것이 더 좋습니다. "마지막 로그인 이후 N 회 시도 실패"와 같은 메시지가 이와 관련하여 유용합니다.

최상의 보안은 첫 번째 인증에 비해 대역 외인 두 번째 인증 요소에서 비롯됩니다. 당신이 말했듯이, "당신이 가진 것"에있는 하드웨어 토큰은 훌륭하지만, (전부는 아님) 많은 것들이 그들의 분배와 관련된 실제 관리 오버 헤드를 가지고 있습니다. 나는 웹 사이트에 적합한 생체 인식 "당신이 무엇인가"솔루션을 모른다. 일부 2 단계 솔루션은 openid 공급자와 함께 작동하며 일부는 PHP / Perl / Python SDK가 있습니다.

가장 좋은 방법은 사용자가 자신의 계정에 대한 잘못된 로그인 시도를 사용자에게 계속 알리 도록하는 것입니다. 사용자가 누군가가 실제로 자신의 계정에 침입하려고한다는 증거가 제시되면 사용자는 암호를 훨씬 더 심각하게 생각할 것입니다 .

나는 실제로 내 동생의 마이 스페이스 계정을 해킹 한 사람을 잡았습니다. 왜냐하면 그들은 그들이 그를 위해 설정 한 gmail 계정에 들어 가려고 시도하고 '메일로 비밀번호 재설정'기능을 사용했기 때문에 ...받은 편지함으로 이동했습니다.

1. 일반 비밀번호를 입력하기 전에 일회용 비밀번호가 필요합니까? 그것은 누군가 주 암호를 추측 할 수있는 많은 기회를 갖기 전에 공격하고 있다는 것을 명백하게 보여줄 것입니까?

2. 전체 로그인 실패 횟수 / 로그인 실패율 (이것은 공격의 지표 임)-공격시 로그인 실패에 대해 더 엄격해야합니다 (예 : IP 금지).

나는 완벽한 답이 있다고 생각하지는 않지만 공격이 감지되면 로봇을 혼란스럽게하려고 시도하여 접근하는 경향이 있습니다.

내 마음의 꼭대기에서 :

대체 로그인 화면으로 전환하십시오. 그것은 실제로 나타나는 여러 개의 사용자 이름과 암호 공백을 가지고 있지만 그중 하나만 올바른 위치에 있습니다. 필드 이름은 RANDOM입니다. 세션 키는 로그인 화면과 함께 전송되며 서버는 어떤 필드가 무엇인지 알아낼 수 있습니다. 성공 또는 실패한 경우 버려 지므로 재생 공격을 시도 할 수 없습니다. 비밀번호를 거부하면 새 세션 ID를 얻습니다.

잘못된 필드에 데이터와 함께 제출 된 모든 양식은 로봇에서 온 것으로 가정합니다 (로그인 실패, 기간 및 IP 제한). 임의의 필드 이름이 합법적 인 필드 이름과 절대 일치하지 않도록 암호를 기억하는 것을 사용하는 사람이 오도하지 않도록하십시오.

다음으로 다른 종류의 보안 문자는 어떻습니까? 인간에게는 문제를 일으키지 않는 일련의 질문이 있습니다. 그러나 이들은 무작위 가 아닙니다 . 공격이 시작되면 모두에게 질문 1이 주어집니다. 1 시간 후에 질문 1 번을 버린 후에는 다시 사용하지 말고 모두 2 번 질문을받습니다.

공격자는 일회용 질문으로 인해 데이터베이스를 다운로드하여 로봇에 넣을 수 없습니다. 그는 무엇이든 할 수있는 능력을 갖기 위해 한 시간 안에 봇넷에 새로운 지시를 보내야합니다.

여러 사람들이 대체 사람 메커니즘으로 보안 문자를 포함 했으므로 보안 문자의 효율성에 대한 이전 StackOverflow 질문과 스레드를 추가하고 있습니다.

reCaptcha가 크랙 / 해킹 / OCR / 패배 / 파손 되었습니까?

보안 문자를 사용한다고해서 제한 및 기타 제안의 개선이 제한되는 것은 아니지만 보안 문자를 폴백으로 포함하는 답변의 수는 보안을 위반하려는 사람들이 사용할 수있는 인간 기반 방법을 고려해야한다고 생각합니다.

또한 사용자 암호의 강도에 따라 조절할 수도 있습니다.

사용자가 비밀번호를 등록하거나 변경할 때 비밀번호의 강도 등급을 계산합니다 (예 : 1-10).

"password"와 같은 것은 1을 득점하는 반면 "c6eqapRepe7et * Awr @ ch"는 9 나 10을 득점 할 수 있으며 스로틀 링을 시작하는 데 시간이 더 오래 걸립니다.

이 질문을 할 때 일반적으로 들었던 첫 번째 대답은 포트를 변경하는 것이지만 잊어 버리고 IPv4를 비활성화하는 것입니다. IPv6 네트워크의 클라이언트 만 허용하면 더 이상 간단한 네트워크 검색을 원치 않으며 공격자는 DNS 조회를 사용합니다. Apache (AAAA) / Sendmail (MX-> AAAA) / 모든 사람 (AAAA)에게 제공 한 것과 동일한 주소로 실행하지 마십시오. 영역을 xferd 할 수 없는지 확인하십시오. 다른 사람이 영역을 다운로드 할 수 있도록 기다리십시오.

봇이 서버 설정 새 호스트 이름을 찾으면 약간의 횡설수설을 호스트 이름 앞에 추가하고 주소를 변경하십시오. 봇넷의 이전 이름과 설정 ** 허니팟 이름을 그대로두고 시간을 초과하십시오.

** 역방향 (PTR) 레코드 (ip6.arpa. 아래)를 테스트하여 레코드 VS / 4가없는 / 4에서 0으로 사용할 수 있는지 확인하십시오. IE 일반적으로 ip6.arpa는 주소에 ~ 32 "."를 갖지만 마지막 몇 개의 누락으로 시도하면 그렇지 않은 레코드 VS 다른 레코드가있는 네트워크 블록을 피할 수 있습니다. 그렇게하면 주소 공간의 많은 부분을 건너 뛸 수 있습니다.

최악의 경우 사용자가 IPv6 터널을 설정해야하지만 DMZ로 VPN을 연결해야하는 것은 아닙니다. 왜 이것이 첫 번째 옵션이 아닌지 궁금합니다.

또한 Kerberos는 멋지지만 IMHO LDAP가 나옵니다 (NISPlus의 기술적 인 문제는 무엇입니까? Sun이 사용자가 LDAP를 원한다고 결정했으며 이로 인해 NIS +가 떨어졌습니다). Kerberos는 LDAP 또는 NIS없이 잘 작동하므로 호스트별로 호스트별로 사용자를 관리하면됩니다. Kerberos를 사용하면 자동화되지 않은 PKI를 쉽게 사용할 수 있습니다.

조금 늦었지만 하드 케이스를 가정하여 공격자가 생각했습니다. 공격자는 수많은 IP, 임의의 사용자 이름 및 가장 인기있는 10,000 개의 목록 중에서 선택된 임의의 암호를 사용합니다.

특히 시스템에 잘못된 암호 시도가 많고 특히 암호가 낮은 엔트로피 인 경우 시스템이 공격을받는 것처럼 보일 수있는 한 가지 방법은 부모의 이름과 같은 보조 질문을하는 것입니다. . 공격자가 암호 'password1'을 시도하는 백만 개의 계정에 도달하면 많은 기회를 얻을 수 있지만 이름을 올바르게 입력 할 확률은 성공을 크게 줄입니다.