사용자가 설정하는 암호를 입력받을때, 걸러내야 할 특수기호?
글쓴이: cococo / 작성시간: 화, 2014/02/25 - 3:44오후
안녕하십니까. 해당 문제가 발생하여 질문 드려 봅니다.
상황은 별거 없습니다. 사용자가 가입하면 ID 와 PWD 를 입력받아 DB에 넣는 건데, 넣기 전에 client 단에서 체크를 해 주려는 거죠.
근데, 이게... 좀 미묘하더군요.
ID 라면 사람들에게 "영어, 숫자만 입력해" 라고 해도 납득을 해 주는데,
PWD 를 영어 + 숫자'만' 입력받게 하면 ... 과히 좋지 않죠.
하지만 필터링의 편리함을 생각하면 특수기호 따위는 싸그리 빼버리고 싶고...
그리하여, 일단 내부적으로는
'-'(하이픈)
';' (세미콜론)
'|' ( OR )
'\'' ( 작은 따옴표 )
'`' ( 작은 따옴표? )
만 빼려고 합니다만...
이거면 될까요? 뭐 더 필요한 게 있을까요?
비슷한 고민을 하신 분들이 많을 것 같은데, 의외로 질문 / 답변 내용이 없어서 글 올려 봅니다.
이상입니다. 모두들 좋은 하루 되시기 바랍니다.
Forums:
DB에 암호를 평문으로 저장하시려고요?
DB에 암호를 평문으로 저장하시려고요?
SQL injection 공격이 걱정이신거
SQL injection 공격이 걱정이신거 같은데,
굳이 입력하는 문자에 제한을 두지 않더라도
프로그래머가 서버 쪽에서 전처리 후처리만 잘해주면 됩니다.
클라이언트 쪽에서 자바스크립트 등으로 걸러내는건
사용자의 편의를 위해서라면 몰라도 보안상으로는 아무런 의미가 없습니다.
wget 같은 간단한 툴로도 원하는 문자열의 query 보내는건 전혀 어렵지 않기 때문입니다.
따라서 반드시 서버 쪽에서 SQL Query 만드는 단계에서 하고 넘어가야 합니다.
php 기준으로라면...
http://kr1.php.net/addslashes
http://kr1.php.net/manual/en/mysqli.real-escape-string.php
http://kr1.php.net/manual/en/function.pg-escape-string.php
특수문자 escape를 위해 각자 용도에 맞는 함수들이 다 있으므로 있는거 쓰시면 됩니다.
길이 늘어나도 상관 없으시면 아예 무식하게 convert_uuencode나 base64_encode 를 쓰는 방법도 있습니다.
이 과정에서 특수문자는 다 걸러집니다.
직접 사용가능한 특수문자 종류를 고르고 encode/decode 함수를 만드시는 것도 좋은데
대신 프로그래머가 꾸준히 관리하고 유지해야 할 정보가 늘어나기 때문에 추천하진 않습니다.
기존에 비슷한 기능이나 포맷이 있다면 활용해 주는게 좋겠지요.
패스워드 용도라면 어차피 crypt 같은거 쓰실텐데 이걸로도 대부분의 특수문자는 다 걸러집니다.
답변은 아니지만..
웹사이트를 이용하면서 굉장히 번거로운 것들중 하나가 사이트별로 이 제약점이 다 다르다는 겁니다. 특히 자릿수 제한과 특수문자 제한이 제일 번거롭습니다. 제한 방식 자체도 제각각이라 자릿수나 특수문자 면에서 완전히 exclusive한 곳마저 있고.. 물론 동일 패스워드를 돌려먹기하는 것은 아니지만 어쨌든 사이트별로 제각각인 제한조건은 암호 기억에 굉장한 방해가 됩니다. 그래서 특이한 제약조건을 가진 사이트는 아예 이용을 안하게 되기까지 하네요.
가급적 보안성을 떨어뜨리는 방향의 제약조건은 적었으면 좋겠습니다. 예를 들어 일정 글자 이상의 길이를 요구한다든지 숫자나 특수문자를 꼭 요구한다든지 이런건 단순한 암호의 생성을 막으므로 보안상 좋은 것이니 괜찮은데, 반대로 최대 설정가능한 암호의 길이제약이 심하다든지 일부 특수문자를 아예 쓰지 못하게 한다든지 이런 게 제일 불편합니다. 보안상으로도 도움이 안 되고 말이죠.
그리고 참고로 제안하신 특수문자들의 일부는 세벌식 자판에서 한글 입력에 사용되는 글쇠들입니다. 따라서 세벌식 한글 단어로 암호를 설정하시는 분들은 큰 불편함을 갖게 될 걸로 보입니다.
--
...
위에 달린 댓글들에 동의하면서,
암호를 저장하는데 특정 문자를 제거해야 개발이 편해진다면, 암호를 받아서 처리하는 로직에 뭔가 근본적으로 문제가 있는 게 아닌가에 한표 던집니다.
댓글 달기