it-swarm-korea.com

일부 웹 사이트 및 프로그램이 암호 특성을 제한하는 이유는 무엇입니까?

어리석은 암호 제한이있는 일부 웹 사이트와 내가 사용하는 프로그램도 있습니다. 예를 들어 많은 포럼에서는 암호를 ~ 32 자로 제한합니다. 다른 사람들은 제한된 문자 집합을 적용합니다.

개발자가 그러한 제한을 두는 원인은 무엇입니까? 클라이언트에서 암호의 초기 해싱을 수행하는 한 엄청난 자동 생성 암호의 해시를 계산해야하는 서버에 부하가 없습니다. 이러한 제한을 사용하면 이점이없는 것 같습니다.

22
TheLQ

그 이유는 다른 입력 유효성 검사와 동일하다고 생각합니다. 처리 및 보관 중에 문제가 발생하지 않는지 확인하십시오. 이제 암호의 경우 해시되어 저장되거나 실제로 일반 텍스트로 처리되지 않기 때문에 이것은 물론 완전히 잘못된 것입니다.

개발자가 보안 상 무엇을하고 있는지 모르고 암호를 일반 텍스트로 저장할 것이라는 표시로 이러한 제한을 적용합니다. 떨어져.

21
Jakob Borg

나는 함께 갈 것입니다 : 사람들이 이상한 일을하는 똑같은 오래된 이유.

  • 당시에는 좋은 아이디어 같았 기 때문입니다. 개발자는 의도는 좋지만 정보가 부족할 수 있습니다. 암호 길이를 제한 할 필요는 없지만 개발자가이를 인식하지 못할 수도 있습니다. 아마도 개발자들은 그것에 대해 생각조차하지 않았을 것입니다.

  • 대안보다 쉬웠 기 때문입니다. 임의 길이의 암호를 처리 할 수없는 API를 사용하고있을 수 있습니다. 더 나은 API를 사용하는 것보다 비밀번호 길이를 제한하는 것이 더 쉬울 수 있습니다. 데이터베이스에 SQL 주입 결함이있을 수 있으며 SQL 주입 결함을 피하기 위해 제대로 코딩하는 것보다 일부 문자를 블랙리스트에 추가하는 것이 더 쉽습니다 (예 : 사용자가 암호에 작은 따옴표를 포함하지 못하도록 금지). 어떤 이유로 든 가변 길이 문자열보다 고정 길이 배열을 사용하는 것이 더 쉬웠을 것입니다. 누가 알아.

하단 선 : 그러한 한계에 대한 정당한 근거는 없습니다. 상업적으로 사용 가능한 소프트웨어에는 종종 온갖 이상한 디자인의 잘못된 기능이 포함되어 있다는 사실에 익숙하다고 확신합니다. 발생합니다. 그것은 삶의 사실입니다. 그것은 "충분하다"가 "완벽하다"보다 훨씬 저렴하다는 사실의 결과이다.

11
D.W.

암호 길이와 가능한 문자 집합을 제한하는 합리적인 이유는 사용자에게 적절한 암호 관리 기술을 적용하도록 프롬프트하기위한 것입니다. 간단히 말해서, 암호가 크거나 이상한 문자로 가득 차있는 경우 사용자가 종이 (전통적으로 키보드 아래에 붙어 있음)에 암호를 적어 두거나 동일한 암호를 여러 시스템에 다시 사용할 가능성이 높아집니다. .

개념적으로 사용자가 자신의 암호를 관리하는 방법은 그의 책임이며 웹 사이트 비즈니스는 아닙니다. 그러나 실제로 사용자는 보안 측면에서 단서가 없으며 즉각적인 보복이없는 것은 무엇이든 지루할 수 없습니다 (특히 사용자가 잠재 고객 인 경우). 따라서 사용자를 보호하기 위해 할 수있는 일을하는 것은 웹 사이트에 달려 있습니다.

나는 좋은 암호 관리를 강요하려한다고 주장하지 않는다는 점에 유의하십시오 .is 주어진 사이트가 암호 길이를 제한하는 이유; I 내 사이트에서 암호 길이 제한을 구상하는 이유 일뿐입니다 (사용자 암호로 웹 사이트를 관리하는 경우).

제한된 허용 문자 집합에 대한 또 다른 근거는 상호 운용성을 높이기위한 것입니다. 가급적이면 사용자가 다양한 입력 장치에 자신의 암호를 입력 할 수 있어야합니다. 비 ASCII 문자는 미국 키보드처럼 보이는 모든 것에 적합하지 않습니다 (미국 키보드에서 비 ASCII 문자를 입력하는 것이 가능합니다. 항상 수행하지만 운영 체제 및 구성에 따라 방법이 다릅니다. 블라인드 타이핑에서는 잘 작동하지 않습니다. 스마트 폰에는 훨씬 더 많은 제한이 있습니다. 다시 말하지만, 상호 운용성은 제한된 문자 집합을 적용하는 좋은 이유이지만 많은 웹 사이트에는 bad 이유로 이러한 제한이 있습니다 (예 : 암호가 SQL에 부주의하게 덤프 될 수 있음) 적절한 문자열 이스케이프없이 요청, 조잡한 엔지니어링으로 만 설명 할 수있는 것).

