사용자가 n 일 / 주 / 월마다 비밀번호를 변경하도록해야합니까?


19

질문은 모든 것을 말합니다. 보안이 매우 중요한 시스템을 설계하고 있습니다. 누군가가 생각한 아이디어 중 하나는 사용자가 3 개월마다 비밀번호를 변경하도록 강요하는 것이 었습니다. 암호를 자주 변경하기 때문에 보안이 강화되었지만 사용자가 암호를 변경하는 것을 기억하고 기억하기 위해 어딘가에 적어 둘 가능성도 높아졌습니다.

같은 생각으로 사용자가 암호를 추측하기가 매우 어렵도록 강요하는 것이 좋습니다. ? % & %와 대문자 소문자를 사용하도록합니다. 나는 그러한 암호를 발명하고 기억하는 것이 번거 롭다는 것을 알고 있습니다.

그런 다음 다시 12345를 사용하는 사람을 원하지 않습니다.

그래서. 이 주제에 대한 백서가 있습니까? 좋은 연습?

PHP로 만든 웹 사이트에 대해 이야기하고 있습니다. 램프 환경에서 MySQL이 변경되면 변경됩니다.


누군가이 주제를 마무리하는 것에 투표했습니다. 암호 관리는 프로그래밍과 관련이 있다고 생각합니다. 그러나 지역 사회가 어려움을 겪고 있다면 어디에서 물어야합니까? 수퍼 유저?
Iznogood

1
솔직히 저는 고객의 보안이 그의 관심사라고 생각합니다. 반드시 SSL을 사용하여 암호화를 유지하여 암호화 할 수 없도록하십시오. 그러나 비밀번호에 "0"을 사용하려는 경우 자체 오류입니다.

나중에 결정한 것을 구현할 수있는 인터페이스를 만드십시오. 암호 강도를 확인하는 방법 (또는 암호에 문제가 있다고 말하는 방법)과 암호 변경시기 또는시기 등을 평가하는 방법 등이 있습니다. 이제 "ok"를 반환하고 "변경할 필요가 없습니다":) 나중에 serverfault에서 답변을 받으면 문을 열 수 있습니다.
helios

2
@mathepic- "비밀번호로"0 "을 사용하려면 본인의 잘못입니다." -개념에 동의하지만 실제로 사이트 소유자에게는 책임이 있습니다. 은행에서 '0'을 사용하고 계정을 정리하면 계정이 정리됩니다.
tomjedrz

2
@mathepic 나는 완전히 동의하지 않는다. 어쩌면 사용자에게 핫메일을 보내는 것은 개인 정보로 가득 찬 개인 시스템 일 때 일부 바보가 "0"을 선택하여 타협 된 경우에는 회사의 문제입니다.
Iznogood

답변:


28

학교와 직장의 IT 부서를 다루는 제한된 경험을 바탕으로이 문제가 소수라고 생각하지만 의무적이고 시간 기반의 비밀번호 변경 정책은 아무 가치가 없으며 최악의 경우에는 유해하다고 생각합니다. 사람들은 좋은 암호를 선택하고 비밀을 유지하는 데 매우 나쁜 경향이 있습니다. 암호 만료 정책은 암호 하나를 해독 / 사회 공학 / 도용 할 수있는 시간을 제한하여이를 완화하기 위해 고안되었습니다. 그러나 실제로는 사용자가 암호를 계속해서 다시 배우도록 강요하기 때문에 실제로이를 달성하지 못합니다. 사용자가 암호를 메모리에 커밋하는 것을 어렵게하면 많은 사람들이 더 약한 암호를 선택하거나 눈을 피할 수있는 곳에 암호를 기록하게됩니다.

또한 정기적으로 비밀번호를 변경해야하는 경우 많은 사용자가와 같이 매우 인식 가능한 패턴을 따르는 비밀번호를 선택합니다 [base string][digit]. 사용자가 고양이 이름 Fluffy를 비밀번호로 사용하려고한다고 가정 해 보겠습니다. 그들은의 암호로 시작 수있는 fluffy다음으로 변경 fluffy1, fluffy2, fluffy3등등. 이 경우 정책은 실제로 보안에 도움이되지 않습니다. 사용자가보다 안전한 기본 문자열을 선택 fluffy하고 비밀번호를 안전하게 기억하더라도 몇 개월마다 변경되는 단일 접미사 문자는 크래킹 또는 사회 공학 공격을 완화하는 데 거의 도움이되지 않습니다.

참고 : 암호 만기 고려 해로운 , 나는이 문제에 대해 잘 소개한다고 생각하는 짧은 기사 (내가 작성하지 않은).


