저장 비밀번호를 AES-256-GCM으로 써도, 왜 「이 PC의 프로그램은 읽지 못한다」가 되지 않나

검색 의도를 한 문장으로 먼저 답하기

「브라우저에 저장한 비밀번호는 암호화되어 있으니 악성 프로그램도 못 본다」를 검색하는 사람이 확인하려는 일은 같습니다. 저장을 누른 뒤, 이 컴퓨터의 다른 프로그램이 평문을 읽을 수 있는가. 알고리즘 이름은 그 답을 주지 않습니다. Google 보안 블로그는 Windows의 예전 경계를 분명하게 적습니다. Chrome은 운영체제가 제공하는 데이터 보호 인터페이스(DPAPI)로 쿠키와 비밀번호 같은 민감한 데이터를 보호합니다. 보호 대상은 그 시스템의 다른 사용자와, 전원을 끈 뒤 디스크를 가져가는 경우입니다. 현재 로그인한 사용자로 코드를 실행할 수 있는 프로그램은 브라우저와 같이 이 경계 안에 서서, 같은 키를 요청할 수 있습니다.

이 글은 두 사람을 위한 것입니다. 한 사람은 「브라우저가 이미 암호화해 저장하니, 비밀번호가 디스크에 남는 일은 더 볼 필요 없다」를 검토하는 개발자와 운영입니다. 다른 한 사람은 최근 보안 보도를 보고, 설정 화면의 「암호화됨」이 무엇을 증명하는지 알고 싶은 사람입니다. 다른 사람의 비밀번호를 저장소에서 푸는 방법은 적지 않으며, 비밀번호 생성기의 사용 설명을 대신하지도 않습니다. 가져갈 것은 따로 대조할 수 있는 세 층입니다. 암호문이 증명하는 것, 키 포장이 증명하는 것, 그리고 2026년 9월 25일 그 보고가 증명하지 않는 것.

디스크의 AES-256-GCM은 평문이 아니라는 뜻까지입니다

Chromium 계열 브라우저는 저장된 로그인을 이 PC의 프로필에 둡니다. 비교적 최근의 비밀번호 필드는 AES-256-GCM으로 감쌉니다. 그 파일을 텍스트 편집기로 열면 사이트 비밀번호 원문이 보이지 않습니다. 이것은 사실입니다. 여기서 GCM이 하는 일은, 대응하는 키가 없으면 한 바이트를 바꿔도 검증이 실패하고, 암호문을 몰래 고칠 수 있는 평문처럼 다루지 못하게 하는 것입니다.

브라우저는 다음에 로그인 칸을 열 때 비밀번호를 다시 채워야 합니다. 그래서 이 키는 사용자만 기억하는 암호 하나에만 둘 수 없습니다. 이 기기의 브라우저가 세션을 연 뒤에 꺼내 쓸 수 있어야 합니다. 질문은 「알고리즘이 강한가」에서 「누가 시스템에게 이 키를 달라고 할 수 있는가」로 바뀝니다. 알고리즘이 강해도, 자격이 「지금 로그인한 이 Windows 사용자」에게 있으면, 그 사용자로 시작한 프로그램은 브라우저와 같은 쪽에 섭니다.

이것이 「내가 직접 쥔 비밀번호로 하는 로컬 암호화」와 같은 문장이 아닌 이유입니다. 파일을 내가 입력한 비밀번호로 브라우저에서 AES-256-GCM 하면, 클라우드와 다른 프로그램은 그 문자열을 기본으로 갖지 않으므로 파일을 열지 못합니다. 브라우저 비밀번호 저장소의 설계 목표는 자동 입력이라, 키를 쓸 자격은 이 기기의 브라우저 쪽에 남아야 합니다. 같은 알고리즘 이름을 보았다고 두 가지 키 소유를 한 가지로 묶으면 안 됩니다.

Google이 직접 적은 그 경계

