비밀번호 모범 사례


30

웹 사이트 관리자로부터 '해커'학습 및 비밀번호 재시 도와 관련된 최근 이벤트를 고려할 때 비밀번호와 관련 하여 모범 사례에 대해 모든 사람에게 제안 할 수있는 것은 무엇입니까?

  • 사이트간에 고유 한 비밀번호를 사용하십시오 (예 : 비밀번호를 재사용하지 마십시오)
  • 사전에있는 단어는 피해야합니다
  • 영어 이외의 언어로 된 단어 나 문구 사용을 고려하십시오
  • 패스 문구를 사용하고 각 단어의 첫 글자를 사용하십시오
  • l33tifying 은별로 도움이되지 않습니다

더 제안하십시오!


4
팁 3은 팁 2와 모순됩니다.
Oddmund

@Oddmund : 영어와 영어 이외의 언어를 모두 사용하는 경우는 아닙니다. 스페인어로 된 One은 uno이므로 OneUno를 사용하십시오. 또는 단어 분리 : 단어의 절반은 영어에서, 다른 절반은 다른 언어에서 나옵니다. 스페인어 축구는 fútbol이므로 futball을 사용하십시오. 그리고 거기서부터 되풀이하십시오.
Kevin M

@Oddmund : A (비 영어) 언어에서 단어를 사용 호는 그들이 (비 영어) 사전에서 찾을 수있는 의미하지 않는다
user1092608

답변:


25
  • 일반적인 단어 나 이름으로 구성 되지 않은 암호를 사용하십시오 . 사전 공격은 수백만 단어로 사전을 사용하며 매우 빠릅니다.

  • 긴 비밀번호를 사용하십시오. 나는 암호 를 사용하는 경향이있다 . 문구, 문장 또는 운을 선택하고 영숫자가 아닌 문자를 사용하여 내 단어가 사전 단어가 아닌 방법을 찾습니다.

  • 여러 로그인 서비스에 동일한 비밀번호를 사용하지 마십시오. 암호 문구를 고르기위한 공식을 생각해 봅시다. 이를 통해 잊어 버린 경우 몇 번의 시행 착오로 다시 만들 수있는 다양한 암호를 사용할 수 있습니다.

  • 반드시 길고 안전한 안전한 암호를 작성하여 어딘가에 숨겨야합니다. 기억하기 쉬운 약한 암호를 사용하는 것보다 낫습니다.

  • 위의 제안 사항을 관리 할 수없는 것으로 판명되면 보안 암호가 긴 암호 관리자를 사용하고 다른 모든 문자에는 임의의 문자 암호를 사용하십시오. 암호화 된 USB 플래시 드라이브 (물론 백업 됨)로 암호 관리자를 가지고 다니십시오.


왜 'passphrases'에서 굵게 표시가 작동하지 않는지 아는 사람이 있습니까? 편집 모드에있을 때 미리보기에서 잘 보입니다. 홀수.
Arnold Spence

두 개의 별을 사용합니까, 아니면 하나를 사용합니까? 하나만 시도하십시오.
Mikeage

1
@Mikeage : 별표 하나 = 이탤릭체; 두 = 대담한. <b> 또는 <strong> 시도해보십시오. 나는 그것을 단어에 포함시키는 것이 SO의 파서를 혼란스럽게 생각합니다.
derobert

1
"통과"바로 뒤에 공백을 넣으려고하면 한 공간] [별표] [별표] 구문을 통과하게됩니다. 그래도 문제가 해결되지 않으면 두 번째 별표 배치와 기간 사이에 공백을 두십시오.
pbz 2016 년

3
"길고 안전한 보안 암호를 작성하고 숨기려면"+1하십시오. 1980 년대에 누군가가 사용자에게 암호를 적어 두지 말라고 경고하기 시작했고, 그 동작이 멈추었고, 그로 인해 우리 모두가 더 나빠졌습니다.
Portman

7

