개발자 도구 · Base64 인코더 및 디코더
Base64는 암호화되지 않습니다. 인코딩된 비밀을 누구나 읽을 수 있는 이유
· 그것이 중요한 이유
베이스64 보안 인코딩
Base64는 아무것도 숨기지 않습니다. 문자열이 있는 사람은 누구나 키 없이 즉시 디코딩할 수 있습니다. 이 게시물에서는 인코딩, 암호화, 해싱의 차이점과 저장소에서 Base64 비밀을 찾을 때 수행할 작업에 대해 설명합니다.
데이터베이스 비밀번호로 뒤섞이고 디코딩된 것처럼 보이는 구성 값 - 구체적인 발견 및 되돌리는 속도
구성 파일에서 Base64를 찾으면 잘못된 안전감을 갖게 됩니다. 개발자는 dGlnZXJfZGF0YWJhc2VfYWRtaW4와 같이 뒤섞인 시퀀스로 나타나는 데이터베이스 비밀번호를 발견하고 암호화된 것으로 가정하고 이를 애플리케이션 코드와 함께 저장소에 커밋합니다. 몇 주 후 보안 검토를 통해 실제 일반 텍스트인 Tiger_database_admin이 드러났습니다.
Base64는 아무것도 숨기지 않습니다. 암호화가 아니라 인코딩입니다. 반전된 동일한 비밀번호는 키나 계산, 지연 없이 브라우저에서 즉시 다시 원시 상태가 됩니다. 이 게시물에서는 인코딩이 존재하는 이유, 암호화 및 해싱과 근본적으로 다른 점, 커밋된 기록에서 Base64 비밀을 발견하면 실제로 어떤 일이 발생하는지 설명합니다.
인코딩, 암호화 및 해싱: 세 가지 다른 작업 — 각각 보장하는 것과 키가 필요한 작업
Base64가 보호처럼 보이기 때문에 혼란이 발생합니다. 인간은 dGlnZXJfZGF0YWJhc2VfYWRtaW4를 보고 Tiger_database_admin을 읽을 수 없습니다. 디코더를 통해 실행할 때까지 가려진 것처럼 보입니다. 표면 수준의 난독화는 보안처럼 느껴지지만 그렇지 않습니다. Base64는 텍스트 전용 채널을 통해 임의의 바이너리 데이터를 이동하는 다른 문제를 완전히 해결하도록 설계되었습니다. 이메일, 이전 웹 양식 및 회선 프로토콜 시스템은 원시 바이트를 전달할 수 없습니다. Base64는 바이트를 인쇄 가능한 ASCII 문자로 변환하므로 데이터가 해당 채널을 그대로 통과할 수 있습니다.
데이터가 도착하면 수신자는 이를 다시 바이트로 디코딩했습니다. 인코딩과 디코딩은 똑같이 간단합니다. 키, 엔트로피, 암호화 라이브러리가 필요하지 않습니다. 인코딩, 암호화 및 해싱은 세 가지 별도의 목적으로 사용되며 세 가지 다른 보장을 제공합니다. 인코딩은 데이터를 다른 표현으로 변환하여 특정 채널을 통과하거나 특정 컨텍스트에서 사용될 수 있도록 합니다. Base64, URL 인코딩, 16진수 표현 및 JSON의 이스케이프 따옴표도 모두 인코딩입니다. 누구든지 되돌릴 수 있으며 비밀 키가 필요하지 않습니다.
Base64가 존재하는 이유 — 텍스트 채널을 통한 안전한 바이트 전송, 절대 기밀 유지
목표는 기밀성이 아닌 형식 호환성입니다. 이와 대조적으로 암호화에는 승인된 당사자에게만 알려진 키가 필요합니다. 올바른 키를 가진 사람만이 암호문을 일반 텍스트로 되돌릴 수 있습니다. 키가 없으면 메시지를 공격할 만큼 정교한 사람에게도 메시지가 불투명하게 유지됩니다. 해싱은 단방향으로 설계되었습니다. 즉, 비밀번호의 암호화 해시는 전혀 되돌릴 수 없습니다. 비밀번호 자체를 저장하지 않고 비밀번호가 저장된 해시와 일치하는지 확인하는 데 사용됩니다.
base64를 포함하는 Database-password라는 Kubernetes 비밀: dGlnZXJfZGF0YWJhc2VfYWRtaW4는 실제로 비밀이 아닙니다. Base64는 Kubernetes가 보호가 아닌 저장을 위해 사용하는 기본 인코딩입니다. YAML 또는 etcd 데이터베이스에 액세스할 수 있는 사람은 누구나 몇 초 만에 값을 디코딩할 수 있습니다. 시작 스크립트에 base64로 인코딩된 API 키가 있는 환경 변수는 동일한 문제에 직면합니다. Authorization: Basic base64_username:password를 서버로 보내는 기본 인증 헤더는 클라이언트와 서버 사이의 프록시, 모니터링 도구 또는 네트워크 관찰자에 의해 디코딩될 수 있습니다.
작업된 예: 브라우저에서 '비밀' 문자열 디코딩 - 서버가 포함되지 않은 붙여넣기, 디코딩 및 일반 텍스트
채널이 HTTPS가 아닌 HTTP인 경우 노출이 더욱 커집니다. 이러한 맥락에서 Base64는 청어입니다. 실제 비밀은 복구 가능한 형태로 저장되거나 전송되어 이미 손상되었습니다. 실제 사례는 문제를 구체적으로 만듭니다. 타사 서비스에 대한 API 키가 구성 파일에 YXBpa2V5XzEyMzQ1Njc4OTAx로 표시된다고 가정해 보겠습니다. 이 문자열을 브라우저의 Base64 인코더 및 디코더에 복사하여 입력 필드에 붙여넣고 디코드를 클릭하세요.
도구는 apikey_1234567890을 반환합니다. 이는 서버에 연결되지 않고 키도 필요하지 않으며 인증도 수행되지 않고 브라우저에서 즉시 발생했습니다. 전체 작업은 1초도 채 걸리지 않습니다. 이제 악의적인 행위자가 공개 GitHub 저장소에서 동일한 키를 발견했다고 가정해 보겠습니다. 그들은 선호하는 도구가 무엇이든 똑같이 쉽게 디코딩하고 이를 사용하여 서비스에 액세스합니다. 문자열이 저장소에 가려져 있거나, 네트워크를 통해 이동하거나, 애플리케이션 로그에 나타나는지 여부는 모든 프로그래밍 언어 및 이와 같은 브라우저 도구에서 사용할 수 있는 간단한 작업을 통해 드러날 수 있습니다.
이 실수가 나타나는 곳 — Kubernetes 비밀, .env 파일, 기본 인증 헤더 및 모바일 앱 리소스
Base64는 너무 흔해서 근접성에 의한 난독화와 연관되기 때문에 실수는 어디에서나 나타납니다. 개발자는 Base64로 인코딩된 데이터를 보고 누군가가 그것이 중요하다고 생각했다고 추론하고 그 형식으로 비밀을 남깁니다. API_KEY=VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0을 포함하는 .env 파일은 하급 엔지니어에게 API_KEY=디코딩에 한 번의 작업이 필요하더라도 실제로는 비밀이 아닙니다. 모바일 애플리케이션은 모든 디컴파일러가 추출하고 디코딩할 수 있는 리소스에 Base64로 인코딩된 토큰을 번들로 묶습니다. 데이터베이스 백업에는 보호되지 않고 검색되는 필드에 Base64로 인코딩된 비밀번호가 포함되어 있습니다.
각각의 경우 누군가가 인코딩을 암호화로 착각하여 읽기에 한 단계가 더 필요한 방식으로 형식이 지정된 일반 텍스트 비밀 아카이브를 만들었습니다. Base64 비밀이 발견되면 수행할 작업은 상황에 따라 다릅니다.
대신 수행할 작업 — 비밀 관리자, 저장 중인 실제 암호화, 이미 커밋된 항목 순환
비밀이 토큰, API 키 또는 비밀번호이고 이미 버전 제어에 커밋된 경우 손상된 것으로 처리합니다. 이를 취소하고 새 것을 생성하고 사용된 모든 장소를 업데이트하십시오. 기록 커밋은 나중에 새 커밋에서 비밀이 제거되더라도 저장소 영구 기록의 일부입니다. 저장소 기록에 액세스할 수 있는 사람은 누구나 이를 찾을 수 있습니다.
Base64로 인코딩된 값에 대한 저장소 검색은 이제 표준 정찰 전술이므로 Base64라는 사실이 이를 비밀로 만들지 않습니다. 진행 중인 작업의 경우 비밀을 Base64로 인코딩하지 말고 보호된다고 가정하세요. 암호화되고 액세스가 제어되며 감사 가능한 값을 저장하는 비밀 관리자를 사용하세요. 애플리케이션 코드 및 구성에는 비밀 자체가 아닌 참조 또는 파생 항목만 저장합니다. 실제 저장 중 암호화는 데이터가 별도로 저장된 키로 암호화되며 해당 키가 없는 사람에게는 쓸모가 없음을 의미합니다.
여기서 다루지 않는 내용 — 암호화 알고리즘 또는 키 관리 설계 선택
중요한 열을 암호화하는 데이터베이스, 하드웨어 보안 모듈의 키로 봉투 암호화를 사용하는 비밀 관리자 또는 사용자 비밀번호에서 암호화 키를 파생하는 비밀번호 관리자는 모두 진정한 기밀성을 제공합니다. 비밀이 생성된 시점의 애플리케이션 수준 암호화는 어디에나 저장되기 전에 더욱 강력합니다. 노출된 비밀을 순환시키면 Base64로 인코딩된 경우에도 오용 기회가 사라집니다. 비밀이 리포지토리에 있는 경우 로그를 확인하여 해당 비밀에 액세스한 시기와 노출 기간 동안 어떤 용도로 사용되었는지 확인하세요.
지속적인 보안을 위해 구성에 저장된 정적 비밀이 아닌 승인 서비스에서 발행된 단기 토큰을 사용하십시오. 한 시간 안에 만료되는 토큰은 손상되더라도 공격자에게 가치가 떨어집니다. 이 기사에서는 암호화 알고리즘, 키 관리 설계 또는 인증 아키텍처 선택에 대해서는 다루지 않습니다. 이는 자체 표준과 장단점이 있는 더 깊은 엔지니어링 질문입니다. 요점은 더 간단합니다. Base64는 이러한 문제를 해결하는 도구 중 하나가 아닙니다. 운송 및 보관을 위한 형식 변환입니다.
요약: Base64를 일반 텍스트로 처리합니다. Base64 인코더 및 디코더가 한 번의 클릭으로 비밀을 탭에서 벗어나지 않고 포인트를 만드는 방법
저장소, 구성 파일 또는 로그에 Base64가 표시되는 것을 보고 데이터가 보호된다는 확신을 갖지 마십시오. 텍스트를 읽을 수 있는 모든 도구는 Base64를 디코딩할 수 있으며 작업은 즉각적이고 결정적입니다. Base64로 인코딩된 문자열을 암호문으로 읽는 것은 흔한 오해이며 실제 비밀을 눈에 띄게 남겨둡니다. 개발자는 프로덕션이나 감사에서 Base64 비밀을 찾은 후에야 이를 깨닫는 경우가 많습니다. 엔지니어가 샘플 문자열을 로컬에서 디코딩하고 원본 일반 텍스트가 즉시 나타나는 것을 보면 새로운 관점이 생깁니다.
도구를 사용하면 인코딩은 암호화가 아니라는 점을 피할 수 없습니다. 일단 구별이 명확해지면 후속 조치가 자동으로 이루어집니다. 코드베이스의 모든 Base64 비밀은 순환되어야 합니다. 비밀이 사용되는 모든 장소를 업데이트해야 합니다. 노출 창을 평가해야 합니다. 미래에는 비밀 관리자와 실제 암호화가 이 역할의 인코딩을 대체해야 합니다. Base64 인코더 및 디코더는 비밀이 브라우저를 떠나지 않고도 반전이 얼마나 빠르고 쉬운지 정확하게 보여줍니다. 이러한 용이함을 실제 보안 태세로 간주하십시오. 즉, 귀하가 즉시 해독할 수 있다면 다른 누구라도 해독할 수 있습니다.