Home Assistant의 Pwned-Password 확인: GitHub 이슈, 옵트아웃 명령, 그리고 프라이버시 논쟁

Home Assistant의 Supervisor는 수년 동안 비밀번호로 표시된 앱 옵션을 Have I Been Pwned (HIBP) 유출 데이터베이스와 조용히 대조해 왔으며, 로컬에서 계산된 SHA-1 해시의 처음 5자만 보내는 k-익명성 방식을 사용합니다. 2026년 10월, "I never authorized an integration that scans my secrets"라는 제목의 GitHub 이슈가 그 오랜 행동을 동의, 옵트인 기본값, 그리고 관리자의 어조에 대한 공개적인 싸움으로 바꾸었고, 관리자의 사과와 확인을 이미 끌 수 있다는 공개로 끝났습니다.

Home Assistant가 실제로 Have I Been Pwned에 보내는 것

Home Assistant의 Supervisor는 비밀번호 값을 로컬에서 해시하고 SHA-1 해시의 처음 5자만 Have I Been Pwned에 보냅니다. 반환된 해시 목록과의 대조는 사용자 자신의 인스턴스에서 이루어지므로 전체 비밀번호와 전체 해시는 시스템을 떠나지 않습니다.

관리자 Franck Nijhof (GitHub 핸들 frenck)는 이슈에 대한 후속 답변에서 메커니즘을 설명했습니다:

프라이버시는 처음부터 이 기능의 설계 요구 사항이었으며, 그래서 당신의 비밀번호는 시스템을 떠나지 않습니다. Supervisor는 그것들을 로컬에서 해시하고 SHA-1 해시의 처음 5자만 Have I Been Pwned에 보냅니다. HIBP는 그 접두사로 시작하는 모든 해시를 반환하고, 대조는 당신 자신의 인스턴스에서 이루어집니다.

그는 독자들을 https://github.com/home-assistant/supervisor/blob/main/supervisor/utils/pwned.py의 구현으로 안내했습니다.

이것은 Cloudflare가 유출된 비밀번호 검증을 위해 문서화하고 Wikipedia에서 k-익명성으로 설명한 것과 동일한 k-익명성 접근 방식입니다. 두 링크 모두 원래 GitHub 스레드에서 인용되었습니다.

pwned-password 확인을 끄는 방법

확인은 명령줄에서 비활성화할 수 있습니다:

ha security options --pwned=false

이 명령은 이슈가 제기된 당시 문서화되지 않았습니다. Nijhof는 그 공백을 인정했습니다: "당신 말이 맞습니다. 우리 문서가 이것을 설명했어야 했고, 끄는 방법도 포함했어야 했습니다. 우리가 그 페이지를 업데이트하겠습니다."

영향을 받는 사람과 받지 않는 사람

스캔 동작은 Home Assistant Core가 아닌 Supervisor에 있습니다. Hacker News 댓글 작성자 (gcommer)는 자체 호스팅 컨테이너에서 Home Assistant Core를 실행하는 사용자는 영향을 받지 않는다고 언급했습니다. 관련 Supervisor 서비스는 Home Assistant OS 및 Home Assistant Supervised 설치의 일부이기 때문입니다.

GitHub 이슈: 무엇이 보고되었고 왜 그런지

이슈는 GitHub 사용자 Viss에 의해 home-assistant/home-assistant.io 문서 저장소에 Home Assistant 버전 2026.10.1에 대해 제기되었습니다. 보고자는 다음과 같이 썼습니다:

이것은 상당히 심각한 프라이버시 침해입니다. 나는 비밀번호를 스캔하고 위로 보내는 어떤 통합이나 플러그인도 승인한 적이 없습니다. 해시되었든 아니든 간에 말입니다. 이 메커니즘은 home assistant github 저장소에 접근할 수 있는 악의적인 위협 행위자에 의해 다양한 방식으로 악용될 수 있습니다.

제안된 해결책은 "이것을 옵트인 기능으로 만들고, 존재조차 알지 못하는 시스템으로 사람들을 비밀번호 스캔에 옵트인시키지 마십시오"였습니다.

보고자의 배경은 분쟁과 관련이 있습니다. Viss는 Phobos Group을 운영하고 국제적으로 보안 프레젠테이션을 하며, "HIBP에 매우 잘 알고 있고", HIBP 창립자 Troy Hunt를 만났으며, 2011년 Twitter에서 유일한 레드팀 직원으로 1Password 배포를 도왔다고 밝혔습니다. 그는 덧붙였습니다: "레드팀원으로서, 나는 이것을 악용하여 지구상의 모든 HA 설치에서 자격 증명을 약탈하는 방법의 목록을 팔 길이만큼 줄 수 있습니다."

