사용자 등록을위한 합리적이고 안전한 암호 요구 사항은 무엇입니까?

이것은 UPS에서 방금받은 비밀번호 정책입니다 (패키지 상태 확인 용).

비밀번호는 8 자에서 26 자 사이 여야합니다. 소문자, 대문자, 숫자, 특수 문자 또는 공백 중 적어도 3 가지 문자 유형을 포함해야합니다. 비밀번호에는 사용자 ID, 이름 또는 이메일 주소가 포함되어 있지 않을 수 있습니다. (SSO_1007)

나는 실제로이 암호를 생성하기 위해 내 두뇌를 어느 정도 깨뜨려야하지만, 가장 중요한 것은 3 일 후에이 암호가 무엇인지 잊게 될 것이라고 확신한다. 사용자는 너무 행복하지 않을 것입니다. 비밀번호 재설정이 빈번 할 수 있습니다. 사용자는 사이트를 사용하지 않으면 사이트를 사용하지 않는 것이 좋습니다.

웹 사이트를 설정할 때 합리적이고 안전한 비밀번호 정책은 무엇입니까? 일부 회사는 일부 해커가 암호를 백만 번 이상 입력하려고하는 것을 두려워 할 수 있으므로 "특수 문자, 소문자, 대문자"에 대한 모든 요구 사항을 추가하지만 계정을 끄거나 비활성화하는 것이 합리적이지 않습니다. 사용자가 30 회 또는 100 회 시도한 경우 비밀번호를 재설정하고 비밀번호를 재설정해야합니까? 또는 사용자가 30 번 시도한 후에 매번 5 초 지연을 추가 하시겠습니까? 그렇다면 그러한 특수 문자는별로 필요하지 않습니다.

솔직히 말해서, 엄격한 암호 요구 사항은 성가신 것으로 이익이 아닙니다. 원칙적으로 가장 합리적인 길이는 특수 문자 + 영숫자 인 길이를 지정하는 것입니다. 더 많은 사람들이 암호를 적어달라고 요구하면 보안 암호를 갖는 모든 목적을 상실합니다. 나는 또한 일반적인 어리석은 규칙 세트를 사용하여 x 일마다 비밀번호를 변경 해야하는 것을 싫어합니다 (예 : 마지막 25 개의 비밀번호를 재사용 할 수 없음). 암호를 요구하지 않을 수도 있습니다.

내 의견은 암호는 길이가 길어야한다는 것입니다. 누군가 "a"를 비밀번호로 입력하는 것을 원하지 않습니다. xkcd 답변에서 알 수 있듯이 암호를 기억하기가 매우 어려운 것은 항상 안전한 것은 아닙니다. 사람들이 항상 자신의 암호를 변경하도록 허용하십시오. "이전 비밀번호에 포함 된 문자는 사용할 수 없습니다"라는 사실을 잊어 버리십시오.

외설적 인 비밀번호 정책을 만드는 것은 좋은 것보다 더 해가됩니다. 대학에서 나는 비밀번호 정책에 갔다가 UPS 정책과 비슷했으며 2 주마다 변경해야했고 이전에 사용한 50 개의 비밀번호를 사용할 수 없었습니다. 따라서 선생님이 계정을 설정할 때 권장하는 것은 규칙을 준수하는 규칙을 사용하고 규칙 끝에 카운터를 추가하고 카운터 번호가 무엇인지 암호 힌트에 입력하는 것입니다.

또한 일반 텍스트 데이터베이스가 SQL 주입 버그에 의해 해킹 당하거나 사용자에게 암호를 전자 메일로 보내면 가로 챌 때마다 엄격한 암호 정책이 아무 것도 수행하지 않습니다.

기본적으로 암호 시스템을 사용자에게 번거롭지 않게 만들거나 안전하지 않은 작업을하도록 권장합니다. 예를 들어, 회사는 데이터 센터에서 전용 서버를받을 때 20 자 길이의 암호를 설정했습니다. 그들은 우리에게 이메일을 보내기에는 너무 안전했고 팩스로 보내야했습니다. 비밀번호를 변경할 수 없었으며 새로운 20 자 비밀번호 만 생성하도록 요청했습니다. 그리고 이것은 모든 사용자에게 이런 방식이었습니다 ... 그래서 우리가 한 일은 데스크톱 컴퓨터에서 암호로 텍스트 문서를 만드는 것입니다. 또한, 우리는 그들이 가지고있는 모든 "보안"에 대해 실제로 매우 안전하지 않기 때문에 더 이상 사용하지 않습니다.

