c# - 데스크톱 앱에서 PasswordVault 보안을 사용할 때




.net wpf (3)

내 데스크톱 응용 프로그램 (WPF 기반)에서 Windows.Security.Credentials.PasswordVault 를 사용하여 사용자의 암호를 안전하게 저장하고 싶습니다. 이 MSDN 기사를 사용하여이 Windows 10 API에 액세스 할 수있었습니다.

몇 가지 실험을했는데 하나의 데스크톱 앱 (기본 UWP 앱이 아닌)에서 PasswordVault에 작성된 데이터는 다른 데스크톱 앱에서 읽을 수 있습니다. Desktop Bridge 기술로 내 데스크톱 응용 프로그램을 패키징하고 패키지 ID를 가지고 있어도이 취약점이 수정되지 않습니다.

모든 아이디어를 수정하고 앱의 데이터를 다른 앱에서 안전하게 저장하는 방법은 무엇입니까?

업데이트 : PasswordVault는 DPAPI 대한 추가 보안을 추가하지 않는 것으로 보입니다. 케이스가 부정적인 결과로 닫힙니다.


(이것은 내가 귀하의 게시물에 대해 이해할 수있는 것입니다)

이러한 종류의 API를 사용하는 경우 데스크톱 응용 프로그램 간의 데이터 액세스를 차단하는 실제 방법은 없습니다. http://www.hanselman.com/blog/SavingAndRetrievingBrowserAndOtherPasswords.aspx 자세히 설명합니다. 아마도 정보를 해독하기를 원할 것입니다.

메모리 액세스 제한이 어렵고, 사용자가 실행 한 코드는 항상 사용자가 검색 할 수 있으므로이를 제한하는 것은 어렵습니다.

Windows Data Protection API 사용을 고려해 보셨습니까? DPAPI

DPAPI는 암호 및 개인 키와 같은 중요한 응용 프로그램 데이터를 보호해야하는 개발자에게 도움이되는 사용하기 쉬운 서비스입니다.

WDPAPI는 운영 체제 및 Triple DES에서 생성 된 키를 사용하여 데이터를 암호화 / 해독합니다. 즉, 애플리케이션이 이러한 키를 생성 할 필요가 없다는 것을 의미합니다.

Rfc2898DeriveBytes 클래스를 사용할 수도 있습니다.이 클래스는 의사 난수 생성기를 사용하여 암호를 해독합니다. 결과에서 암호로 돌아갈 실질적인 방법이 없으므로 대부분의 암호 해독기보다 안전합니다. 이는 입력 된 비밀번호를 확인하고 다시 검색하지 않는 경우에만 유용합니다. 나는 너를 도울 수 없기 때문에 나는 실제로 이걸 사용하지 않았다.

https://msdn.microsoft.com/en-us/library/system.security.cryptography.rfc2898derivebytes(v=vs.110).aspx

내가 할 수있는 것보다 더 나은 설명을주는이 게시물을 참조하십시오. 안전하게 사용자 이름 / 암호 (로컬)를 저장하는 방법?

내가 어떤 식 으로든 질문을 오해 한 경우, 대답을 업데이트하려고합니다.

현대 / 지하철 앱에는 다른 방법으로 액세스 할 수 있지만이 문제는 없습니다.


기타 암호화 및 저장 전략을 사용하여 항상 보안을 강화할 수 있습니다. 더 어려운 것을 만드는 것은 데이터 검색을 더 길게 만드는 것입니다. 따라서 실행 비용 x 시간 (사람 및 기계) 및 개발 비용 x 시간 측면을 고려하여 가장 적절한 보호 수준을 고려해야합니다.