2
히스토리 비밀번호를 다양 화하여 비밀번호 정책에서 두 번째 포인트를 방지 할 수 있습니다.
워너

@ Warner : 어떻게 안전한 방식으로 구현 하시겠습니까? 암호를 먼저 해시하지 않고 저장 fluffy1해서는 안되며 , 와는 완전히 다른 해시를 가져야합니다 fluffy2. 사용자가 정확히 동일한 암호 를 재사용하지 못하게하는 것은 쉽지만 , 이것이 당신이 할 수있는 전부라고 생각합니다.
bcat

더 동의 할 수 없습니다 ...
Antoine Benkemoun

1
@ bcat, 새 비밀번호가 이전 비밀번호를 쉽게 바꿀 수 있는지 확인할 수 있습니다 . 증분 번호 접미사의 경우 새 비밀번호 접미사 (숫자 인 경우)를 간단히 줄이고 증분하고 해시와 해당 사용자에 대해 이전에 저장된 해시를 비교하십시오. 다른 간단한 변환 검사도 넣을 수 있습니다. 비밀번호를 일반 텍스트로 저장하지 않고 모두.
mmcdole

1
@bcat : Linux는 PAM (pluggable authentication module)을 통해 이러한 유형의 검증을 사용하며 사용자가 시스템 내에서 비밀번호를 변경하여 현재 비밀번호를 먼저 요청하여 새 비밀번호에 대해 판단 할 수 있도록하는 유틸리티를 사용합니다.
syn-

14

2009 년 가을에 대규모 조직 (15000 명 이상의 사용자)이 120 일마다 "비밀번호 변경"을 구현했습니다. 이는 엄청난 IT 문제와 지원 리소스 낭비입니다. 120 일의 창구가 돌릴 때마다 수천 명의 사용자가 비밀번호를 변경해야합니다. 헬프 데스크는 가능한 한 많은 셀프 서비스를 시도했지만 비밀번호 호출로 가득 차 있습니다.

사용자 / 고객이 당신을 미워하길 원한다면 ... 그리고 프론트 라인 IT 직원이 기회가 생길 때마다 암호 변경을 구현해야합니다.

암호 변경 정책은 일부 IT 관리자가 어딘가에 예약하는 방법의 확인란이며 15 년 전에 작성되었습니다. 실제로 정책을 구현하거나 지원하는 참호에 아무도 좋은 생각을하지 않습니다.

나는 암호 대신에 "패스 문구"에 대해 여기에서 주장했다. .. 터널의 끝에있는 빛이 다가오는 기차를 가지고 있었다. :)

암호문은 "MyCatIsFromSpainAndICallHimElGato"와 같이 기억하기 매우 길고 거의 추측 할 수없는 문자열입니다. 또는시나 노래의 줄일 수도 있습니다.

당신이 정말로 깨지기 어려운 것을 만들고 싶다면 .... 케이스와 함께 문장을 추가하고, 구두점을 추가하고, 일부를 실수로 바꾸거나, 0으로 바꾸고, @로 등을 바꾸십시오 ...하지만 기억하십시오 ... 그게 열쇠 야. 손가락에서 키보드로 쉽게 흐를 수 있도록 선택할 수있는 방법도 있습니다. 손 사이나 SHIFT 및 이상한 문장 부호를 사용하지 않아도됩니다.

그래서...

  • 긴 "암호 구"를 사용하십시오.
  • 내부적으로 강도를 테스트하십시오.
  • 전체 인프라에 "싱글 사인온"을 구현하여 고객이 하루에 한두 번만 사용하면됩니다.
  • 강요하지 마십시오.
  • 그리고 올바른 사용법을 교육하고 교육하며 교육합니다.

매트

편집 : 2011 년 8 월 24 일 XKCD는 동의하고 나보다 더 잘 말했습니다.


암호 정책이 아니라 사용자 교육에 실패하지 않았다는 좋은 주장처럼 들립니다. IT 부서에서 일하는 사람은 모든 직원이 암호 변경 프롬프트를 표시하기 위해 모든 직원이 자신의 아이디어를 제시해야했기 때문에 IT 부서에서 일하는 사람이 잘못을 저지른 것입니다.
Kara Marfia

싱글 사인온은 실제로 첫 번째 글 머리 기호 여야하며, 사용자가 암호를 배울 이유가되는 당근입니다. 또한 만료 시간은 사용자가 암호를 사용하는 빈도를 기준으로해야하며 30 일 만료는 매일 사용되는 시스템에 적합하지 않지만 이전 고용주에서 (SSO 이외의) 비용 앱 (대부분의 사람들 만 사용하는 앱) 한 달에 한 번 로그인)에 30 일의 만료 정책이 있었는데, 내가 아는 모든 사람들이 사용할 때마다 헬프 데스크에 전화를 걸었습니다.
GAThrawn

