비밀번호 보호 파일 전송 서비스 리뷰

파일 전송 서비스의 비밀번호 보호는 형식적인 것부터 암호학적으로 의미 있는 것까지 다양합니다. WeTransfer Pro는 서버 측에서 확인한 후 다운로드를 잠금 해제하는 비밀번호 게이트를 추가하지만, 파일 자체는 WeTransfer 자신이 복호화할 수 있습니다. Smash, SwissTransfer, Dropbox Transfer도 유사한 모델을 따릅니다. Tresorit Send와 HexaTransfer는 비밀번호(또는 파생 키)를 PBKDF2 또는 Argon2id를 통한 실제 파일 암호화의 입력값으로 사용하므로 비밀번호 없이는 암호문이 수학적으로 읽을 수 없습니다. 서비스 제공업체조차도 마찬가지입니다.

서버 측 게이트 대 암호학적 키

중요한 차이는 비밀번호가 확인되는 위치입니다. 서버 측 게이트 모델에서 제공업체는 비밀번호 해시(bcrypt 또는 Argon2이기를 바람)를 저장하고 파일을 제공하기 전에 입력 값을 검증합니다. 파일 자체는 제공업체가 보유한 키로 암호화됩니다. 공격자가 데이터베이스를 침해하거나 법원이 제공업체에 강제하면 비밀번호 강도에 관계없이 파일이 평문으로 나옵니다.

암호학적 키 모델에서는 비밀번호가 키 파생 함수(KDF)—보통 60만 회 이상 반복하는 PBKDF2 또는 메모리 비용이 조정된 Argon2id—를 통과하여 실제 파일 암호화 키를 생성합니다. 비밀번호가 없으면 키가 없고, 키가 없으면 평문이 없습니다. 제공업체는 소환장을 받아도 비밀번호 없이는 파일을 복호화할 수 없습니다.

WeTransfer Pro: 편리한 게이트, 암호화는 아님

WeTransfer는 Pro 플랜(약 €10/월)에 비밀번호 보호를 도입했습니다. 업로드 시 비밀번호를 입력하고, 별도 채널로 공유하며, 수신자가 다운로드 페이지에서 입력합니다. 내부적으로 WeTransfer는 해시 비교를 수행합니다. 파일은 AWS KMS로 관리되는 키로 AES-256 암호화되어 있으며 비밀번호에서 파생되지 않습니다.

이 설계는 링크 전달에 대한 일상적인 보호에는 적합하지만, WeTransfer 자체나 호스팅 공급업체를 신뢰하지 않는 위협 모델을 충족하지 못합니다. 속도 제한이 없으면(WeTransfer는 공개적으로 문서화하지 않음) 온라인 무차별 대입 공격에도 취약합니다.

Smash: 비밀번호 + 이메일 인증

Smash는 모든 유료 플랜에서 비밀번호 보호를 제공합니다. 특이한 점은 선택적 수신자 이메일 인증과의 결합입니다. 수신자가 특정 이메일 주소의 소유권을 마법 링크로 증명하고 비밀번호도 입력하도록 요구할 수 있습니다. 이는 전달된 링크 + 가로채인 비밀번호라는 일반적인 공격을 무력화합니다.

비밀번호는 여전히 서버 측 게이트이지 파생 입력이 아닙니다. 그러나 두 요소 방식(알고 있는 것 + 접근할 수 있는 것)은 보안 기준을 상당히 높입니다. 특정 당사자에게 계약서를 보낼 때 사용성과 보안의 합리적인 절충점입니다.

SwissTransfer: 간단한 선택적 비밀번호

SwissTransfer의 비밀번호 필드는 선택적이며 서버 측에 적용됩니다. 서비스는 무료이고 계정 불필요이며, 스위스 Infomaniak 인프라에만 호스팅됩니다. 비밀번호는 링크의 무분별한 공유를 막지만, 암호화 이야기는 바뀌지 않습니다(파일은 서비스가 관리하는 키로 AES-256 at rest). UI가 깔끔합니다: 체크박스 하나, 비밀번호 필드 하나, 확인 하나. 비밀번호 강도 측정기나 최소 복잡도 적용이 없어 "123"을 입력해도 수락됩니다.

Dropbox Transfer: 관리자 정책이 있는 비밀번호

Standard 이상의 Dropbox Transfer는 관리자가 설정 가능한 최소 복잡도를 가진 비밀번호를 지원합니다. 팀 관리자는 최소 8자, 대소문자 혼합, 숫자, 기호를 적용할 수 있습니다. 비밀번호 확인은 Dropbox가 팀 설정에 따라 미국 또는 EU 리전에서 파일을 스트리밍하기 전에 서버 측에서 발생합니다. Dropbox Business의 SAML SSO 통합은 비밀번호 흐름을 신원 확인 액세스로 완전히 대체합니다.

