특정 사이트가 비밀번호 공백을 방지하는 이유는 무엇입니까?

새로운 웹 사이트에서는 일반적이지 않지만 계정을 필요로하는 많은 웹 사이트 (예 : 청구서 지불 등)에 공백이있는 암호를 만들 수 없습니다. 이로 인해 기억하기가 더 어려워 지며 암호 공간, 암호화 또는 (허용되지 않은) 공간에 대한 데이터베이스 또는 프로그래밍 제한이 없습니다. 그러면 스페이스 바가 사이트에 가입 할 때 일반적으로 차별되는 이유는 무엇입니까?

웹 사이트의 암호와 관련하여 엄청난 양의 어리 석음 이 있습니다.

• 일부는 순수한 기술적 이유가 있습니다 (유효한지 여부, 다른 질문이지만 거의 모든 것이 아닙니다).

비밀번호는 4 자 길이 여야하며 숫자 만 있어야합니다.

(암호를 0001 .. 9999 범위로 제한하면 데이터베이스에 간단히 숫자로 일반 텍스트로 저장할 수 있습니다)

• 다른 사람들은 암호를 더 안전하게 만들 것이라는 잘못된 생각 으로 설명됩니다 .

비밀번호는 대문자로 시작하고 숫자로 끝나야합니다.

(개발자 또는 관리자 이렇게함으로써, 가정 이 실제로 안전한 암호를 선택하는 사용자를 강제하는 동안 암호는 적어도 하나의 대문자, 소문자하고있다. 6 자 분을 포함하고 있어야합니다 "등의 규칙 숫자 "는 마술처럼 실패합니다)

• 기타, 마지막으로 암호가 저장되어 있다는 사실에 의해 설명되는 일반 텍스트를 하고, 거기에 약간의 모호성 후 저장 처리 또는 검색하는 방법에 대한, 그리고 단위 테스트 그들에게 시간이 없습니다.

비밀번호에 잘못된 문자가 포함되어 있습니다 é.

또는,

비밀번호 y$₯46¥*A'xD<7&฿=ᴙcN&sF5_Ở!d에 유효하지 않은 문자가 포함되어 있습니다. 라틴 알파벳과 숫자 만 사용하십시오.

또는,

비밀번호는 공백 문자를 포함 할 수 없습니다.

세 가지 경우 모두 개발자는 이와 같은 비밀번호가 올바르게 저장되도록 보장했습니다.

• 첫 번째 경우, 전송시 어떻게 é변환 %C3%A9됩니까? 또는 데이터베이스가 é잘못 저장되면 어떻게 됩니까?

• 두 번째 경우, PHP (왜 PHP?)가 유니 코드를 처리 할 수없고 이와 같은 암호를 수신 할 때 끔찍한 일이 발생하면 어떻게됩니까? <캐릭터가 문제를 일으키는 경우 어떻게해야 합니까? &문자가 URL에서 구분 기호로 해석되는 경우 (어떤 이유로 비밀번호가 POST 대신 GET을 통해 전송된다고 가정 할 경우)? 만약 '데이터베이스에 의해 해석 된다면 , SQL 인젝션이 무엇인지, 어떻게 피할 수 있을지 모릅니다. 아니면 어떻게 '변형 \'됩니까?

• 세 번째 경우, PHP (다시?)가 경우에 따라 공백을 제거 하고 다른 경우에는 공백 을 제거하지 않으면 어떻게됩니까? 사용자가 공백을 하나만보고 사용자가 3 개의 연속 공백을 설정 하여 관리자 (놀랍게도 일반 텍스트로 사용자 암호에 액세스 할 수있는)가 손실 되면 어떻게됩니까?

세 가지 경우 모두 모호성은 테스트 , 특히 단위 테스트를 통해 쉽게 해결됩니다 . 그러나 엄청난 양의 프로젝트에는 테스트가 전혀 없으며 테스트 할 시간이 없습니다 (그러나 나중에 디버그 할 시간은 충분합니다).

이는 개발자가 공백 또는 유니 코드 문자 를 허용 하거나 ASCII 48..57 ∪ 65..90 ∪ 97..122 (숫자, 소문자, 대문자) 이외의 문자 를 허용 할 때 발생할 수있는 결과에 대해 생각하는지 여부를 의미합니다. , 시험이 가능하지 않을 때 가장 쉬운 방법은, 단지 그들을 금지하는 것입니다 .