암호 문구에 몇 가지 문제가 있습니다.

  • 많은 사이트는 암호 길이의 상한을 20 문자처럼 제한합니다. 어리석은 일이지만 어떻게 할 수 있습니까?
  • 다른 사이트는 비밀번호에 공백을 허용하지 않습니다.
  • 긴 텍스트를 맹목적으로 입력하면 오류가 발생하기 쉽습니다. 특히 터치 타이피스트가 좋지 않은 경우에 특히 그렇습니다.
  • 50 자 암호를 입력하면 좋은 15 자 암호보다 시간이 오래 걸립니다.

이 문제에 대한 나의 해결책은 암호를 실제 암호의 니모닉으로 사용하는 것입니다. 예를 들어 윌리엄 헨리 데이비스 (William Henry Davies) (76 자)에서 몇 줄의 위대한시를 고를 수 있습니다.

우리가 숲을 지나갈 때
다람쥐가 잔디에 견과류를 숨기는 곳 을 볼 시간이 없습니다 .

그리고 나는 각 단어의 첫 글자를 골라 다음과 같은 16 자짜리 암호를 만듭니다.

Nttswwwp,Wshtnig

시를 사용하는 것이 기억하기 쉽고 암호를 변경하라는 요청을 받으면시의 다음 몇 줄을 선택할 수 있기 때문에 특히 좋습니다.


3
또한, 비밀번호가 변경 될 때마다 새로운시를 배우게되므로 약간의 문화적 포인트를 얻게됩니다. :)
Jonathan

4
나는 노래 가사를 사용하여 이것으로 발을 내딛었다. 먼저 노래를 윙윙 거리는 경향이 있습니다. 둘째, 노래가 한 달 동안 내 머리에 갇히게 ...
Kara Marfia

4

다른 사람에게 암호 체계를 지시 할 때는 고유 한 임계 값보다 길고 대소 문자, 특수 문자 등을 포함하도록 요구할뿐만 아니라 암호 관리자 또는 체계에 대해 암호를 구성 / 기억하도록 교육해야합니다. 그렇지 않으면 사용자는 암호를 적어 두거나 "기억"할 다른 안전하지 않은 방법을 찾습니다.


암호 관리자를 가르치는 것은 기술이 아닌 일반 사용자에게는 나쁜 예입니다. 약간 더 좋지만 나쁜 습관 (비밀번호 쓰기)을 거래하고 있지만 여전히 나쁜 습관 (전자식으로 저장)입니다. 암호 관리자의 취약성 (예 : 약한 마스터 암호, 원격 악용 등)으로 인해 재해가 발생할 수 있습니다.
spoulson

즉, 은행 로그인 등과 같은 비밀번호 관리자에 중요한 비밀번호를 저장하지 않습니다.
spoulson

Bruce Schneier조차도 사이트간에 재사용 및 / 또는 섞인 약한 암호를 사용 하는 것보다 강력한 암호를 가진 암호 관리자를 사용할 것을 권장한다는 점에 동의하지 않습니다 .
Martin C.

@ spoulson : 기술에 대한 맹목적인 의존은 항상 위험합니다. 나는 개인적으로 암호화 된 암호 볼트 (좋은 암호를 사용하고 마음을 사로 잡는 것)는 로그인 프롬프트와 마찬가지로 안전하다고 생각합니다. 로그인을 강화하기 위해 OS 공급 업체를 신뢰하는 경우 Password Managers 작성자도 신뢰할 수 있습니다. 편집증 규칙. .. 아무도 믿지 마세요 ..... 그러나 결국 그것은 항상 믿음의 도약에 해당합니다 ...
lexu

2
Schneier는이를 적어 두는 것이 좋습니다 : schneier.com/blog/archives/2005/06/write_down_your.html
Will M

4

암호를 기억하는 데 어려움이 있으면 잘 알려진 텍스트를 사용하십시오. 문장을 고르고, 각 단어의 n 번째 문자를 암호로 사용하고, 문장 부호를 유지하십시오. (예 : 이 답변의 첫 번째 문장에서 첫 번째 문자로 생성 된 비밀번호는 "Iyhtrp, uswkt"일 수 있습니다.) 대문자를 변경하고 특수 문자를 추가하여 더 강력하게 만들 수 있습니다.


정말 좋은 방법입니다!
Techboy

3

