2008년 12월 25일 목요일

삼성생명 보험계약종합안내






아래 내용으로 삼성생명에 메일을 보냈더니

담당자가 직접 수정한 메일을 보냈습니다.

그리고 앞으로 될때까지 직접 챙기겠다고 합니다.

담당자 메일을 웹사이트 접속이 불가하여

인터넷 검색엔진에서 이용자 약관내용을 찾았고 그 안의 담당자 메일이 있어 거길로 발송하였습니다.

-----------

삼성생명 보험계약종합안내 메일 오류 관련 개선 요청


안녕하세요.
저는 삼성생명 고객인 이*산입니다

IT산업에 종사하고 있고
주로 Mac OSX에서 Firefox browser를 사용합니다.

최근 삼성생명에서 발송하는 보험계약종합안내 메일에서
파이어폭스나 리눅스 유저를 고려하여 일반메일 재발행 신청하기라는 기능이 추가되었는데

아래와 같은 문제가 있어서 자세하게 안내해드립니다.

기왕 파이어폭스나 리눅스, 매킨토시 유저를 지원하기로 하였으면
유저입장에서 정확하게 동작하는지 확인후 안내하고 실제로 동작할 수 있도록 조치해주십시오.

1. 아래 그림처럼 삼성생명에서 메일을 받았습니다.

2. 저는 Mac OSX에서 파이어폭스를 주로 사용하고 있는데
메일 내용중 "보안프로그램(Active-X)은 일부 운영체계(윈도우비스타, 파이어폭스, 리눅스, 매킨토시 등) 및 일부 회사 메일의 경우 첨부파일이 개봉되지 않을 수 있으니 아래 [일반메일 재발행 신청하기]에서 일반메일을 신청하시기 바랍니다"라고 하는 안내문구가 보여서 [일반메일 재발행 신청하기] 링크를 클릭하였습니다.
몇단계 확인 alert 창이 뜬 이후 일반메일 신청 화면이 아래 그림처럼 나옵니다.

3. 주민번호 뒤번호 7자리를 입력하면 아무런 반응이 없습니다.
혹시나해서 Firefox의 JavaScript 오류 정보 창을 열어보니 아래와 같은 사이트 오류가 확인되었습니다.

4. 혹시나 해서 [에러 발생시 신청방법] 링크를 클릭하면 아래 그림처럼 ActiveX 설치를 시도하고 다음 단계로 진행을 할 수 없습니다.

2008년 12월 18일 목요일

PCI DSS Guide관련 블로그 오픈

PCI DSS 안내하는 블로그를 오픈하였습니다.
http://pcidssguide.blogspot.com

살펴보세요

웹표준과 지불결제

웹표준과 지불결제

1. 웹표준

1.1 전세계 브라우저 점유율 (by NetApplications)



* MSIE점유율은 줄어들고 있고 Firefox는 상승중

1.2 대한민국 브라우저 점유율 종합 (by NetApplications)

* 국내 MSIE점유율 종합은 96.59%(4월), 95.65%(5월)

1.3 지불결제가 필요한 쇼핑분야 점유율(by internettrend)


* 쇼핑분야는 국가평균보다 점유율이 더 높음

* 기간별 변화율 추이는 점차 줄어들고 있음.


1.4 국가별 MSIE Market Share 비율 (by NetApplications)

* 오차율을 감안한다면 "South Korea"는 세계 최고의 MSIE Market Share 비율을 보이고 있음.

1.5 페이게이트 결제를 사용하는 특정 업체의 브라우저 점유율 (by analytics.google.com)

누적5월까지
누적6월까지

1.6 웹표준 이전과 이후





웹표준 이전

웹표준 이후

유저환경에 대한 기술적 별도 대응 - IPTV환경 따로 - 모바일환경 따로 - PC환경 따로 동일한 하나의 기술로 모든 시장환경에 대응 PC, 모바일, IPTV 환경의 구분 불필요

1.7 웹표준은 돈이되는 기술






















구분

웹표준 미준수업체

웹표준 준수업체

MSIE PC Market (95%) 유저의 95% 수용, but 시장이 점점 줄어들고 있음. (좌동)
Non-MSIE PC Market (5%) X 숨어있는 새로운 5% 유저 수용, 매출 5% 증대 가능성
Mobile Full Browsing Market (00%) X 무한 가능성 가진 새로운 유저층 수용, 매출 증대 가능성 가늠불가
IPTV Setup Market (00%) X 무한 가능성 가진 새로운 유저층 수용, 매출증대 가느성 가늠불가
냉장고에 붙은 embeded device X 숨어있는 새로운 유저 수용, 매출증대 가능성
기타 웹표준 순수 device(iphone, PSP, XBox...) X 숨어있는 새오운 유저 수용, 매출증대 가능성