귀하의 요청을 엄격하게 고려한다면 암호를 암호화하는 계층 (클래스, 인터페이스)을 추가하기 만하면됩니다. RSA가 아닌 비대칭 암호화에 가장 적합합니다. 다른 소프트가 프로그램 데이터 (프로그램, 파일 또는 프로세스)에 액세스하지 않는다고 가정하면 충분합니다. SSH.NET ( https://github.com/sshnet/SSH.NET )을 사용하면이를 신속하게 수행 할 수 있습니다.

보안을 강화하고 이진 역 공학 (개인 키 검색 포함)에 대한 일정 수준의 보호를 제공하려는 경우 작은 (프로세스 제한적) 암호화 된 VM (Docker, https://blogs.msdn.microsoft.com/mvpawardprogram/2015/12/15/getting-started-with-net-and-docker/ 과 같은)을 사용하는 것이 좋습니다 https://blogs.msdn.microsoft.com/mvpawardprogram/2015/12/15/getting-started-with-net-and-docker/ ) Denuvo ( https://www.denuvo.com/ )와 같은 솔루션을 기반으로합니다. 암호화는 고객 및 기계별로 고유합니다. 모든 in-memory ciphering-deciphering을 수행 할 ac / c ++ 프로그램 (컨테이너처럼 작동)에 C # 프로그램을 캡슐화해야합니다.

필요로하는 투자 및 보증의 종류에 따라 자신 만의 전략을 구현할 수 있습니다.

당신의 프로그램이 백엔드 프로그램이라면, 클라이언트 측에 개인 키를 저장하고, 백엔드 쪽의 공개 키를 저장하고, 로컬 암호를 해독하는 모든 전략 중 가장 좋은 전략을 선택할 수 있습니다. 따라서 암호화되어야합니다. 나는 패스워드와 키가 실제로 동일한 목표를 달성하기위한 다른 전략이라고 말하고 싶다. 프로그램이 그 사람의 신원을 알지 못하고 올바른 사람과 대화하는지 점검한다. 내 말은 : 암호를 저장하는 대신 공개 키를 직접 저장하는 것이 좋습니다.


어려운 사실은 데스크탑 응용 프로그램에 암호를 100 % 안전하게 저장하는 것이 불가능하다는 것입니다. 그러나 100 %에 가까워 질 수 있습니다.

원래 접근법 과 관련하여, PasswordVault는 창에 내장되어있는 Credential Locker 서비스를 사용하여 안전하게 데이터를 저장합니다. 자격 증명 보관함은 사용자의 프로필에 바인딩됩니다. 따라서 PasswordVault를 통한 데이터 저장은 데이터 보호를위한 마스터 비밀번호 접근 방식과 본질적으로 동일합니다. 자세한 내용은 아래에서 자세히 설명합니다. 유일한 차이점은이 경우 마스터 비밀번호가 사용자의 자격 증명이라는 점입니다. 이를 통해 사용자 세션 중에 실행중인 응용 프로그램이 데이터에 액세스 할 수 있습니다.

참고 : 명확히 말하면 일반 텍스트에 액세스 할 수있는 방식으로 저장하는 것에 대해 엄격히 말합니다. 즉, 암호화 된 데이터베이스에 저장하거나 암호화하고 암호문을 어딘가에 저장하는 것입니다. 이러한 종류의 기능은 암호 관리자와 같은 프로그램에서는 필요하지만 일종의 인증이 필요한 프로그램에서는 필요하지 않습니다. 이것이 필수 사항이 아니라면 암호를 해싱 하는 것이 좋습니다. 이상적으로는 zaph this 응답에 제시 한 지침에 따라 수행하는 것이 가장 좋습니다. Thomas Pornin this 훌륭한 게시물에서 더 많은 정보를 제공 this .

필요하다면 상황 좀 더 복잡해집니다. 다른 프로그램 (또는 내가 생각하는 사용자)이 일반 텍스트 비밀번호를 볼 수 없도록하려는 경우 실제 옵션은 암호화하는 것뿐입니다. PasswordVault에 암호문을 저장하는 것은 선택 사항입니다. 올바른 암호화를 사용하면 단점은 키를 발견하는 것입니다. 따라서 암호문 자체는 어느 곳에 나 저장할 수 있습니다. 그것은 우리를 열쇠 자체로 데려옵니다.

실제로 각 프로그램 인스턴스에 저장하려고하는 암호의 수에 따라 키 생성하고 안전하게 저장하는 것에 대해 걱정할 필요가 없을 수도 있습니다. 여러 암호를 저장하려면 사용자에게 하나의 마스터 암호 를 입력하고 일부 암호 해시 및 해싱을 수행 한 다음 그 결과를 다른 모든 암호의 암호화 키로 사용하도록 요청하면됩니다. 암호를 해독 할 시간이되면 사용자에게 암호를 다시 입력하라고 요청하십시오. 여러 암호를 저장하는 경우이 접근 방식을 강력히 권장합니다. 가능한 가장 안전한 방법 입니다. 그러나 나머지 내 게시물에 대해서는 실행 가능한 옵션이 아니라고 가정합니다.

먼저 모든 설치에 대해 동일한 키를 사용 하지 않기를 바랍니다. 안전하게 생성 된 무작위 데이터를 기반으로 프로그램의 모든 인스턴스에 대해 새 인스턴스를 만듭니다. 시스템에 대한 정보를 기반으로 필요할 때마다 즉각적으로 생성되도록하여 "키를 저장하지 않아도되는"유혹에 저항하십시오. 하드 코드 string superSecretKey = "12345"; 만큼 안전 string superSecretKey = "12345"; 귀하의 프로그램에. 공격자가 프로세스를 이해하는 데 오래 걸리지는 않습니다.

자, 저장하는 것은 정말 까다로운 부분입니다. infosec의 일반적인 규칙은 다음과 같습니다.

물리적 액세스 권한이 있으면 아무 것도 안전하지 않습니다.

그래서, 이상적으로, 아무도 것입니다. 적절하게 보안 된 원격 서버에 암호화 키를 저장하면 공격자가 복구 할 가능성이 최소화됩니다. 서버 측 보안과 관련하여 전체 서적이 작성되었으므로 이에 대해서는 여기서 논의하지 않겠습니다.

또 다른 좋은 옵션은 HSM ( 하드웨어 보안 모듈 )을 사용하는 것입니다. 이 멋진 작은 장치가 작업을 위해 만들어졌습니다. HSM에 저장된 키에 액세스하는 것은 거의 불가능합니다. 그러나이 옵션은 엔터프라이즈 환경과 같이 모든 사용자의 컴퓨터에 이러한 컴퓨터 중 하나가 있다는 것을 알고있는 경우에만 실행 가능합니다.

.Net은 구성 시스템을 통해 일종의 솔루션을 제공합니다. app.config 의 암호화 된 섹션에 키를 저장할 수 있습니다. 이것은 종종 연결 문자열을 보호하는 데 사용됩니다. 이 작업을 수행하는 방법에 대한 많은 리소스가 있습니다. 나는 당신이 알 필요가있는 것을 대부분 말해 줄 this 환상적인 블로그 포스트를 추천 this .

이전에 간단하게 키를 생성하지 말라고 말한 이유는 코드에 변수를 저장하는 것과 같이 독점적으로 보안을 유지하기 위해 난독 화 에만 의존하기 때문입니다. 이 방법에 대한 문제는 대개는 그렇지 않다는 것 입니다. 그러나 때로는 다른 옵션이 없습니다. 화이트 박스 암호를 입력하십시오.

화이트 박스 암호화는 근본적으로 난해한 난독 화입니다. 공격자가 바이트 코드에 액세스하고 바이트 코드를 수정할 수있는 화이트 박스 시나리오에서도 효과적입니다. 그것은 모호함을 통한 보안의 전형입니다. 단순한 상수 숨김 (infosec은 string superSecretKey 접근법을 string superSecretKey ) 또는 필요할 때 키를 생성하는 것과는 달리, 화이트 박스 암호화는 본질적으로 암호 자체 를 생성하는 것에 의존합니다.

전체 papers 이 적어졌으며, 적절한 구현을 작성하기가 어렵고 마일리지가 다를 수 있습니다. 가능한 한 안전하게이 작업을 정말로 실제로 수행 하려는 경우에만 이것을 고려해야합니다.

그러나 난독 화는 여전히 난독 화입니다. 정말 할 수있는 일은 공격자의 속도를 늦추는 것입니다. 내가 제공해야하는 최종 해결책은 거꾸로 보일 수도 있지만 작동합니다. 암호화 키를 디지털 방식으로 숨기지 마십시오. 그것을 물리적으로 숨 깁니다. 사용자가 암호화 할 때 USB 드라이브를 삽입하게하고 임의로 키를 생성 한 다음 usb 드라이브에 기록합니다 (안전하게 생성). 그런 다음 암호 해독 할 때마다 사용자는 드라이브를 다시 넣기 만하면 프로그램에서 키를 읽습니다.

이는 마스터 비밀번호 접근 방식과 조금 비슷합니다. 즉, 키를 안전하게 유지하기 위해 사용자에게 남겨 둡니다. 그러나 몇 가지 주목할만한 장점이 있습니다. 예를 들어,이 접근 방식은 방대한 암호화 키를 허용합니다. 단순한 1 메가 바이트 파일에 들어갈 수있는 키는 무차별 공격을 통해 깨기까지 수십억 년이 걸릴 수 있습니다. 또한 키가 발견되면 사용자는 자신을 비난해야합니다.

요약 하면 암호화 키를 저장하지 않아도되는지 확인하십시오. 할 수 없다면 모든 비용을 들이지 않고 로컬 에 저장하지 마십시오. 그렇지 않으면 해커가 가능한 한 알아 내려고하지 않는 것이 좋습니다. 어떻게 할지라도 모든 키가 다른지 확인하십시오. 따라서 공격자가 키를 찾더라도 다른 사용자의 키는 안전합니다.





passwordvault