싱글 사인온 (SSO)은 매우 유용합니다. 사용자가 알아야 할 암호의 양을 크게 줄이는 데 도움이됩니다.
Anthony Giorgio

10

아닙니다. 제 개인적 의견은 불필요 하고 심지어 비생산적 이라는 것 입니다. 나는 내 블로그에 뛰어 들었지만 관심이 있다면 사냥을 할 수 있습니다.

간단히 말해 다음 두 가지 이유가 있습니다.

1. 사용자가 지속적으로 비밀번호를 변경하도록하면 비밀번호가 잘못됩니다.

이것에 대한 일화 적 증거가 부족하지는 않지만 x 일마다 새로운 것을 기억해야한다면 그 것들을 기억하기 쉽고 아마도 서로 관련시킬 것입니다.

사용자는 "Jan2010"또는 "Password05"와 같이 "추측 가능"암호를 선택해야 할 가능성이 훨씬 높습니다. 문자에 대해 엄격한 정책을 시행하면 약어가 아닌 느낌표 나 철자가 추가 될 수 있습니다. 기술적으로 복잡한 암호와 추측 할 수없는 암호에는 큰 차이가 있습니다.

2. 정기적으로 비밀번호를 변경해도 공격을 막을 수는 없으며 위험을 줄입니다

비밀번호를 추측하거나 발견 한 경우 공격자가 해당 정보를 사용하는 데 시간이 얼마나 걸립니까? 공격자의 신발을 착용하십시오. 방금 비밀번호를 발견했습니다. 누군가가 알아 채기 위해 바로 로그인해서 모든 정보를 추출하지 않겠습니까? 30 일 만에 이미 원하는 모든 것을 얻었습니다.

내 추천 :

  • 매우 엄격한 암호 정책을 강제하십시오 (예 : 영어 단어가 3자를 초과하지 않는 15 자, 위, 아래, 숫자 및 특수 문자)
  • 사용자가 비밀번호를 변경하지 않도록하십시오. 그들이 종이에 암호를 써서 지갑에 보관해야한다면 실제로는 괜찮습니다. 사람들은 종이 조각을 잘 지키지 만 임의의 문자열을 기억하는 데는 좋지 않습니다.

+1-120 일 또는 180 일 만료를 좋아하지만 대부분 동의합니다. 정치 조직에서 "엄격히 엄격한"암호 정책을 유지하는 것이 좋습니다.
tomjedrz

"사람들은 종이 조각을 잘 지킨다"-정말로? 당신은 나보다 훨씬 더 나은 사람들을 알아야합니다! 데스크탑 지원을 할 때 책상에 남은 종이 일기를 집어 들고 뒷 페이지로 돌아간 다음 가장 새로운 단어를 입력하여 주변에 없었을 때 사용자 PC에 쉽게 접근 할 수있었습니다. 비밀번호 상자.
GAThrawn

나는 그것이 종이 조각과 그것이 얼마나 중요한지에 대한 그들의 의견에 달려 있다고 생각합니다. 같은 사람들이 책상에 50 달러짜리 노트를 놔둘까요? 그들의 신용 카드? :)
Damovisa

4

사용자 관점에서 비밀번호를 변경해야하는 것은 매우 불편합니다. 나는 그렇게하는 것을 절대적으로 싫어하고, 비밀번호를 변경 해야하는 경우 절대적으로 필요한 사이트 만 사용 합니다.

어떤 사람들은 암호를 기억하기 위해 암호를 써야하기 때문에 이것이 실제로 좋은 습관인지 아닌지에 대한 토론도있었습니다.

사람들이 암호를 입력하는 동안 암호가 얼마나 강력하거나 약한지를 보여주는 위젯 중 하나를 구현할 수 있습니다. 실제로 더 강력한 결과를 낼지는 모르겠지만 유용합니다. 비밀번호.


이 경우 등록 양식이없는 개인 사이트입니다. 사용자는 직원이므로 그가 사용하는 시스템을 사용해야합니다. 그것은 내가 매우 높은 보안에 동의 할 필요는 없다고합니다. 그러나 나는 당신이 보는 모든 것을 결정할 수 없습니다 ..
Iznogood

3

매우 엄격한 암호 정책 환경 ( "암호를 추측하기 매우 어렵고"및 암호 변경 방식)을 사용하는 사용자는 하드 암호 만 있으면된다는 의견이 있습니다. 사용자가 익숙해 지려면 약간의 시간이 걸리지 만 (특히 12345 종류의 사용자 인 경우) 일주일 이내에 쉽게 기억하고 입력 할 수 있어야합니다.

