사고 & 취약점
Takufile-bin 정보 유출 사건(2019) — 비밀번호 평문 보관은 왜 치명적인가, 해싱이라는 방어
2019년 1월, 파일 전송 서비스 Takufile-bin(Ogis-Research Institute)이 부정 접근을 당해 탈퇴자를 포함한 약 481만 건의 개인정보가 유출됐습니다. 결정적이었던 것은 유출된 로그인 비밀번호가 암호화되지 않은 '평문'으로 보관돼 있었다는 점. 공격 절차가 아니라 당신의 서비스에서 비밀번호를 어떻게 안전하게 보관할지를 공개 기록의 사실에만 근거해 해설합니다.
실제로 일어난 공개 사고를, 뉴스의 재방송이 아니라 "당신의 환경에서 어떻게 막을 것인가" 의 관점으로 읽어냅니다. 본 글은 공개 기록(기업 공식·보도)에 근거한 해설입니다. 출처는 말미에 명기하며, 공격 재현 절차는 다루지 않습니다.
- 대상
- 파일 전송 서비스 "Takufile-bin"의 이용자 정보(운영: Ogis-Research Institute)
- 발각
- 2019년 1월 22〜25일(수상한 파일을 탐지→정지→공표)
- 수법 분류
- 서버의 취약점을 찌른 부정 접근 → 고객 정보의 절취(로그인 비밀번호가 평문 보관)
- 영향 규모
- 약 481만 건(이름·이메일·로그인 비밀번호·생년월일·성별 등/탈퇴 완료 고객 포함)
- 근본 원인
- 비밀번호를 평문(되돌릴 수 있는 형태)으로 보관 + 서버의 취약점 + 탈퇴자를 포함한 불필요 데이터의 보유
- 본질적 대책
- 단방향 해시+솔트(bcrypt/Argon2id)/불필요 데이터를 갖지 않기·보유 기간의 최소화/취약점 관리/재사용에 대한 대비(2FA)
무엇이 일어났는가(쉽게)
서비스는 이용자의 비밀번호를 맡습니다. 문제는 그 맡는 방식 입니다. 비밀번호를 평문(그대로 읽을 수 있는 형태)이나, 키로 되돌릴 수 있는 암호화 로만 보관하면, 데이터가 유출된 순간 내용이 그대로 쓰여 버립니다.
Takufile-bin에서는 서버의 취약점을 찔려 부정 접근이 일어났고, 고객 정보가 유출됐습니다. 그리고 후속 보고에서, 유출된 로그인 비밀번호가 암호화돼 있지 않았다(평문이었다) 는 사실이 공표됐습니다. 많은 사람이 같은 비밀번호를 여러 서비스에서 재사용 하기 때문에, 평문 그대로 유출되면 공격자는 그것을 다른 서비스에서 시도해 계정 탈취 에 쓸 수 있습니다. 침입 그 자체보다, 평문 보관이 피해를 단숨에 넓힌 것이 본질입니다.
'암호화'와 '해싱'은 다른 것
비밀번호 보관에서 흔한 오해가, 암호화하면 안전하다는 착각입니다. 암호화는 키가 있으면 되돌릴 수 있어서, 키까지 함께 유출되면 평문과 다르지 않습니다. 올바른 방식은, 되돌릴 수 없는 단방향 해싱에, 사용자별 솔트를 더하고, 의도적으로 느린 알고리즘(bcrypt / Argon2id)을 쓰는 것입니다. 로그인 시에는 입력을 같은 절차로 해싱해 대조하므로, 평문을 보관할 필요가 애초에 없습니다.
공격의 연쇄는 '방어의 지도'이기도 하다
이 사건도, 각 단계마다 멈출 곳이 있었던 연쇄였습니다. 공격 절차가 아니라, 어디서 끊어낼 수 있었는가 로 읽어 주세요.
① 서버의 취약점을 찔려 부정 접근
알려진 약점을 방치하면 침입의 입구가 된다.
⊘ 멈출 곳: 취약점 관리·패치 운용·공격 대상 영역의 최소화
② 고객 정보와 로그인 비밀번호를 취득
탈퇴자를 포함한 대량의 데이터를 보유하고 있었다.
⊘ 멈출 곳: 애초에 불필요한 데이터를 갖지 않기·보유 기간을 최소화
③ 비밀번호가 평문=즉시 악용 가능
암호화돼 있지 않아, 유출된 순간 그대로 쓸 수 있었다.
⊘ 멈출 곳: 단방향 해시+솔트(bcrypt/Argon2id)=유출돼도 직접 쓸 수 없다
④ 재사용된 곳에서의 2차 피해(계정 탈취)
같은 비밀번호를 쓰는 다른 서비스가 노려진다.
⊘ 멈출 곳: 재사용을 그만두기·2단계 인증·유출 시의 신속한 강제 리셋
공표된 시계열
2019-01-22
회사가 인식하지 못한 파일이 서버 내에 생성돼 있는 것을 탐지(부정 접근의 징후).2019-01-23
안전 확인을 위해 서비스를 정지.2019-01-25
부정 접근과 정보 유출을 공표(탈퇴자를 포함한 약 481만 건).2019-01-30
상세 후속 보고. 유출된 로그인 비밀번호는 암호화돼 있지 않았다(평문)고 공표.2019-03
외부 전문 사업자의 상세 조사 결과를 보고. 당분간의 서비스 휴지를 계속.2020-01-14
서비스의 종료를 발표(안전한 재구축에 드는 비용·시간을 고려). 같은 해 서비스 종료.
근본 원인은 '침입당한 것'만이 아니다
이 사건을 '부정 접근을 당했다'로 정리하면, 요점을 놓칩니다. 침입은 일어날 수 있다는 전제로, 유출돼도 피해를 최소화하는 보관 이 돼 있었는가가 본질입니다.
무너져 있던 구성(사건 당시)
- 로그인 비밀번호를 평문으로 보관(유출되면 즉시 악용)
- 탈퇴자를 포함한 대량의 데이터를 계속 보유하고 있었다
- 서버의 취약점이 침입의 입구가 됐다
- 유출 시에 재사용된 곳에서의 계정 탈취를 멈추기 어렵다
지켜진 구성(재발 방지)
- 비밀번호는 단방향 해시+솔트(bcrypt/Argon2id)로 보관
- 불필요한 데이터를 갖지 않기·보유 기간을 최소화(탈퇴 후에는 삭제)
- 취약점 관리·패치 운용으로 침입의 입구를 막는다
- 2단계 인증과 유출 시의 신속한 강제 리셋으로 2차 피해를 억제한다
사후의 대가는, 사전의 설계 투자보다 훨씬 크다
Takufile-bin은 당분간의 휴지를 거쳐, 최종적으로 서비스 자체를 종료 했습니다(안전한 재구축에 드는 비용·시간을 고려). 비밀번호를 올바르게 해싱해 두는 비용은 작은 반면, 평문 보관이 초래하는 신뢰의 실추·이탈·2차 피해의 비용은 훨씬 크게 듭니다. 비밀번호의 보관 방식은, 만들 때 올바르게 설계해 두는 것이 본질입니다.
당신의 환경에서의 재발 방지
이용자의 비밀번호를 한 건이라도 맡는다면 내 일입니다. 우선순위 순의 대책입니다.
비밀번호는 단방향 해시+솔트로 보관한다
평문이나 '되돌릴 수 있는 암호화'로 보관하지 않는다. 단방향 해시에, 사용자별 솔트를 더하고, bcrypt나 Argon2id처럼 의도적으로 느린 알고리즘을 쓴다. 자세히는 비밀번호를 안전하게 저장하는 법을 참조.
애초에 불필요한 데이터를 갖지 않는다
모으는 항목을 필요 최소한으로 하고, 탈퇴·불필요해진 데이터는 삭제한다. 보유하지 않은 데이터는 유출되지 않는다. 탈퇴자의 정보까지 끌어안지 않는다.
취약점을 막고, 침입의 입구를 줄인다
서버·라이브러리의 취약점을 관리해 패치를 적용하고, 공개 범위·공격 대상 영역을 최소화한다. 침입은 일어날 수 있다는 전제로, 입구를 줄여 둔다.
유출돼도 피해를 넓히지 않는 대비(2FA·재사용 대책)
2단계 인증을 마련하고, 유출 시에는 신속하게 강제 리셋한다. 사용자에게는 재사용을 그만두는 동선을 제시한다. 해싱과 함께, 유출돼도 직접은 쓸 수 없는 상태를 만든다.
본 사이트의 설계 사상과 겹치는 점
이 사건의 본질은, 비밀번호라는 가장 중요한 비밀을, 유출되면 그대로 쓸 수 있는 형태(평문)로 보관하고 있었다 는 점입니다. 본 사이트 자신의 원칙——비밀은 되돌릴 수 없는 형태로 다루기·불필요한 것은 갖지 않기·폭발 반경을 최소화하기——와 꼭 뒤집힌 관계에 있습니다. "암호화했으니 안전하다"는 착각은 위험하며, 비밀번호는 단방향 해시+솔트 가 정답입니다. "평문을 갖지 않기·불필요 데이터를 갖지 않기·유출돼도 쓸 수 없는 형태로 만들기"는, 규모를 불문하고 누구나 구현할 수 있는 방어입니다.
출처(공개 기록)
본 글의 사실은, 아래의 공개 정보에 근거합니다. 공격 재현 절차는 다루지 않고, 방어의 교훈에 집중합니다.
- Ogis-Research Institute 공식 발표("Takufile-bin" 서비스에서의 부정 접근에 대하여/사과와 보고, 2019〜2020) — ogis-ri.co.jp
- 각종 보도(서비스 휴지·상세 조사 결과·서비스 종료의 공표, 2019〜2020) — 일차 발표에 근거한 보도
다음에 읽기
- 실무: 비밀번호를 안전하게 저장하는 법(해싱과 솔트)
- 용어: 비밀번호 해싱이란 / 솔트란
- 용어: 2단계 인증(2FA)이란(유출돼도 직접 쓸 수 없게 하는 대비)/ 실무: 보안 베이스라인 체크리스트
FAQ
QTakufile-bin 사건에서 가장 중대했던 문제는 무엇인가요?
유출된 로그인 비밀번호가 암호화되지 않은 '평문'으로 보관돼 있었다는 점입니다. 계기는 서버의 취약점을 찔린 부정 접근이지만, 비밀번호가 평문이었기 때문에 유출된 순간 그대로 악용할 수 있는 상태였습니다. 비밀번호를 되돌릴 수 없는 단방향 해시(+솔트)로 보관했더라면, 설령 유출되더라도 직접은 쓸 수 없어 피해를 크게 줄일 수 있었습니다.
Q비밀번호는 '암호화'하면 안전한가요?
'암호화'와 '해싱'은 다른 것입니다. 암호화는 키가 있으면 되돌릴 수 있어서, 키까지 함께 유출되면 평문과 같습니다. 올바른 방식은 되돌릴 수 없는 단방향 <strong>해싱</strong>에, 사용자별 <strong>솔트</strong>를 더하고, bcrypt나 Argon2id처럼 <strong>의도적으로 느린</strong> 알고리즘을 쓰는 것입니다. 로그인 시에는 입력을 같은 절차로 해싱해 대조하므로, 평문을 보관할 필요가 애초에 없습니다.
Q개인 사용자로서 스스로 방어할 수 있는 것이 있나요?
있습니다. ①비밀번호를 서비스마다 재사용하지 않는다(평문으로 유출돼도 다른 서비스로의 2차 피해=계정 탈취를 막을 수 있다) ②비밀번호 관리자로 길고 무작위한 값을 쓴다 ③2단계 인증이나 패스키가 있으면 반드시 활성화한다. 운영 측의 보관이 허술하더라도, 재사용을 그만두는 것만으로 피해의 연쇄를 크게 끊을 수 있습니다.