정확히 기억은 안나지만 Mozilla Servo가 릴리즈 되었으니 아마도 2016이 맞을거 같다. 그때는 한창 대한민국의 자랑스러운 공군 병장으로서 당당히 전날 야간 근무를 마치고 취침 후 사지방에 있었을 때였다(혹은 주말이어서 비번이었건?). 계기는 모르겠지만 어떤 이유로 Mozilla에서 Servo라는 웹 브라우저 엔진을 새로 개발하였고 이는 Rust라는 Mozilla에서 만든 새로운 언어로 개발 됐다는 것을 알게되었다. 어째서였을까? 이건 마치 운명같은 만남이었을까? 나는 Rust 컨셉을 보고는 그대로 이 언어에 매료되었다.

쿠키가 마녀에게 잡혀 있던 이유가 있었다.

오븐브레이크가 아니라 멘탈브레이크였다.

쿠키런때부터 인성 알아봤다.(인성 문제있어?)

그렇게 탈출을 도와주려고 했는데... 쿠키 넌 개인주의야

intro.​

거진 2-3주에 걸친 쿠키 삽질기를 녹여낸 글입니다. 브라우저에서 쿠키를 사용할 때 엄청 애를 먹었습니다. stack overflow나 MDN를 읽는 것만으로 알기 어려운 내용도 일부 포함하였습니다.

이 글을 통해서 기본적인 쿠키의 개념들과 제가 겪었던 문제의 해결법을 같이 기술하겠습니다.

intro.​

너무 당연하게 패스워드는 클라이언트에서 해싱 후에 서버에 보내서 가공해야한다고 생각했습니다. 그게 보안적으로 좀 더 안전하다고 생각했기 때문인데요. 지인에게 2차 비밀번호 평문을 HTTPS(TLS v1.2 이상)로 보냈을 때 무슨 문제가 있는가에 대한 질문을 받았습니다. 저는 당연히 해시를 해서 보내야 한다고 생각만 해봤지 왜인가에 대해서 충분히 생각해보지 못했음을 깨닫고 조사를 해봤습니다. (물론 데이터베이스에 저장할 때는 해시를 한다는 가정입니다.) 그래서 오늘은 HTTPS를 사용할 때 패스워드를 평문을 보내도 되는지에 대해서 조사해봤습니다.

AUSG 블로그에 Vim 관련 글을 투고했습니다. 많이 봐주세요! 😄
https://t.co/dwJ4QBhEMk

— yoonhoGo (@yoonho_go) 2020년 9월 8일

Intro​

OAuth 2.0은 인증을위한 산업 표준 프로토콜입니다. OAuth 2.0은 2006 년에 작성된 원래 OAuth 프로토콜에 대한 작업보다 우선합니다. OAuth 2.0은 클라이언트 개발자의 단순성에 중점을 두면서 웹 응용 프로그램, 데스크톱 응용 프로그램, 휴대 전화 및 거실 장치에 대한 특정 권한 부여 흐름을 제공합니다. 이 사양 및 확장은 IETF OAuth Working Group 내에서 개발되고 있습니다.
- oauth.net의 소개글에서

OAuth 2.0은 RFC에서 제의된 6749번 문서입니다. OAuth 2.0은 기존의 1.0버전이 가진 보안 취약점, 인증 방식 등을 개선하여 대체하기 위하여 제시되었습니다.

그렇습니다. 제목은 어그로를 끌려는 저의 작전이었던 것입니다.

주의! 이 글은 경력자로서 작성한 정보 전달의 글이 아닙니다. 공부한 내용을 정리하기 위한 글임을 명심해주시고, 관련하여 조언이 있으시면 언제든지 하단의 댓글을 통해 혹은 PR을 통해 아낌없는 조언 부탁드립니다.

이전 회사에서 개발하면서 DevOps를 사용하고 있었는데, 보안 전공자로서 모든 개발, 배포, 운영 과정에서 자연스럽게 보안에 대한 부분들을 고려하면서 개발했습니다. 그때는 "당연히 모든 과정에서 보안 부분을 검토해야지"하는 생각에 내가 DevSecOps를 하고 있다는 자각이 없었는데, 이후 DevSecOps를 알고 나니 좀 더 공부할 필요가 느껴졌습니다.

이 글은 그 이후에 관련된 직종으로 이직을 준비하면서 정리하는 글입니다.

얼마전 카카오, 네이버, 라인 코딩 테스트를 봤다고 포스팅 했었는데요. 드디어 네이버에서도 결과가 나왔습니다. 사실 결과가 나온지는 조금 됬습니다. 바빠서 이제야 포스팅하게 됐네요.