11
Thomas Pornin

나는 우리가 이와 같은 질문이 있다고 생각했지만 오늘 밤 내 검색 푸가 약하거나 다른 사이트에있었습니다.

기본적으로 대부분의 응용 프로그램이나 데이터베이스에서 입력 문자열에 대한 유용한 제한을 정의하는 것이 좋습니다. 이렇게하면 한도에 도달하면 (오버플로 등을 방지 할 수 있음) 입력을 중지하고 코드 성능을 예측할 수 있습니다.

또한 암호가 해시되기 전에 유효성을 검사하는 동안 임시 저장소가 필요할 수 있습니다. 다시 한 번 임의로 긴 입력을 허용하면 문제가 발생할 수 있습니다.

왜 32 명입니까? 대부분의 목적을위한 합리적인 수치-32 자의 엔트로피는 엄청납니다. 물론 일부 환경에서는 이것으로 충분하지 않지만 대부분의 경우 인증서 또는 두 번째 요소 (예 : 토큰)가 어쨌든 더 적절할 수 있습니다.

3
Rory Alsop

첫 번째 질문이 누락되었으므로 별도의 답변을 제공합니다. 주된 이유는 제한이 필요하기 때문입니다. 저장 공간과 데이터 덩어리에 대한 우려는 정확하지만 몇 가지 문제가 있습니다.

첫째, 아래의 원래 답변을 읽으면 권장 사항 중 하나가 반복적 해싱 (즉, pbkdf)임을 알 수 있습니다. 진정으로 효과적이려면 많은 반복이 필요합니다. 사용자가 큰 문자열을 제출할 수있는 경우이 반복적 인 해시 값을 계산하는 데 드는 비용은 단순 인증 기능의 예상보다 금방 더 비쌉니다.

서버에서 계산 비용이 많이 드는 단일 작업, 특히 인증되지 않은 사용자가 명시 적으로 사용할 수있는 작업은 서비스 거부 공격을 수행하기 위해 악의적 인 사용자에 의해 악용 될 수 있습니다.

둘째, 고정 길이 암호를 구현하여 매우 긴 요청이 제출 될 경우 조기 종료 할 수있는 기회를 제공합니다. 요청의 매개 변수가 예상 길이를 벗어난 경우 오류 메시지를 발행하고 연결을 닫는 것이 간단합니다.


많은 사이트에서 암호 복잡성 요구 사항이 적용되는 이유는 사용자가 취약한 암호를 선택하지 못하도록하기 위함입니다. 최근 역사에는 대부분의 사용자가 복잡한 암호보다 약하고 입력하기 쉽고 기억하기 쉬운 암호를 선택한다는 것을 보여주는 수많은 예가 있습니다. 이런 일이 발생하면 사이트 소유자는 암호가 도난 당하거나 크랙 된 경우 사용자가 사이트를 비난하고 사이트와 영향을받는 사용자 모두에게 어떤 결과를 초래할 수 있는지 항상 위험에 처하게됩니다.

강력한 암호 요구 사항을 구현하여 공격자가 쉽게 암호를 추측 할 수있는 가능성을 줄입니다. 또한 두 가지 다른 공격 경로로부터 암호를 보호해야합니다. 첫 번째, 온라인 공격은 사이트 개발자에게 무차별 대입 공격이 성공하지 못하도록 방지하는 정책이 있어야합니다. 이는 사용자가 적절하게 길고 복잡한 암호를 선택하도록 요구하고 속도를 늦추거나 (즉, 임시 잠금, 캡차 등) 로그인 시도를 중지 (영구 잠금, 필수 암호 재설정, 계정 확인)하기 전에 실패한 로그온 시도 횟수를 제한함으로써 수행됩니다. 등).

두 번째 공격은 오프라인 공격으로, 공격자가 암호 데이터베이스의 복사본을 획득하고 Rainbow 테이블 또는 오프라인 암호 크래커를 사용하여 여러 계정을 크래킹하려고 시도합니다. 이러한 유형의 공격은 사용자 별 솔트와 함께 강력한 해싱 알고리즘을 사용하고 오프라인 크래킹의 계산 비용을 높이기 위해 pbkdf2 또는 bcrypt/scrypt 스타일 재해 싱을 사용하여 방지합니다.

궁극적으로 사이트에서 사용자가 다양한 계정에 대해 고유 한 암호를 선택하도록 권장하지 않으면 이러한 두 기술 모두 실패합니다. 많은 사용자가 여러 계정에 대해 동일한 암호를 선택하고 해당 암호가 특히 이메일 계정에 노출되면 공격자가 다른 서비스에서 해당 자격 증명을 사용할 수 있습니다. 이러한 이유로 각 사이트 또는 최소한 다른 사이트 그룹에 대해 고유하고 강력한 암호를 생성하고 보안 암호 관리자를 사용하여 다른 암호를 모두 저장하는 것이 가장 좋습니다.

1
ygjb