신용 카드 암호화를 위한 최고의 .NET 알고리즘이 있습니까?

https://stackoverflow.com/questions/41220

09-06-2019
|

문제

.NET System.Security.Cryptography 네임스페이스에는 신용 카드 정보를 암호화하는 데 사용할 수 있는 다소 당황스러운 알고리즘 모음이 있습니다.어느 것이 가장 좋나요?

상대적으로 짧은 문자열에 대해서는 분명히 안전해야 합니다.

편집하다:저는 영국에 거주하고 있으며, 3자리 CVV 번호가 저장되지 않는 한 암호화된 신용 카드 정보를 저장해도 괜찮다는 것을 알고 있습니다.그리고 좋은 답변을 주신 모든 분들께 감사드립니다.

해결책

공격은 아니지만 질문은 약간 "잘못"되었습니다."만병통치약" 해결책은 없습니다.일반적으로 암호화에 대해 읽어본 다음 몇 가지 위협 모델링을 수행하는 것이 좋습니다.스스로에게 물어봐야 할 몇 가지 질문(포괄적인 목록은 아님)은 다음과 같습니다.

암호화를 수행하는 모듈이 이를 해독해야 하는 모듈입니까(이 경우 대칭 암호화 사용) 아니면 이를 사용할 다른 모듈(다른 시스템에 있음)로 데이터를 보낼 것입니까(이 경우 공개 키를 고려해야 함) 암호화폐)
무엇으로부터 보호하고 싶나요?누군가 데이터베이스에 액세스하지만 소스 코드가 없는 경우(이 경우 암호화 키를 소스에 직접 하드코딩할 수 있음)?누군가 귀하의 로컬 네트워크를 스니핑하고 있습니까? (IPSec와 같은 투명한 솔루션을 고려해야 합니다)누군가가 귀하의 서버를 훔치고 있습니까(데이터 센터에서도 발생할 수 있습니다. 이 경우 전체 디스크 암호화를 고려해야 합니다).
정말로 데이터를 보관해야 합니까?신용카드 처리업체에 직접 전달하고 확인을 받은 후 삭제할 수는 없나요?클라이언트의 로컬 쿠키나 Flash LSO에 저장할 수 없나요?클라이언트에 저장하는 경우 쿠키에 넣기 전에 서버 측에서 암호화했는지 확인하세요.또한 쿠키를 사용하는 경우 http 전용으로 설정했는지 확인하세요.
데이터의 동등성을 비교하는 것으로 충분합니까(즉, 클라이언트가 나에게 제공한 데이터가 내가 가지고 있는 데이터와 동일합니까)?그렇다면 해시를 저장해 보세요.신용 카드 번호는 상대적으로 짧고 축소된 기호 집합을 사용하므로 해싱하기 전에 각각에 대해 고유한 솔트를 생성해야 합니다.

나중에 편집:동일한 범주의 표준 암호화 알고리즘(예: 3DES 및 AES - 둘 다 대칭 블록 암호임)의 강도는 비슷합니다.대부분의 (상업용) 시스템은 누군가가 암호화를 무차별 공격했기 때문에 손상된 것이 아니라 위협 모델링이 충분히 상세하지 않았기 때문에(또는 전혀 없었기 때문에) 손상되었습니다.예를 들어 모든 데이터를 암호화할 수 있지만 SQL 주입에 취약한 공개 웹 인터페이스가 있는 경우 큰 도움이 되지 않습니다.

다른 팁

그것은 중요하지 않습니다.

전체 카드 번호가 디스크에 닿아서는 안 됩니다.

중요한 것은 인증 코드입니다.

추적 등의 경우 마지막 4자리 xxxx xxxx xxxx 1234와 만료 날짜만 사용합니다.

카드 번호를 저장하려는 경우 암호화 선택은 인수 은행에서 의무화합니다.

당신이 인수자가 아닌 이상, 어떤 경우에는 오래된 유닉스 프로그래머/db2 담당자에게 물어봐야 합니다.

