보안 및 암호화 오류가 계속 발생할 수 있습니다.

참고: 최초 출시 martinheinz.dev
암호학과 안전성에 관해서는 통상적으로 많은 오해와 잘못된 가설이 있다.사람들은 암호화된 원어를 자주 남용하여 어떤 것이 기본적인 상황에서 안전하거나 유행이 지난 기술/알고리즘을 사용한다고 가정한다.그래서 이런 신화와 흔히 볼 수 있는 실수를 살펴보자. 그러면 미래에 그것을 피할 수 있다.

/dev/random 사용 중지

거의 모든 사람들이 암호화를 항상 사용해야 한다고 말할 것이다.응, 그건 틀렸어./dev/random 및 /dev/urandom 은 동일한 CSPRNG를 사용합니다.그것들 사이의 차이점은 엔트로피가 충분할 때까지 막는다는 것이다.이것은 또 다른 문제입니다. - 응용 프로그램이 엔트로피를 기다리고 /dev/random를 둘러싸고 막을 가능성을 고려하여 논리를 설계하는 것을 원하지 않습니다. 특히 엔트로피가 그렇게 많이 필요하지 않다는 것을 고려하면...당신이 필요로 하는 것은 약 256위의 엔트로피입니다. 당신은 /dev/random 에서 얻을 수 있습니다.이 주제를 깊이 연구하려면 문장here을 참조하십시오.

AES ECB를 사용하지 마십시오.

알다시피 AES는 그룹 암호입니다.그것은 128비트의 블록으로 순수한 텍스트를 암호화합니다.네, 괜찮은데 ECB 모드를 사용하는 데 무슨 문제가 있습니까?각 블록에 변하지 않는 키를 사용하기 때문에 128비트 이상의 데이터를 암호화하면 다음과 같은 메시지가 표시됩니다.


이것은 암호화라고 할 수 없죠?그렇다면 당신은 ECB를 대체하기 위해 무엇을 써야 합니까?카운터 모드(CTR)!왜?암호화는 병행할 수 있고 IV (nonce) 를 사용하여 변경되지 않은 키 문제를 없앨 수 있기 때문에 ECB 모델은 이런 특성을 가지고 있다.정맥 주사를 영원히 반복하지 말라는 것을 기억해라.
이것은 CTR 모드에서 암호 텍스트의 모양입니다.


너는 /dev/random로 스스로 시험해 볼 수 있다.

~ $ identify gopher.png
gopher.png PNG 650x650 650x650+0+0 8-bit sRGB 38.9KB 0.000u 0:00.000  # Note the dimensions
~ $ convert -depth 32 gopher.png gopher.rgba
~ $ openssl enc -aes-128-ecb -e -in gopher.rgba -out gopher-ecb.rgba -k toomanysecrets  # Replace ecb with other modes too (e.g. ctr)
~ $ convert -size 650x650 -depth 32 gopher-ecb.rgba gopher-ecb.png

D5를 사용하지 마십시오.

우리가 이제껏 사용한 적이 없는 것에 대해 이야기할 때...D5를 잊어버리세요. 예를 들면, 지금.그것은 안전한 암호화 산열 알고리즘으로 설계되었지만, 아직 안전하지 않다.충돌 빈틈이 있습니다. 동일한 MD5 해시를 가진 파일을 만들 수 있습니다. 이것은 SSL 또는 CA 인증서를 위조할 수 있다는 것을 의미합니다.
그럼 무엇으로 대체할까요?이것은 용례 - 암호 해시 사용/dev/urandom 또는openssl에 달려 있다.내가 보기에, 네가 어떤 것을 사용하느냐가 개인적인 선호이다. bcrypt 보다 더 좋게 설계되었지만, 그것은 갱신되었기 때문에 직면한 심사가 더욱 적다.개인적으로 여전히 사용scrypt.다른 용례는 SHA-2 시리즈의 해시 함수를 사용하십시오. 예를 들어 SHA-512와 같은 더 긴 요약이 좋습니다.

항상 암호화하고 MAC

이 절의 제목은 "암호화를 먼저 하고 MAC를 암호화한다"이지만, 먼저 거슬러 올라가 봅시다.많은 사람들이 암호화와 메시지 인증을 항상 결합해서 사용해야 한다는 것을 깨닫지 못한다.나는 당신이 왜 메시지에 대해 신분 검증을 해야 하는지 상세하게 토론하고 싶지 않다. 내가 말하고자 하는 것은, 만약 당신이 메시지에 대해 신분 검증을 하지 않는다면, 당신의 응용 프로그램은 재방송 공격이나 주동적인 공격 등 많은 가능한 공격에 직면하게 될 것이다.
그렇다면 왜 MAC을 암호화해야 합니까?간단하게 말하면 이것은 안전성을 증명할 수 있는 유일한 방법이다. 이것은 항상 필요한 것은 아니지만 이런 구조를 사용할 때 암호화를 망칠 수 없다는 것을 의미한다.
더 깊이 있는 설명을 원하신다면 Colin Percival의 글here을 추천합니다.

특수 문자는 당신의 비밀번호를 좋아지게 할 수 없습니다

