it-swarm-korea.com

비밀번호로 어떤 문자를 허용하지 않아야합니까?

사용자가 사용자 이름과 비밀번호를 등록해야하는 웹 사이트를 개발할 계획입니다. 사용자가 비밀번호를 선택할 때 사용자가 비밀번호에 어떤 문자를 허용해야합니까? http 프로토콜 또는 구현 언어의 보안 문제로 인해서는 안되는 것이 있습니까?

아직 구현 언어를 결정하지는 않았지만 Linux를 사용합니다.

20
Jonas

보안/구현 측면에서 '\ 0'(문자를 입력하기 어려운)과 별도로 문자를 허용 할 필요가 없습니다. 더 많은 문자를 입력할수록 가능한 암호의 전체 단계 공간이 작아 지므로 암호를 무차별 처리하는 것이 더 빠릅니다. 물론, 대부분의 암호 추측은 실제로 입력 도메인의 체계적인 검색보다는 사전 단어를 사용합니다 ...

그러나 sability 관점에서 볼 때 일부 문자는 다른 시스템에서 동일한 방식으로 입력되지 않습니다. 예를 들어, shift-3이 하나는 #, 다른 하나는 £를 생산하는 두 개의 다른 컴퓨터가 있습니다. 암호를 입력하면 둘 다 '*'로 표시되므로 암호가 올바른지 여부를 알 수 없습니다. 어떤 사람들은 그러한 인물들을 불허하기 시작할 정도로 사람들을 혼란스럽게 할 수 있다고 생각합니다. 나는 그것이 가치가 있다고 생각하지 않습니다. 대부분의 실제 사람들은 하나 또는 두 대의 컴퓨터에서 실제 서비스에 액세스하며 암호에 많은 확장 문자를 넣는 경향이 없습니다.

43
user185

비 ASCII 문자에 문제가있을 수 있습니다. 암호는 글리프 시퀀스이지만 암호 처리 (해싱)에는 bits 시퀀스가 ​​필요하므로 글리프를 비트로 변환하는 결정적인 방법이 있어야합니다. 이것은 code pages 의 전체 ​​어두운 늪입니다. nicode 를 고수하더라도 문제가 발생합니다.

  • 단일 문자는 코드 포인트로 여러 분해를 가질 수 있습니다. 예를 들어, "é"문자 (프랑스어로 매우 빈번한)는 단일 코드 포인트 U + 00E9 또는 시퀀스 U + 0065 U + 0301로 인코딩 될 수 있습니다. 두 서열은 동등하다. 하나 또는 다른 것을 얻을 수 있는지 여부는 입력 장치에서 사용하는 규칙에 따라 다릅니다.

  • 유니 코드 문자열은 code points (0에서 1114110 범위의 정수)의 시퀀스입니다. 이러한 시퀀스를 바이트로 변환하기위한 몇 가지 표준 인코딩이 있습니다. 가장 일반적인 것은 UTF-8, UTF-16 (big-endian), UTF-16 (little-endian), UTF-32 (big-endian) 및 UTF-32 (little-endian)입니다. 이들 중 하나는 BOM 으로 시작하거나 시작하지 않을 수 있습니다.

따라서 단일 "é"는 20 가지 이상의 고유 변형을 사용하여 바이트로 의미있게 인코딩 할 수 있으며 "주류 유니 코드"를 고수 할 때입니다. 라틴 -1 인코딩 또는 해당 Microsoft 대응 도 널리 보급되어 있으므로 21을 지정하십시오. 특정 소프트웨어가 사용할 인코딩은 많은 요인에 따라 달라질 수 있습니다. 로케일 을 포함합니다. 사용자가 구성을 "캐나다-영어"에서 "캐나다-프랑스어"로 전환했기 때문에 더 이상 컴퓨터에 로그온 할 수 없으면 문제가됩니다.