관리자의 첫 응답과 확대

Nijhof의 첫 답변은 프레임을 완전히 거부했습니다:

그것은 프라이버시 침해가 아니며, 이렇게 하는 다른 앱들이 분명히 있습니다 (가장 주목할 만한 것은 1Password 비밀번호 관리자). 당신의 비밀번호는 절대 보내지지 않고, 절대 게시되지 않습니다.

그는 또한 썼습니다: "오히려 출력에서 배우십시오. 당신이 사용하는 비밀번호가 비밀번호 데이터베이스에 나열되어 있어 쉽게 '해킹'될 수 있기 때문입니다."

교환은 또 다른 오랜 사용자 0x00string이 이슈를 다시 열고 확인을 비활성화하는 문서화된 방법을 요청하면서 확대되었습니다: "이것을 합리적으로 해결할 관심이 없다면, 우리가 제거하고 포크할 수 있도록 알려주십시오."

Nijhof는 응답했습니다:

죄송합니다, 이것들은 우리가 작업할 수 있는 진술이 아닙니다. 그런 위협을 하고 협박하려는 것은 당신을 어디에도 데려가지 않을 것입니다. 기능 요청을 하고 싶다면 괜찮습니다, 우리는 그것을 위한 장소가 있습니다.

그는 보고서를 "won't fix"로 닫았으며, 문서 저장소에 제기되었다고 언급하고 "이것을 조정하거나 해결하기 위해 내가 조정할 수 있는 문서의 양은 없습니다"라고 말했습니다.

스레드는 이후 "너무 과열"로 잠기고 2026년 10월 16일에 협력자로 제한되었습니다.

후속 사과와 정정

Nijhof는 나중에 같은 이슈에 후속 답변을 게시하여 이전 답변의 어조에 대해 사과하고 옵트아웃에 대한 기록을 정정했습니다:

이 저장소가 우리 문서를 위한 것이므로 이것을 닫은 채로 두지만, 후속하고 싶습니다. 왜냐하면 내 이전 답변이 이것이 받을 자격이 있는 것보다 더 경시적이었기 때문입니다. 사과드립니다.

그는 또한 타임라인을 명확히 했습니다: 확인은 "새로운 것이 아니며, 수년 동안 Supervisor의 일부였습니다. 비밀번호로 표시된 앱 옵션을 확인합니다. 최근 릴리스가 그것을 표면화하는 경고를 수정했으며, 그래서 지금 그것을 보고 있는 것입니다."

기능을 지지하는 프라이버시 주장: k-익명성

확인의 설계 의도는 비밀번호가 공개 유출 말뭉치에 이미 나타날 때 사용자에게 경고하는 것입니다. 5자 해시 접두사만 전송되므로 서비스는 사용자가 보유한 특정 비밀번호를 결정할 수 없습니다. 반환된 후보 집합은 모호할 만큼 충분히 큽니다. 이것은 비밀번호 유출 확인에서 k-익명성의 표준 주장이며, 관리자가 1Password의 행동과 비교한 이유입니다.

반대하는 프라이버시 주장: 동의와 최소 놀라움

비평가들은 암호화를 논쟁하지 않았습니다. 그들은 기본값을 논쟁했습니다. 가장 많은 투표를 받은 Hacker News 댓글인 eranation의 댓글은 불일치를 일련의 질문으로 구성했습니다:

비밀번호 관리자가 옵트인 없이 아무것도 보내지 않고 재사용된 비밀번호에 대해 경고해야 합니까? 예 - 비밀번호 관리자가 좋은 의도와 수학적으로 '안전하다'고 입증되었더라도 옵트인 없이 내 데이터의 1바이트라도 어떤 서비스에 보내야 합니까? 나는 아니오라고 말합니다. - 그렇다면 스마트 홈 관리자든 토스터든 다른 어떤 제품이 옵트인 없이 내 데이터를 해시되었든 아니든 제3자에게 보내야 합니까? 'donothing.com'이라는 페이지에 '1'이라는 바이트 하나만이라도? 나는 절대 안 된다고 말합니다.

그 댓글은 또한 포크 위협에 대한 Nijhof의 반박을 옹호했습니다 — "우리 모두 때때로 나중에 후회하는 순간의 열기 속에서 답변을 쓸 수 있습니다" — 그러나 "어떤 종류의 귀환 통신도 최소 놀라움의 원칙을 위반하는 것입니다"라고 결론지었습니다.

