2009-11-28 4 views
1

로그인 시스템에서 작업 - 고객이 사이트 액세스를 위해 암호를 선택하는 지점.사용자 암호 문자 집합 제한

RegEx를 사용하여 암호가 충분히 강하다는 것을 제외하고는 일반적으로 데이터베이스에 기록되는 모든 데이터를 주입 등으로 검사하고 합리적으로 제한된 문자 집합을 모든 필드에 적용합니다. 암호를 너무 제한하는 보안에 대한 약간의 반 패턴이라고 생각하기 때문에 암호에 대해 특히 제한적인 문자 집합을 원합니다. 어느 시점이 문자 제한에 무엇이 있는가

  • : 암호의 경우 그러나

    , 나는 질문의 소수를 제기하는 어쨌든 삽입을위한 소금에 절인 SHA-512로 해시됩니다 고객이 암호로 사용할 수있는 설정 - 즉, 내가 해싱에 의해 완전히 회피 될 것이라고 가정하고있는 주입 이외의 취약점에 노출되어 있습니까?

  • 허용 접근법에는 부정적인면이 있어야합니다. 앞으로 무고한 결합이 위험한 요소가 될 수 있다는 사실을 생각해 볼 수 있습니다. 놓친 적이 있습니까?

  • 거부해야하는 문자/문자열이 있습니까? 네이티브 ASP.NET 보호 기능을 사용할 수 있습니까?

  • 좀 더 주관적 일 수도 있지만 SHA-512 해시를 지정하면 합리적인 매개 변수 내에서 선택할 수있는 최대 암호 길이를 제한하는 데있어 중요한 점은 상당한 크기의 암호/복잡성으로 인해 설정을 확인하는 경고가 발생할 수 있습니다.

도움 주셔서 감사합니다.

EDIT : ADO.NET (LINQ/EF 아님)을 사용하여 MSSQL2008 데이터베이스에 액세스하는 ASP.NET 웹 응용 프로그램입니다.

답변

1

일반 텍스트 (Danger, Will Robertson, Danger!)로 데이터베이스에 암호를 실제로 삽입하지 않으면 SQL 삽입 공격에 대해 걱정할 필요가 거의 없습니다. 쿼리를 매개 변수 화하면 이슈. [a-zA-Z0-9]와 일부 특수 문자 세트를 허용해야합니다. 아마도 제한 할 유일한 문자는 '<'이며 ASP.net 유효성 검사 경고를 유발합니다. 클라이언트 측에서 암호 복잡성 검사를 수행하는 많은 재미있는 도구가 있습니다. 나는 this one을 좋아한다. 사용자가 타이핑 할 때 사용자에게 즉각적인 피드백을 제공합니다.

3

영어 이외의 관점에서 볼 때 암호에는 제한이 없어야합니다.

예를 들어 일본어를 사용하는 사람이 US-ASCII 문자 집합을 사용하도록 제한하는 이유는 무엇입니까? 그리고 왜 프랑스 인은 악센트 부호가없는 문자를 사용하지 않아야합니까?

해시가 올바르게 지속되었다고 가정하면 제한 할 기술적 인 이유가 없습니다.

+0

감사합니다. 국제 문자를 내 관심에 끌기 위해 +1합니다. – Chris

1

암호가 해시되므로 16 진수 형식으로 데이터베이스에 저장됩니다. 따라서 허용 된 문자 유형을 제한 할 필요가 없습니다. 비밀번호에 중국어 문자를 사용하고 싶다면 그렇게 할 수 있어야합니다. 임의의 바이트를 생성하는 Firefox 용 확장 프로그램을 설치하여 암호 용으로 사용하는 경우이를 수행 할 수 있어야합니다. 여기서의 교훈은 사용자의 암호를 제한하지 않는 것입니다.

또한 RegEx에는 사용자가 모든 언어의 문자를 사용했는지 여부를 감지 할 수있는 유니 코드 지원 기능이 있습니다. 비밀번호의 유효성을 확인할 때 유용 할 수 있습니다.