1.8 Mobile Device에서 결제 demo


1.9 지불결제분야의 웹표준 활성화를 위한 요건







사업적

매우 매력적

기술적

제약 없음.

제도적

공인인증서 의무사용 개인보안프로그램 의무사용 기타등등.

2. 지불결제 및 보안에 대한 이해

2.1 보안방식의 변화 필요





현재

희망사항

보안당국이 국민 개개인의 보안을 모두 책임지려는 불가능한 자세
국가가 전국민을 보호
개인의 선택권(자율성, 권한)을 존중하는 방향으로 개선 필요 국가의 보호도 필요하지만 내 PC를 내가 보호할 수 있도록 개인의 선택권 존중.
국가가 전국민을 보호 + 자신을 내가 추가로 보호
* 전자금융거래법 시행세칙 29조 2항 3절 : 전자금융업자에게 국민 개개인의 이용자 PC에 프로그램을 설치하도록 요구함. 본질적으로 이용자의 동의 및 허용이 있어야 가능한 조항


2.2 사용자에 대한 관점 변화 필요





현행

희망사항

사용자는 무지하고 피동적이고 잠재적인 범죄자이다. 사용자는 똑똑하고 능동적이고 선량하다 ==> 개인의 선택권 존중해야함

2.3 전자금융거래와 전자서명법의 공인인증서










구분

전자금융거래법

전자서명법

공인 전자서명/서명검증 요구됨 요구됨
데이터 암복호화 요구됨 요구되지 않음.
==> 데이터 암복호화와 서명 /서명검증의 명확한 분리 필요 ==> 현재는 전자금융거래시 사용되는 공인인증서가 사실상 데이터 암복호화를 포함하여 사용.

3. 전자서명법과 공인인증서

3.1 인감제도와 공인인증서 비교

























구분

인감제도

공인인증서

취지 오프라인에서 국민 누구든지 자유롭게 상대방의 신원 및 의사 확인 온라인에서 국민 누구든지 자유롭게 상대방의 신원 및 의사 확인
본인의 표시 인감도장 공인인증서 Private Key
본인의 표시에 대한 제3자 증명 인감증명서 공인인증서
본인의사 표시 인감 날인 공인 전자서명
신원확인 인감증명서 대조 공인전자서명 서명검증
누구나 자유롭게 날인하고 대조 서명하고 검증 불가능
어떠한 영역에 대해서도 적용 불가능 (금융거래등에만 제한적 사용)

3.2 전자서명법상의 공인인증기관의 의무

- 전자서명 가입자 설비 제공 의무 : 전자서명 생성을 위한 소프트웨어 제공 - 서명검증을 위한 쉬운 수단 제공 의무 : 전자서명 검증을 위한 쉬운 수단 제공

3.3 공인인증기관이 가입자 설비를 제공하면 기존 보안업체들은 모두 다 망하는가?







현재

희망사항

아주 많은 업체들(공인인증기관 포함)이 기초적인 공인인증서 전자서명, 서명검증 소프트웨어 반복하여 제작 => 리소스 낭비 6개 공인인증기관이 검증된 가입자 설비 제공, 기존보안업체들은 좀더 창의적인 업무에 집중가능(데이터 암복호화, 키관리, 기타 응용 서비스 분야) 기존 보안업체뿐만 아니라 다양한 사업체들이 참여로 인한 활성화
공인전자서명/서명검증을 할 수 있는 소프트웨어를 만들기 위해서는 돈이 많거나 기술이 뛰어나거나 시간이 아주 많아야함. 구멍가게 쇼핑몰 아저씨도 이용가능

4. 웹표준 지불결제처리를 위한 기술적/제도적 대안

4.1 주요 이슈 및 대안 요약













구분

현행

대안

키보드보안 ActiveX Control 자동설치 OnScreen Keyboard
개인보안프로그램(방화벽, 안티바이러스) ActiveX Control 자동설치 유저가 능동적으로 사전 설치, 기설치 유저는 추가설치 없이 진행허용
공인인증서 ActiveX Control 가입자설비 - 사용안함(예외규정 준용) - Java Applet (KLDP OpenSigner) - XPCOM (전자정부) - 신용카드 금액인증

4.2 키보드보안 방안