암호를 사용하지 마십시오. 처음부터 잘못되었습니다. 임의의 문자 모음 (최소 8 자) 또는 암호를 사용하십시오. ILikeStackOverflowOnions 또는 ILikeServerFaultOnions와 같이 각 사이트에 대해 다른 암호를 생성하는 공식을 만들 수 있습니다. 이렇게하면 외부인으로부터 안전하게 보호 할 수 있지만 실제 사이트가 해킹되고 암호가 소금에 맞지 않거나 관리자가 처음에 손상된 경우에도 여전히 문제가 발생할 수 있습니다.


1+ 그러나 암호 문구에 공백이나 문장 부호가없는 이유는 무엇입니까? "I 올리브와 serverfault.com을 좋아합니다!"와 같이 imho에 힘을 더하고 있습니다. 이는 입력하고 기억 ^^ 아직 매우 빠르고 쉽게 꽤 강력한 암호를해야합니다 (암호에 공백에 싫은 내색을 정말 오래되거나 모호한 시스템 - 지옥에 가서 그들에게)
오스카 Duveborn

글쎄요, 구두점은 물론 공백도 플러스입니다. 하지만 난 한 번 :-(하지 않았다 은행이 있었다, 구두점과 암호를하지 않습니다 매우 짜증나는 안전하지 않은 사이트 거기 발견했습니다
아담 Gibbins

1
@Oskar Duveborn : 암호에 문장 부호를 사용하는 대신 암호를 더 길게 만들 수 있습니다. 수학적으로 결과 (가능한 암호 수)는 동일합니다. 조금 더 길게 만들면 소문자만으로도 PW를 사용할 수 있습니다.
sleske

예, 사람들을위한 문구를 쉽게 기억하기 위해 구두점에 빠졌습니다. 더 긴 암호의 이점은 보너스 일뿐입니다.) 또한 3 년 전에 공백을 취하지 않은 은행도있었습니다. 요즘은 괜찮습니다. 그리고 오래된 유닉스 시스템은 최대 8 자이지만 입력 한 내용을 볼 수 없으므로 항상 30 자 암호 전체를 입력하는 것처럼 보일 수도 있습니다.)
Oskar Duveborn

3

비밀번호를 정기적으로 변경하십시오. 내가 일하는 곳은 30 일주기입니다. PITA이지만 해킹 된 비밀번호의 가치를 제한된 시간 창으로 완화합니다. 또한 복잡한 AD 암호 정책에 따라 8 자 이상이어야하며 상위, 하위, 숫자 및 기호를 포함해야합니다.

보충하기 위해 셀프 서비스 암호 관리자 서비스를 사용합니다. 사용자가 암호를 잊어 버린 경우 다시 설정하거나 암호를 너무 많이 잘못 입력 한 경우 잠금을 해제 할 수있는 기능을 제공하는 사용자 지정 Windows GINA를 제공합니다. 비밀번호 관리자 앱은 사용자가 서비스에 등록해야하며 나중에 사용자가 비밀번호를 재설정 / 계정 잠금 해제해야 할 때 질문으로 사용되는 개인 정보 만 제공합니다.


3
시간 기반 암호 변경을 시행하는 것은 일반적으로 실제로 나쁜 습관으로 간주됩니다. 나는 대부분의 사람들 암호의 마지막 몇 자리가 마지막으로 설정된 달 또는 연도를 포함한다는 것을 거의 보증 할 수 있습니다.
앤드류

3

사용자가 생각하지 않고 암호를 생성해야한다고 생각합니다. 이것은 추측하기 쉬운 암호로 모든 바보 같은 문제를 피합니다.

pwgen 을 사용하고 싶습니다.

Bai4phei Gohh7Too cee3Iegh eegh7Aiy kaing6Mu ohBi0woo oH7bieRo Opai1Vov
sahpee6Y joo3iKe4 iegai4Ae chi1Akee se2vaDoo Xivae4ew eN4aquoh ahMaeye1
Ci3mie2e Oosh3aiy pueX1OoF uXee7chi theo4doT ied6Haeg Pey3beer viZeish2 
Itoogoa3 RaeD6woh IeJ9guLo Afuozii9 equahGh7 ui9uaJae qui4Geis Eikib2ko 
Ua7viequ iedieY9Y Deihae1u uu6aR7xa ThooG6mu HeiZ7jai choo7ohM jael0Lai 
Beelae6s wu0uTieK eiX8equu uPeeS2ub WaiceeP1 tha2Ohz1 xeiroh9E Eak6leiy 

