Archive for the ‘보안’ category

금융감독원에 드리는 공개 질의

February 8th, 2010

사방에서 들끓는 원성에 귀를 막고, 규제와 강제의 철권을 휘둘러 대는 금융감독원의 처사는 옳지 못하다고 생각합니다. 공개적으로 질의를 드립니다.

첫째, 공인인증서는 손쉽게 무단 복제되므로 기술적으로도 부인방지 효과를 거둘 수 없다는 사실을 외면하는 이유는 무엇입니까? (아무 공격도 이루어지지 않았을 경우에만 부인방지 효과가 있는 조치가 무슨 의미가 있습니까?)

둘째, 공인인증서에 더하여 보안카드(매 거래마다 다른 번호를 입력하게 하는 조치)를 도입하지 않을 수 없었다는 사실은 공인인증서가 실제로 부인방지 효과도 없고, 공격도 막아내지는 못하는 ‘기술적 군더더기’라는 점을 반증하는데 왜 이 사실을 외면합니까?

셋째, 공인인증서+보안플러그인이 가장 탁월한 기술이라면 강제 규정이 없어도 금융기관이 스스로 선택할 것입니다. 20년 전에 나온 인증서 기술보다 나은 기술은 지구상에 존재하지 않습니까? 더 나은 기술을 선택하지 못하도록 하는 이유는 무엇입니까?

넷째, 법률에도 없고, 세계 어느 나라도 채택하지 않는 공인인증서 ‘사용 강제’ 조항을 금감원이 만든 이유는 무엇입니까? 누구를 위한 것입니까?

다섯째, 스마트폰 전자상거래를 언제까지 막으실 계획이십니까? 무엇을 이루고자 하십니까?

전자금융 감독체제 개선을 위한 제언

January 24th, 2010

최근 불거져나온 “세계 최초 아이폰 백신 소동“은 그저 웃어 넘길 일은 아닙니다. 세계의 기술 트렌드로부터 고립되어 특이한 해법과 미봉책으로 일관해 오던 국내 보안/거래 솔루션 업계의 실상과, 정확한 전문 지식 없이 선정적 보도로 일관해온 국내 일부 기술 매체들의 수준을 드러내 주는 “상징적 사건”입니다.

이 사건을 계기로 그동안의 전자금융 감독 체제가 과연 바람직했었는지를 되짚어 볼 필요가 있습니다. 다음과 같은 기본 원칙들을 다시 한번 음미해 보시면 좋을듯 합니다.

1. 금융, 보험 서비스의 공공성

금융, 보험 서비스는 많은 소비자의 이해 관계에 큰 영향을 미치는 것이므로 규제의 필요성이 분명히 있습니다. 사기업에 불과하므로 시장 논리에 방임해 둘 수 밖에 없다는 주장은 천박한 논리일 뿐 아니라, 금융 보험 서비스의 근본 성격에 대한 몰이해를 노출하는 것입니다. 요컨대, 규제의 필요성 자체는 분명하지만 구체적으로 어떻게, 어느 수준에서 규제하는 것이 옳은지에 대한 고민이 필요할 것입니다.

2. 규제와 자율의 조화

사업자의 단기적/개별적 이익과 공동체의 장기적/거시적 이익이 합치하지 않는 영역에서는 강력한 규제가 필요합니다. 예를 들어, 서브 프라임 모기지와 같이 고 위험/고 수익 사업 아이템의 경우, 개별 사업자의 단기적 이익 추구를 방임할 경우, 전체 시스템의 리스크는 감당하기 어려울 만큼 커지게 됩니다. 눈 앞의 이익 추구는 누구나 원하는 것이므로, 이것을 자율에 맏겨둘 수는 없고 규제를 통하여 전체의 손해 발생을 예방하는 것이 바로 금융감독 당국의 임무라고 생각합니다.

