관리자 / 루트 비밀번호는 얼마나 자주 변경합니까?


12

내 도메인에서 관리자 암호를 거의 변경하지 않는 나쁜 습관이 있습니다. 내가 사용하는 암호는 꽤 좋지만 더 일관성이 있기를 원합니다.

좋은 빈도는 무엇이라고 생각하십니까? 아마 6 개월마다?


90 일은 암호를 변경하는 가장 좋은 방법입니다.
워너

유닉스에서는 sudo와 같은 도구를 사용할 수 있습니다. 즉, 특정 사용자에게 짧은 기간 동안 루트 권한이 부여 될 수 있습니다. 그들은 루트 암호를 알 필요가 없습니다. 실제로, 당신은 하나의 세트가 없거나 그것을 알지 못하는 상태로 도망 갈 수 있습니다. 이 경우에는 변경할 필요가 없습니다. 그러나 사용자는 자신의 비밀번호를 변경해야합니다.
Matt

오 신,이 모든 게시물을 읽은 후 administrator암호가 7 년 동안 같은 경우 (내가 sysadmin이 아니지만 관리자 계정이있는) 도메인에서 일하는 도메인이 있다는 것을 알고 있습니다. 길이는 8 자입니다. 어쩌면 내가 그들에게 이메일을 보낼 것입니다 ...
Mark Henderson

답변:


9

빠른 계산을 수행하고 잠시 동안 모범 사례를 잊어 버리십시오.

공격자가 시스템을 해킹하는 데 6 개월이 걸린다고 가정합니다. 또한 암호는 크기 62의 문자 세트에서 임의로 선택된다고 가정합니다.


시나리오 1 : 6 개월 동안 9 자 암호를 사용합니다.

시나리오 2 : 처음 3 개월 동안 9 자 암호를 사용하고 나머지 3 개의 Mont에 다른 9 자 암호를 사용합니다.

시나리오 3 : 6 개월 동안 10 자 암호를 사용합니다.


에서 시나리오 1 그가 그 시간에 62 ^ 9 시도를 할 수 있다면, 브 루트 포스 공격자는 100 % 확실 계정을 해킹.

에서 시나리오 2 , 그가 시간의 절반 (삼개월) 만 (62 ^ 9) / 2 시도한다 할 수 있다면, 그는 50 %의 확신을 가진 계정을 해킹 할 수 있습니다. 후반에는 50 %의 확신을 가지고 또 다른 기회를 얻게됩니다. 통계적으로 그는 75 % 확실하게 계정을 해킹 할 것입니다.

시나리오 3 에서는 6 개월 동안 62 ^ 9 회 시도합니다. 그러나 62 ^ 10 가능성이 있습니다. 따라서 그는 1/62의 확실성만으로 계정을 해킹 할 것입니다.


따라서 도난당한 암호 및 기타 종류의 공격과 같은 다른 모든 요소를 ​​제외하면 더 자주 변경되는 경우에도 더 짧은 (또는 더 간단한) 암호를 사용하는 것보다 더 긴 암호를 선택하는 것이 좋습니다. 특히 시나리오 3 에서는 기억해야 할 문자가 10 자에 불과하며 시나리오 2 에서는 18 자입니다.


2
+1, 매우 긴 비밀번호를 사용하십시오. 실제로 6 개월 안에 18 자 이상의 문자 암호를 해독 할 사람은 없습니다. 그들이 당신의 데이터가 그렇게 나쁜 것을 원한다면, 침입하여 서버를 훔칠 것입니다.
Chris S

이것을 좋아하십시오. 암호로 ... 크기가 중요합니다.
Kara Marfia

따라서 좋은 긴 암호는 꽤 오랫동안 잘 작동해야합니다. 나는 단지 좋은 암호를 사용하고 12 개월주기를 할 것이라고 생각합니다. 이것은 나에게 안타깝게도 모든 것을 문서화 할 수있는 좋은 기회를 제공 할 것이다. 편집 : 16 문자 이상을 의미합니다. 문장 부호와 공백이 포함 된 문장을 사용하고 싶습니다.
user24555

누군가가 암호를 무차별 적으로 사용하는 것에 대해 이야기 할 때 항상 킥킥 웃습니다. 그렇지 않을 것입니다. 기간. NSA (또는 이와 동등한) 또는 조직 범죄만이 가능합니다.이 경우 좋은 암호로 해결할 수없는 훨씬 더 큰 문제가 있습니다.
Dan Andreatta

이전 의견에 덧붙여, 나는 빠른 수학을했고 현대 데스크탑으로 6 문자 암호를 해독하는 데 약 1 일이 걸릴 것이며, 8 문자 암호의 경우 10 년이 걸립니다. openssl 속도 테스트의 경우 암호화 성능.
Dan Andreatta

2