실험적으로 , 암호를 printable ASCII 문자의 범위로 제한하여) 이러한 종류의 대부분의 문제를 피할 수 있습니다 (32에서 126 사이의 코드가있는 코드-개인적으로 공간을 피할 것이므로 33에서 126까지) 및 바이트 바이트 인코딩 (BOM 없음, 한 문자가 하나가 됨) 바이트). 시각적 피드백없이 다양한 키보드에서 암호를 입력해야하므로 최적의 유용성을 위해 문자 목록을 훨씬 더 제한해야합니다 (키보드에 쓰여진 내용이없는 캐나다 레이아웃 과의 일일 전투) 특히 하나 또는 두 개의 중첩 RDP 연결 ; '<', '>'및 '\'문자가 가장 많이 이동하는 경우)와 같이 기계가 생각하는 것과 일치해야합니다. 문자 (대문자 및 소문자)와 숫자 만 있으면 괜찮습니다.

사용자에게 책임이 있다고 말할 수 있습니다. 그는 입력 문제를 다루는 한 원하는 문자를 자유롭게 사용할 수 있습니다. 그러나 그것은 궁극적으로 가능하지 않습니다. 사용자가 문제를 겪을 때, 그들은 your 헬프 데스크라고 부르며, 실수의 일부를 가정해야합니다.

17
Thomas Pornin

generating 임의의 암호 인 경우 다른 사람과 혼동 될 수있는 문자를 사용하지 않는 것이 좋습니다. 예를 들어 (기호 무시) :

  • 소문자 : l, o
  • 대문자 : I, O
  • 번호: 1, 0
11
Justin Morgan

모든 문자를 허용하는 것 외에도 암호에 암호를 사용하는 사람들을 지원할 수 있도록 암호 필드의 최대 길이를 고려하십시오.

"내 비밀번호는 모두 소문자로되어 있습니다."라는 문구는 실제로 길이로 인해 합당한 강력한 비밀번호 문구입니다.

6
Antony

어떤 문자도 허용해서는 안됩니다. may 암호가 6 자보다 짧지 않게하려고 할 수 있습니다. 그런 다음 bcrypt 사용 를 사용하여 암호를 해시해야합니다.

1
Stephen Touset

문제를 일으킬 수있는 몇 가지 문자가 있습니다.

*,? % : 이들은 종종 와일드 카드로 사용되므로 기본 프로그래밍 언어를 혼동 할 수 있습니다.

Tab, Return, NewLine, Vertical Tab, Escape : 이러한 특수 문자는 프로그래밍 언어 OR 고객이 사용하는 브라우저에서 이상한 동작을 요구할 수 있습니다. (고객이 여러 다른 브라우저를 사용하는 경우) 하나는 이들을 입력 할 수 있고 다른 브라우저는 허용하지 않을 가능성이 매우 높습니다 (그 브라우저에서 고객을 자신의 계정에서 효과적으로 잠그십시오).

\는 종종 특별한 의미를 따르는 문자를 제공하는 이스케이프 문자로 취급됩니다.
예 : 많은 경우 "\ n"은 줄 바꿈입니다. "\ t"는 탭입니다.
프로그래밍 언어 (또는 고객 브라우저)가이 작업을 수행하면 위에서 언급 한 문자를받을 수 있습니다.
따라서 안전하기 만하면 안되는 것이 가장 좋습니다.

0
Tonny

'가상 키보드'또는 이와 유사한 도구를 사용할 수 없다면 균일 한 방식으로 문자를 생성 할 수있는 경우 영숫자 문자 만 사용할 수 있다고 생각합니다. 나머지 키보드의 위치는 키보드마다 다를 수 있습니다. 사용자가 다른 위치에서 서비스에 액세스해야하는 경우 서비스를 효율적으로 잠글 수 있습니다.

가상 키보드를 사용하여 어떤 시스템/키보드/어떤 것이 사용 되든 동일한 방식으로 동일한 문자 표현 (이미 유니 코드에 대해 언급 됨)을 동일한 방식으로 보내는 방법으로 가상 키보드를 사용하는 것이 좋습니다. 따라서 키워드에 입력 할 수있는 문자를 제외 할 필요가 없습니다.

0