2024년 7월 30일 같은 설명은 운영체제 차이도 적습니다. macOS는 키체인을 쓰고, Linux는 시스템이 제공하는 지갑(kwallet 또는 gnome-libsecret)을 쓰며, Windows는 DPAPI를 씁니다. 아래의 「현재 로그인한 사용자로 시작한 프로그램」은 Google이 Windows DPAPI에 대해 적은 문장입니다. 모든 Mac에 그대로 씌우지 마세요. 키체인은 시스템 확인 창을 띄울 수 있어서, 「같은 사용자의 프로세스가 조용히 푼다」와 같은 상호작용이 아닙니다.

Windows에서 DPAPI는 키를 그 사용자의 로그인 자료에 묶습니다. 다른 Windows 계정이 내 프로필 폴더를 열거나, 전원을 끈 뒤 디스크를 떼어 가면서 내 로그인 비밀을 갖지 못하면, 기본으로는 풀지 못합니다. 제품 설명에서 「암호화되어 있다」가 가장 든든하게 서는 쪽이 여기입니다. 다른 쪽은 Google이 적어 둔 빈칸입니다. 악성 프로그램이 이미 현재 사용자로 실행될 수 있으면, 브라우저와 같은 시스템 인터페이스로 이 키를 요청할 수 있습니다. 암호화가 깨진 것이 아닙니다. 경계는 처음부터 「다른 사용자」에 그어져 있었고, 「이 사용자의 다른 프로세스」에 그어진 것이 아니었습니다.

그래서 「비밀번호 저장소는 AES-256-GCM이니, 로컬 악성 프로그램은 읽지 못한다」를 검토할 때는 둘로 나누세요. 앞부분은 저장소 파일이 평문이 아니라는 것으로 뒷받침됩니다. 뒷부분은 DPAPI 세대에서 Google의 공개 설명과 반대입니다. 따로 증거가 필요한 것은, 이 브라우저가 이런 비밀을 다음 경계로 옮겼는지입니다. 알고리즘 이름 자체가 그 증거가 되지 않습니다.

Chrome 127은 경계를 사용자에서 프로그램으로 좁힙니다

같은 설명은 이어서 이렇게 적습니다. Chrome 127은 Windows에서 앱 바운드 암호화(App-Bound Encryption)를 도입했습니다. 데이터는 더 이상 「현재 사용자로 도는 아무 프로그램」도 풀 수 있는 상태가 아니고, 키를 브라우저 프로그램의 신원에 묶습니다. 시스템 쪽 구성요소가 호출자가 신뢰된 브라우저인지 확인한 뒤에 키를 넘깁니다. 공식 이전 순서는 쿠키부터입니다. 비밀번호, 결제 데이터, 그 밖의 지속 로그인 토큰은 이후 버전에서 넓힐 대상이며, 127이 나온 날에 전부 옮겨진 것이 아닙니다.

2026년에 포렌식 쪽 공개 설명(예를 들어 ElcomSoft가 2026년 1월에 적은 글)은 이렇게 말합니다. 앱 바운드 암호화가 이미 켜진 비교적 최근 Chrome과 Edge 프로필에서는, 예전 방식인 「현재 사용자로 풀기」만 하는 외부 프로그램이 실패합니다. 이 새 경계가 막는 것은 「브라우저 밖에 선 일반 프로세스」입니다. 「브라우저 프로세스 안」까지 밖으로 밀어내지는 않습니다. 악성 확장 프로그램이나, 이미 브라우저 프로세스 안에서 실행되는 코드는 여전히 경계 안에 있습니다. 앱 바운드 암호화가 바꾸는 것은 호출자의 자격입니다. 「AES-256-GCM이라고 적혀 있으면, 메모리의 자동 입력 로직도 비밀번호를 보지 못한다」가 아닙니다.

그래서 서로 대신할 수 없는 문장이 둘 있습니다. 첫째, 내 Chrome이 127보다 높으니 저장 비밀번호는 반드시 이전이 끝났다. 공식 설명은 2024년 7월에 비밀번호를 확장 대상으로 적었습니다. 버전 번호만으로 이 항목이 끝났다고 볼 수 없습니다. 둘째, 뉴스에서 아직 예전 방식으로 비밀번호를 읽는 사람이 보이니 앱 바운드 암호화는 쓸모가 없다. 그것은 아직 옛 경계에 있는 프로필이나 데이터가 있거나, 샘플이 설명하는 것이 옛 경계라는 뜻입니다. 「새 경계가 공개적으로 깨졌다」는 증명이 되지 않습니다.

