문제

저는 금융기관에서 프로그래머로 일하고 있습니다.나는 최근에 모든 새로운 사용자 ID에 최소한 하나의 알파벳과 하나의 숫자를 갖도록 강제하라는 지시를 받았습니다.나는 즉시 이것이 끔찍한 아이디어라고 생각했고 오히려 구현하지 않으려고 했습니다. 왜냐하면 이것이 안티 기능이고 열악한 사용자 경험이라고 믿기 때문입니다.문제는 이 요구 사항을 구현하지 않은 좋은 사례가 없다는 것입니다.

이것이 좋은 요구 사항이라고 생각하십니까?

그렇게 하지 말아야 할 타당한 이유가 있나요?

제가 참고할 수 있는 연구를 알고 계시나요?

편집하다:이것은 ~ 아니다 비밀번호에 관해서.우리는 이미 이에 대한 유사한 요구 사항을 가지고 있으며 저는 이에 반대하지 않습니다.

도움이 되었습니까?

해결책

이에 대한 한 가지 주장은 다른 영역의 많은 사용자 이름/ID에는 숫자 구성 요소가 필요하지 않다는 것입니다.사용자가 다른 곳에서 사용한 사용자 ID를 더 잘 기억할 가능성이 더 높으며 숫자를 포함할 필요가 없는 경우 그럴 가능성이 더 높습니다.

또한 시스템에 따라 사용자 ID는 외부 시스템에 연결할 때 기본값으로 잘 작동할 수 있습니다(ssh는 유닉스 계열 시스템에서 이 방식으로 작동합니다).이 경우 시스템 간에 공유되는 하나의 ID를 갖는 것이 확실히 유리합니다.

여러 위치에서 동일한 ID를 사용하면 일관성이 향상됩니다. 이는 좋은 소프트웨어 인터페이스의 잘 알려진 측면입니다.사람들이 시스템과 상호 작용하는 방식을 보여주는 것은 그리 어렵지 않습니다. ~이다 사용자 인터페이스이며 잘 알려진 인터페이스 지침 중 (적어도 일부)을 준수해야 합니다.(알 수 없는 여러 시스템 간의 상호 작용을 고려하는 경우 키보드 단축키와 같은 아이디어는 분명히 의미가 없지만 일관성과 같은 측면은 하다 적용하다.)

편집하다: 이 논의는 사용자 이름이나 공개적으로 표시되는 ID에 관한 것이라고 가정합니다. 아니다 비밀번호와 같이 보안과 직접적으로 관련된 것입니다.

다른 팁

나는 그들에게 이것의 구체적인 이유를 묻는 것부터 시작하겠습니다.글머리 기호 목록과 그 이유가 있으면 반박하거나 대안을 제시하는 것이 더 쉽습니다.

일반적인 아이디어는 다음과 같습니다.

  • 이것은 의견이지만 사용자 이름에 숫자를 추가한다고 해서 반드시 보안이 강화되는 것은 아닙니다.사람들은 포스트잇에 사용자 이름을 적습니다. 대부분의 사용자는 추측하기 쉽도록 사용자 이름의 시작이나 끝에 '1'을 추가합니다.
  • 유용성 관점에서 볼 때 이는 표준을 깨뜨리기 때문에 좋지 않습니다.사용자 이름에 숫자를 추가하도록 강요하면 위와 같은 상황이 발생합니다.사용자 이름의 끝이나 시작 부분에 '1'을 추가하기만 하면 됩니다.

인증 시스템이 복잡할수록 일반 사용자가 이를 우회하는 방법을 찾아 체인의 링크를 약하게 만들 가능성이 더 높다는 점을 기억하십시오.

사용자 ID?암호를 영숫자로 요구하는 것은 사전 공격에 대한 저항력을 높여주기 때문에 일반적으로 좋은 생각입니다.사용자 이름에는 실제로 의미가 없습니다.이름/비밀번호 조합의 요점은 이름 부분을 비밀로 유지할 필요가 없다는 것입니다.

금융기관에 근무한다면 이런 일에 대한 규제가 있기 때문에 손댈 수 없을 가능성이 높습니다.하지만 당신이 할 수 있는 한 가지는 사용자가 잘못된 ID를 입력했을 때 이를 사용자에게 명확하게 알리는 것입니다.그리고 그가 제출을 클릭할 때까지 기다리지 마십시오.필드 바로 옆에 일종의 메시지를 표시하고 입력할 때 업데이트합니다.