그러나 실제로는 모든 PW 생성 프로그램이 할 것입니다. pwgen의 한 가지 장점은 모음을 포함 시켜서 암호를 기억에 남게 만드는 것입니다.


그게 내가하는 방식입니다. 많은 암호를 생성하고 1, l I 등과 같은 모호한 문자가없는 암호를 선택하십시오.
John Gardeniers


2
  1. 강력한 비밀번호를 사용하십시오.
  2. 비밀번호를 재사용하지 마십시오.
  3. # 2를 고려할 때 압도적 인 이질적인 계정에 직면 할 때 PwdHash 와 같은 도구를 사용하십시오 .


2

로그인 한 모든 웹 사이트에 대해 고유 한 비밀번호를 생성 하려면 SuperGenPass 와 같은 도구를 사용하십시오 .


비밀번호를 생성하는 데 백만 개의 바보 같은 규칙이 아닌 비밀번호 만 생성하는 경우 +1입니다.
sleske

2

Hak5 는 Remote Exploit 의 도구를 보여주는 에피소드를 방금 보여 주며 여러 문자열을 사용하고 모든 조합, 상한, 하한, 거머리 철자 등의 사전을 생성합니다. 따라서 대상의 이름, 아이의 이름, 생년월일 또는 대상에 대해 알고있는 기타 정보 생성 된 사전은 약한 암호를 무차별 공격하기위한 입력으로 사용할 수 있습니다.

도덕 : 비밀번호에 개인 정보를 사용하지 마십시오


1
다른 한편으로, 나는 클라이언트의 암호 요구 사항 중 하나가 "사전 단어의 형태가 될 수 없음"(leet 등) 인 사이트에서 작업하기 때문에 비슷한 생성기를 만들어야했습니다. 금지 된 다양한 변형은 모두 암호를 변경했을 때 포스트 백주기 내에서 충분히 빠르게 실행될 수있었습니다.
GalacticCowboy

좋은 점, 더 많은 선택을 제한할수록 가능한 선택이 더 명확해질 수 있습니다.
spoulson

1
@spoulson이 동일한 것을 의미하는지 확실하지 않지만 사전에서 단어를 적극적으로 금지하는 경우 기본적으로 가능한 암호 수를 제한하지 않습니까? 따라서 이론적으로 암호를 쉽게 찾을 수 있습니까?
Arjan

아이디어는 사전 공격을 받거나 제 3자가 쉽게 기억할 수있는 암호에서 인식 가능한 패턴을 제거하는 것입니다. 약한 암호를 만드는 기능을 제거해도 암호 체계가 약해지지는 않습니다.
spoulson

@Ajran : 물론, "약한"암호를 허용하지 않으면 암호의 비트 길이 (주어진 최대 길이)를 효과적으로 줄일 수 있습니다. 그러나 이것은 암호 공간에서 무시할 수없는 부분을 실제로 허용하지 않는 경우에만 중요합니다.
sleske

2

영어 이외의 언어로 된 단어 나 구를 알고 있으면 암호의 일부로 사용할 수 있습니다. 예를 들어, 나는 일반적으로 일본어 단어를 암호의 일부로 사용하여 사전 공격을 피하면서도 무작위로 생성 된 암호와 달리 암호를 기억할 수 있습니다.


2
암호를 공격하는 사람들이 영어 만 사용한다고 가정하지 마십시오. 영어 만 사용하는 공격자가 암호 크래커에 다른 언어 사전을 추가하지 않을 것이라고 가정하지 마십시오.
pgs

2

나는 웹 암호를 저장하기 위해 Bruce Schneier가 원래 디자인 한 Password Safe를 사용하기 시작했습니다 . 비밀번호 안전에 매우 강력한 비밀번호 문구가 있으며 다른 모든 비밀번호는 자동 생성되며 전체 웹 사이트에서 재사용되지 않습니다.

