이것은 언뜻보기에는 끔찍한 아이디어처럼 들릴지 모르겠지만, 여기에는 나의 시나리오가 있습니다. 사용자 이름 인증을 사용하여 여러 WCF 끝점을 제공하는 Windows 서비스가 있습니다. 사용자 지정 인증자는 로컬 데이터베이스 (암호가 소금에 절인 SHA-1로 저장 됨)에서 사용자의 자격 증명을 조회하거나 다른 서비스에 WCF 요청을 만들어 암호의 유효성을 검사합니다. User 객체에는 내부 또는 외부의 열거 형을 사용하여 사용할 인증 소스를 나타냅니다.WCF 서비스의 메모리에 일반 텍스트 암호 캐싱
lookup + 해시 확인 또는 WCF 호출을 수행하는 것이 서비스에 대한 모든 단일 요청에 대해 비용이 많이 들기 때문에 사용자 이름/암호 정보를 캐시하고 싶습니다. 캐시의 각 항목에는 수명이 있으므로 캐시의 항목이 60 초인 경우에는 다음 요청시 인증자가 캐시 대신 원본 소스에 대한 자격 증명을 확인한 다음 업데이트합니다.
로컬 데이터베이스의 경우 사용자 이름/SHA1 쌍을 사전에 저장할 수 있으며 "내부"사용자의 각 요청에 대해 제공된 암호를 다시 해시하고 비교해야합니다. "외부"사용자의 경우 인증 자에게 제출 된 일반 텍스트 비밀번호 만 갖기 때문에 캐시를 해싱하고 캐시의 일부로 저장할 수 있습니다. 이렇게하면 데이터베이스 요청 또는 원격 서비스 호출의 오버 헤드를 확실히 줄일 수 있지만 매번 해시 작업을 수행해야합니다.
해당 서비스는 네트워크 보안뿐만 아니라 물리적 인 상태가 양호한 내부 서버에서 실행됩니다. 해시 된 버전을 저장하는 대신 캐시에 일반 텍스트 암호를 저장하는 것이 허용되는 방법입니까? 이 경우 내 위험은 프로세스 메모리를 덤프하고 암호를 얻는 공격자 인 것 같습니다. 그 위험을 받아 들일 수 있다고 생각하면 메모리에 일반 텍스트 암호를 사용하지 않아야하는 다른 이유가 있습니까?
평문 암호를 사용하도록 선택하면 SecureString이 내 위험을 어느 정도 제한 할 수 있다고 생각합니다. SecureString을 사용하는 것이 가치가 있습니까? (구현은 매우 둥근 것처럼 보입니까?) 나는 암호화되지 않은 암호를 지속적으로 저장하는 위험에 대해 잘 알고 있지만, 일반 텍스트 암호의 휘발성 저장소에 대한 동의가 무엇인지 확신 할 수 없습니다.
아주 좋은 점. 토론 후에는 WCF 사용자 지정 사용자 인증이 일반 텍스트로 암호를 전달한다는 것을 알았습니다. 따라서 특정 시점에서 메모리에 일반 텍스트 암호 (인증과 해당 변수가 GC'ed되었을 때)가 있습니다. 그래서 그들 (특히 하나의 만료)의 캐시를 가지고 우리의 위험을 많이 증가하지 않습니다. 좋은 점을 가져 주셔서 감사합니다. 토론에서 가져 왔으며 이것이 우리 환경에서 받아 들일 수 있다는 결론에 도달하는 데 도움이되었습니다. –