비밀번호를 복사한 뒤, 클립보드는 누가 또 읽는가

운영이 데이터베이스 비밀번호를 막 만들고 복사를 누른 뒤, 터미널로 옮겨 붙여넣습니다. 그 삼십 초 동안 같은 문자열이 생성 페이지, 시스템 클립보드, 그리고 다음에 포커스가 가는 모든 입력칸에 동시에 있습니다. 앞부분은 많은 사람이 확인합니다. 생성이 서버로 올라갔는가. 그 확인은 Network에서 평문이 브라우저를 떠나지 않았는지 보는 글에 적혀 있습니다. 뒷부분은 자주 건너뜁니다. 복사가 끝난 뒤, 이 버퍼를 또 누가 읽는가.

이 글은 강한 비밀번호나 읽기 쉬운 패스프레이즈를 어떻게 만드는지가 아닙니다. 「복사」를 제품 기능 목록으로 쓰지도 않습니다. 질문은 하나입니다. 비밀번호가 클립보드에 들어간 뒤, 어떤 종류의 프로그램이 그 값을 읽을 수 있는가. MyPassGen의 복사 단추는 navigator.clipboard.writeText를 호출해 문자열을 시스템 클립보드에 넣습니다. 사이트에 비밀번호 보관함이 없고, 탭을 닫아도 서버에 그 값이 남지 않습니다. 클립보드는 운영체제의 공유 영역입니다. 페이지를 닫아도 남아 있습니다. 아래는 명세, 시스템 설정, 그 자리에서 할 수 있는 단계로 경로를 나눕니다.

복사가 끝나면 비밀은 이미 페이지를 떠났다

생성 페이지의 입력칸은 지금 열린 탭에 속합니다. 클립보드는 어떤 탭에도 속하지 않습니다. MDN은 Clipboard API를 「시스템 클립보드를 비동기로 읽고 쓰는 인터페이스」로 적습니다. 쓰기에 성공하면 메모장, 터미널, 카카오톡, 원격 데스크톱이 각자의 규칙으로 읽습니다. HTTPS가 지키는 것은 생성 페이지와 서버 사이 구간입니다. 이 기기의 버퍼는 그 구간에 들어가지 않습니다.

옛 인터페이스 document.execCommand('copy')는 권장되지 않고, 구현도 들쭉날쭉합니다. 새 페이지는 navigator.clipboard.writeText를 써야 합니다. 이 쓰기 자체는 보통 「읽기를 허용하시겠습니까」를 띄우지 않습니다. Chromium은 clipboard-write를 자동으로 줄 수 있는 쓰기 권한으로 봅니다. Firefox와 Safari는 방금 사용자 제스처가 있어야 합니다. 단추를 누르거나 키를 치는 일, 명세의 순간 활성화입니다. 「복사」를 누르는 행위가 그 제스처입니다. 스크립트가 뒤에서 조용히 쓰면 Safari에서는 자주 실패합니다. 「어떤 페이지는 한 번 눌러야 복사가 된다」는 사이트 심술이 아닙니다.

MyPassGen의 비밀번호 생성, 일회용 링크, 정리된 결과의 복사는 모두 같은 writeText를 탑니다. 가입 없이 바로 씁니다. 복사가 성공했다는 것은 문자열이 시스템 클립보드에 들어갔다는 뜻일 뿐입니다. 몇 초 뒤에 누가 읽을지를 증명하지 않고, Win+V 기록에 안 남는다는 뜻도 아닙니다. 「복사됨」네 글자를 안전의 끝으로 보면, 뒤에 이어지는 경로가 빠집니다.

웹에서 읽기: 권한과 붙여넣기 이벤트

웹 페이지가 클립보드를 먼저 읽으려면 navigator.clipboard.readText() 또는 read()를 탑니다. 명세는 보안 컨텍스트(HTTPS 또는 localhost)를 요구하고, 사용자가 방금 페이지를 조작한 뒤에 읽히기를 기대합니다. 브라우저마다 실제 동작이 다릅니다. 그래서 그 자리에서 시험할 수 있습니다.