이 소프트웨어에는 암호 만료 등과 같은 기능도 있습니다.

나는이 (주어진 고려 강력한 안전한 암호) 웹 사이트 암호에 최고의 트레이드 오프와 가장 안전한 방법이 될 수 있습니다.


1

나는 가족과 친구들에게 일반적으로 애완 동물 이름과 어머니 성함과 같은 물건과 다음 두 가지 일이 발생하는 한 물건을 사용하는 것이 좋습니다.

  • 최소한 두 개의 이름을 연결하십시오 (예 : 어머니의 성함 + 애완 동물 이름)
  • 대문자와 특수 문자를 통합하십시오.

보안 수준이 낮은 응용 프로그램에는 좋습니다. 그러나 온라인 뱅킹 사이트와 같은 경우에는 원하지 않습니다.
David Z

나쁜 생각은 완전히 멈췄다. 너무 예측 가능하며 모든 곳에서 약한 암호를 권장합니다. 직원에게 제공되는 것과 같은 조언을 가족 및 친구에게 제공해야합니다.
Judioo

@ i-moan 동의하는 경향이 있지만 올바른 방향으로 나아가는 단계로 사용하고 있습니다. 애완 동물의 이름이나 뭔가를 사용하여 그냥 반대로 내가 그들이 방법을 사용하여 얻을 수 있다면 나는 그것이 올바른 방향으로의 한 단계라고 생각
기독교 Hagelid

좋은 의견. 기억하기 쉽지만 다른 사람들이 추측하기가 불가능한 것들
Techboy

1

필수 비밀번호 만료 기간을 설정하는 경우 일 블록 (예 : 30 또는 60 일)이 아닌 7의 요소를 선택하십시오.

30 일 만료의 결과로 사용자는 휴일 또는 주말에 비밀번호를 변경해야하며 다음 날에 일을 시작하면 놀라게 될 수 있습니다.

만기 스케일을 7로 설정하면 암호 변경 날짜가 이전 변경과 동일한 요일에있게됩니다.


실제로, 만기일이있는 대부분의 시스템에는 두 개의 만기일이 있습니다. 첫 번째 이후에는 다음 로그인시 비밀번호를 변경해야합니다. 두 번째가 pw 변경 만 통과 한 후에 만 ​​료가 실제로 발생합니다. 따라서 이것은 일반적으로 문제가되지 않습니다.
sleske

1

동일한 사용자 기반에 대해 여러 사이트가있는 경우 Shibboleth와 같은 단일 형식의 단일 사인온을 강력하게 제안해야합니다. 사용자가 여러 사이트에 대해 다른 비밀번호를 사용하면 모든 비밀번호를 기억하는 데 어려움이 있습니다. 하나 또는 두 개의 암호는 대부분의 사람들이 쉽게 기억하며, 세 개는 비밀 위치에 암호를 기록 할 수 있습니다. 사용자가 4 명 이상이면 게시물에 메모를 작성하여 책상이나 모니터에 적용 할 수 있습니다.

암호는 지나치게 복잡 할 필요는 없지만 첫 번째 또는 두 번째 시도를 방지하기에 충분히 복잡해야합니다. 시스템 / 사이트에 로그인 시도 횟수를 제한하는 일종의 보안 조치가있는 한 암호는 너무 복잡 할 필요가 없습니다.

예를 들어, 시스템의 시간당 로그온 시도 횟수가 3 회로 제한되는 경우 "Cindy65"와 같은 기본 암호는 더 복잡합니다. 해커는 사용자의 실제 이름이 Cindy라는 것을 알지만 실제로는 1965 년에 태어난 것을 알지 못할 것입니다. 그의 시도는 당연히 "cindy", " l astname", "Cindy", L astname "입니다. 시간이 차단되었습니다.

이것은 단순한 경우이고 간단한 암호 일 수 있지만 관리자가 모든 서버를 올바르게 설정 한 경우 실제로 필요한 모든 것입니다. 또한 임의의 키 조합과 같이 기억하기 쉬운 약간 더 복잡한 암호를 요청할 수도 있습니다. 기호와 대문자도 크게 도움이됩니다.