적어도 꼭 그렇지는 않다.좋은 비밀번호는 기억할 수 있기 때문에 scrypt 문자를 입력하면 응용 프로그램 사용자가 잊어버리거나 다른 사람이 볼 수 있는 곳에 쓸 수 있습니다.
우선, 왜 비밀번호에 특수 문자를 추가합니까?이것은 엔트로피입니다. 그래서 만약에 우리가 사용자에게 암호에 특수 문자를 포함하도록 강요하고 싶지 않다면 어떤 대체 방법으로 충분한 엔트로피를 유지할 수 있습니까?
Looong으로 만들어.Popularxkcd Password Strength comic에서 보듯이 몇 개의 무작위 단어로 연결된 비밀번호를 사용하는 것이 헛소리를 기억하려는 것보다 의미가 있다.이런 암호를 만드는 것은 사람의 수요를 만족시킬 뿐만 아니라 컴퓨터의 수요도 만족시킨다. 다시 말하면 기억하기 쉽고 추측하기 어렵다. (고엔트로피, 폭력 수단이 없다.)
주의: 이상적인 세계에서 모든 사람들은 암호 관리자를 사용하고 그들의 무작위 초고엔트로피 암호를 생성하지만 이것은 우리가 기대할 수 있는 일반적이고 기술을 모르는 사용자가 아니다.

암호화 키 회전 오해

누군가가 너에게 일정 시간마다 키를 돌려야 한다고 말했을지도 모른다. 그래, 너는 절대로 이렇게 해야 한다.그러나 많은 사람들은 키가 파괴될 확률을 낮추기 위해 이렇게 해야 한다고 생각하지만, 암호화 키는 그렇지 않다.암호화 키를 바꾸어 키 암호화의 데이터 양을 줄이고 단일 키 유출로 인한 잠재적인 손실을 줄여야 합니다.이런 오해는 당신이 관건을 돌려야 한다는 사실을 바꾸지 않았지만, 중요한 것은 당신이 왜 이렇게 하는지 알아야 어떤 간격을 사용해야 하는지 정확하게 평가할 수 있다는 것이다.

사용자 암호를 저장하지 않음

다시 한 번 일하지 않는다는 화제로 돌아왔다.이것은 약간 으르렁거리는 것이다. 나는 이렇게 여러 번 본 적이 있다. 이 사이트가 나에게 보낸 이메일 비밀번호를 본 후에 나는 등록했다.좋아하다사용자로부터 비밀번호를 얻었을 때, 가장 먼저 해야 할 일은 비밀번호를 산열하고 버리는 명문 버전이다. 만약 당신이 이메일로 나에게 보냈다면, 당신은 분명히 이렇게 하지 않았을 것이다.
그럼, 우리 숨을 깊이 쉬자...그러면 이 비밀번호를 어떻게 저장합니까?
사용자로부터 비밀번호를 받으면 최소 12의 느린 산열 함수bcrypt를 사용하여 산열을 하고 메모리에서 명문 비밀번호를 삭제합니다.작업 계수 12는 발표될 때 현재 유효하며 1년 후에는 부족할 것이다.나는 개인적으로 400ms에 달하는 암호 검증을 찍을 것이다. 너는 너의 기계에서 어떤 작업 요소가 너에게 줄지 검사할 수 있다.
만약 bcrypt를 사용하지 않으려면 비밀번호에 소금을 추가해서 무지개 시계 공격과 같은 예상 공격을 방지하십시오.

용기가 안전하지 않다

많은 사람들이 Docker 컨테이너가 기본적으로 안전하다고 생각하지만 사실은 그렇지 않습니다.그것들은 보안 문제가 아니라 배치 문제를 해결하기 위한 것이다.
심지어 공격자!@#$%^&*가 호스트 시스템에 접근할 수 있도록 허용하는 빈틈도 존재하며, 필요한 것은 케이스가 용기에 대한 접근일 뿐이다.그렇다면 어떻게 이런 안전 문제와 빈틈을 피할 수 있을까?

가장 작은 기본 이미지를 사용하여 공격면을 줄입니다. 이 이미지의 예는 bcrypt 기반 이미지나 Red Hat universal 기반 이미지입니다.

필요한 라이브러리만 설치합니다. - 용기에 있는 라이브러리가 적을수록 이용할 가능성이 낮아집니다.

신뢰할 수 있는 이미지 사용 - Docker Hub에서만 이미지를 다운로드하지 마십시오.심사를 거쳐 신뢰할 수 있는 팀에서 유지하고 대량으로 다운로드(대량의 관심)를 하는 소프트웨어를 사용한다.

bcrypt 태그를 사용하지 마십시오 - 고정 태그를 사용하면 다음 구축에 빈틈이 없도록 할 수 있습니다.

사용 권한이 가장 낮은 사용자(영원히 root - 사용 권한이 없는 사용자를 위해 alpine 명령을 종료하는 것이 좋습니다latest. 용기를 열면 추가 빈틈이 생길 수 있습니다.

이미지를 보호하기 위해 더 많은 일을 할 수 있습니다. 잠시 후 구글에서 검색할 수 있지만, 위의 목록은 모든 사람이 Docker 이미지/용기를 사용할 때 기억해야 할 최소한의 요구라고 생각합니다.

결론

모든 소프트웨어 개발자/DevOps 엔지니어는 응용 프로그램과 시스템의 안전성에 대해 책임을 져야 합니다. 적어도 어느 정도는 그렇습니다.따라서 상술한 것처럼 어리석은 잘못과 오해를 피하기 위해 우리 모두가 필요한 연구를 해야 한다고 생각한다.
다른 사람이 너에게 알려준 것만 믿지 마라.보안과 암호화가 관련되었을 때, 사실에 따라 스스로 찾고 검사한다.