위의 답변 중 일부에는 반론이 있습니다.사용자가 다른 사이트에서 사용하는 것과 동일한 사용자 이름을 선택하면 금융 사이트에서도 동일하거나 유사한 비밀번호를 선택하여 보안이 저하될 가능성이 높습니다.

하지 말아야 할 이유:사용자에게 이전보다 더 많은 제한을 가하면 사용자는 로그인 정보를 기록하기 시작하게 되며 이는 명백한 보안 손실입니다.

내가 가지고 있는 두 은행 계좌 모두 온라인 로그인을 위해 영숫자 사용자 이름과 두 개의 비밀번호가 필요합니다.그 중 하나에는 꼭 기억해야 할 이미지도 있습니다.두 비밀번호는 한 달에 한 번씩 변경해야 합니다.따라서 여기 텍스트 파일에 모든 로그인 정보가 있습니다.(봐도봐도 별 의미가 없습니다.은행에 가서 비밀번호를 다시 재설정해야겠습니다.이는 6번의 로그인에 대한 총 7번의 비밀번호 재설정입니다.보안에 대해 이야기하지도 마세요. 내 계정에 액세스할 수 있습니다.)

비밀번호에 있으면 좋습니다. (아쉽게도 금융 회사는 귀하의 보안 권리를 거부하기를 좋아합니다 [아메리칸 익스프레스에 대해 이야기하고 있습니다]).

사용자 이름, 그들이 원하지 않는 한 나는 아니오라고 말합니다.

사용자 이름은 (아마도) 지원을 요청할 때 전화상에서 인용되어야 하므로 비밀번호와는 달리 공개됩니다.또한 사용자 이름 필드는 비밀번호 필드처럼 브라우저에서 가려지지 않으므로 훨씬 더 많이 노출되고 다양한 위치에 캐시/로그가 발생하므로 추가 보안의 '이점'이 즉시 취소됩니다.

그리고 일을 더 어렵게 만들수록 사용자는 보안을 다시 약화시키는 어딘가에 기록할 가능성이 더 커집니다. (실제로 비밀번호 정책에도 동일하게 적용되지만 이는 또 다른 이야기입니다!)

저는 또한 금융 기관에서 일하고 있으며 사용자 이름(실제 사람과 프로덕션 ID 모두)은 모두 소문자, 알파벳, 최대 8자이며 이것이 문제라고 생각한 적이 없습니다...0 대 O, 1 대 I, 8 대 B의 혼동을 방지합니다. 나와 같은 회사에 근무하고 새로운 정책을 시행하려고 하지 않는 한...

기능을 추가하면 비용이 추가됩니다.지금은 이를 구축하고 테스트하고 향후 지원하는 데 시간이 걸릴 것입니다.정말 타당한 이유 없이는 어떤 기능도 구축해서는 안 됩니다.

이 기능은 무의미합니다.사용자 이름은 비밀로 유지되어서는 안 되므로 강력한 사용자 이름을 갖고 있다고 해서 이점이 없습니다.비밀번호(또는 기타 인증 요소)를 강력하게 만드는 데 시간을 투자할 가치가 있지만 사용자는 보안 위험 없이 자신의 사용자 이름을 다른 사용자에게 전달할 수 있어야 합니다.

애플리케이션이 사용자 ID 선택에 추가 제한사항을 적용하는 경우 일부 사용자는 환경의 다른 애플리케이션과 다른 사용자 ID를 갖게 됩니다.메모:나는 이것이 인터넷 연결 응용 프로그램이 아닌 내부 응용 프로그램(직원이 사용하기 위한)이라고 가정합니다.

일관되지 않은 사용자 이름을 사용하면 다음과 같은 여러 가지 특정 위험이 추가됩니다.

  1. 감사 추적을 따르기가 더 어려워집니다(심각한 보안 위험).
  2. 나중에 사용하기 시작하면 비용이 추가될 수 있습니다. 싱글 사인온.
  3. 사용자는 이 애플리케이션이 이상한 사용자 이름을 사용한다는 사실을 기억해야 하므로 사용자 경험이 좋지 않을 수 있습니다.
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top