그러나, 사업자의 단기적 이익과 공동체의 장기적 이익이 합치하는 영역에서는 과연 규제의 필요성이 있는지를 좀더 면밀히 검토해야 할 것입니다. 개별적 이해관계와 공동체의 거시적 이해관계가 일치하는 분야에서 함부로 규제의 칼날을 들이댈 경우 개별 사업자에게도 해롭고, 공동체의 전체적 이익마저도 저해할 가능성이 있습니다.

전자금융거래 보안이 바로 이런 부문입니다. 허술한 보안 선택을 하는 사업자는 당장에 자기 자신에게 손해가 돌아옵니다. 전자금융거래법은 전자금융거래 사고가 발생하면 고객의 고의나 중대한 과실을 사업자가 입증하지 못하면 사업자가 배상 책임을 지도록 규정하고 있습니다(제9조). 보안을 강화하고 전자거래를 안전하게 설계하는 것은 개별사업자의 목전의 단기적 이익에도 부합하고, 모든 사업자들과 소비자들의 거시적, 장기적 이익에도 부합하는 것입니다.

요컨대, 전자금융 거래 보안은 규제당국이 개입하지 않더라도, 개별 사업자가 스스로의 단기적 이해관계 때문에라도 사고발생을 줄이고 싶어하는 영역입니다.

3. 규제 과잉의 폐해

규제가 필요 없는 영역에 규제 당국이 개입할 경우, 과잉규제의 폐해가 다음과 같이 나타납니다:

(1) 경쟁이 저하됩니다. 국내 금융기관들은 하나같이 ActiveX 플러그인을 사용한 해법을 똑같이 채택하고 있습니다. 모두들 그저 “금감원이 하라는 대로만 하면 된다”는 태도를 견지하고 있습니다. “이용자PC에 보안프로그램을 설치”하라, “공인인증서를 사용하라”는 등의 경직된 규정을 애초에 두지 않았더라면 국내 금융기관들 중, 적어도 일부는 벌써 ActiveX 플러그인을 걷어내고, 더욱 진전된 보안 해법을 채택하여 사업을 펼치고 있었을 것입니다. 국내의 보안 업계도 미국, 유럽, 이스라엘, 호주 등 세계 유수의 보안 솔루션 사업자들과 경쟁하는데 필요한 기술력 확보를 위한 노력을 기울였을 것입니다. 공인인증서와 ActiveX가 최상의 탁월한 해법이라면 강제 규정이 없더라도, 누가 시키지 않아도, 업계가 스스로 채택하고 있을 것입니다.

(2) 혁신이 저하됩니다. 규제는 사업자에게 부담으로 작용하기도 하지만, 다른 한편으로는 경쟁과 혁신의 고통을 덜어주기도 합니다. 국내 은행들은 모두들 규제 당국을 원망하면서 고만고만한 똑같은 해법으로 현상 유지를 하면서 현재의 시장 구도에 안주하고 있습니다. 겉으로는 불평을 늘어 놓지만, 한편으로는 편안함을 누릴 뿐 아니라, 심지어는 혁신적 뱅킹 사업을 추진하고 준비할 인력 조차 마련하지 않고 있는 실정입니다. 실제로 일부 시중 은행들의 e-business 사업단은 파이어폭스가 무엇인지도 모르는 ‘컴맹 e-business 사업단장님’께서 군림하는 한가한 부서일 뿐입니다. 새로운 어떤 경쟁 사업자가 혁신적 뱅킹 솔루션을 선보이면서 기존의 시장 구도를 뒤흔드는 “피곤한” 사태가 생길 가능성이 봉쇄되어 있기 때문입니다. 최근 선보인 하나N뱅크 앱에 대하여, 가장 큰 불평과 볼멘 소리를 쏟아 낸 자들은 바로 국내 은행들입니다. 편안히 장사해 오고 있는데 왜 피곤하게 만드냐는 것이지요.

(3) 서비스의 질이 저하되고 소비자가 피해를 입게 됩니다. 온국민들이 자기 컴퓨터에 ActiveX를 덕지덕지 설치하긴 했지만, 그래도 그럭저럭 잘해왔지 않느냐? 라고 반문하실지 모르겠습니다. 그러나 바이러스에 감염된 좀비 컴퓨터의 비율이 세계에서 가장 높은 축에 속하는 현 사태는 한마디로 전국민이 입은 막대한 피해입니다. 외국은 계좌이체를 하려면 이틀 사흘이 걸리지 않느냐? 라고 반문하실지 모르겠습니다. 유럽, 호주를 가보십시오. 하다 못해 이웃 일본을 살펴 보십시오. 우물안 개구리가 꿔왔던 자화자찬의 긴 꿈에서 빨리 깨어나지 않으면, 앞으로 제2, 제3의 “세계 최초 아이폰 백신 소동”이 계속 벌어질 것입니다.

실제로 사고를 잘 막아 오긴 했습니까? 이점이 바로 모든 금융소비자들이 궁금하게 여기는 점입니다. 아래 설명드리는 규제 당국의 역할과 개입이 시급하고도 절실히 필요한 분야가 바로 여기입니다.

4. 투명성 제고

각 금융기관별 전자금융 사고 발생 빈도, 발생 규모, 사고의 유형에 대한 정확한 자료가 있습니까? 모두들 사고발생을 조용히 덮고 적당히 무마하고 넘어가려 하고 있습니다. 이것이 과연 누구를 위해서 도움이 됩니까? 지금까지 정말 잘 막아 왔다면, 사고발생 내역을 투명하게, 자랑스럽게 공개하지 못할 이유가 없습니다. 실제로 우려할 만한 수준의 사고가 발생하고 있다면, 더더욱 이 사태를 숨겨서는 안될 것입니다.

각 금융기관이 자발적으로 자신과 관련된 사고거래 내역을 규제 당국에 정직하게 신고하기를 기대할 수는 없습니다. 그러나 이 문제를 훌륭하게 해결하는 손쉬운 방법이 있습니다.

사고거래가 발생하면 피해자(라고 주장하는 소비자)는 해당 금융기관에 항의하거나 소비자 단체에 호소하거나, 그래도 잘 해결되지 않으면 언론사 기자를 어렵게 접촉하여 기사화 시키는 등의 “매우 힘겨운 싸움”을 벌여야 합니다. 거대한 은행과 개인이 1대1로 맞서는 상황에서, 서로 기싸움과 힘겨루기가 벌어지는 현재와 같은 사태는 시급히 교정되어야 합니다.

앞으로는, 전자금융 사고 신고 및 피해 보상 요구 절차를 금융감독원이 일괄 관리할 필요가 있습니다. 금감원이 분쟁에 직접 개입하라는 뜻이 아닙니다. 금융기관의 홈페이지 초기화면에는 전자금융 사고신고/분쟁조정 링크를 제시하도록 하고, 소비자가 이 링크를 누르면, 금융감독원이 운영하는 전자금융사고 통합 신고 페이지로 연결되도록 하십시오. 피해자가 여기에서 사고거래의 상세한 내역을 입력하면, 금융감독원은 그 내용을 파악한 다음 해당 은행에 이첩하고, 분쟁 처리 과정을 모니터하면 될 것입니다.

이 작업은 진작에 금융감독원이 당연히 했어야 할 금융 소비자 권익보호조치의 중요한 내용이라고 생각합니다. 이렇게 수집된 정보를 규제 당국은 적절하고 합리적인 수준에서 투명하게 공개해야 합니다. 그래야 소비자들은 어떤 은행의 해법이 저열한지를 합리적으로 판단하고, 적절한 선택을 할 수 있습니다.

사고거래 발생과 관련된 정보가 제대로 관리되고 투명하게 공개되면, 모든 금융기관은 최선을 다해서 안전한 기술선택을 할 것입니다. 사고거래의 유형이 이렇게 잘 정리되고 분석된다면, 예방 대책을 마련하는 일도 더욱 효과적으로 수행될 수 있을 것입니다. 더이상 금융감독원이 보안기술의 상세한 내용에 대하여 이래라 저래라 지시하고, 명령할 필요도 없습니다. 굳이 외국의 사례를 인용하지 않겠습니다. 이와 유사한 수준의 투명한 정보 공개를 통하여 전자금융서비스의 안전을 합리적으로 관리하는 나라는 이미 있습니다. 그런 나라의 금융감독 당국은 보안기술의 상세한 내용에 대하여 경직된 규정을 들이대지 않습니다.

소비자와 사업자의 합리적 판단을 존중하는 것이야 말로 전자금융 보안을 확보하는 가장 올바른 길입니다. 합리적 판단에 필요한 정확한 정보를 제공하는 일은 바로 규제 당국의 몫입니다.

5. 금융감독원에 거는 기대

최근 발표된 스마트폰 전자금융 보안대책은 종래의 PC 전자금융 보안대책에 비하면 획기적으로 진전된 바람직한 내용을 담고 있다고 생각합니다. 종래와 같이 “이용자PC에 보안프로그램을 설치”하라는 식의 특정기술 편향(플러그인 편향)의 표현도 이제는 사라졌고, “공인인증서를 사용”하라는 식의 경직된 표현 대신에 “전자서명 등”을 사용하라는 보다 유연한 정책 기조를 담고 있습니다.

무엇보다도 “취약점 모니터링 체제”를 도입하겠다는 부분은 훌륭한 정책 선택이라고 생각합니다. 취약점 모니터링은 사고거래의 유형을 분석하는 작업을 당연히 전제하는 것이며, 위에서 제안드린 전자금융 사고 통합신고 체제를 이미 구상하고 계시는 것으로 보입니다. 스마트폰 전자금융 보안대책과 같이 (1) 유연하고 중립적인 보안 기준(입력정보 보호대책, 악성코드 예방대책 등)을 제시하고, (2) 취약점 모니터링을 통하여 각 사업자의 performance 를 합리적 수준에서 투명하게 공개하는 정책 방향은 조만간 PC전자금융 부문에도 동일하게 적용되는 것이 바람직하다고 생각합니다.

과거에 채택된 정책에 대하여는 지속적, 상시적 평가가 이루어져야 함은 당연하고, 그 정책의 미비점이 발견되면 신속히 수정하시는 것이야 말로 현명한 규제 당국의 선택일 것입니다.

전자금융거래와 관련하여 그동안 철저히 외면되었던 소비자의 알권리에 대해서도 이제는 관심을 가지실 때 입니다.

“세계 최초” 아이폰 백신 소동

January 23rd, 2010

지난 1월21일 국내 일부 언론은 정보보호 업체인 NSHC가 안티바이러스 프로그램 개발 업체인 하우리(주)와 공동으로 ‘아이폰 전용 백신 프로그램’을 세계 최초로 개발했다고 보도하였다. 그러나 이 업체가 개발하였다는 프로그램은 앱 스토어에 등록되기는 커녕, 바로 다음날 등록 신청마저 신속히 거부되었다.

아이폰 운영체제의 설계 원리를 이해한다면, ‘아이폰 전용 백신’이라는 개념 자체가 성립되지 않는다는 점을 알 수 있다. 안드로이드 운영 체제와는 달리 아이폰 운영체제는 음악재생을 제외하고는 멀티태스킹(multi-tasking)을 허용하지 않는다. 그뿐 아니라 아이폰의 프로그램 실행환경은 철저히 고립/차단된 sandbox 내부이므로, 어떤 프로그램이 다른 프로그램의 실행 프로세스에 간섭하거나 개입할 여지가 없다. 이렇게 설계된 운용 환경에서 안티바이러스 프로그램을 실행한다는 것 자체가 그다지 설득력이 없을 뿐 아니라, 애플사는 자사가 직접 관리하는 앱 스토어를 통해서만 프로그램이 아이폰에 설치될 수 있도록 하고, 앱 스토어 등록 신청 과정에서 프로그램을 사전 점검하여 악성 프로그램은 애초에 등록되지 못하게 함으로써 아이폰 운용 환경의 안전을 담보하고 있다.

바이러스가 아예 침입할 수 없도록 관리되는 환경에서 안티바이러스 프로그램 설치를 운운하는 것 자체가 코메디일 뿐 아니라, 애플사가 회사의 명운을 걸고 전세계에 판매하는 아이폰 운영체제의 신뢰성 자체에 대한 근거없는 모욕이다. 만일 아이폰용 ‘안티바이러스’ 프로그램을 애플사가 승인한다면, 그말은 곧 바이러스가 포함된 프로그램들이 앱 스토어에 마구 등록되는 사태가 이미 발생하였다고 시인하는 꼴이다. 애플사가 망하기 전에는 이런 일이 벌어질 가능성은 없다.

“세계 최초”에 열광하는 국내의 일부 성향을 적절히 자극하면서, 기술적으로나 논리적으로 터무니 없는 업체의 선전 자료를 검증 없이 베껴 적는 기사, 바로 다음날 등록신청이 거부되었다는 사실은 조용히 덮고 정정 보도조차 내지 않는 무책임함은 안타깝게도 국내 기술언론 매체의 부끄러운 현주소이다.

유사한 사태는 사실 그동안 거듭 반복되었다. 이른바 ‘리눅스용 안티바이러스 프로그램’ 소동이 그것이다. ‘윈도우’가 운영체제인지 컴퓨터인지도 잘 모르던 과거의 규제당국이 전자금융거래에는 백신프로그램을 우선 설치하라는 규정을 도입하자, 국내 일부 보안업체는 ‘리눅스용 백신프로그램’이라는 것을 개발하였다고 발표하는 사태가 벌어졌었다. 문제의 프로그램 개발에 관여하였다는 분의 주장은 “리눅스 운영체제에서 작동하는” 안티바이러스 프로그램은 공개소스로 이미 존재하며(예를 들어 clamAV), 자신은 이것에 기반하여 제품을 만들었다는 것이다.

놀라울 뿐이다. “리눅스에서 작동하는” 안티바이러스 프로그램은 리눅스 이용자를 공격하는 바이러스 프로그램(그런 바이러스가 전파될 가능성은 애초에 희박하다)이 있다는 말이 아니라, 윈도우 이용자들을 공격하는 악성 프로그램을 리눅스 운영체제로 가동되는 메일서버, 파일서버가 스캔해 주는데 사용되는 프로그램들이다. 이메일 서버들은 흔히 리눅스 운영체제로 구축되는 경우가 많다. 이런 메일서버들이 이메일 수령자들에게 전달될 첨부파일을 일괄 스캔하여 악성코드가 포함된 첨부파일은 아예 이메일로 전달되지 않도록 예방하는데 사용되는 프로그램들인 것이다. 이런 프로그램을 개인 컴퓨터에 설치하겠다는 발상은 리눅스가 무엇인지, 클라이언트/서버가 무엇인지 기본 개념 부터가 없거나, 영어를 해석할 능력조차 없는 수준의 인력이나 해낼 수 있는 발상이다. 그런 보안업체의 보도자료를 그대로 베껴적는 IT기자가 수두룩하다는 것이 바로 “IT 강국” 한국의 현실이다.

국내에서는 심지어 ‘리눅스용 키보드보안 프로그램’이라는 것이 실제로 배포되기까지 하는 실정이다. 그야말로 “세계 최초”일 뿐 아니라, “세계 최후”의 발상일 것이다. 리눅스 운영체제에서는 이용자의 계정 암호 없이는 컴퓨터를 아예 사용할 수 없는 것이 보통이고, 키보드 입력값을 가로채는 프로그램이 설치되려면, 계정암호 뿐 아니라, 루트(관리자) 암호까지도 이미 공격자가 입수한 사태가 벌어져야 가능한 일이다. 루트 암호가 유출되었다면 키보드보안 프로그램 따위를 설치해 둔다고 해서 무슨 소용이 있겠는가? 장례식장에서 고인에게 감기약 복용을 권하는 꼴일 뿐이다.

“세계 최초” 아이폰 백신 소동은 세계에서 철저히 고립된 국내 보안업체와 국내 기술매체의 수준을 적나라하게 드러내 보여주는 씁쓸한 에피소드로 기억될 것이다.

스마트폰 보안정책 – 해설3(입력정보 보호대책)

January 14th, 2010

금융감독원의 스마트폰 보안 정책 중, “입력정보 보호대책”은 대략 다음과 같은 방향을 생각해 볼 수 있습니다.

기본 개념

  • 고객이 입력할 인증 정보의 성격/종류/기술적 특성을 분석하여 대처할 필요가 있습니다.
  • 인증 정보 중, 고정값과 변동값을 적절히 구분하고, 그에 따른 대응책을 마련합니다.
  • 입력을 요구할 인증정보의 종류 및 빈도를 합리적으로 분석, 결정할 필요가 있습니다.

키보드보안 프로그램만 설치하면 만사해결이라는 황당한 태도는 아마추어리즘의 극치라고 밖에는 달리 표현할 길이 없습니다.

1. 인증서 암호

  • 웹브라우저의 보안저장장치(secure key store) 또는 하드웨어적 보안장치(보안토큰)에 인증서를 설치하고 사용할 경우(표준적 방법), “인증서 암호”는 아예 존재하지 않습니다.
  • 웹브라우저/하드웨어 보안장치 접근에 필요한 암호는 해당 machine 에만 적용되는 것이므로 유출되어도 인증서의 보안성에 영향이 없으며, 이용자의 컴퓨터 자체에 대한 공격과도 무관합니다.
  • 요컨대, 표준적 방법으로 인증서를 사용하면, 인증서 암호라는 것을 아예 입력할 필요가 없어집니다.
  • 하드디스크나 USB의 NPKI폴더 안에 일반 파일 형태로 저장된 인증서는 이용자가 자진 삭제하도록 안내, 유도하면 보다 안전한 인증서 운용 환경이 마련될 것입니다.

공인인증서가 국내에서 불러일으킨 엄청난 문제는 일차적으로 KISA에게 책임이 있습니다. KISA는 시급히 인증서 저장 규격을 개선/개정해 주시면 좋겠습니다.

2. 보안카드 번호

  • 보안 카드는 소지 수단(possession-based means of access)으로 기능하며, 일종의 OTP (일회용 비밀번호)에 해당합니다.
  • 그러나, 앞 두자리, 뒷 두자리로 나누어 합계 4자리 숫자의 입력을 요구하는 현재 방식은 공격자가 요구값의 패턴을 비교적 쉽게 유추할 수 있는 열악한 운용방식이므로, 이것을 수정할 필요가 있습니다.
  • 예를 들어, 매 거래 마다 무작위로 지정된 연결되지 않은, 합계 3자리 숫자만 입력하게 할 경우, 노출값은 적어지고 요구값의 패턴은 획기적으로 그 경우의 수가 많아지므로, 공격자가 보안카드의 전체 정보를 고객의 입력값(노출값)으로부터 역으로 유추하는 작업이 비현실적으로 됩니다. 여기 참조.
  • 보안카드 운용 방식을 적절히 개선할 경우, 키보드 보안 프로그램은 불필요 합니다.

3. 계좌이체 비밀번호

  • 이미 유출되었을 가능성이 가장 큰 인증정보입니다. 오랫동안 각종 신청 서류에 계좌이체 비밀번호를 아예 기재한 적도 있고, 그 후에도 그 정보를 그대로 유지하는 고객의 비율도 높습니다.
  • 신용카드 결제의 경우, 카드 비밀번호 첫 2자리를 입력하게 하는데, 이 번호와 계좌이체 비밀번호 첫 두자리가 동일한 경우도 많습니다.
  • 계좌이체 비밀번호는 낮은 수준의 신뢰성을 가진 인증정보이므로, 낮은 수준의 보호대책인 화상 키보드로 대처하면 적절할 것입니다. 장기적으로, 금융PIN(6자리)을 사용하고 계좌이체 비밀번호는 인터넷 뱅킹에서는 사용을 중단하는 방안을 검토할 필요가 있습니다.
  • 금융PIN 을 사용할 경우, 매 거래마다 무작위로 선택한 3개의 숫자(예컨데, 넷째, 첫째, 둘째; 그 다음 거래에는 둘째, 다섯째, 여섯째 등)만을 입력하도록 설계할 경우(영국 HSBC가 채용하는 방법), 키보드보안 프로그램은 별 필요가 없습니다.

4. 인증정보 입력 요구 빈도

  • “안전한 것 같은 느낌이 들게”하는 것과, 실제로 안전한 것은 구분할 필요가 있습니다.
  • 암호 입력을 자주 요구하면 할수록 공격의 기회는 늘어납니다. 무지한 고객은 암호입력창이 자꾸 뜨면, 꼬박꼬박 입력하면서 해당 서비스가 “안전하게 설계된 듯한 느낌”을 가질 수는 있으나, 합리적 고객은 저열한 설계에 대한 반감을 가지게 됩니다. 그리고, 모든 이용자들이 공격에 더욱 노출될 뿐입니다.
  • 거래 개시에 필요한 인증 단계를 통과한 고객에게 그 세션 중 이루어지는 개별 거래에 대하여 또다시 암호 입력, 인증/서명 등을 거듭 요구하는 것은 무의미 합니다. 거래 세션 개시에 필요한 인증 수단을 구비한 자라면 해당 세션 중 아무리 여러번 암호 입력, 인증/서명을 거듭 요구해도 그 과정을 모두 통과할 수 있습니다. 노출되는 입력 정보만 많아질 뿐입니다.
  • 본인이 자리를 비운 사이에 다른 자가 거래할 가능성에 대한 차단은 일정 기간(약 5분?) 입력이 없으면 세션을 종료하는 방법으로 대처하는 것이 옳습니다. 금융거래 세션을 열어두고 자리를 비우는 행위 자체가 “중대한 과실”에 해당할 여지가 많으며, 그로 인한 거래는 그자가 책임을 지는 것이 옳다는 주장은 법원도 쉽게 수긍할 것입니다.

그저 암호입력창만 자꾸 띄워주면 더 안전하지 않을까하는 소박, 유치한 수준의 설계에 길들여져 있는 분들은 제대로 설계된(실제로 안전한) 전자금융거래를 접하시면 “일종의 불안감”을 느낄 수도 있습니다. 너무 간편, 신속하기 때문입니다.

뱅킹 거래 한번하려면, 온갖 프로그램을 설치하고, OK를 무수히 누르고, 웹브라우저를 몇번이나 재시작 하고, 심지어는 컴퓨터를 재 부팅 까지한 다음, 로그인을 하고, 이체할 때마다 무슨 인증서 암호 입력창이 또 뜨고 … 한 마디로 “생 쑈“를 해 온 나머지, 적지 않은 이용자들은 “이렇게 복잡하고 어려우니 안전하지 않을까?”하는 “느낌”을 가지게 됩니다. 그러나 이것은 학대받아온 일반 이용자의 “자기 위안”에 불과할 뿐, 보안기술적으로는 어디 내놓기 부끄러운 수준입니다.