엔터프라이즈 측면은 감사 로깅입니다. 자격 증명 스터핑을 나타낼 수 있는 실패 시도를 포함하여 모든 비밀번호 시도가 기록됩니다. SOC 2 및 ISO 27001 증거에 그 기록이 중요합니다.

Tresorit Send: 비밀번호 파생 암호화 키

Tresorit Send는 암호학적 접근 방식을 취합니다. 비밀번호를 설정하면 Tresorit은 PBKDF2를 통해 이미 암호화된 파일 위에 추가 암호화 레이어를 파생합니다. 비밀번호 없이는 Tresorit조차도 파일을 복호화할 수 없습니다. 회사는 스위스에 기반하며 ISO 27001 인증을 보유하고 암호학 백서를 공시합니다.

사용자에게 보이는 동작은 WeTransfer와 유사합니다. 비밀번호를 입력하고 공유합니다. 그러나 수학은 근본적으로 다릅니다. Tresorit에서의 데이터베이스 침해는 복구 가능한 파일이 아닌 암호문과 솔트를 노출합니다.

HexaTransfer: URL 프래그먼트 키와 선택적 비밀번호 래핑

HexaTransfer의 기본 모델은 URL 프래그먼트(# 뒤)에 임베드된 256비트 랜덤 키를 사용합니다. 브라우저는 이를 서버에 전송하지 않습니다. 그 키는 다운로드 후 클라이언트 측에서 AES-256-GCM 암호문을 복호화합니다. 비밀번호를 추가하면 PBKDF2(60만 회 반복)가 랜덤 키를 래핑하여 비밀번호로 언래핑해야 합니다.

이 계층화된 접근 방식은 세 가지가 복호화에 맞아야 함을 의미합니다: 암호문(서버에서), URL 프래그먼트(링크에서), 비밀번호(별도 채널에서). 하나만 가로채서는 아무것도 얻지 못합니다. Firefox Send가 탐구하고 현대 프라이버시 중심 서비스가 정제한 모델입니다.

비교 매트릭스

| 서비스 | 비밀번호 유형 | KDF | 최소 강도 | 속도 제한 | |---|---|---|---|---| | WeTransfer Pro | 서버 게이트 | 없음 | 미적용 | 미문서화 | | Smash | 서버 게이트 + 이메일 | 없음 | 선택적 정책 | 있음 | | SwissTransfer | 서버 게이트 | 없음 | 미적용 | 있음 | | Dropbox Transfer | 서버 게이트 + SSO | 없음 | 관리자 설정 | 있음 | | Tresorit Send | 암호 KDF | PBKDF2 | 8자+ | 있음 | | HexaTransfer | 암호 KDF | PBKDF2 60만 | 적용됨 | 있음 |

비밀번호 강도와 엔트로피 문제

파일 전송을 위한 "강한 비밀번호"는 최소 70비트 엔트로피를 목표로 해야 합니다. 대형 사전에서 랜덤한 단어 네 개(다이스웨어 방식) 또는 12자 이상의 랜덤 문자입니다. 60만 회 반복하는 PBKDF2는 오프라인 공격에 대해 약 20비트의 유효 엔트로피를 추가하여 적당히 강한 비밀번호를 진정으로 크래킹하기 어렵게 만듭니다.

취약한 고리는 보통 전달입니다. SMS로 링크와 같은 전화번호에 비밀번호를 보내면 의미가 없습니다. 별도 채널을 사용하세요. Signal로 링크를, 전화로 비밀번호를, 또는 반대로. B2B 전송의 경우 기존 화상 통화 중에 비밀번호를 조율하세요.

비밀번호만으로는 부족한 경우

진정으로 민감한 전송—금융 M&A 문서, 소스 코드, 의료 기록—의 경우 비밀번호 보호에 수신자 이메일 인증, 짧은 만료(24시간), 다운로드 알림을 결합하는 것을 고려하세요. GDPR, HIPAA, 개인정보 보호법(PIPA)의 적용을 받는 맥락에서는 특히 그렇습니다. 비밀번호 보호는 유용한 추가 레이어이지 완전한 액세스 제어 시스템이 아닙니다. 비밀번호 필드가 있다고 해서 서비스 자체가 파일을 읽을 수 없다고 가정하지 마세요. 종종 여전히 읽을 수 있습니다.

hexatransfer.com에서 사용해 보세요 — 무료, 계정 불필요, 최대 10GB.