Linux에서 사용자 비밀번호를 일반 텍스트로 표시하는 방법은 무엇입니까?


28

우리는 사용자의 비밀번호가에 저장되어 /etc/passwd있지만 암호화 된 방식으로 저장 되므로 루트조차도 비밀번호를 볼 수 없습니다.

jane:x:501:501::/home/jane:/bin/bash
fred:x:502:502::/home/fred:/bin/bash

위와 같이 :x:비밀번호를 나타냅니다.

암호 /etc/passwd를 일반 텍스트 로 저장 하고 루트가 볼 수 있는 방법 (가능한 구성)이 있습니까?


10
그리고 그것은 기능입니다. 루트 계정에는 파일에 액세스하기 위해 사용자의 비밀번호가 필요하지 않기 때문에 그럴 이유가 없습니다. 어떤 상황에서 이것을 원하십니까?
HalosGhost

1
나는 이것에 대해 궁금합니다. 시스템의 관리자 (루트)가 왜 다른 사용자의 암호를 볼 수 없습니까?
user78050

5
루트 사용자는 다른 사용자의 비밀번호를 알아야 할 이유가 없기 때문에 @ user78050은 그렇게 할 수있는 중대한 보안 위험이 될 수 있습니다.
David Z

16
비즈니스에서 가장 간단한 보안 원칙을 위반하기 때문에 "암호를 일반 텍스트로 저장하지 마십시오." 보안이 제대로 이루어 지면 사용자 만이 자신의 암호를 알아야합니다. 또한 이것을 할 이유가 전혀 없습니다. 루트 사용자가 다른 사용자의 비밀번호를 아는 데 도움이되는 단일 관리 상황을 생각할 수 없습니다.
HalosGhost

3
MD5 "암호화 방법"을 사용한 다음 레인보우 테이블을 사용하여 암호를 해독하십시오 .
Cristian Ciupitu

답변:


58

다른 두 가지 답변은 이것이 바로 Bad Idea ™라는 것 입니다. 그러나 그들은 또한 당신에게 많은 프로그램을 변경해야한다는 어려운 말을 들었습니다 .

그건 사실이 아니야. 그건 매우 쉬워요. 하나 또는 두 개의 구성 파일 만 변경하면됩니다. 제어하지 않는 시스템에 로그인 할 때 알고 있어야하므로이 점을 지적하는 것이 중요하다고 생각합니다. 이들은 실제로 일반 텍스트 비밀번호를 /etc/passwd또는 /etc/shadow에 넣지 않고 다른 파일로 이동합니다. 참고 비밀번호를 일반 텍스트로 사용하지 않기 때문에 테스트하지 않았습니다.

  1. 편집 /etc/pam.d/common-password또는 (비밀번호 변경에 잡으려고) /etc/pam.d/common-auth(로그인시 캐치로)와에 추가… pam_exec expose_authtok log=/root/passwords /bin/cat

  2. 둘 다 편집하고을 사용하여 pam_unix에서 pam_userdb로 전환하십시오 crypt=none. 또는 암호를 변경했을 때만 기록하기 위해 공통 암호 (pam_unix를 그대로 두는 것)에만 넣을 수도 있습니다.

  3. 당신은 제거 할 수 shadow그림자 파일을 사용하지 않도록은 pam_unix에서 (뿐만 아니라 강력한 해시 옵션) 옵션을, 전통 토굴 암호로 돌아갑니다. 평범한 텍스트는 아니지만 리퍼 존이 당신을 위해 그것을 고칠 것입니다.

자세한 내용 은 PAM 시스템 관리 안내서를 확인 하십시오 .

PAM의 소스 코드를 편집하거나 자체 모듈을 작성할 수도 있습니다. PAM (또는 모듈) 만 컴파일하면됩니다.


1
일반 텍스트 암호가에 쓰여졌다 고 가정합니다 /root/passwords.
Faheem Mitha

Btw. 그것이 얼마나 쉬운 지, 그리고 타협 된 시스템을 두려워하는지 어디를 봐야하는지 아는 것은 매우 좋습니다.
erik

8
@erik 수락 한 답변으로 가장 도움이되는 답변을 선택하는 것은 어뢰의 특권입니다. OP가 "그렇게하지 마라!" 가장 도움이됩니다… 또한 명확하게 말해서, 이것이 손상되었거나 악의적으로 관리되는 시스템에서 암호를 훔치는 유일한 방법은 아닙니다. 따라서 PAM 구성 만보고 안전하다고 판단 할 수는 없습니다.
derobert

3
이것은 배포판이 PAM을 사용하고 있다고 가정하는 것입니다.
Vality