Chromium: clipboard-read 권한

Chrome, Edge 등은 문서에 포커스가 있어도 읽기가 명세에 완전히 맞지 않으면, Permissions API의 clipboard-read를 요청합니다. 「허용」을 누르면 권한이 남습니다. 같은 출처의 스크립트는 다음에 창을 다시 띄우지 않고 읽을 수 있습니다. 사이트 설정에서 「클립보드」를 찾고 거둘 수 있습니다. 다른 페이지에 끼워 넣은 iframe은 Permissions-Policy의 clipboard-read / clipboard-write도 통과해야 합니다. 부모 페이지가 열어 주지 않으면 자식은 인터페이스를 호출해도 실패합니다. 개발자 도구 Application → Permissions에서 확인할 수 있는 사실이지, 구호가 아닙니다.

Firefox와 Safari: 잠시 뜨는 붙여넣기 메뉴

Firefox와 Safari는 이 지속 권한을 구현하지 않을 생각입니다. 읽기가 명세에 맞지 않더라도 순간 활성화가 있으면, 항목이 하나인 짧은 컨텍스트 메뉴가 뜹니다. 「붙여넣기」뿐입니다. 약 일 초가 지나야 누를 수 있습니다. 같은 출처 내용은 이 단계를 건너뛰는 경우가 있습니다. 다른 출처는 대체로 건너뛰지 못합니다. 그 항목을 누르지 않으면 스크립트는 텍스트를 가져가지 못합니다. Chromium의 「한 번 허용하면 다음에도 읽는다」와는 다른 모델입니다.

직접 붙여넣을 때: 페이지는 반드시 읽는다

Ctrl+V / Cmd+V를 치거나 입력칸의 「붙여넣기」를 누르면 paste 이벤트가 납니다. 처리 함수는 clipboardData에서 텍스트를 꺼냅니다. 지금 페이지에 직접 건넨 것이지, 뒤에서 훔친 것이 아닙니다. 위험은 다른 데 있습니다. 포커스가 슬랙, 카카오톡, 티켓 답장, 엉뚱한 브라우저 설정 페이지에 있을 때 손이 눈보다 빠릅니다. 클립보드는 「비밀번호를 붙이려는가」를 묻지 않습니다.

휴대폰에는 한 겹이 더 있습니다. iOS 14부터, 앱이 백그라운드에서 클립보드를 읽으면 화면 위에 배너가 잠깐 뜹니다. iOS 16부터는 시스템 붙여넣기 메뉴, 단축키, UIPasteControl을 쓰지 않고 UIPasteboard를 바로 읽으면, 시스템이 먼저 「붙여넣기를 허용하시겠습니까」를 묻습니다. 배너와 창은 「누가 읽고 있다」는 증거입니다. 「아무도 읽지 않았다」는 증거가 아닙니다. 안 보였다면 이번엔 트리거가 안 됐거나, 예전에 허용을 눌렀을 뿐입니다.

시스템 기록과 클라우드 동기화

웹 권한은 「지금 탭의 스크립트」만 덮습니다. 운영체제는 따로 기록을 들고 있고, 다른 기기로 동기화할 수도 있습니다. 이 두 경로는 clipboard-read 창을 거치지 않습니다.

Windows 10 / 11에서 클립보드 기록을 켜면 Win+V로 최근 복사 항목을 봅니다. Microsoft 설명은 이렇게 적습니다. 최대 25건. 고정하지 않은 항목은 다시 시작하면 비워지고, 고정한 항목은 남습니다. 설정에서 「디바이스 간 동기화」도 켤 수 있습니다. 같은 Microsoft 계정으로 로그인한 PC 사이에 텍스트가 오갑니다. 비밀번호가 기록에 들어가면, 이 PC 앞에 앉은 사람과 동기화 대상 기기의 사람이 패널에서 평문을 봅니다. 고정(핀)은 특히 위험합니다. 다시 시작해도 지워지지 않습니다.