그러나 강력한 비밀번호를 사용하고 비밀번호를 변경해야하는 경우 불편한 최종 사용자를 예측할 수 있습니다.


3

IT 관리 관점에서 가장 좋은 방법은 고객이 사용중인 기존 인증 체계의 싱글 사인온 기능을 응용 프로그램에서 사용할 수 있도록하는 것입니다. 분명히 Active Directory는 큰 역할을하지만 응용 프로그램 이 온 사이트 IT가 이미 구성한 정책으로 작동 하는 경우에도 휠을 다시 만들지 않아도됩니다.

강제 암호 변경이 좋은 아이디어인지에 대한 논쟁이 많이 발생했기 때문에 (주요 질문에 부차적이라고 생각하지만) 여기 에서 아이디어와 링크 중 일부를 즐길 수 있다고 생각 했습니다 . 대부분의 경우 암호 복잡성 및 변경 일정을 적용하지 않을 경우 암호가 전혀 없을 수 있지만 구현 방법 (훈련, 관리 지원 등)이 스트레스보다 중요합니다.


2

암호를 변경하면 사용자가 암호를 적어 놓을 수도 있습니다. Bruce Schneier ( http://www.schneier.com/blog/archives/2005/06/write_down_your.html ) 에 따르면 나쁜 생각은 아닙니다 .

보안이 유용성을 방해하는 것이 언젠가는 좋은 일이 될 수 있다고 주장합니다. 사용자가 안전하게 행동하도록 상기시키기 때문입니다. 예를 들어, 내가 일하는 은행에서 많은 보안 조치가 보안 극장입니다 (예 : 문에서 얼굴 인식, 인식이 실패하면 보안 담당자가 문을 열 것입니다). 이러한 조치만으로는 보안을 향상시킬 수는 없지만 항상 보안이 업무상 중요한 관심사이고, 일정량의 로깅 및 검사가 진행 중이며, "안전하지 않은"무언가를 저지른 경우 곤경에 처할 것입니다.

물론 이것은 은행 직원의 보안에 적용되며 웹 사이트 사용자에게는 적용되지 않을 수 있습니다 ...


1

보안 정책에 따라 사용자는 n 일마다 강제로 변경해야합니다. 저는 주 정부 기관에서 일하고 있으며 이는 주 감사실에서 시행하는 요건입니다. 나는 그것에 대해 일을 할 수 없으므로 강제로 변경해야합니다.

암호 변경을 강제하는 규정에 구속되지 않으면 강제로 변경하지 마십시오. 설정 한 비밀번호가 특정 최소 복잡성 요구 사항을 충족하는지 확인하십시오. 길이는 대부분의 암호 시스템에서 복잡성을 능가하므로 가변 표준이 가장 좋습니다. 같은 :

  • 비밀번호는 10 자 이하 여야합니다.
  • 10-25 자 사이의 비밀번호에는 3 자 이상이 필요합니다.
  • 25-40 자 사이의 비밀번호는 최소 2 자 세트가 필요합니다.
  • 40 자보다 긴 암호는 단일 문자 집합을 사용할 수 있습니다.

Active Directory와 같은 기본 제공 복잡도 체계는 이러한 종류의 계층 형 시스템을 지원하지 않습니다. 자신의 암호 변경 환경을 구축하면 다음과 같은 작업을 수행 할 수 있습니다. Shift 키를 사용할 때마다 팻 핑거 (finger-finger) 이벤트가 발생할 가능성이 높아 지므로 여러 문자 세트가있는 긴 암호는 특히 학습 단계에서 로그인 실패 이벤트가 발생할 가능성이 훨씬 높습니다. 계정 잠금 시스템이있는 경우 큰 문제가 될 수 있습니다. 가장 좋아하는시 (63 자!)의 세 번째 줄을 암호문으로 사용하는 사람에게는 h @ x0r이 없어도 빠르고 효율적으로 입력 할 수 있습니다.

기술이나 위험 환경이 크게 변하고 암호가 복잡하지 않은 경우 일정 기간 동안 암호를 만료시키는 방법을 사용하십시오. 특히 이전에 변경을 한 적이없는 경우 사람들은 필요에 대해 중얼 거릴 것이지만 보안 상태를 유지하는 데 도움이됩니다.


나는 그것에 의해 구속되지 않을 정도로 운이 좋다. 감사!
Iznogood

0

추측하기 어려운 암호는 좋은 것입니다. 복잡성으로 얻은 보안이 프로세스에서 완전히 손실되므로 사용자가 암호를 잊어 버리거나 암호를 써야하는 복잡성 수준을 적용하는 것은 좋지 않습니다. 불행히도 우리가 사는 곳이 아닌 이상적인 세상에서는 복잡성과 유용성간에 균형이 맞아야합니다. 물론 다른 사람들은 다른 장소에서 그 균형점을 볼 것입니다.

X 일 동안 정기적으로 비밀번호를 변경하는 논리는 조금 나빠졌습니다. 내가 일반적으로 듣게되는 이유는 도난당한 암호의 유용성을 제한하기위한 것입니다. 실제 비밀번호는 어쨌든 처음 몇 시간 내에 거의 확실하게 처리 될 것입니다. 예를 들어 Fred는 Mary의 암호를 "알고 있습니다". Mary가 비밀번호를 변경하는 것과 거의 동시에 발생하지 않는 한 내일 또는 다음 달에 비밀번호를 변경하면 어떤 차이가 있습니까? Fred가 암호를 사용하기 전에 1 주일 또는 2 주 정도 기다릴 가능성이 있습니까?

필요한 이유나 의심이있는 경우 분명히 암호를 변경하는 것은 완전히 다른 문제입니다.


0

응용 프로그램에 이와 같은 높은 수준의 보안이 필요한 경우 SecurID 토큰과 같은 것을 사용해 보셨습니까? 즉, 사용자는 60 초마다 새 비밀번호를받습니다. 암호를 적어 두어도 걱정할 필요가 없습니다. 그러나 이들은 비용이 든다. 솔루션은 얼마나 안전해야합니까?


꽤 안전하지만 보안이 필요한지 궁금합니다. 링크 감사합니다 감사합니다!
Iznogood

0

사용자에게 정보가 중요하다고 생각합니다. 비밀번호를 만드는 방법과 동일한 비밀번호를 두 번 사용하지 않는 것이 얼마나 중요한지를 설명하십시오. 암호를 만드는 쉬운 방법은 문장을 잡고 모든 단어에서 첫 글자를 가져와 숫자를 추가하는 것입니다.

전의. 나는 세상을 지배하고 싶다 = Iltrw99

비밀번호를 변경하도록 강요하지 마십시오. 혼동 될뿐입니다.


0

3 개월마다 암호를 변경하는 것에 동의하지 않지만 회사가 공개적으로 거래되는 경우 이는 필수 조건이며 SOX 호환의 일부입니다. 참고 사항 : Sarbanes-Oxley가 짜증납니다.


0

내가 언급하지 않은 것은 리소스에 대한 외부 액세스입니다.

귀하가 합리적인 비밀번호 정책을 선택하는 경우, 누군가 비밀번호를 기록하지 않는 한 아무도 비밀번호를 추측하지 않을 것이라는 데 동의합니다.

그러나 웹 메일에 액세스 할 수있는 오프 사이트가 있다고 가정 해 봅시다. 이제 스파이웨어 / 악성 프로그램 / 트로이 목마 등으로 인해 비즈니스 데이터에 노출 될 위험이있는 "오래된 PC"및 IMO에 자격 증명을 입력하는 사용자가있을 수 있습니다. .


매우 좋은 통찰력 감사합니다! 우리가 어떻게 자신을 보호 할 수 있는지 궁금해하십시오. 우리는 Firefox / chrome을 강화하고 IE6-7-8을 강화할 것입니다.
Iznogood

-1

사람들이 간단한 암호를 쓰면 거대한 암호 나 매우 복잡한 암호를 쓰지 않을 것이라고 생각합니다. 증분 암호 변경으로 수행되는 작업은 더 이상 사용자 ID를 자동으로 제거하지 않으므로 개별 사용자가이 모든 것에 대해 책임을 져야합니다. 사람들은 사람들이되어 무언가를 성취하기 쉬운 길을 찾고 있습니다. 반복되는 비밀번호와 점차적으로 변경된 비밀번호를 감지하고 거부 할 수 있습니다. 복잡성 요구 사항을 강화할 수 있으며 강제 암호 변경으로 IT 이외의 사용자가이 모든 일에 책임을지게 할 수 있습니다. 암호 변경에 대해 불평하는 대부분의 사용자는 자신의 암호 변경을 가장하는 게으른 사람은 열린 심장 수술과 같습니다. 징징 거리지 말고 책임을지고 쉬운 거리를 찾지 마십시오


"간단한 암호"보다 "거대한 암호"가 훨씬 더 기억하기 쉽습니다. 이것에 대해 유명한 xkcd 만화가 있기 때문에, 나는 혼자가 아니라고 확신합니다.
Michael Hampton
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.