- 유저가 원하는 경우 사용하지 않고 진행가능하도록 선택권 부여해야함. (시행세칙 29조 기 명시) - Auto Form Filler 활성화 - OnScreen keyboard : 광범위하게 사용되는 검증된 방식, 국내 다수 금융기관에서 이용 - Smart Card등 PKCS#11 device이용한 보완 - 기타 : http://en.wikipedia.org/wiki/Keystroke_logging 참조 *국민은행 온스크린 키보드 보안 적용 화면

4.3 개인보안프로그램

- 유저가 원하는 경우 사용하지 않고 진행가능하도록 선택권 부여해야함. (시행세칙 29조 기 명시) - 유저가 능동적으로 사전 설치할 수 있도록 프로그램 목록 제시 * 페이게이트의 경우

4.4 공인인증서 사용예외 (시행세칙 31조)

- 본인 계좌에 대한 조회 업무 - 전화, CD/ATM 등과 같이 공인인증서의 설치·운용이 불가능한 수단을 이용한 전자금융거래 - 등록금, 원서접수비 등 본인확인이 가능하고 입금계좌가 지정되어 있는 경우 - 전자상거래에서 지급결제로서 30만원 미만의 신용카드 결제 또는 온라인 계좌이체 - 전자화폐, 선불전자지급수단을 온라인상에서 사용하는 경우 - 금융기관 등이 범위를 정하여 공인인증서 적용을 제외할 것을 감독원장에게 요청하고 감독원장이 이를 승인하는 경우

4.5 신용카드 금액인증

- 이용자(페이게이트도 이용자임)의 자유로운 창의력을 저해하지 않았을때 도출될 수 있는 결과물의 한 예.
- 시행세칙 31조의 "본인 계좌에 대한 조회업무"에 대한 공인인증서 적용예외 규정을 기반으로 공인인증서를 사용하지 않음.
- 공인인증서 미사용시 발생할 수 있는 신원확인 요구사항을 "신용카드 금액인증"이라는 기술로 보완


[신용카드 금액인증 50만원 결제예시] 1) 서버에서 1회용 비밀번호 생성로직으로 난수 발생하여 신용카드 거래 1차승인 (237698원) 2) 승인금액을 고객에게 안내하지는 않음. 3) 고객은 자신의 카드발행사에서 승인금액이 얼마인지 확인 (다양한 확인방식 병행, SMS문자, 웹사이트조회, 팩스조회, 전화조회, 방문조회 등) 4) 승인금액을 인증코드로 입력하면 서버에서 1차 승인금액과 비교 5) 나머지 잔액 추가승인하여 결제 완료
신용카드 금액인증에 관한 보다 자세한 내용은 아래 URL 참조
http://docs.google.com/a/paygate.net/Doc?id=dhm28v4q_1631cd5kj9dk


4.6 ActiveX Control이용방식 개선

- ActiveX Control 사용이 꼭 필요한 경우가 여전히 존재함

- 꼭 ActiveX를 사용해야한다면 아래와 같이 사용방식을 개선







현행 개선
- Page Head에 걸어버리거나 <html> <head> <OBJECT ....>...</OBJECT> </head> - 사이트 전역에 반영되는 Hidden frame에 넣어버리면 IE가 아닌 브라우저들은 접근자체가 불가해짐. - ActiveX가 꼭 필요할때만 DIV tag 안에서 선언하여 이용. <div id=forActiveX></div> document.getElementById('forActiveX').innerHTML = '<OBJECT...>...</OBJECT>'; - 이용후에는 Div tag내용 삭제 document.getElementById('forActiveX').innerHTML = '';
ActiveX를 이용하여 Client와 Server간의 세션 보호 SSL이용

2008년 12월 17일 수요일

Latest Browser MarketShare






최신 브라우저 마켓쉐어


netapplications 유료 계정 만료가 얼마안남아서
최신 브라우저 마켓쉐어 자료를 뽑아보았습니다.

자료 발췌시기 : 2008년 12월 18일

1. 전세계 브라우저 마켓쉐어

MSIE가 69%입니다.
Firefox가 20%를 넘어섰고 Safari도 많이 늘었군요.

2. 대한민국 브라우저 마켓쉐어

MSIE가 90%로 줄었습니다.

3. 전세계 브라우저 점유율 변화추이입니다.

IE는 계속 떨어지고 다른 브라우저는 계속 올라가는군요.
국가별 추이도 뽑아볼수 있으면 좋은데 그건 아직 없습니다.

4. 전세계 MSIE 국가별 점유율 순위입니다

대한민국이 드디어 소말리아에게 MSIE 점유율 1위를 내줬습니다.(ㅠㅠ)


5. 전세계 OS 통계입니다.