애플의 유니버설 클립보드는 Handoff를 탑니다. 기기가 가까이 있고, 같은 Apple 계정이며, 블루투스와 Wi-Fi가 켜져 있고, Handoff가 켜져 있어야 합니다. 기본값은 켜짐입니다. 한 기기에서 복사하면 근처 다른 기기에서 붙여넣을 수 있습니다. 내용은 짧은 시간만 남거나, 어느 한쪽에서 새 내용을 복사할 때까지 남습니다. Apple 보안 가이드는 더 직접적입니다. 앱은 사용자가 아직 붙여넣지 않아도 클립보드 데이터에 접근할 수 있습니다. 유니버설 클립보드를 켠 뒤엔, 그 접근이 같은 iCloud 계정의 다른 기기로 연장됩니다. 암호화는 Handoff와 같은 채널(BLE 4.2 페어링, 256비트 AES 키, 광고는 AES-256-GCM)을 씁니다. 길에서 엿듣는 사람을 막는 것이지, 이미 로그인한 옆 아이폰이 못 읽는다는 뜻이 아닙니다.

비밀번호 관리자도 클립보드를 짧은 노출 창으로 인정합니다. 1Password는 기본으로 약 90초 뒤 복사한 내용을 지우고, 보안 설정에서 끌 수 있습니다. Bitwarden은 데스크톱, 모바일, 브라우저 확장에서 「클립보드 지우기」를 제공합니다. 간격은 약 10초에서 5분, 안 지움으로도 둘 수 있습니다. 브라우저 생성 페이지는 보통 대신 해주지 않습니다. MyPassGen은 복사에 성공해도 카운트다운으로 비우지 않습니다. 덮어쓰려면 직접 다른 것을 복사하거나, 시스템 패널에서 지워야 합니다.

원격 데스크톱, 확장, 잘못 붙여넣기

원격 데스크톱, VNC, 많은 회의 프로그램은 클립보드를 양쪽으로 넘기는 것을 기본값으로 둡니다. 원격 세션에서 복사하면 이 기기에도 붙고, 이 기기에서 복사하면 상대에도 붙습니다. 비밀번호가 두 기계의 버퍼에 동시에 나타납니다. 화면을 공유할 때는, 터미널에 방금 붙인 글자가 회의 녹화나 캡처에 남을 수 있습니다. 「웹이 올렸는가」와는 다른 층입니다. Network 패널에는 안 보입니다.

브라우저 확장이 clipboardRead / clipboardWrite(또는 Chromium의 대응 호스트 권한)를 신청했다면, 페이지 스크립트의 권한 모델 밖에서 클립보드를 읽고 쓸 수 있습니다. 확장 스토어의 권한 목록에서 확인할 수 있습니다. 「클립보드 강화」「기기 사이 붙여넣기」류 확장을 깐 것은, 동기화 채널을 하나 더 연 것과 같습니다. 생성 페이지가 올렸는지만 보지 말고, 확장 목록도 보세요.

가장 흔하고, 그 자리에서 재현하기 쉬운 일은 여전히 잘못 붙여넣기입니다. 포커스가 슬랙, 메일 본문, 티켓 답장에 있을 때 손가락이 붙여넣기를 칩니다. 채팅 기록, 메일 보관함, 티켓 시스템은 평문을 남기고, 그 보관 시간은 클립보드의 90초보다 훨씬 깁니다. 비밀번호를 원격 동료에게 한 번만 넘길 때는 일회용 링크를 탑니다. 키는 주소의 # 뒤에 두고, 읽기 페이지는 로그인하지 않습니다. 같은 평문을 클립보드에 복사하고 단톡방에 또 붙이지 마세요.

