it-swarm-korea.com

최대 비밀번호 길이는 얼마입니까?

권장되는 최소 암호 길이는 약 8 자이므로 표준/권장 최대 암호 길이가 있습니까?

60
Mohamed

Bruce Schneier는 암호 정책에 관한 흥미로운 기사를 몇 가지 가지고 있습니다.

실제 비밀번호 -비밀번호 길이, 복잡성 및 일반 비밀번호를 포함합니다.

암호 조언 -다음을 포함한 일부 및하지 말아야 할 것 :

  • 비밀번호 관리자를 사용하십시오
  • 비밀번호를 자주 변경하십시오. 6 개월마다 광산을 바꿉니다 ...
  • 이전 비밀번호를 재사용하지 마십시오.
  • 사전 단어, 생일, 가족 및 애완 동물 이름, 주소 또는 기타 개인 정보로 구성된 비밀번호를 사용하지 마십시오.
  • Https를 통해 사이트를 보호하지 않으면 공개 Wi-Fi 네트워크 또는 신뢰할 수없는 다른 네트워크를 통해 비밀번호로 보호 된 계정에 액세스하지 마십시오.

그리고 더 많은

암호 변경 -사용량 및 위협 환경에 따라 얼마나 자주 변경해야하는지에 대한 자세한 설명.

15
Alexandru Luchian

보안에 관한 많은 질문과 같이 이것에 대한 대답은 "의존적"입니다.

암호 길이를 볼 때 고려해야 할 몇 가지 요소가 있습니다. 첫 번째는 긴 암호가 보호하기 위해 고안된 것 중 일부입니다. 일반적으로 암호 추측 공격 (온라인 또는 오프라인)의 무차별 대입입니다.

온라인 암호 추측의 경우, 상대적으로 공격적인 잠금 정책 (예 : 3 번의 잘못된 시도 및 부정확 한 잠금)이있는 경우 공격자가 암호가 무엇인지 잘 모르는 경우 단일 계정에 대한 공격은 성공할 수 없습니다. 될 것.

공격자가 사용자 이름 (예 : 웹 포럼)을 처리 할 수있는 동일한 잠금 정책을 가진 많은 수의 사용자에 대한 공격을 찾고 있다면 가장 중요한 요소는 아마도 사용 된 암호가 정말 일반적인 것들.

또한 계정 잠금 측면에서주의해야 할 점은 여기에 온라인 응용 프로그램에 대한 공격적인 정책이 추가 대책 없이도 서비스 거부 공격을 매우 쉽게 만들 수 있다는 것입니다.

오프라인 무차별 대입의 위험이있는 경우 암호 강도가 더 중요해집니다. 여기서 문제는 개선 된 처리 능력과 공격 방법이이를 힘의 관점에서 움직이는 목표로 만든다는 것입니다. 사실 나는 당신이 10 개 이상의 문자와 암호가 일반적인 사전 목록에 없다는 강력한 시행을보고 있다고 말하고 싶습니다 (@andy는 암호 문구가 여기에서 좋은 옵션이라고 말합니다).

여기서 고려해야 할 또 다른 요소는 사용자 기반과 응용 프로그램 사용 방법입니다. 어떤 경우에는 매우 강력한 암호 요구 사항으로 인해 실제로 보안 수준이 떨어질 수 있습니다. 사용자가 같은 장소에있는 응용 프로그램 (예 : 많은 회사 응용 프로그램)이 있고 암호 정책을 매우 "강하게"(암호 길이 및 회전 요구 사항 측면에서) 만드는 경우 사용자가 시작될 가능성이 있습니다 암호를 적어두면 해당 응용 프로그램의 보안 목표 중 하나를 우선 무시할 수 있습니다.

이것에 대한 더 많은 정보의 좋은 소스 중 하나는 라는 책입니다. 인증 : 암호에서 공개 키

20
Rory McCune

지금까지 좋은 답변이지만 다른 가능성을 제안하고 싶습니다 : pass phrases . StackOverflow 자신의 Jeff Atwood가 제안한 것처럼, 기술적 인 제한에 의해 금지되지 않으면 암호 문구를 허용하고 제안하는 것을 고려할 수 있습니다. 당신은 그것들을 시행 할 수 있지만, 아마도 대부분의 사이트에서 일부 사용자를 소외시킬 것입니다. 길이가 길기 때문에 크랙하기가 훨씬 어려울 수 있으며 "A1lUrB @ se!"와 같은 암호보다 기억하기 쉽습니다. 또는 그런 것들.

19
Andy