공백을 허용하십시오. 내가 아는 모든 사람들은 문구에서 각 단어의 첫 글자를 입력 할 수있는 것보다 짧은 문구를 빠르게 입력 할 수 있습니다. 예를 들어을 입력 Bird in a Tree한 다음을 입력하십시오 BiaT. 이것은 스티커 메모 pick Up milk나 Meetings all day스티커 메모에 모호한 작업에 적합한 문구를 쓸 경우 분명히 암호가 아니라는 이점이 있습니다.

나는 "숫자와 기호가 있어야합니다"규칙을 좋아하지는 않지만 일관되게 적용하면 (예 : 항상 1, 항상 @), 스티커에 영어 문구를 쓸 수 있습니다. 알려진 유일하게 당신이 말해야 할 규칙, B1rd in @ tree암호 대화 상자에 입력하십시오 . 보안 관점에서 숫자와 기호는 별다른 의미는 없지만 사용자를 미치게 만들 필요는 없습니다.

암호 길이가 최대 인 사이트는 멋진 문구가 "너무 길다"고 생각하면 불안합니다. 26이 합리적으로 보입니다. 나는 누군가가 기둥의 너비를 디자인해야한다는 것을 알고 있지만 12는 어리석게 짧습니다.

안전 대 편리

암호 보안 정책은 손상 비용에 적합해야합니다. 귀하의 웹 사이트가 내 금융 계좌를 앞두고 있다면 엄격한 비밀번호 보호를 원합니다. 오토봇에 대한 틈새 팬 사이트라면 별다른 보호가 필요하지 않습니다.

UPS 규칙은 다음을 제외하고 합리적입니다.

• 최대 길이가 너무 작습니다. 기억하기 쉽고 더 안전 할 수있는 암호 구의 사용을 촉진해야합니다.

인용 된 규칙에서 X 번 시도한 후에 재설정을 보지 못했습니다. 대부분의 경우 이것이 바보라고 생각합니다. 재설정을 강요하는 대신 일정 시간 동안 누군가를 잠그는 것이 좋습니다. 이는 특정 수준의 보안을 의미합니다. 이것이 필요하지 않은 경우에는 그렇지 않으며 잠금 / 재설정은 문제가됩니다.

보안에 한계가있는 암호 정책 규칙이 많이 있습니다. 그러나 암호 보안에 실질적이고 실질적인 이점이있는 규칙도 있습니다.

규칙 및 이유 :

• 최소 길이

매우 짧은 암호를 빠르게 손상시키는 조합 시도 및 오류 공격을 방지합니다.

• 단일 영어 단어 (또는 다른 언어) 사용에 대한 처방

사전 공격을 방지합니다.

• 다른 카테고리를 강제로 포함 (예 : 대소 문자, 숫자, 문장 부호)

이것은 평균 공격 공간을 증가시킵니다.

이러한 모든 이유는 암호 선택시 사용자의 편견을 최소화하는 것으로 추적 할 수 있습니다. 대부분의 사용자는 더 짧고 기억하기 쉬운 암호를 만드는 편향되어 있습니다. 불행히도 일반적으로 암호를 공격하기가 더 쉽습니다. 대부분의 사용자에게 필요한 것은 기억하기 쉬운 암호 또는 더 긴 암호를 만드는 방법에 대한 지침입니다.

기억하기 쉬운 비밀번호

길이 제한이있는 암호를 만들어야 할 때 항상 문구로 시작하므로 내장 된 니모닉이 있습니다. 나는 문구를 가지고 각 단어에서 동일한 위치 문자를 얻습니다. 나는 이제 일련의 문자가 있습니다. 그런 다음 대문자 또는 대문자를 선택합니다. 일부는 문구의 올바른 이름 또는 패턴 (첫 번째 및 마지막, 다른 모든 문자 등)을 기준으로합니다. 그런 다음 임의의 규칙이나 패턴에 따라 문장 부호와 숫자를 추가합니다. (즉, 문구에 'and'가있는 경우 '&'를 사용하여 모든 'j'는 7입니다.)

엄마, 방금 남자를 죽였습니다. 머리에 총을 대십시오. 내 방아쇠를 당겨 이제 죽었어

Queen이 제공하는 문구

1. mjkampagahhpmtnhd- 모든 단어의 첫 글자
2. MjkamPagahhPmtnhd-대 / 소문자 구분
3. Mjk0mP0g0hhPmtnhd- 'a'를 0으로 변경
4. Mjk0mP0g0 () Pmtnhd- '그의 머리'를 ()로 변경했습니다

문구를 생각할 때 몇 번 입력하면 기억에 문제가 없습니다.

비밀번호는 8 ~ 26 자 사이 여야합니다

8 자 길이의 최소 암호는 Lan Manager의 유산입니다. Lan Manager는 암호를 2 개의 7 자 문자열로 나눈 다음 해시했습니다. 최소 8자를 요구함으로써 두 번째 단어가 빈 암호와 동일하지 않다는 것을 보장했습니다 (소금이 없으므로 7 개의 빈칸이 모두 같은 결과로 해시되었습니다).

3 일 후에이 비밀번호가 무엇인지 잊어 버릴 것입니다.

나는 포기했다, 규칙은 너무 어리 석고 비 웃으며 지금 적어 둔다. 내가 웹 사이트에 사용하는 것을 제외하고 모두. 현재 고용주는 또한 지난 24 개의 암호를 재활용하여 암호를 재활용 할 수 없으며 암호에 3 자 이상의 영어 단어 (앞뒤)를 포함 할 수 없습니다. 또한 이전 단어를 사용하지 않고 단어의 일부로 숫자를 증가시킵니다 (따라서 P4ssw0rd1사용하면 P4ssw0rd2, 또는을 사용할 수 없음 P4ssw0rd0).

암호를 변경해야 할 때 사무실에서 어려운 교훈을 얻었습니다. 시스템이 교체품을 받아들이는 데 45 분이 걸렸습니다. 그러면 내가 가진 것을 잊어 버렸고 다시 설정하여 다른 것을 낭비해야했습니다 .45 몇 분 동안 요구 사항을 충족하기에 충분히 복잡한 기억할 수있는 무언가를 얻으려고 노력했습니다. 당신이 알 수없는 규칙에 맞는 것을 생각해내는 것은 그리 재미 있지 않습니다. 최소한 마스터 마인드 와 같은 게임에서는 얼마나 가까이 있는지에 대한 단서가 제공됩니다. 사무실에서 일부 사람들은 스마트 카드 를 사용 합니다. 나는 그들 중 하나가 아닙니다.

암호를 저장할 때 bcrypt를 사용 하는 것은 처음 시작하는 것이 좋습니다. 단순히 무차별 대입 해킹 시도를 실행할 수 없기 때문입니다.

합리적이고 안전한 것은 상호 배타적입니다. 그들은 막대의 두 끝입니다. 중간에 균형을 잡는 것이 가장 좋습니다. 안전하고 사람들을 위해 비밀번호를 적어 두거나 완전히 안전하지 않은 비밀번호 잠금 해제 기능을 사용하십시오.

위의 예는 합리적인 것보다 더 안전하다고 생각합니다. 나는 더 나쁜 것을 보았다.

나는 합리적인쪽으로 기울기를 선호합니다. 열쇠는 백엔드의 보안 장치에 기대는 것입니다. 가능한 적은 소금을 사용하여 저장하십시오. 비밀번호는 데이터베이스에 인코딩하고 한 가지 방법으로도 인코딩하는 데 권장되는 모든 최신 방법입니다. 그런 다음 데이터베이스와 코드를 안전하게 유지하십시오. 또한 시스템에 대한 관리자 권한이있는 사람에게 고유 한 보안 암호를 사용해야하도록 교육하십시오. 여러 사전 단어를 함께 묶는 것이 특수 문자와 대소 문자를 드래그하는 것보다 더 안전하다는 것이 최근에 나타났습니다. 해커에게는 현명한 시간을 추가하는 복합 사전 일치가 필요했지만 여전히 사용자에게는 기억에 남았습니다.

사전 단어 나 사소한 변형이 아닙니다. 그게 다야. 두 개의 사전 단어 묶음은 거의 깨지지 않습니다. 명백한 대체물 (0-O, 1-I, 5-S)이 아닌 문자를 대체하는 단일 문자 대체.

또한 응답 시간을 제한하는 경우 (1 초 후에 비밀번호 허용 / 거부 됨) 동일한 로그인에 대해 두 번의 병렬 시도가 허용되지 않는 경우, 사전 이외의 다른 6 자 모두 소문자로 시도하기 전에 하나를 완료 (확인 또는 오류)해야합니다. 특수 문자 비밀번호는 9 년이 걸립니다.

암호 요구 사항의 복잡성은 사이트의 내용과 균형을 이루어야합니다. 은행은 매우 복잡한 암호 (대문자, 소문자, 숫자 및 특수 문자)가 필요합니다. 그러나 저장된 검색 및 추적 번호와 같이 내용이 사소한 경우 암호 요구 사항을 완화해야합니다. 6 자 이상이어야합니다. 그렇지 않으면, 그것은 단순히 청중을 귀찮게하고 로그인을 만드는 것을 막을 것입니다.