대조표: 다섯 갈래 유출 경로

방금 복사한 테스트 비밀번호는 적어도 다섯 갈래로 나뉩니다. 차이는 알고리즘 이름이 아닙니다. 누가 읽는지, 그 자리에서 볼 수 있는지입니다.

생성 페이지가 Web Crypto로 난수 문자열을 만들고, Network에 비밀번호 본문이 없다면 「올리기」한 갈래만 닫힌 것입니다. 표의 나머지 네 갈래는 그대로 열려 있습니다. 관리자가 자동으로 채워 줄 수 있으면 클립보드를 거칠 필요가 없습니다. 손으로 치거나 꼭 복사해야 하면, 노출 창을 「붙인 뒤 바로 덮어쓰기」까지로 줄입니다.

그 자리에서 확인하기

아래 단계는 어떤 브랜드 약속에도 기대지 않습니다. 실제 계정에 쓰지 않을 비밀번호로 하세요. 생성기의 기본 16자 랜덤 문자열이면 충분합니다. 지금 쓰는 마스터 비밀번호로 연습하지 마세요.

1. 생성 페이지를 열고 테스트 비밀번호를 만든 뒤 복사합니다. 로그인에 쓰지 마세요. 개발자 도구 Network를 열고 「로그 보존」을 켠 뒤, 복사 동작 이후 요청 본문과 분석 이벤트에 이 문자열이 없는지 봅니다. 올리기를 확인하는 방법은 브라우저에서 암호화할 때, 평문이 올라가지 않았는지 그 자리에서 확인하는 방법에 있습니다.
2. 메모장이나 아무 텍스트 칸을 열고 한 번 붙여넣어, 클립보드에 방금 그 문자열이 있는지 확인합니다. 한 글자 x를 다시 복사한 뒤 한 번 더 붙입니다. x가 나와야 덮어쓰기가 된 것입니다.
3. Windows이고 클립보드 기록이 켜져 있으면 Win+V를 칩니다. 기록에 테스트 비밀번호가 보여야 합니다. 이미 덮어썼다면 맨 위는 x이고, 비밀번호는 더 아래에 남아 있을 수 있습니다. 고정은 누르지 마세요. 「모두 지우기」를 쓰거나, 의미 없는 텍스트를 계속 복사해 목록에서 비밀번호가 사라질 때까지 갑니다.
4. 빈 탭의 콘솔에서 navigator.clipboard.readText().then(console.log, console.error)를 실행합니다. Chromium은 읽기 권한을 띄우거나 실패해야 합니다. Firefox / Safari는 붙여넣기 항목이 뜨거나 거절해야 합니다. 「디버깅이 편하다」고 「허용」을 누르지 마세요. 허용은 이 출처에 지속 읽기 권한을 남기는 일입니다.
5. 같은 Apple 계정 또는 Microsoft 계정으로 로그인하고 동기화를 켠 두 번째 기기가 있으면, 그 기기에서 붙여넣습니다. 테스트 비밀번호가 나오면 클라우드 동기화 또는 유니버설 클립보드가 평문을 보낸 것입니다. 동기화를 끄거나 Handoff를 끈 뒤, 또는 시간이 지난 뒤에 한 번 더 시험합니다.
6. 설치한 확장의 권한 목록에서 클립보드 읽기·쓰기가 있는지 봅니다. 원격 데스크톱이 열려 있으면 상대 메모장에서 한 번 붙여넣어, 전달이 켜져 있는지 확인합니다.

MyPassGen 비밀번호 생성은 이 경계를 따릅니다. 랜덤 모드는 6–128자, 기본 16자, 8자 미만이면 약하다고 알립니다. 두 모드 모두 지금 탭에서 getRandomValues로 뽑고, 복사는 writeText를 탑니다. 가입 없이 바로 씁니다. 계정과 비밀번호 보관함이 없습니다. 확인할 것은 권한 창, Win+V, 다른 기기에서의 붙여넣기입니다. 페이지의 「복사됨」이 아닙니다.