"클라이언트의 로컬 쿠키에 저장할 수 없나요?" <-- 절대 안 됨

나는 정말로 타당한 이유가 없는 한 쿠키를 저장해서는 안 되며 쿠키에 저장하는 것은 정말 나쁜 생각 - 그들은 단지 너무 쉽다 (누군가가 쿠키를 훔치면 어떻게 됩니까? 그러면 쿠키가 얼마나 암호화되어 있는지는 중요하지 않습니다.)

반복 결제가 필요한 경우 대부분의 CC 제공업체는 카드 번호를 전혀 유지하지 않고 초기 결제에서 일종의 토큰을 저장하여 이를 수행할 수 있는 방법을 제공합니다(마지막 4자리만 유지하여 고객에게 표시할 수 있음). 어떤 카드가 저장되어 있는지 알 수 있습니다).

정말, 하지 마세요!

또한 CCV 코드를 절대 보관해서는 안됩니다.

에 따라 PCI DSS 규정 준수 규칙을 준수하는 경우 업계 최고의 암호화 표준이면 충분합니다.따라서 256비트 키를 사용하는 3DES이면 충분합니다(다른 표준을 사용할 수도 있음).이것 좀 봐 http://pcianswers.com/2006/08/09/methods-of-encrypting-data/

여기서 무결성을 잊지 마세요.공격자가 키를 모르지만 암호문을 조작할 수 있는 경우 기본 암호화에 대한 위조 공격이 있습니다.다음과 같은 경우에는 특히 불쾌할 수 있습니다.

짧은 문자열을 암호화하고,
알려진 하위 문자열 포함

신용카드의 경우가 바로 그렇습니다.따라서 자체 체크섬을 롤링하지 않고 CBC 모드에서 System.Security.Cryptography AES 또는 3DES를 사용하는 것은 위험할 수 있습니다.읽다:비밀 키가 없는 공격자가 신용 카드 번호를 다른 신용 카드 번호로 바꿀 가능성이 있습니다.

타사 결제 게이트웨이를 사용하는 경우 번호를 저장할 필요가 없습니다.

요점이 없습니다.

3des는 꽤 좋습니다. 소금을 옆에 저장하고 표준 키를 데이터베이스나 구성 파일이 아닌 곳에 보관하세요.그렇게 하면 당신이 해킹당하더라도 해독할 수 없습니다.

고려해야 할 법적 측면도 있습니다.다른 곳의 상황은 모르겠지만 독일에서는 신용카드 번호를 저장할 수 없습니다.¹⁾. 기간. 암호화 여부와 저장 형식은 중요하지 않습니다.

당신들 모두 5월 do(여기서는 사법 지식 없이 기억에서 언급한 것입니다)는 마지막 4자리 숫자 및 계좌 번호와 함께 신용 카드 번호의 강력한 해시(SHA-256?)를 저장합니다.그리고 그렇습니다. 이러한 정보만으로 전체 숫자를 재구성하는 것은 쉽지 않습니다.법이 항상 논리적인 것은 아닙니다.

¹⁾ 단, 연방 인증 신용카드 기관인 경우는 제외됩니다.

힌트: 신용카드 번호를 저장하는 것이 합법적인지 조사해야 합니다.예를 들어 스웨덴에서는 다음 기관의 인증을 받아야 합니다. PCI(지불카드산업), 내부 및 외부 보안이 테스트되는 곳입니다(다른 많은 것들과 함께 오랫동안).

신용카드 정보를 저장하기 전에 한두 번 생각해 보아야 합니다. 잘못 입력할 경우 법적 비용이 많이 들 수 있기 때문입니다.

공개 키로 신용 카드를 암호화합니다.개인 키는 결제 처리기에만 제공하세요.그런 다음 결제 프로세서 기계는 데이터베이스에 쿼리하고 작업을 수행할 수 있으며, 항목을 추가한 기계를 포함하여 누구도 이를 해독할 수 없습니다.

PHP의 openssl_seal과 비슷하지만 원하는 경우 다른 알고리즘을 사용할 수도 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow