보안이란…

전산보안에서 가장 큰 취약점은 포스트잇에 적어 모니터에 붙여놓은 패스워드.

가끔 보면,

1) “반드시 N자리의 숫자로 패스워드를 구성”하라거나,
 : 보통 4자리 숫자 패스워드는 익숙하지만, 갑자기 7자리 숫자로 입력라고 하면 패스워드 만들어내는 게 고역이 된다. 7자리라는 숫자단위는 자주 사용되지 않는 단위라서 만들어내기도 어색하고 기억하기에도 어색하다. 차라리 자릿수 제한을 없애고 X자리 이상이라는 조건만 둔다면, 개인에 따라 각자 자신이 기억하기에 편리한 자릿수로 결정할 수 있을텐데…

2) “반드시 숫자나 특수기호를 하나 포함하여…”
사전 대입법을 이용한 해킹시도에 대한 방어법이긴 한데, 이렇게 하면 대개의 경우 그냥 숫자 0을 덧붙이거나 ! 정도를 덧붙이기 마련이다. 즉 “lullaby”라는 패스워드가 사전대입법에 취약해서 안된다고 하면 대부분의 사용자는 그냥 “lullaby0″이라는 패스워드를 만들고 만다. 기존 해킹방법에 비해 2배(대부분 0을 붙이고 마니까)~10배(고작해야 한자리 숫자만 더 붙이고 나니까.) 정도의 시간만 더 투자하면 뚫리게 된다는 소리. 물론 “jx7d%Q#~” 같은 패스워드를 만드는 사람도 있고 이런 경우 안전하지 않겠냐 하겠지만(저걸 기억할 수 있는 사람이 있다는 가정하에), 해커입장에서는 “lullaby0” 형태의 패스워드가 더 많으니 대략 마지막에 숫자 한자리 붙여서 시도해보고 안되면 다른 계정에 대해 시도해보면 그만이다. 결국 시스템의 해킹가능성에 대해서 열려있다는 점에는 변함없다.
아예 원천적으로 패스워드 오류시 재입력 횟수 제한(패스워드 5회이상 틀릴 시 계정 블록)을 두는 쪽이 사용자에게도 편하고 또 보안에 대한 경각심을 불러일으킬 수도 있다. 내 계정이 블록당했다면(혹은 블록위험이 있다면), 최소한 해킹시도가 있었음을 알게 될테니까.

다 떠나서, 각각의 서비스 단위에서는 나름 안전한 해킹방어를 한다쳐도, 대부분의 사람들이 여러 서비스에 대해 같은 패스워드를 쓰는 마당에 어떤 한 서비스만 뚫리면 다른 서비스에도 무방비가 되는 셈.

전산보안은 풀리지 않는 숙제…