비밀번호를 해시하려는 경우 왜 상한값을 설정해야합니까?

웹 기반 또는 기타 텍스트 필드의 최대 문자 제한에 대해 걱정할 필요는 없습니다. 따라서 사용중인 텍스트 필드의 경계 조건을 제한하기 위해 최대 수백 자까지 설정할 수 있습니다.

물론 여러 사이트에서 사용하려고하는 암호 생성에 대해 이야기하고 있다면 걱정하지 마십시오. 거기에 아무도 동의하지 않는 것 같습니다. 더 나쁜 것은 다른 입력 필드에 대해 최대 문자 제한이 다른 사이트를 발견했기 때문에 로그인하려면 더 많은 문자를 허용하는 다른 필드가 제공되기 전에 먼저 잘못 입력해야합니다. 물론 모든 사이트가 인위적으로 제한하지 않고 일반적인 텍스트 필드의 최소 예상 기능으로 허용한다면 약 2k 문자가 허용되며 전혀 걱정할 필요가 없습니다.

추가하도록 편집 : here 전달에서 언급 한 내용으로 인해 일시 중지되었습니다.

해시 작업을 서버 또는 장치에서 사용 가능하고 합리적인 수준으로 확장해야합니다. 예를 들어, Discourse에서 사소한 서비스 거부 버그가 발생하여 사람들이 로그인 양식에 최대 20,000 자의 비밀번호를 입력 할 수있게했습니다.

따라서 계산 비용이 많이 드는 방식으로 물건을 해시하는 경우 암호 설정 및 시도에 대해 합리적인 제한을 두는 것이 좋습니다. 수백 자의 문자로 인해 여전히 폭발하는 것을 막을 수는 있지만 사용자가 시도한 것보다 더 많은 방법이 있습니다.

16
Doug Kavendek

최대 암호 길이는 없어야합니다. 사용자가 매우 긴 암호를 사용하는 경우 차단가 아니라 권장이어야합니다.

소프트웨어는 여러 시스템에서 GUI 문제, 프로그래밍 불량 또는 이전 시스템과의 하위 호환성으로 인해 암호 크기를 제한합니다. 예를 들어, 오래된 유닉스 시스템은 처음 8자를 사용한 암호 해싱 프로세스를 사용했으며 다른 모든 문자는 완전히 무시했습니다. 마찬가지로 이전 Windows 시스템의 내부 제한은 14 자로 제한되었습니다. 따라서 암호가 처음 14 자로 잘릴 때 여전히 "강력한"것이 가장 좋습니다.

그러나 최대 암호 크기에 대한 유일한 제한은 사용자의 인내심입니다. 여기서는 어떤 것도 시행 할 필요가 없습니다.

8
Thomas Pornin

오늘날 일반적인 최소값은 12 자이며, 합당한 시간 내에 합리적으로 자금을 조달 한 조직의 무차별 대입 균열을 막기에 충분할 정도로 큽니다.

최대 길이까지; 여기 몇 가지 생각이 있습니다. 수백 바이트보다 긴 암호는 거의 확실하게 악의적입니다 (예 : SQL 주입 시도). 또한 암호를 해시하는 경우 (그리고 그렇지 않은 경우 다시 시작 해야하는 경우) 해시 출력보다 암호 longer 더 이상 엔트로피를 추가하지 않습니다. "길이"는 키 길이가 같은 문자 길이가 아니라 같은 비트 수를 의미합니다. 따라서 해시 길이보다 긴 암호를 허용하는 것은 편의상 허용이어야하지만 수학적인 관점에서는 그러한 것이 필수 .

대소 문자를 혼합하면 알파벳 크기가 두 배가되므로 복잡한 반환이 필요하며 아마도 필요할 것입니다. 숫자를 요구하면 알파벳에 20 % 더 추가 될 수 있습니다. 이는 그리 큰 문제가 아니며 기호를 요구하면 그 위에 16 %에서 40 % 더 추가 할 수 있습니다 (심지어 어떤 기호에 따라 다름). 상당히 큰 수익이지만 분명히 허용해서는 안됩니다.

3
tylerl

개인적으로 암호 생성기 (lastpass.com 또는 1password와 같은)를 사용하여 최소 8 자 및 최대 32 자의 암호를 생성하고 사용합니다 (모든 사이트가 10 또는 15 이상의 암호 길이를 지원하는 것은 아니기 때문에) 하나의 마스터 암호를 사용합니다 (이것은 lastpass.com과 같은 사이트에 대한 귀하의 신뢰에 달려 있습니다) 또는 Mac 및 Windows 용 클라이언트 측 암호화 된 1 암호 유틸리티입니다.