제 생각에는 이것이 공백을 금지하는 유일한 이유입니다. Yannis Rizos는 UX와 관련된 또 다른 이유를 제시했습니다. 이론상 그럴듯한 이유는 아니지만 실제로 실제로는 작동하지 않습니다. 실제로 UX에 관심이있는 사람들이 만든 웹 사이트는 어리석은 암호 규칙을 수정하지 않습니다. 대신 공백이 실제로 금지 된 웹 사이트는 대부분 UX에 대해 들어 본 적이없는 사람들이 수행합니다 . 이것은 모든 문자가 UX 관점에서 실제로 성가 시므로 유용한 문자를 포함하여 모든 암호 관련 제한을 최소 문자 수로 사용하지 않기 때문에 특히 그렇습니다.

답은 역사입니다

많은 것들의 기초는 스토리지가 디스크 나 메모리에서 효과적으로 비워지지 않았을 때,이 모든 것들을 관리 할 수있는 능력이 현재보다 다소 낮고 자동화 된 시스템의 능력 과 동등 하지 않은 시점에서 비롯된 것 같습니다. 같은 균열을 시도하는 것도 다소 적었다.

우리가 지금 알고있는 것과 지금 할 수있는 것에 기초하여 암호에 대한 많은 불만이 있지만, 단순한 사실은 종종 우리가 종종 레거시 사고와 레거시 시스템의 조합을 다루고 있다는 것입니다.

이제 새로운 시스템에 제한이 있습니까? 나는 더 적은 이유를 지금 희망하지 않을 것입니다

IMHO, 현대 해싱 및 / 또는 솔트를 사용하여 암호를 공백으로 만들지 않는 암호를 저장하는 사이트 / 앱은 어리 석습니다. 그래서 공백이 허용하지 않는 -하지만 (이 곳에 대해 읽기) 일부 레거시 시스템은 여전히 일반 텍스트로 암호를 주변에 통과 할 수 있습니다 의미합니다. 또한 일부 앱은 수신 한 모든 문자열 입력을 "스트립"할 수 있습니다. 따라서 암호로 시작하거나 공백으로 끝나는 암호는 좋지 않을 것입니다 (물론 너무 많이 고안되었지만 거의 모든 사람이 자신의 사이트를 만들면 발생할 수없는 것을 상상할 수 있습니다). 암호에 공백을 허용하는 데 "나쁜"것은 없습니다. 지적했듯이 DB는 해시 또는 일반 텍스트 버전을 허용하지 않습니다.

실제로 대부분의 Windows 친구는 암호에 공백을 사용할 수 있다는 것을 알지 못합니다. 따라서 Tim Medora의 답변에 따라 사이트 소유자는 lamahs (용서) 또는 기회를 갖기를 원하지 않습니다. 공간이 제공 할 수있는 장점을 오해하고 /하거나 무지하다.

많은 사이트에서 하이픈, 아포스트로피 또는 ASCII가 아닌 문자를 이름으로 허용하지 않는 것과 같은 이유로 수행됩니다. 비록 미국 내에서도 매우 일반적인 관행이며 단순히 허용하는 것보다 이러한 문자를 허용하지 않는 데 더 많은 작업이 필요합니다. 그들.

같은 이유 때문에 많은 사이트의 단어 필터를 사용하면 "자기", "지연"또는 "누적"과 같은 단어를 사용할 수 없습니다 (많은 일반적인 인종 비방은 완벽하게 괜찮습니다).

많은 개발자가 상식적으로 완전히 부족하거나 가능한 사용자 입력 및 시나리오를 고려할 때 최소한 매우 제한된 상상력을 가지고 있기 때문입니다. 소수의 사람들이 허위 정보로 작업하고있을 수 있습니다 (영숫자가 아닌 문자를 제외하는 것이 표준 관행이거나 해시 알고리즘 또는 저장 방법이 공백이나 특수 문자를 처리 할 수 ​​없음). 다른 사람들은 단순히 게으른 것일 수도 있습니다. 문자 집합 문제가 걱정되기 때문에 입력을 최소한의 문자 공간으로 제한하기 만합니다. 그리고 실제 위협에 대한 이해 부족으로 편집증으로 인해 지나치게 열악한 입력 검증 / 위생을하는 사람들이있을 수 있습니다.