붙여넣은 뒤 어떻게 마무리하나

오늘 꼭 복사해야 하는 한 건은 이 순서로 마무리합니다. 포커스가 올바른 비밀번호 칸에 있는지 확인한 뒤 붙여넣습니다. 바로 의미 없는 한 글자를 복사하거나 시스템 패널에서 기록을 지웁니다. 다른 사람에게 넘겨야 하면 일회용 링크로 바꾸고, 키는 # 뒤에 둡니다. 평문을 클립보드에 「백업」으로 남기지 마세요. 관리자 자동 채우기로 바꿀 수 있는 계정은, 복사 단계를 절차에서 빼세요.

공용 PC, 발표용 노트북, 원격 데스크톱이 열린 운영 점프 박스는 「클립보드를 두 번째 사람이 읽는다」를 기본값으로 둡니다. 이런 환경에서는 마스터 비밀번호를 복사하지 마세요. 손으로 쳐야 하면 더 긴 패스프레이즈로 오타를 줄이고, 쓴 뒤에는 바꿉니다. 100개 표에서 네 단어는 약 27비트라 마스터 비밀번호로는 부족합니다. 대조는 랜덤 비밀번호와 패스프레이즈는 어떻게 고르나에 있습니다.

「붙인 뒤 덮어쓰기」와 「읽기 허용을 누르지 않기」를 하면, 이 글의 질문에 답할 수 있습니다. 복사 뒤에 누가 또 읽는가는 웹 권한, 시스템 기록, 클라우드 동기화, 원격 세션, 그리고 다음번 붙여넣기에 달려 있습니다. 생성 페이지가 올리지 않았다는 것은 서버 로그에 이 문자열이 없다는 뜻일 뿐입니다. 운영체제가 이미 나눠 준 한 부는 거두지 않습니다.

자주 묻는 질문

HTTPS면 복사한 비밀번호는 안전한가?

아닙니다. HTTPS가 지키는 것은 브라우저와 서버 사이 전송입니다. 클립보드는 이 기기에 있고, 그 TLS를 타지 않습니다. 웹이 올리는 일, 시스템 기록, 유니버설 클립보드, 잘못 붙여넣기는 주소창의 자물쇠를 보지 않습니다.

「클립보드 읽기 허용」을 눌렀다면 나중에 거둘 수 있나?

Chromium에서는 됩니다. 사이트 설정 → 권한 → 클립보드를 차단으로 바꿉니다. Firefox와 Safari는 이번 읽기를 지속 권한으로 남기지 않는 경우가 많아, 다음에도 붙여넣기 항목을 거칩니다. 한 번 덜 누르려고 믿지 않는 출처에 읽기 권한을 주지 마세요.

비밀번호 생성에 가입이 필요한가? 복사는 서버로 올라가나요?

가입은 필요 없습니다. 생성과 복사는 지금 탭에 남아야 합니다. 복사는 문자열을 시스템 클립보드에 쓰는 일이고, 서버로 POST하는 일이 아닙니다. Network를 여세요. 복사 뒤에 요청 본문과 분석 이벤트에 그 비밀번호가 나와서는 안 됩니다. 동료에게 남겨야 하면 일회용 링크를 쓰고, 클립보드를 전송 통로로 쓰지 마세요.

비밀번호 관리자 자동 채우기가 복사보다 안전한가?

「시스템 클립보드에 한 번 덜 노출된다」는 점에서는 그렇습니다. 자동 채우기는 비밀번호를 지금 폼에 넣고, Win+V 기록을 거치지 않습니다. 관리자가 여전히 「복사」를 제공한다면, 그 한 번의 복사는 생성 페이지의 복사와 같은 버퍼를 탑니다. 그래도 덮어써야 합니다. 자동 채우기를 고를 수 있으면 복사하지 마세요.