모든 사이트에 암호 세트를 사용하지 않는 것이 좋습니다. 특히 포럼에서 비밀번호를 일반 텍스트로 이메일로 보냅니다. "비밀번호 분실"기능을 사용하는 경우 일부 사이트에는 일반 비밀번호로 전송하는 기능이 있습니다.

일반적으로 서버 (웹 사이트)에서 제한 사항이 설정됩니다. 우리는 사용자 암호에 대한 제한을 설정하지 않기 위해 사용하는 서버를 비난해야합니다.

즉, 매번 다른 암호를 사용하십시오. 기억해야 할 암호가 10-15 개 이상인 경우 "보안"암호 관리자를 사용하는 시간입니다. (기록을 위해 파이어 폭스 암호 관리자는 전혀 안전하지 않습니다)

2
Sairam

16 자.

이것은 Wikipedia 에 따라 96 비트를 제공하며, 이는 해당 기사에 따라 해독 가능한 것 이상입니다.

개인적으로 Firefox의 마스터 비밀번호 기능과 결합 된 휴대 전화 용 비밀번호 프로그램을 사용합니다. 마스터 비밀번호는 25 자 이상이며 Dice Ware를 기반으로하므로 기억하기가 쉽습니다. 파이어 폭스는 어쨌든 나를 위해 암호를 기억하기 때문에 거의 모든 암호가 무작위로 재생성됩니다.

2

나는 경비원이 미친 클라이언트에 있었다. 그는 가능한 모든 단일 암호 복잡성 정책을 사용하고 싶었습니다. (Novell eDirectory에는 많은 암호 복잡성 문제가 있으며 추가 플러그인을 사용하여 더 추가하려고했습니다!)

지금까지 기억할 수있는 비밀번호를 생성하는 것은 불가능합니다. 나는 씻지 않은 대중이 그를 찾을 것을 기대하고 있었고, 그것이 실행 된 후에 타르와 깃털을 썼다.

즉, 너무 멀리 가져갈 수 있습니다.

1
geoffc

조언

2019 년 보안 암호/암호에 필요한 임의성은 다음과 같습니다.

  • 소문자, 대문자 및 숫자로 임의로 생성 된 12 개의 문자 또는
  • 6 개의 무작위로 생성 된 단어. (Do not 직접 단어를 선택하십시오! 패턴을 만듭니다.)

이 중 20 개를 기억하는 것은 불가능하므로 정기적으로 사용하는 몇 가지 중요한 것들만 외우십시오. 예를 들어, 전자 메일 계정 용 암호와 암호 관리자 용 암호를 기억할 수 있습니다. 다른 모든 경우에는 비밀번호를 비밀번호 관리자에 저장하십시오.

관련 : 일반 사용자는 실제로 암호 관리자가 필요합니까?
최고의 답변은 "예"입니다.

관련 : 비밀번호 관리자는 얼마나 안전합니까?
정답에서, paj28 (강조 광산) :

대부분의 사람들은 이러한 위험을 감수 할 수 있으며 비밀번호 관리자를 사용하여 대부분의 비밀번호를 사용하는 것이 모든 곳에서 동일한 비밀번호를 사용하는 것보다 낫습니다.-이 방법이 주요 대안이라고 생각합니다 . 그러나 거기에 모든 암호를 저장하지는 않습니다. 온라인 뱅킹과 같이 가장 중요한 것을 기억하기 위해 노력하십시오.

일반적으로 언급되는 암호 관리자는 KeePass (X), 1Password 및 LastPass입니다. 브라우저의 암호는 마스터 암호로 Firefox를 사용할 때 전용 암호를 사용하는 것만 큼 좋습니다. 비밀번호에 액세스하기 전에 브라우저에 비밀번호가 필요하지 않은 경우 비밀번호가 안전하지 않습니다 (세부 사항은 정확한 구현에 따라 달라 지므로 전체 주제 임).

개발자

애플리케이션을 빌드 할 때 다음과 같은 유용한 고려 사항이 있습니다.

암호를 안전하게 해시하는 방법?
요약 : Scrypt 또는 Argon2를 최대한 느리게 사용하십시오. 이들이 사용 불가능한 경우 Bcrypt 또는 PBKDF2를 사용할 수 있습니다. saltpepper 를 모두 추가하십시오.

최대 암호 길이를 지정해야합니까?
요약 : DoS 공격에 대해서만, 따라서 몇 킬로바이트 정도입니다.

클라이언트 측 비밀번호 해싱 구현
전체 공개 : 가장 완벽한 답변이라고 생각하기 때문에 본인의 답변에 연결됩니다. 다른 사람들의 의견도 읽으십시오.

세부

"왜 내 PIN 코드는 4 자리 숫자입니까? 그러면 내 은행 계좌를 안전하게 유지하기에 충분합니다!") 궁금 할 것입니다. 이 질문에 전념하는 질문 이 있습니다. 요약은 두 가지입니다. 액세스를 위해 은행 카드가 필요하고 (두 번째 인증 요소), 3 번의 시도 후에 칩이 잠 깁니다.

웹 사이트는 훨씬 관대하므로 공격자가 더 많은 시도를 할 수 있습니다. 또한 웹 사이트는 조만간 해킹 될 것으로 예상되며, 그 후 공격자는 해시 된 비밀번호를 효율적으로 해독 할 수 있습니다.

대부분의 웹 사이트는 암호를 일종의 단방향 암호화 (해싱이라고 함)와 함께 저장합니다. 암호 해독 키가 없습니다. 동일한 해싱 알고리즘을 다시 적용하면 시스템은 방금 입력 한 암호와 데이터베이스의 저장된 암호를 비교하여 암호가 같은지 알 수 있습니다. 그러나 데이터베이스 만 있으면 원래 비밀번호를 알 수 없습니다.

과거에는 빠른 해싱 방법이 일반적이었습니다. 이것은 또한 해시를 얻은 공격자가 자신의 컴퓨터가 평균 게임 컴퓨터에서 초당 수십억 회 시도를 할 수 있음을 의미합니다. 초당 100 억 회 시도를 가정하면 11 자 임의 암호는 약 165 년 동안 유지됩니다. 그리고 그것은 하나의 게이머 일뿐입니다. 일부 외국 경쟁자들이 관심을 가지고있는 회사 데이터에 액세스 할 수 있다고 상상해보십시오. 추가적인 계산 능력으로 인해 165 년이 갑자기 몇 달의 크래킹으로 바뀌 었습니다. 그리고 내년에는 같은 가격으로 더 빠른 새로운 CPU가 등장하여 다시 강점을 줄입니다. 그렇기 때문에 12 개의 문자가 강력한 암호의 최소값 인 이유는 하나의 추가 문자가 문자 그대로 10 만 년을 크래킹 시간 (165 년 대 10230 년)에 추가하고 가까운 미래에 안전하다는 것입니다.

그건 그렇고, 암호 강도를 계산하는 것은 쉽습니다 : variations^length / guesses_per_time. 변형은 고유 한 요소의 수이며 길이는 사용하는 요소의 수입니다. 따라서 숫자 만 사용하면 10 가지 변형 (0-9)이 있습니다. 사전의 단어를 사용하면 사전에 많은 단어가 있습니다. 그런 다음 guesses_per_time은 공격자가 얼마나 빨리 크랙 할 수 있는지를 가정 한 것입니다. 합리적인 가치는 초당 수백억입니다.
예: 10^14/10e9/3600은 초당 10e9 회 시도 (1 시간에 3600 초, 60 * 60)를 가정 할 때 14 자리 코드를 해독하는 데 걸리는 시간을 보여줍니다.

일부 웹 사이트는 똑똑하고 느린 해싱 알고리즘을 사용합니다. 서버가 해싱을 수행하기 때문에 어느 쪽인지 알 수 없으므로 외부에서 볼 수 없습니다. 이 경우 단일 추측 (서버 및 공격자)을 계산하는 데 시간이 더 오래 걸립니다. 합리적인 경우, 자금이 잘 갖춰진 공격자는 초당 5 만 번의 추측 만 할 수 있으며,이 경우 9 자 암호이면 충분합니다. 그러나 9 개의 임의의 문자는 이미 여러 계정에 대해 암기하기가 매우 어렵습니다. 특히 정기적으로 사용하지 않는 경우 특히 그렇습니다. 따라서 비밀번호를 실제로 보호하려면 비밀번호 관리자가 필요합니다.

그러나 실제로 고유 한 비밀번호가 필요합니까? 다른 사이트에서 강력한 암호를 다시 사용하지 않는 이유는 무엇입니까? 웹 사이트가 자주 손상되기 때문입니다. 매일 발생하는 것은 아니지만 haveibeenpwned.com 에 이메일 주소를 입력하십시오. 확실히 많은 일이 발생합니다. 이것은 계정이 가장 자주 해킹되는 방식입니다. 비밀번호 재사용. 암호 관리자의 타협은 훨씬 덜 일반적입니다.

0
Luc