겐도사마의 재림

이전에 암호를 다르게 넣어도 인증되는 오류(암호화 알고리즘은 함부로 생각해 내지 말자라는 교훈을 주고 있음)와 이번에 Plain Text로 로그에 저장하는 문제때문에 시껍한 문제의 프로그램... 본인이 지켜본 리니지2 클라이언트의 변화를 적어 보고자 한다. 일전에 NCSoft에 면접 보러 갔다가 거기의 아는 선배가 던진 질문이 생각난다. 서버의 부하때문에 일부 연산은 클라이언트로 옮기는 것이 좋을거 같은데 괜찮을까? 역시 대답을 예상하고 던진 질문이겠지만 "NO"이다. 다른 게임의 Speed Hack(게임에서 설정한 정상적인 이동 속도보다 더 빠르게 움직일 수 있게 하는 프로그램)이 이런 이유에서 나올 수 있는 것이다. 리니지를 보고 있노라면 적어도 이런 부분은 잘 지키고 있다. 클라이언트는 말 그대로 ..

우선 권장하는 책은 Writing Secure Code 2/E : 안전한 코드 작성 기술 정도가 있다. 이 분야에 대해 그나마 뭔가 주제를 가지고 쓴 책. 내용도 상당히 훌륭한 편. 언젠가 웹페이지나 프로그램에서 암호 부분에 '*'로 표시 된 것을 읽어 내는 프로그램이 유행한 적이 있다. 대부분의 개발자나 사용자는 화면에 보이지 않으면 암호가 안전할 것이라 생각하였는데 그런 부분에 대한 일침이었다. 하지만 아직도 많은 곳에서 이 방법을 사용중에 있다. 이것을 고치려는 노력은 별로 보이지 않는다. 정말 일부분의 프로그램만이 해당 위치에 가비지값을(혹은 암호화된 내용. 원래 패스워드를 구지 거기에 적을 필요는 없지 않은가) 넣어 둔다. 보안이라는 것은 자신의 자산을 지키는 것도 중요하지만 이제는 타인 특히 ..

지식인에 검색해 보세요라고 하고 싶다. --; 사람의 감정이라고 하는 것은 삶의 활력소가 될 수도 있지만 반대로 힘빠지게 만들 수 있는 양면성을 가지고 있을 것이다. 특히 사랑, 애정 이런 등등의 감정은 그 정도가 매우 심할 것이다. 언제부턴가 무엇인가 하고싶은것, 가지고 싶은것 등에 많은 미련을 두지 않는 버릇이 생겼다. 회사일이든 개인적인 일이든 되면 되고 말면 마는 거지란 마음가짐으로 산달까. 그것을 반드시 해 내고 싶어라는 생각이 들라치면 그것을 실패했을 때의 모습이 상상되면서 그럴바엔 기대치를 낮추는 방향으로 생각을 전환하곤 한다. 물론 그 일에 최선을 다하지 않는 것은 아니다. 어떤 일이 불가능해 보여도 상황의 다각적인 분석으로 최적의 대안을 찾아 내어야 한다는 것이 지론이지만(뭐 끊임없는 피..

강컴 4월의 서평상 빠밤~~~

일전에 일부 사이트에서 카드 정보 유출이 파악되는 순간 모 카드사는 해당 카드를 모두 정지시키고 일괄 재발급을 했다는데요.. 아무튼. 이번처럼 대대적으로 아이디/패스워드 유출사고가 일어나는 경우 해당 시스템의 변경보다 더 중요한 것은 다른 사이트의 계정 정보입니다. 뱅킹에 사용하는 패스워드까지 동일하셨던 분들은 반성좀 하시구... 아무튼 동일한 아이디와 비번을 쓰는 모든 서비스의 패스워드를 변경해야 합니다. 특히 개인정보 침해의 경우 친구나 애인사이에도 빈번히 일어나기 때문에 PC방에 간적이 없다라고 해도 개인이 사용하는 장비가 아닌 다른 곳에서 쓴 적이 있거나 개인장비를 타인도 쓸 수 있다고 한다면 유출 가능성이 매우 높다고 봐야 합니다. 친구사이에 그것도 못믿나가 아니라 자신의 정보는 자신이 지켜야 ..

어차피 다 알거 이름 다 밝혀서 적는다. NCSoft의 Lineage2 클라리언트에서 로그파일에 ID와 패스워드를 기록하는 문제점이 발견. 지금 현 시점 긴급 업데이트 준비중입니다. PC방에서 Lineage2 했던 분들은 당장 그 PC방의 그 자리로 가서 처치 하여야 할듯 ;;;; 업데이트로 적당히 해결할 수 있을지 몰라도 악덕 PC방 주인이나 알바들은 악용할 소지가 다분히 있죠. 많은 디버깅 관련 책들이 실제 사용중에 문제 발생시 디버깅을 위한 로그파일 생성이나 인터넷을 통해 그 내용을 전달할 수 있도록 하는 것들을 권장하곤 합니다. 그중 일부의 책들이 몇마디 말로 이런 경고를 하죠. 사용자의 중요한 데이터가 포함될 가능성을 조심하라구요. 기존의 일부 프로그램들은 메모리 오류 발생시 저장되어 있던 아이..

중간에 너무나 정형적인 개발 프로세스에 대한 비판이 나오면서 http://www.construx.com/resources/ 여기를 지적하고 있는데 아는 사람은 알겠지만 이 회사는 바로 Steve McConnell씨의 회사이자 그의 책에서 쓸만한 리소스들을 보라고 가르쳐 준 곳이다. (Code Complete, Rapid Development, Software Survival Guide, Professional Software Development 등의 저자) 블로그의 특성답게 조엘씨는 스티브씨를 거의 대놓고 씹어 버린게 아닌가 싶을 정도이다. 일련의 나의 팀에 표준 개발문서들이 그 리소르를 토대로 만들었단 말이닷! ㅠ.ㅠ 사실... 그것을 만들면서 너무 쓸데없는 것들이 많은게 아닌가 하는 생각도 들었지만..

피플웨어(Peopleware)라는 책이 나에게 정리를 해 준 생각이자 최근 고민의 나름대로의 해석일 수도 있을 것이다. 간단히 요약하자면 어느 단계의 할 수 있는 것에 대해서 다른 단계를 완전히 고려하지 않을 수 없다는 것이다. 회사의 단계에서 흔히 저지르는 실수를 예를 들고자 한다. S대기업이 아마 대표적인 예라고 생각이 드는데 필요하다면 얼마든지 돈을 댈 수 있기 때문에 마음먹은 것은 모두다 할 수 있다는 것이다. 대장이든 아니면 내부의 누구든 "저 고지를 향해 돌격~~!~!" 한마디만 하면 그 고지로 가는 길로 가는데 필요한 사람은 내부에 이미 충분히 있거나 돈으로 뽑으면 되거나 세계적인 M모사의 경우 팀이 없다면 회사를 사버리면 된다는 신념으로 일을 진행하곤 한다. 저 고지가 올바른 길인지는 논외..