3 posts tagged with "security"

intro.​

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

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를 알고 나니 좀 더 공부할 필요가 느껴졌습니다.

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