Hacker News 의견

• 관리자의 요청으로 특정 문자열을 넣었다는 한 개발자의 이야기. 해당 사이트는 비밀번호를 저장하지 않으며, 외부 계정 관리에 대한 인터페이스를 제공함. 레거시 앱에서 특정 문자열을 포함한 비밀번호로 로그인할 수 없는 이상한 검증이 있을 수 있다는 소문이 있지만, 구체적인 예는 알지 못함.

• 어린 시절 큰 소셜 플랫폼을 해킹한 경험담. 금지된 단어를 단순히 제거하는 방식을 이용해 유효한 HTML 태그를 주입하고, 페이지를 방문하는 사람들을 제어함.

• 일부 경우에는 이러한 요구사항이 좋은 아이디어라고 생각하는 의견. 많은 사람들이 나쁜 코드와 시스템 아키텍처를 작성하고 있으며, 이를 잡아내고 변화를 강제할 수 있는 충분한 역량, 조직적 권한, 시간을 가진 사람이 부족함. 미국에서는 형편없이 코딩된 웹사이트를 통해 비즈니스를 해야 할 수도 있음. 이 경우, 구현이 흔히 그렇듯이 끔찍할 수 있다고 가정하고, 그에 따른 완화책을 권장하는 것이 더 나을 수 있음.

• SQL 인젝션을 완전히 방지하기 위한 적절한 저장 프로시저와 기술을 사용하는 대신, 몇 가지 키워드를 제한하고 해커들이 생각하지 못한 무언가를 만들어내지 않기를 바라는 접근 방식에 대한 비판. 2005년도 아니고, 사용자 입력이 SQL과 섞이지 않도록 하는 것은 더 이상 로켓 과학이 아님. 비밀번호를 암호화하지 않고 저장하는 것은 2005년에도 어리석은 일이었음.

• truncate를 대신 사용하겠다는 댓글.

• 오래된 시스템에서 유래된 것 같다는 의견. 일부 대학과 은행이 중앙 인증을 위해 오래된 메인프레임 시스템을 사용하고 있으며, 비밀번호를 평문으로 저장하고 8자리, 대문자로만 제한하는 경우가 있음. 시스템을 업그레이드하지 않는 주된 이유는 비용과 복잡성 때문임.

• 금지된 문자열을 모두 확인하지 않는다는 학생의 경험담.

• 작업 중에 이러한 요구사항을 만들어야 했다는 한 사람의 이야기. 모든 문자열을 적절히 이스케이프하고, SQL 인젝션 공격을 피하기 위해 파라미터화된 쿼리를 사용해야 하지만, 깊이 있는 방어를 위해 SQL이나 HTML처럼 보이는 코드를 모든 필드에서 거부해야 함.

• 자신의 비밀번호가 절대 잡히지 않을 것이라는 자신감 있는 댓글.

• 이러한 요구사항이 지나치게 열성적인 WAF(웹 애플리케이션 방화벽)에서 비롯되었을 수 있다는 낙관적인 추측.