우리는 주로 창이며, 각 관리자는 자신의 도메인 관리자 계정을 가지고 있으며, 서로 강력한 암호를 가지고 있고 때때로 변경하기 위해 서로를 신뢰합니다. 우리는 동료 압력을 사용하여 암호가 길고 숫자 및 / 또는 문자를 포함하기 때문에 강력한 암호를 가지고 있다고 확신하지만 자주 암호를 변경하지는 않습니다. \

추가 : 지금까지 대부분의 사람들은 아마도 이것을 들었을 것입니다. 암호화 및 보안 전문가 Bruce Schneier는 강력한 암호를 가지고 기록해 두어야 한다고 말합니다 .


그 동료 압력은 어떻게 작동합니까? 사람들이 서로의 비밀번호를 볼 수 있습니까?
Bill Weiss

2
내 경험으로는 아무도 IT 직원조차도 자신의 암호를 변경하도록 신뢰할 수있는 사람이 없습니다.
ITGuy24

@ 빌 : 그냥 우리 셋이있다, 그리고 또래 집단의 압력이 "나는 ... 그냥 다음 어떤 숫자를 입력 보지 못했다"의 라인을 따라 그래서 우리는 함께 오랜 시간 작업 한
워드 - 분석 재개 모니카

그것은 잘 확장되지 않습니다 :) 또한, 사람들이 자신의 관리자 암호를 보는 습관을들이는 것은 다른 사이트를 자주 방문하면 잘되지 않습니다.
Bill Weiss

"맹세 항아리"와 같은 것이 있습니까? 다른 관리자가 ophcrack과 같은 암호를 사용하여 암호를 깰 수 있다면 팟에 $ 5를 넣어야합니다.
Nic

1

이론적으로 암호를 자주 변경하는 것이 훨씬 낫지 만, 유효 기간이 짧아 질수록 포스트-인-포스트-투-인-포스트-잇-팩터가 기하 급수적으로 증가합니다.

개인용으로 만 사용하는 경우 공개 키 인증을 사용하지 않고 키링에 적합한 PW를 가지십시오.


1
이 질문에는 암호 관리를위한 수많은 아이디어가 있습니다 : serverfault.com/questions/21374/…
Ward-Reinstate Monica

1

실제로 도메인의 관리자 계정 (SID : S-1-5-21domain-500)에 대해 이야기하고 있거나 자신이 직접 만든 관리자 계정에 대해 이야기하고 있으며 누가 무엇을하는지에 대한 유용한 로그를 얻을 수 있습니까?

일반적으로 관리자 계정은 긴 (20 자 이상의 암호)를 갖도록 설정하고 안전한 위치에 암호를 저장하고 해당 계정을 사용하지 마십시오. 나는 일반적으로 매년 그 암호를 변경합니다. 우리의 네트워크에는 또한 잠금 시스템이있어 원격 무차별 대입 공격의 효과를 막을 수 있습니다. 일상적인 작업에 암호를 사용하지 않기 때문에 암호를 가로 챌 가능성이 거의 없습니다.

관리자 권한을 부여한 개인 계정에 대해 이야기하는 경우 6 개월마다 변경하는 경향이 있습니다. 또한 가능할 때마다 키 기반 인증을 사용하여 암호가 거의 전송되지 않는 경향이 있습니다. 또한 일반적으로 대부분의 사람들이 위험이 높은 시스템이라고 생각하는 것을 다루지 않습니다.


도메인 관리자에 대해 이야기하고 있습니다. 내 계정은 도메인 관리자 그룹의 일부가 아닙니다. 원래 도메인 관리자 사용을 중지하고 다른 사용자 이름으로 보조 도메인 관리자를 만드는 것이 좋습니다.
user24555

0

아무리 복잡한 암호를 설정하더라도 상관 없습니다. 항상 30 ~ 42 일마다 비밀번호를 변경하는 것이 좋습니다. 6 개월은 너무 오래된 비밀번호입니다. 안전하고 안전하게 유지하기 위해 항상 좋은 암호 정책이 구현되어 있어야합니다 :-)


4
"30 ~ 42 일"은 어디에 있습니까?
Bill Weiss

환경에 따라 암호가 30 ~ 90 일마다 만료되도록하는 것이 가장 좋습니다. 이런 식으로 공격자는 제한된 시간 동안 사용자의 암호를 해독하고 네트워크 리소스에 액세스 할 수 있습니다. 기본 : 42. 내 말이 아니라 "모범 사례"
가져옴

1
이것이 '우수 사례'라는 것을 반복하는 대신 문서 또는 참조에 대한 링크를 제공하는 것은 어떻습니까. 일반적으로 신뢰할 수있는 출처로 출판되지 않는 한 모범 사례로 간주하기를 거부합니다.
Zoredache


브라우저의 검색 도구가 깨져 있어야합니다. 거기에 "42"가 표시되지 않습니다.
Bill Weiss

-1

나는 보통 직원이 떠난 후에 만 ​​루트 암호를 재설정하지만 ... sudo 액세스 권한을 가진 사용자가 90 일마다 암호를 변경하도록 권장합니다.

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