9월 25일 그 보고가 증명하는 것

K7 Labs는 2026년 9월 25일 한 종류의 Windows 프로그램 분석을 올렸고, 이어지는 며칠 동안 여러 보안 매체가 옮겼습니다. 보고는 이렇게 말합니다. 그 프로그램은 여러 Chromium 계열 브라우저에서 저장 비밀번호, 결제 카드 기록, 방문 기록, 세션을 읽고, Firefox의 방문 기록과 쿠키를 읽습니다. 비교적 최근의 비밀번호 필드는 AES-256-GCM으로 두고, 키는 Windows의 사용자 수준 데이터 보호로 풉니다. K7은 이 프로그램이 얼마나 퍼졌는지, 몇 대에 영향을 줬는지는 확인하지 못했다고 적었습니다.

이 설명은 앞 절의 옛 경계와 맞습니다. 자격이 「현재 사용자」에게 있으면, 같은 로그인 안의 프로그램은 경계 안에 설 수 있고, AES-256-GCM은 필드가 평문이 아니게 하는 일만 합니다. 보고는 「Chrome의 앱 바운드 암호화를 이미 우회했다」고 쓰지 않았고, 「당신의 Chrome은 반드시 당했다」로 바꿀 피해 대수도 내지 않았습니다. 제목의 알고리즘 이름을 「암호화가 깨졌다」로 읽거나, 「그래서 내 비밀번호 저장소는 절대 안전하다」로 읽으면, 한 걸음 더 나간 것입니다.

보고는 쉽게 한 덩어리로 섞이는 다른 자료도 같이 다룹니다. 세션과 저장 비밀번호는 두 가지 자료입니다. 세션이 넘어가면, 공격자는 한동안 이미 로그인된 상태를 그대로 쓸 수 있습니다. 원래 사이트에서 비밀번호를 바꾸면, 무효가 되는 것은 다음 비밀번호 로그인입니다. 이미 발급된 세션까지 반드시 무효가 되지는 않습니다. 세션을 처리하려면 계정의 기기 또는 세션 목록에서 로그아웃하거나, 사이트가 직접 취소할 때까지 기다려야 합니다. 이것은 「비밀번호 저장소 암호화가 강한가」와 별개입니다. 「비밀번호를 바꿔도 이미 등록된 세션은 막지 못한다」는 앞선 대조는 패스키 글에 있습니다. 두 일을 스위치 하나로 합치지 마세요.

그 자리에서 대조하기: 목록만 보고, 데이터베이스는 열지 않기

슬로건과 뉴스 제목은 이 브라우저의 설정을 대신하지 못합니다. 버려도 되는 테스트 사이트 계정 하나면 됩니다. 아래 네 단계는 지금 쓰는 브라우저에서 끝내며, 프로필 폴더를 복사해 낼 필요는 없습니다.

