이 강의에서는
업계에서 비밀번호를 취급할 때
우리에게 주어지는
다양한 옵션 또는 표준을
이해해보겠습니다
아주 오래 전
거의 웹 애플리케이션 초기 시절에
모두가 자격 증명을
일반 텍스트 형식으로 저장했지만 이후에
보안 침해, 기술 발전에 의해
업계가 발전했습니다
이 변수들로 인해
얼마 후 인코딩, 암호화, 해싱과 같은
옵션들이 등장했습니다
이 강의에서 우리가 할 일은
이러한 옵션들을 모두 다뤄보고
그 중 어떤 하나가 저장소에
비밀번호를 저장하고 취급하는 데에
가장 적합한지 선별하는 것입니다
첫 번째 옵션은 인코딩입니다
인코딩은 여러분의 데이터를 한 형식에서
다른 형식으로 변환하는 과정이며
어떠한 기밀성도 포함하지 않는데
무슨 뜻이냐면 제가 일반 텍스트 비밀번호를
인코딩을 따라 인코딩 값으로 변환한다면
누구든 이 인코딩 값을 가져다가
디코딩 과정을 따라할 수 있다는 겁니다
그리고 이렇게 디코딩하면
인코딩 과정에 사용한 최초의 일반 텍스트 비밀번호가
무엇인지 쉽게 볼 수 있습니다
아무런 기밀도 포함하지 않고
완전히 가역적이기 때문에
비밀번호 관리에는 적합하지 않습니다
물론 일반 텍스트 비밀번호를
저장하는 것보다는 낫지만
여전히 우리가 고려할 옵션은 아니고
인코딩은 주로 MP3 파일이나
영상 파일을 인코딩하는
상황에서
사용됩니다
음성 파일이나 영상 파일을 압축할 때
이 인코딩과 디코딩을 사용하는 겁니다
여기서 보시다시피
다양한 시나리오에서 업계가 준수하는
유명한 인코딩을 정리해두었습니다
하나는 ASCII고
하나는 BASE64 그리고 UNICODE입니다
요즘에도 몇 웹 애플리케이션
내부에서 볼 수 있습니다
일반 텍스트 비밀번호나 네트워크를
전송하는 대신 몇몇 개발자와 애플리케이션은
BASE64 인코더로 비밀번호를 전송하는데
이것이 일반 텍스트 비밀전호 전송보다
훨씬 낫기 때문입니다
이 인코딩과 디코딩을 라이브로 보여드리겠습니다
그러기 위해 웹사이트로 이동하겠습니다
base64decode.org라는 웹사이트로 왔습니다
여기서 먼저 이 Encode 옵션을
클릭할건데 이 Encode 옵션을 클릭하면
BASE64 형식의 도움으로
일반 텍스트를 인코딩할 수 있습니다
일반 텍스트 비밀번호인 1, 2, 3, 4, 5를
입력해보겠습니다
여기 ENCODE 버튼을 클릭하면
이것이 제 일반 텍스트 비밀번호의
인코딩 값입니다
같은 값을 가지고 디코딩을 해보겠습니다
그러기 위해 여기 Decode 옵션을 클릭하고
이 인코딩된 비밀번호를 여기
Decode from BASE64 format
아래의 양식에 입력하고 DECODE 버튼을 클릭하면
저의 원래 비밀번호인 1, 2, 3, 4, 5를
볼 수 있습니다
그러니 여기서는 비밀이나
기밀성이 없습니다
아무런 노력 없이 완벽히 되돌릴 수 있기 때문입니다
그러니 여러분의 엔드 유저 비밀번호를 취급하고
저장소에 저장하는 데에 인코딩을 고려하지 않으시길 바랍니다
그럼 우리의 두 번째 옵션인
암호화로 넘어가 보겠습니다
암호화 또한 기밀성을
보장하는 방법으로 여러분의
일반 데이터를 변환하는 과정입니다
이 기밀성을 충족할 방법은
우리가 데이터를 암호화하려고 할 때마다
특정 알고리즘을 따르고 이 암호화 알고리즘에
비밀 키(secret)를 제공하는 것입니다
이 비밀 키 값을 고려하여
암호화 알고리즘은 저의 일반 텍스트 비밀번호를
아무도 이해하지 못하는 형식으로 암호화합니다
일반 텍스트 비밀번호를 암호화한 다음에
특정 암호화 값의 일반 텍스트 비밀번호가
무엇인지 알고 싶다면
복호화를 해야 합니다
복호화는 암호화의 반대 과정입니다
누군가 특정 암호화 값을
일반 텍스트 비밀번호로
복호화하고 싶은 경우에는 무조건
암호화 과정에서 사용된 동일한 알고리즘과
동일한 비밀 키(secret) 또는 키를
사용해야 합니다
이 암호화 알고리즘과 비밀 키는
주로 백엔드 애플리케이션
내부에 기밀 데이터로 관리됩니다
그렇기 때문에 암호화가 인코딩보다 훨씬 낫습니다
여러분의 알고리즘 정보와
비밀 키 정보를 보호하는 한
아무도 여러분의 비밀번호를 해킹할 수 없으니
편하게 잠들 수 있습니다
하지만 여기에도 문제가 있습니다
여러분의 서버 관리자가 비밀 키와 알고리즘과 같은
변수에 접근할 수 있는
개발자 또는 테스터라는 것입니다
그들은 이 변수들을 손쉽게 활용하고
암호화 값을 복호화할 수 있으며
비밀번호를 악용할 수 있습니다
즉 암호화된 값을
일반 텍스트 비밀번호로 되돌릴
가능성이 있다는 것입니다
그렇기 때문에 이것 또한 비밀번호 관리에
고려하는 것을 추천하지 않습니다
물론 이 암호화와 복호화가
웹 애플리케이션에서
데이터베이스 또는 서버의
비밀번호를 저장하기 위해 종종 사용되는 것을
보셨을 수도 있고 속성 파일 내부의
민감한 데이터를 직접 언급하는 대신
파일 개발자들은 항상 암호화 방식으로
속성 파일 내부에 속성을 저장합니다
이 속성은 여러분의 데이터베이스 자격 증명이나
Mrs Q 자격 증명 또는 SMTP 자격 증명일 수 있습니다
하지만 이것은 일정 수준까지 허용 가능한데
여러분의 애플리케이션 자격 증명을 저장할 뿐
엔드 유저의 자격 증명을 저장하는 게 아니기 때문입니다
암호화가 인코딩보다 낫기는 하지만
이런 한계점들로 인해 엔드 유저 비밀번호 관리에
암호화도 고려해서는 안됩니다
이로써 우리에게는
마지막 옵션인 해싱만 남았습니다
다음 강의에서는 해싱이 무엇이고
비밀번호 관리에 어떻게 활용할 수 있는지
자세히 다루도록 하겠습니다
감사드리며 다음 강의에서 뵙겠습니다
수고하셨습니다