무슨 일이 있었나
DreamHost는 1990년대 후반부터 운영된 미국 웹 호스팅 업체예요. 워드프레스 공식 사이트의 추천 호스팅 목록에 오래 올라 있었을 만큼 개인 블로그부터 소규모 비즈니스 사이트까지 많이 쓰는 곳이죠.
이 DreamHost가 상태 페이지(dreamhoststatus.com)에 진행 중인 사고(incident)를 공지하면서 사용자들에게 비밀번호 재설정을 요구했어요. 아직 진행 중인 사고라 정확한 원인과 영향 범위는 공식 공지를 계속 지켜봐야 해요. 참고로 DreamHost는 2012년에도 데이터베이스 무단 접근을 감지하고 FTP·셸 비밀번호를 일괄 재설정한 적이 있어요.
DreamHost를 안 쓰더라도 한 번쯤 짚어볼 만한 일이에요. 어떤 호스팅이나 클라우드를 쓰든 언젠가 비슷한 공지를 받을 수 있거든요.
비밀번호를 ‘강제로’ 바꾸게 한다는 건 무슨 뜻일까
업체가 비밀번호 재설정을 강제하는 이유는 보통 몇 가지예요.
먼저 비밀번호 해시가 노출됐을 가능성이 있어요. 해시는 비밀번호를 원래대로 되돌릴 수 없게 바꿔놓은 값이에요. 제대로 된 서비스는 비밀번호 원문 대신 이 값만 저장해요. bcrypt나 Argon2 같은 느린 해시 알고리즘에 솔트(사용자마다 다른 랜덤 값)를 섞으면 풀기가 아주 어려워지지만, ‘password123’ 같은 약한 비밀번호는 추측으로 결국 뚫려요.
세션이나 인증 시스템 자체가 침해됐을 가능성도 있어요. 이 경우엔 모든 로그인 상태를 끊고 새로 인증하게 해야 해요. 뚜렷한 증거는 없지만 예방 차원에서 하는 경우도 있고요.
어느 쪽이든 메시지는 같아요. 업체가 “기존 비밀번호는 더 이상 믿을 수 없다”고 판단한 거예요. 사용자는 최악을 가정하고 움직이는 게 맞아요.
제일 무서운 건 크리덴셜 스터핑이에요. 한 곳에서 새어 나간 아이디·비밀번호 조합을 다른 사이트에 자동으로 넣어보는 공격이에요. 호스팅 비밀번호를 이메일이나 깃허브에도 똑같이 썼다면 피해가 호스팅 계정에서 끝나지 않아요.
비밀번호만 바꾸면 끝? 아니에요
호스팅 계정은 사실상 서버 열쇠 꾸러미예요. 열쇠 하나가 의심스러우면 꾸러미 전체를 점검해야 해요.
1. 계정 비밀번호 변경 + 2단계 인증: 문자 인증보다 OTP 앱이나 패스키가 안전해요.
2. 같은 비밀번호를 쓴 다른 서비스: 전부 바꾸세요. 이참에 비밀번호 관리자를 쓰는 걸 추천해요.
3. SFTP·SSH 접근: 비밀번호를 바꾸고, ~/.ssh/authorized_keys에 모르는 공개키가 추가되지 않았는지 확인하세요.
4. 데이터베이스 비밀번호: 바꾼 뒤 wp-config.php나 .env 같은 설정 파일도 함께 고쳐야 사이트가 안 멈춰요.
5. 서버에 저장된 외부 서비스 키: 결제, 메일 발송, 클라우드 스토리지 API 키도 로테이션하세요. 새 키를 발급하고 옛 키를 폐기하는 걸 로테이션이라고 해요.
6. DNS와 도메인: A 레코드, MX 레코드(메일을 어디서 받을지 정하는 설정), 네임서버가 바뀌지 않았는지 보고 도메인 이전 잠금도 켜두세요.
7. 최근 변경 흔적: find ~ -type f -mtime -7로 최근 7일 안에 바뀐 파일을 훑고, crontab -l로 낯선 예약 작업이 없는지 보세요. 워드프레스라면 모르는 관리자 계정이나 플러그인이 생기지 않았는지도 확인하고요.
8. 피싱 주의: 사고 소식을 틈탄 “비밀번호를 재설정하세요” 가짜 메일이 꼭 돌아요. 메일 속 링크 대신 주소창에 직접 입력해서 들어가세요.
업계 맥락: 요즘 사고는 ‘계정’에서 시작돼요
최근 몇 년 동안의 큰 사고들을 보면 공통점이 있어요. 2022년 LastPass는 개발 환경이 뚫린 뒤 암호화된 사용자 금고 백업이 유출됐고, 2023년 Okta는 고객지원 시스템이 침해당했어요. 2024년 Snowflake 고객사 연쇄 유출은 2단계 인증이 꺼진 계정에 탈취된 비밀번호로 로그인하면서 시작됐고요. 영화 같은 해킹보다 인증 정보 관리 실패가 훨씬 흔한 출발점이에요.
공동 책임 모델(Shared Responsibility Model)도 알아두면 좋아요. 업체는 인프라를 책임지고, 고객은 계정·애플리케이션·데이터를 책임진다는 원칙이에요. 업체에 사고가 나도 내 쪽에서 피해를 줄일 수 있는 부분이 꽤 많다는 뜻이죠.
한국 개발자에게 주는 시사점
국내에서도 카페24, 가비아 같은 국내 호스팅과 해외 호스팅을 섞어 쓰는 경우가 많아요. 고객사 사이트 여러 개를 관리하는 프리랜서나 에이전시라면 사고가 났을 때 어디부터 손대야 할지 막막해지기 쉽고요.
평소에 해두면 좋은 일은 세 가지예요. 비밀 정보를 비밀번호 관리자나 팀 볼트 한곳에 모아두고, 키 로테이션을 미리 한 번씩 연습해두고, 사고 때 그대로 따라 할 한 장짜리 대응 문서(런북)를 만들어두는 거예요. 개인정보를 다루는 서비스라면 법적 의무도 챙겨야 해요. 개인정보 보호법은 유출 사실을 안 날부터 72시간 안에 정보주체에게 알리고, 일정 규모 이상이면 당국에도 신고하게 하고 있거든요.
마무리
비밀번호 강제 재설정 공지는 끝이 아니라 점검을 시작하라는 신호예요.
API 키나 DB 비밀번호를 실제로 로테이션해 본 적 있나요? 팀에서는 비밀 정보를 어떻게 관리하고 계신지도 궁금해요.
🔗 출처: Hacker News