1. 브라우저에 들어 있는 비밀번호 관리자를 엽니다. 설정의 「비밀번호 / 자동 완성」이거나, 주소창으로 그 브라우저의 비밀번호 관리 페이지에 들어가면 됩니다. 사이트 목록만 보세요. 메일, 인터넷뱅킹, 클라우드 콘솔, 코드 호스팅이 각각 한 줄로 있는지. 평문 표시를 누르지 말고, 내보내지도 마세요.
2. 「비밀번호를 저장할지 묻기」또는 같은 역할의 스위치를 찾으세요. 이것은 다음 로그인이 다시 저장소에 들어갈지를 정합니다. 끄더라도 이미 있는 기록은 지워지지 않습니다. 지우려면 목록에서 한 줄씩 제거하거나, 브라우저가 제공하는 저장 비밀번호 삭제를 쓰세요.
3. 「정보」페이지를 열고, 브라우저가 아직 공식 업데이트를 받는지 확인한 뒤 버전 번호를 적으세요. 버전 번호는 비밀번호 필드가 앱 바운드 암호화로 옮겨졌다는 증명이 되지 않습니다. 설정 화면도 DPAPI나 앱 바운드라는 글자를 찍지 않습니다. 이 확인을 하려고 프로필 폴더의 키 접두어를 뒤지지 마세요.
4. 이 컴퓨터가 이미 출처가 불분명한 프로그램을 돌리고 있다고 의심되면, 이 기기에서 「비밀번호 표시」를 누르지 마세요. 아직 신뢰하는 다른 기기로 바꿔, 중요한 사이트에서 다른 세션을 로그아웃하고 비밀번호를 바꾸세요. 사이트마다 비밀번호를 재사용하지 마세요. 이 단계가 처리하는 것은 영향입니다. 이 PC에서 비밀번호 저장소를 풀어 「정말 읽히는지」 보는 일이 아닙니다.

버전 번호는 키가 어느 세대인지 답하지 못합니다

Chrome 127은 앱 바운드 암호화가 쿠키를 덮기 시작한 버전입니다. 「모든 저장 비밀번호가 그 날 포장을 바꿨다」는 버전이 아닙니다. 130, 140 또는 그 이상을 보았다면, 주 버전이 그 시작점보다 늦다는 뜻까지입니다. 비밀번호 필드가 이전이 끝났는지는, 공식 설명이 「이후 버전」이라는 범위를 남겨 두었고, 화면은 포장 세대를 보여 주지 않습니다. 버전 번호를 검토표에 적을 때는 옆에 「이것으로 비밀번호 저장소가 앱 바운드라고 단정할 수 없음」을 쓰세요. 체크 표시로 끝내면 안 됩니다.

저장 안내가 저장소에 들어가는 스위치입니다

많은 비밀번호가 저장소에 들어가는 이유는, 어떤 암호화 페이지가 「동기화로 업로드」해서가 아닙니다. 로그인이 성공한 뒤 브라우저가 저장할지 묻고, 사람이 저장을 눌렀기 때문입니다. 그 다음부터 그 기록은 위에서 말한 경계 안에 있습니다. 이 기기에서만 나타난 비밀번호를 만들고 저장을 거절하면, 그것은 비밀번호 관리자의 한 줄이 되지 않습니다. 저장을 거절했다고 페이지 스크립트가 비밀번호를 밖으로 보내지 않았다는 증명은 되지 않습니다. 그것은 네트워크 패널로 따로 봐야 합니다. 거절이 증명하는 것은, 이 문자열을 브라우저의 저장 비밀번호 목록에 넘기지 않았다는 점뿐입니다.

「암호화됨」을 너무 넓게 읽는 네 가지

첫째, AES-256-GCM을 「악성 프로그램은 읽지 못한다」로 읽는 일입니다. 이 알고리즘은 필드가 평문이 아니라는 것과, 키가 없으면 암호문을 고칠 수 없다는 것을 말합니다. 키를 DPAPI로 현재 사용자에게 감쌌다면, Google은 이미 이렇게 적었습니다. 그 사용자로 실행되는 프로그램도 브라우저와 같은 자격으로 이 키를 요청할 수 있습니다. 알고리즘 이름과 경계의 위치는 두 줄입니다.

둘째, 「Windows 로그인 비밀번호가 있다」를 「비밀번호 저장소는 악성 프로그램에 면역이다」로 읽는 일입니다. 로그인 비밀번호의 역할은, 다른 계정과 종료 후 디스크 복사가 DPAPI를 풀지 못하게 하는 것입니다. 프로그램이 이미 로그인된 뒤에 돌고 있다면, 그 프로그램이 쓰는 것은 이미 풀린 이 사용자 환경입니다. 로그인 비밀번호는 여전히 설정해야 합니다. 그것이 답하는 것은 다른 경계입니다.