별도의 댓글 작성자 thunderfork는 반대 의견을 가졌습니다: "그래서, 잠깐, 이것들은 이미 h-a에 주어진 비밀번호이고, 해시되었으며, 해시의 처음 5자만 보내지는 것입니까? 네, 나는 관리자에 동의합니다. 이것은 실제 문제보다 분노 극장처럼 보입니다, 그렇지 않나요?"

Arcuru는 같은 기술적 질문을 직접 제기했습니다: "이 기능은 옵트인이어야 하지만, 누가 이것이 보안 문제인지 설명할 수 있습니까? 내 비밀번호의 sha256의 처음 5자리를 공유하는 것이 실제 보안 위험이 될 수 있는지 이해하지 못하겠습니다."

토론에서 제기된 법적 질문

한 Hacker News 댓글 작성자 Rygian은 통합이 유럽에서 규정 준수 문제를 일으킬 수 있다고 주장했습니다: "그 통합이 GDPR 때문에 EU에서 완전히 불법이고, 따라서 HIBP가 법적 정당성 없이 개인 식별 정보를 수집하는 데 문제가 생길 것이라고 놀라지 않을 것입니다." 같은 댓글 작성자는 원래 답변을 비판했습니다: "첫 답변이 '그것은 프라이버시 침해가 아니다'라는 것은 프라이버시 주제에 대한 무능력을 보여줍니다. 그것은 결코 유효한 답변이 아닙니다." 스레드에서 법적 결정은 내려지지 않았습니다.

Hacker News에서의 커뮤니티 반응

이야기는 Hacker News에서 177점과 131개의 댓글에 도달했습니다. 반응은 세 가지 방향으로 나뉘었습니다: k-익명성의 기술적 건전성, 프라이버시 중심 프로젝트에 대한 옵트아웃 기본값의 적절성, 그리고 관리자 응답의 어조.

여러 댓글 작성자는 기능 자체보다 어조와 절차에 집중했습니다. interf4ce는 관리자가 닫은 이유 — 이슈가 코드 저장소가 아닌 문서 저장소에 제기되었다는 것 — 가 "이해할 수 있지만" "OP를 올바른 저장소로 안내하는 데 더 많은 노력이 들지 않았을 것"이라고 언급했습니다. Cameri는 "개발자가 자기중심적으로 보입니다... 그가 자신의 무감각한 응답으로 일으킨 것을 과열이라고 부릅니다"라고 썼습니다. Home Assistant Green을 구매하려고 했다고 말한 onionisafruit는 그 멈춤이 "haveibeenpwned에 해시를 보내는 것에 대한 것이 아니라 github에서 이 응답에 대한 것"이라고 썼습니다.

다른 사람들은 관리자의 직설성을 옹호했습니다. altairprime는 "결단력 있는 소프트웨어 창작자는 자격을 가진 불일치의 떼에게 훨씬 덜 매력적이며, 그 같은 결단력이 최고의 소프트웨어를 만드는 것입니다"라고 썼고 스레드를 "코미디-소극"으로 묘사했습니다. TZubiri는 포크 댓글을 위협으로 특성화하는 것에 반박했습니다: "사용자가 소프트웨어 사용을 중단할 수 있다는 것을 개발자에게 알리는 것이 부적절하거나 '위협'이라고 생각하지 않습니다."

abletonlive는 사과가 반응적이라고 제안했습니다: "이 경우, frenck은 확실히 HN의 첫 페이지에 있다는 것을 깨닫고 열기를 원하지 않아서 물러섰습니다."

한 댓글 작성자 speerer는 관찰했습니다: "AI 응답이 인간이 쓴 응답보다 개선된 드문 경우입니다."

한 댓글 작성자는 또한 Nijhof를 NixOS nixpkgs 저장소의 관련 없는 이전 논란 (풀 리퀘스트 126326)에 연결하고 2021년 Hacker News 토론을 가리켰습니다.

Home Assistant가 다음에 무엇을 할 것이라고 말했는지

이슈는 문서 저장소에 제기되었기 때문에 닫힌 채로 남아 있습니다. 관리자 후속 답변의 구체적인 약속은: pwned-passwords 기능의 문서 페이지가 메커니즘과 비활성화 방법을 설명하도록 업데이트될 것이며, 행동을 옵트인으로 변경하려는 사용자는 문서 저장소가 아닌 Home Assistant의 일반 기능 요청 채널을 통해 기능 요청을 제출하도록 안내되었습니다.

Home Assistant OS 및 Supervised 사용자를 위한 기능적 요점은 확인이 이미 선택 사항이라는 것입니다 — ha security options --pwned=false가 오늘 그것을 비활성화합니다.