1
@msw 나는 평범한 암호로 리눅스 박스를 운영하는 것이 어렵다는 일반적인 통념 때문에 분명히 대답했다. 암호 재사용을 장려하기 때문에 위험합니다. 방금 "실제로 쉽게 파일을 편집 할 수 있지만 말하지 않을 것입니다"라는 답변을 게시 한 사람은 아무도 믿지 않았을 것입니다. 왜 더 높은 투표를 받고 더 철저한 답변을 듣게됩니까? 요점을 밝히려면 어떻게해야하는지 말해야합니다. (하지만, 그들은 예제를 복사하여 붙여 넣을 수는 없습니다. 여전히 사용해야합니다.)
derobert

34

오, 자기야, 처음부터 시작하자 ...

사용자 비밀번호는 / etc / passwd에 저장되지만 암호화 된 방식으로 저장됩니다

아니요, 에 저장되어 있으며 /etc/passwd꽤 오래 전입니다. 오늘날 암호는 대부분 소위 섀도 파일에 저장 됩니다/etc/shadow .

그러나 암호화 된 방식으로 루트조차도 볼 수 없습니다.

때로는 상호 교환 적으로 사용되지만 해싱암호화 가 아닙니다 . 암호화는 정의상 뒤집을 수 있으므로 암호화 된 것을 다시 일반 텍스트 형식으로 변환 할 수 있습니다. 해싱은 어떤 식 으로든 뒤집을 수 없도록 설계되었습니다 (무차별 대입 제외). 해시 된 원래의 일반 텍스트 형식은 복구 할 수 없습니다.

새도우 파일의 비밀번호는 해시로 저장됩니다.

위와 같이 : x : 비밀번호를 나타냅니다

x이 경우는 기존 암호 필드에 대한 자리 표시 자입니다. 이는 x섀도 파일에서 비밀번호를 찾을 수 있음을 의미합니다.

암호를 / etc / passwd에 일반 텍스트로 저장하여 루트가 볼 수 있도록하는 방법 (가능한 구성)이 있습니까?

그렇습니다. 이것은 실제로 가능하지만 어떤 이유로 좋은 생각이 아닙니다. Derobert의 답변은 그것을 수행하는 간단한 방법을 설명합니다 .

그러나 왜 좋은 생각이 아닌가? 간단하지만 매우 중요한 이유는 보안입니다. 다음 질문을 읽어보십시오.

그러나 요약하자면 다음과 같이 가정하십시오. 회사에 서버가 있고 모든 사용자 계정이 비밀번호로 보호되며 이러한 사용자 계정의 데이터가 동일한 비밀번호로 암호화됩니다. 외부의 크래커는 서버에 액세스 할 수 있지만 중요한 데이터는 사용자 계정에 여전히 암호화되어 있으므로 액세스 할 수 없습니다.

이제 비밀번호가 일반 텍스트로 저장된다고 가정하십시오. 암호를 읽을 수 있기 때문에 크래커는 갑자기 모든 것에 액세스 할 수 있습니다. 그러나 해시 값으로 저장되는 경우 무차별 대입 공격을 수행 할 리소스가 많은 사람을 제외하고는 누구에게나 거의 쓸모가 없습니다.


2
암호화 및 해싱에 대한 OP의 방어 에서 glibc 의 crypt man 페이지 는 다음과 같이 말합니다.«소금이 문자로 시작하고 그 "$id$"뒤에 끝나는 문자열이 다음에 오는 문자열 인 경우 "$": $id$salt$encrypted DES 기계를 사용하는 대신 사용 id암호화 방법을 식별합니다. 문자열의 나머지 해석 방법을 결정합니다».
Cristian Ciupitu

1
흥미롭지 만 derobert의 답변과 마찬가지로 주요 질문에 대답하지 않습니다.
erik

6
@erik 때로는 질문에 대한 정답은 기술적으로 가능하더라도“하지 마십시오”입니다. 이것은 그 때 중 하나입니다.
Gilles 'SO- 악마 그만해'

1
이 줄을 바꾸는 것이 좋습니다. "아니요. 많은 응용 프로그램과 작동 방식을 바꾸는 것 외에는 다른 방법이 없습니다." 그것은 쉽지 않다는 인상을 남깁니다 (또는 적어도 기능적으로 동등한 것을하기는 적어도 쉽습니다).
derobert

2
@Bobby 이것은 훌륭한 답변이지만 훌륭한 답변은 아닙니다. 훌륭한 답변을 얻으려면 derobert의 답변에 표시된 것처럼 명확하지 않기 때문에 "쉽게 불가능한"부분을 변경해야합니다.
Michael Dorst

10

먼저 암호화 된 암호에없는 /etc/passwd,하지만 그들은에있다 /etc/shadow. 그 이유 중 하나 /etc/passwd는 공개적으로 읽을 수 있기 때문에 (예를 들어 다른 사용자의 GECOS 필드 정보를 찾을 수 있음), 특히 오래된 암호화 체계를 사용하면 암호화 된 비밀번호에 대한 무차별 대입 공격을 허용 할 수 있습니다.