셋째, 「버전이 127보다 높다」를 「저장 비밀번호와 쿠키가 모두 앱 바운드이고, 프로세스 안도 보지 못한다」로 읽는 일입니다. 공식이 적은 시작점은 쿠키이고, 비밀번호는 확장 대상입니다. 앱 바운드 암호화가 막는 것은 브라우저 밖의 예전 풀기입니다. 확장 프로그램과 이미 브라우저 프로세스 안에서 실행되는 코드는, 이 경계 때문에 갑자기 앞이 안 보이게 되지 않습니다.

넷째, 「사이트마다 다른 비밀번호를 쓴다」를 「저장소 전체가 읽혀도 상관없다」로 읽는 일입니다. 서로 다른 비밀번호가 막는 것은, 한 사이트 저장소가 새 뒤에 같은 문자열로 메일과 클라우드 콘솔을 두드리는 일입니다. 「프로그램이 비밀번호 관리자의 저장 기록을 한 번에 가져가는 일」은 막지 못합니다. 두 통제 모두 할 가치가 있습니다. 덮는 실패가 같은 종류가 아닙니다.

자주 묻는 질문

비밀번호 관리자에 암호화됨이 보이면, 이 PC의 다른 프로그램은 읽지 못하나요?

그렇게 읽으면 안 됩니다. 암호화됨은 디스크의 비밀번호 필드가 평문이 아니라는 뜻입니다. Windows의 DPAPI 세대에서 Google이 적은 보호는 다른 사용자와 종료 후 디스크 복사입니다. 현재 로그인한 사용자로 실행되는 프로그램은 막지 못합니다. Chrome 127부터의 앱 바운드 암호화는 쿠키를 먼저 덮고, 이미 옮긴 데이터에 대한 외부 프로그램의 예전 풀기는 실패합니다. 브라우저 프로세스 안은 여전히 읽을 수 있습니다. 화면의 「암호화됨」은 이 기기의 비밀번호 필드가 어느 세대에 있는지 알려 주지 않습니다.

Chrome 127의 앱 바운드 암호화는, 악성 프로그램도 저장 비밀번호를 풀 수 없다는 뜻인가요?

아닙니다. 2024년 7월 30일 설명은 비밀번호와 결제 데이터를, 이후 버전에서 넓힐 대상으로 적었습니다. 앱 바운드 암호화는 자격을 「현재 사용자」에서 「시스템 구성요소가 인정한 브라우저 프로그램」으로 좁힙니다. 그래서 예전 사용자 풀기만 하는 외부 프로그램이, 이미 옮긴 데이터에서 실패하는 이유를 설명할 수 있습니다. 프로세스 안의 코드가 경계 밖으로 밀려났다는 뜻은 아니고, 이 브라우저의 저장 비밀번호가 한 줄도 빠짐없이 이전을 마쳤다는 뜻도 아닙니다.

9월 25일 보고는, 내 Chrome 비밀번호를 아무 프로그램이나 읽을 수 있다는 뜻인가요?

그 결론으로 바로 바꾸면 안 됩니다. 보고가 적는 것은, 한 종류의 Windows 프로그램이 여러 Chromium 계열 브라우저의 저장 비밀번호, 결제 카드, 방문 기록, 세션과 Firefox의 방문 기록, 쿠키를 읽고, 비밀번호 필드가 AES-256-GCM이며 키는 사용자 수준 데이터 보호를 탄다는 점입니다. K7은 피해 대수를 내지 않았고, 그 샘플이 앱 바운드 암호화를 이미 우회했다고 쓰지도 않았습니다. 내 브라우저가 어느 세대인지는 저장 목록과 업데이트를 아직 받는지로 봐야 합니다. 이 보도의 알고리즘 이름으로 대신할 수 없습니다.

사이트 비밀번호를 바꾼 뒤, 이미 남아 있는 세션도 함께 끊기나요?