우리는 사용자가 더 힘들게 만들수록 공개적으로 기록 할 가능성이 높다는 것을 기억하면됩니다.

내가 항상 사용자에게 요청하고 싶은 한 가지는 자신이 사용하는 약품 이름, 좋아하는 음식, 가장 친한 친구 이름 등으로 연결된 이름을 작성하는 것입니다. 단순하면서도 사전 단어의 조합은 크랙하기가 거의 불가능합니다.

예 : CindyProzac, WilliamCodene, JoePetertherabbit

행운을 빕니다.


0

적어 두지 마십시오. 그리고 그렇게한다면, 금고에 넣으십시오. 그리고 콤보도 쓰지 마십시오 .


2
누군가가 집에 침입하여 비밀번호를 훔친 마지막 시간은 언제입니까? 개인 사용자의 경우 암호를 적어 두는 것이 가장 안전합니다. 강력하고 고유하며 기억하기 어려운 암호를 권장하기 때문입니다.
Portman

본인은 Ben에 동의합니다-특히 작업 환경에 대한
Techboy

0

보안 요구 사항이 매우 까다로운 경우 가능한 한 암호를 사용하지 마십시오. ssh 키 기반 인증, 스마트 카드의 클라이언트 인증서 등을 사용하는 것이 좋습니다. 제대로 작동하려면 많은 기술과 예산이 필요하므로 적절한 위험 평가를 수행해야합니다.

암호를 고수하기로 결정했다면 capar와 lexu의 조언을 따르겠습니다.


0

암호 길이 제한은 바보입니다. (암호를 6-8 자로 제한하는 것이 일반적이지만 현대 시스템에서는 의미가 없습니다.)

빈번한 암호 변경을 요구하면 사용자는 암호를 기록하고 더 간단한 암호를 선택할 수 있습니다. 이는 위협과의 상충이며 어떤 위협이 더 관련성이 있는지 고려해야합니다.

문자로만 구성된 30 자 암호를 허용하는 대신 정확히 8 자 암호에 "특수 문자"를 포함하도록 요구하는 것은 말이되지 않습니다.

사용자에게 명백한 암호를 제공하지 말고 변경하도록 요청하십시오. 그들은하지 않습니다. 처음 로그인 할 때 비밀번호를 변경하거나, 비밀번호를 적어 둔다는 것을 알기 위해 강력한 비밀번호를 선택하거나, 본인 앞에서 강력한 비밀번호를 선택하도록하십시오.


0

우리는 암호 문구를 선택하고 각 단어의 첫 글자를 사용하도록 사용자를 교육합니다.
WTOUTPPAUTFLOEW-0 또는 3을 추가하고 (수확), 몇 번의 Capslock을 변경하면 사전에서 찾을 수 없지만 기억하기 쉬운 것이 있습니다.

그러나 회사 슬로건 / 비전 진술 등을 기반으로 비밀번호를 비밀번호 문구로 변경하지 않도록하십시오.


-1

해당 웹 사이트 관리자에게 발생한 일을 방지하고 Unix 쉘 또는 Cygwin에 액세스 할 수 있다고 가정하면

$ echo -n *password* | md5sum -

d1b13e9abbe4edb1b07317241969376e -

http://gdataonline.com/ 과 같은 MD5 데이터베이스에서 해당 값을 확인하십시오 . 거기에 나타나지 않는지 확인하십시오.

또한 다음은 해시 값 (경고 : 큰 파일)을 간단히 검색하여 얻은 더 원시 MD5 사전의 예입니다. https://secure.sensepost.com/sp-hash/jebwy


1
예, 이것은 작업 대기열에 새로운 해시를 제출하는 완벽한 방법이므로 특정 시점에서 간단한 해시에 대한 Google 검색으로 비밀번호가 표시됩니다. 그러한 사이트에 해시를 제출하지 않는 것이 좋습니다.
serverhorror 2012 년

2
당신의 해시는 "jeffa"btw ...
serverhorror
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.