비밀번호를 일반 텍스트로 저장하기 위해서는 필요하지 않으며 /etc/shadow유효한 비밀번호를 확인하기 위해 정보를 읽는 비밀번호 프로그램 및 라이브러리를 업데이트해야 합니다. 그런 다음 모든 유틸리티가 일반 텍스트 비밀번호 스토리지를 이해하지 못하는 것과 정적으로 링크되는 대신 공유 라이브러리를 사용하여 해당 정보에 액세스하기를 희망해야합니다.

이것이 설정 구성의 옵션이라면, 부적절하게 스위치를 켜는 어리석은 사람들이 항상있을 것입니다. 그리고 그들은 여전히 ​​CRT 스크린에서 작업하면서 정보를 보면서 건물 외부에서 쉽게 선택할 수있는 방식으로 방송합니다.

그 외에도 사람들은 여러 시스템에서 동일하거나 유사한 암호를 사용하는 경향이 있으므로 암호를 사람이 읽을 수있는 것은 좋지 않습니다. 일부 sysadmin은 다른 시스템에서 다시 시도 할 수 있으므로 사용자에게 계정이 있음을 알고 있습니다.

더 흥미로운 것들이 있어야합니다. 시스템의 작동을 조사 할 수 있습니다.


3
/etc/shadow암호화 된 비밀번호를 저장하지 않고 비밀번호 해시를 저장합니다. 예,이 함수는 crypt이며 매뉴얼 페이지에 "암호화 됨"이라고 표시되어 있지만 물고기를 자전거라고 부를 경우 바퀴가 없습니다. /etc/shadow프로그램을 다시 컴파일하지 않고 다른 형식으로 저장 암호 를 만들 수 있습니다 (최소한 Linux 및 Solaris에서). 인증 방법은 항상 동적으로 연결됩니다. 암호를 일반 텍스트로 저장하는 것은 끔찍한 생각 이지만 약간의 작업으로 가능 합니다.
Gilles 'SO- 악마 그만해'

@gilles 방금 OP 용어를 재사용했지만 해시는 더 적절한 용어입니다.
Anthon

3

기본적인 이유 (이것이 나쁜 생각 인 이유)는 사용자 (루트, 관리자 또는 기타)가 다른 사람의 사용자 암호에 액세스 할 수 없기 때문입니다.

비밀번호는 인증 수단이기 때문에 간단합니다. 다른 사용자의 비밀번호를 알고있는 경우 본인의 자격 증명 (사용자 이름 + 비밀번호)을 알고 있으므로 해당 사용자로 로그인 하여 자신 또는 다른 사람으로 가장 할 수 있습니다 .

해당 사용자로 로그인 할 때 수행 한 모든 조치는 다른 사용자에게 책임이 있습니다. 그리고 이것이 인증이 작동하는 방식이 아닙니다.

중요한 파일을 모두 삭제, 하드 디스크 지우기, 백업 지우기, 원자력 계획 종료 등과 같은 작업은 비참 할 수 있습니다.

아니면 그냥 불법입니다. 본인 (관리자)이 모든 비밀번호에 액세스 할 수있는 은행 기관을 상상해보십시오. 계산원의 암호를 사용하여 대통령의 은행 계좌에서 창업자의 은행 계좌로 백만 달러 이동을 주문할 수 있습니다. 그런 다음 계산원의 고급 비밀번호를 사용하여 거래를 승인하십시오. 그런 다음 창 클리너 계정에서 본인의 해외 은행 계좌로 수표를 승인합니다.

그런 다음 바하마에서 긴 휴가를갑니다 ...


이 관점에서 암호 해싱과 별도의 섀도 파일 사용은이 규칙을 시행하는 수단으로 볼 수 있습니다 (사용자는 다른 사람을 사칭 할 수 없음).

그리고 @Miral이 언급 한 것처럼 *su 가장 (및 위의 주장을 버리는 종류)을 허용하면서도 사용 로그를 유지하는 예외가 있습니다 (따라서 규칙은 "관리자 만 다른 사람을 사칭 할 수 있지만 로그가 유지됩니다 ").

* 은행 사례는 아마도 최고가 아닐 것입니다. 보안이 중요한 환경에서는 일반적으로 암호 하나보다 더 많은 인증 및 권한 부여 수단이 필요합니다.


이 인수의 한 가지 단점은 루트 사용자가 암호를 몰라도 시스템의 다른 사용자를 가장 할 수 있다는 것입니다. 쉽게 su otheruser.
Miral

@Miral 당신이 맞아, 나는 이것을 고려하지 않았다. 또한 사용 su이 기록되어 있지만 su는 사용자가 다른 사람을 사칭하는 동안 실제로 수행 된 작업에 대한 기록을 유지하지 않습니다. 또한 악의적 인 루트가 로그를 변경하여 향후 조사자의 조치를 숨길 수 있습니다.
ypercubeᵀᴹ
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.