꼭 그렇지는 않습니다. 비밀번호를 바꾸면 무효가 되는 것은 다음에 그 문자열로 로그인하는 일입니다. 이미 발급된 세션은 계정의 기기 목록에서 다른 세션을 로그아웃하거나, 사이트가 취소해야 끊기는 경우가 많습니다. 같은 종류의 프로그램은 세션과 저장 비밀번호를 함께 가져갑니다. 비밀번호 한 곳만 바꾸고 다른 세션을 로그아웃하지 않으면, 처리한 것은 비밀번호이지 세션이 아닙니다.

열어 바로 쓰는 생성기로 「저장소에 안 넣기」를 한 번 대조하기

「비밀번호가 한 번 나타났다」와 「비밀번호가 브라우저 저장소에 들어갔다」가 같은 단계가 아니라는 것을 보려면, FastPwd의 비밀번호 생성기를 열면 됩니다. 가입은 필요 없습니다. 무작위 모드는 기본 16자로, 버려도 되는 비밀번호를 하나 만드세요. 브라우저가 저장 안내를 띄우면 저장하지 않기를 고르세요. 비밀번호 관리자로 돌아가면, 방금 그 테스트 사이트가 목록에 새로 생기면 안 됩니다. FastPwd는 비밀번호 보관함을 두지 않고, 브라우저의 저장 비밀번호 목록에 대신 쓰지도 않습니다.

생성은 crypto.getRandomValues를 씁니다. 길이는 6–128자이고 기본값은 16자입니다. 8자 미만이면 보안이 낮다고 알립니다. 결과는 기본적으로 업로드하지 않습니다. 개발자 도구의 Network를 열고 Preserve log를 켠 뒤, 비밀번호 문자열 전체로 요청 줄과 요청 본문을 검색하세요. 업무 요청에는 이 문자열이 없어야 합니다. 이 단계가 증명하는 것은 「이번엔 HTTP 본문으로 탭을 떠나지 않았다」입니다. 이 PC의 악성 프로그램이 페이지나 클립보드를 읽지 못한다는 증명은 되지 않습니다. 이 컴퓨터를 이미 신뢰할 수 없으면, 다른 기기에서 다시 만들고 다시 로그인하세요.

만든 뒤에 이 문자열이 공개된 고빈도 목록의 취약 비밀번호처럼 보이는지 보려면, 다른 버릴 테스트 문자열을 비밀번호 강도 검사에 넣으세요. 검사할 비밀번호는 업로드하지 않습니다. 목록에 없다는 것은 전 웹에서 본 적 없다는 증명이 아니고, 맞았다는 것은 너무 흔하다는 뜻일 뿐입니다. 막 쓸 실제 비밀번호를 검사 칸에 붙이지 마세요. 브라우저 비밀번호 저장소를 통째로 내보내 검사에 넣지도 마세요.

이 비밀번호를 다른 사람에게 한 번 넘겨야 한다면, 서버 로그에 남을 수 있는 티켓 본문에 붙이지 마세요. 열람 후 파기로 바꾸세요. 서버는 암호문만 잠시 두고, 키는 링크의 # 뒤에 있습니다. 만들기와 읽기 모두 계정이 필요 없습니다. 그 통로가 답하는 것은 「한 번 어떻게 건네는가」입니다. 「브라우저에 이미 저장된 옛 비밀번호를 어떻게 안전하게 만드는가」가 아닙니다. 옛 기록은 여전히 비밀번호 관리자에서 지우고, 신뢰하는 기기에서 바꿔야 합니다.

더 읽을거리

페이지의 「로컬, 업로드하지 않음」은 카나리아로 Network를 검색해 확인합니다. 브라우저 로컬 암호화에서 원문이 이 기기를 떠나지 않았는지 확인하는 방법을 보세요. 비밀번호를 바꿔도 이미 발급된 세션은 막지 못하는 이유는 패스키를 지금 업데이트하라며 전화가 온다. 이 수법이 훔치는 것은 Passkey가 아니라 세션인 이유에 있습니다. 로컬 취약 비밀번호 목록이 흔한 약한 비밀번호는 잡고, 전 웹 조회로 치면 안 되는 이유는 로컬 취약 비밀번호 목록이 증명할 수 있는 것과, 전 웹 조회가 아닌 이유에 있습니다.