사용자의 비밀번호로 보호되는 개인 키와 쌍을 이루는 공개 키로 암호화하여 웹 응용 프로그램 데이터베이스의 PII를 보호합니까?

Question

목표 :

I 사용자가 질문을 작성하고 사용자 정의 웹 응용 프로그램에 다른 사용자의 정보를 수집 (PHP/MySQL을이 강해 호스팅 환경에서) 및 수집 된 데이터를 보호 할 수 있도록하고 싶습니다

.

배경 :

모든 사용자가 답변을들은 개인 식별 정보 (PII)으로 해석 할 수없는만큼 일반적입니다 기본 질문, 따라서 그것을 보호하기 위해 내 책임을 제한하지만, 사용자가 자신의 누가 만들 질문은 가능성이있는 PII를 요구할 것입니다.

나는이 정보를 보호하여 호스팅 계정 또는 데이터베이스가 손상되었거나 (또는 ​​둘 다!), PII가 상당한 양의 작업없이 복구 될 수 없도록 보호합니다. 이론적으로 작은 부분 만 복구 할 수 있습니다.

제안 된 솔루션 :

의 MySQL의 내장 PII 테이블을 암호화하는 데 사용되는 AES_ENCRYPT()/AES_DECRYPT() 기능, 암호는 호스팅 계정이 손상되었다, 그래서 만약 호스팅 계정에 저장해야 데이터를 가정 쉽게 읽을 수 있습니다.

사용자의 암호가 잘 보호되어 있기 때문에 (소금으로 해시 됨) 인증 과정에서 일반 텍스트 암호를 캡처하고 암호화 한 다음 사용자가 로그 아웃 할 때까지 PHP 세션에 저장하려고합니다.

개인 키가 사용자의 암호 + salt로 암호로 보호되어 공용/개인 키 조합이 각 사용자에 대해 만들어집니다.

그런 다음 해당 사용자의 사용자 정의 질문에 기반한 PII 데이터가 DB에 추가되면 사용자의 공개 키를 사용하여 앱을 통해 수집 한 개인 식별 정보를 암호화합니다. 데이터를 읽을 때 (사용자가 로그인 한 경우에만) 사용자의 개인 키 (암호 + 소금으로 잠금 해제 됨)로 데이터가 암호화되지 않습니다.

혜택 I은 ​​참조 :

서버가 완전히 손상 최악의 시나리오에

1. , 응용 프로그램 코드는 암호화 키를 찾을 수 읽기, PHP 세션 파일은 사용자의 암호, 다음 항목을 찾을 해독 해당 사용자와 연관된 PII 테이블의 암호가 해독되면 만 현재 로그인 한 사용자의 질문에서 수집 한 PII를 복구 할 수 있습니다. 로그인하지 않은 모든 사용자는 안전합니다.
2. DBA 또는 유사한 사람도 PII를 읽을 수 없습니다.

단점이 내가 볼 수 있습니다. 그들이에 로그온 한 상태

1. 사용자 암호는 복구 할 수있는 형태로 저장되어있는 데이터에 대한 액세스를 푸는 것이 자신의 암호를 잊어
2. 사용자를.
3. 비교적 작은 비트의 데이터는 암호화로 인해 DB에서 훨씬 많은 공간을 차지합니다.

내 질문 : 더 좋은 방법이 있나요?

Answer 1

보안 관점에서이 디자인에 몇 가지 문제점이 있음을 알았습니다. 우선 모든 암호는 암호화되어서는 안되며, 이는 CWE-257으로 식별되는 취약점입니다.

더보기 MySQL의 AES_ENCRYPT()은 여러 가지 이유로 인해 완전한 쓰레기입니다.

원본 이미지 : (어떤 MySQL의의 AES_ENCRYPT() 용도이다)

EBC 모드 :

이것이 쓰레기 이유의 좋은 예를 EBC 모드를 사용하고, 여기에

그러나 공격자가 손상된 데이터베이스가 을 활성화하여 AES_ENCRYPT()을 (를) 퇴치하려는 경우.

암호화를 위해 사용자의 암호를 사용하는 것을 피해야합니다. 사용자는 crypgoraphic nonce를 사용해야합니다. 암호를 사용하는 경우 String2Key 기능을 사용해야합니다. random iv과 함께 CBC 또는 CMAC 모드를 사용해야합니다. 나는 비대칭 암호화가 어떻게 도움이되는지를 정말로 보지 못합니다. 비대칭 암호화는 매우 느리고 메모리 집약적입니다. 암호화 된 텍스트 데이터를 비교할 수 있기 때문에 침입자가 메시지를 제어 할 때 보호하는 데이터가 덜 안전합니다. 이런 이유로 무작위 IV is important이고, 비대칭 세계에서는이 수준의 보호를받지 못합니다. $key=string2key($base_nonce.$salt.$user_password)

확실히 당신의 string2key 함수의 출력이 키 스페이스와 같은 크기의 확인 :

키 생성은 같은 것을 보일 것입니다. 따라서 AES 128에는 128 비트 키가 필요합니다. 각 암호는 자체적으로 $salt이어야하고 $base은 텍스트 파일에 저장된 암호화 논스입니다. (이 값이 128 비트와 같고 논점이 큰 경우 공격자는 키를 크랙하기 전에이 파일을 읽어야합니다.) 각 메시지는 자체적으로 $iv이 필요하며이 값은 암호화 nonce 여야합니다 (소금). 나는 $salt, $iv 및 $base_nonce을 /dev/urandom에서 생성합니다. IV는 암호 텍스트와 함께 데이터베이스의 컬럼에 일반 텍스트로 저장 될 수 있습니다.

보안 cryptogrpahic 시스템을 구축하더라도 내부자 위협에 여전히 문제가 있으며 서버가 완전히 손상된 경우 법적으로 모든 데이터가 손상됩니다. 이것은 실제로 엔지니어링 문제가 아닙니다.

법적 위협에 대한 최선의 방어는 숙련 된 변호사가 작성한 강력한 이용 약관입니다.

Answer 2

걱정거리는 다음과 같습니다. "로그인하지 않은 모든 사용자는 안전 할 것"이라는 부분은 너무 낙관적입니다. 사용자의 비밀 번호로 개인 키를 보호함으로써 다양한 비밀번호 무단 침입 공격까지 가능합니다. 현재 세션뿐만 아니라 모든 세션에 적용됩니다. 하나의 효과적인 하나는 단순히 상위 100 개의 공통 암호를 나열하고 모든 사용자에 대해이를 시험해 보는 것입니다. 공격자는 일부 키를 발견해야합니다. (나는 당신이 공격자가 볼 수있는 사용자 레코드와 함께 사용자 별 임의의 소금을 저장하고 있거나 침입자가 침입을 통해 얻을 수 있었던 비밀 소금을 가지고 있다고 가정하고 있습니다.)