비밀 키를 시드로 사용하고 hmac sha1 (Amazon S3 방식)으로 서명 한 메시지로 요청의 일부 데이터를 사용하여 aproach와 같은 S3에 대해 논쟁했습니다. 에미 터와 서버가 알고있는 비밀 키로 데이터의 대칭 암호화를 지원하는 다른 개발자와 비교합니다.hmac sha1 서명과 대칭 데이터 암호화와 같은 REST 인증 S3
hmac sha1 대 symetric 키와 함께 서명 된 데이터를 사용하면 전자 메일에서 사용자 이름이나 암호를 암호화 할 필요가 없다는 점 이외에 어떤 이점이 있습니까?
무엇이 가장 쉬울까요? S3에서 대칭 암호화 또는 sha1 해시?
큰 선수들이 대칭 키없이 oauth 등을 사용한다면 확실한 이점이 있다는 것을 확신 할 수 있습니다.
hmac와 대칭 암호는 상호 배타적 인 아이디어가 아닙니다. 사실 AES-CMAC은 MAC (해시가 아닌)과 대칭 암호이며, AES-CMAC은 WPA 보안을 유지하는 암호화 기본 요소입니다. (WPA는 여전히 rainbow table을 사용하여 깨질 수 있지만).
이 경우 이국적인 인증 시스템이 필요하지 않습니다. 사용자 이름과 암호로 로그인하고 쿠키로 세션 상태를 유지하는 것은 구현하기 쉽고 안전하기 때문에 일반적으로 사용됩니다. Cookie와 같은 상태를 저장하면 더 이상 기술적으로 RESTful이 아니지만 그 일을 막을 수있는 방법은 없습니다.
그러나 인증면에서 나는 RSA와 같은 비대칭 암호화가 가장 안전하다고 믿습니다. (Amazon은 기본적으로 ssh 연결에 비대칭 암호화를 사용합니다.) 이렇게하면 공개 키만 저장할 수 있기 때문에 손상 될 서버에 인증 자격 증명을 사용할 수 없도록 할 수 있습니다. 또한 MITM 공격을 방어합니다. 많은 경우 HTTPS가 이미 클라이언트 인증서를 지원하기 때문에 REST로 이식 할 수 있습니다. 무료로 클라이언트 인증서에 서명 한 다음 verify them 자신을 서명 할 수 있습니다.
제대로 구현되면, hmac 대 대칭 암호의 강점은 대개 비밀의 강점에 달려 있습니다. 비밀 번호 같은 비밀 번호를 사용하는 경우, 두 시스템은 똑같이 매우 약합니다. 이러한 비밀은 커야합니다 (Cryptographically Secure Psudorandom Numbers). 염두에 두어야 할 또 다른 점은 대칭 암호가 제대로 구현하기 어렵다는 것입니다. 대부분의 프로그래머는 이것을 이해하지 못해서 스트림 암호를 사용할 때 PRNG를 재사용하거나 블록 암호를 사용할 때 잘못된 모드를 사용하고 IV를 남겨 둡니다. 반대로 HMACS는 매우 쉽게 구현하고 덜 갈 수 있습니다. 모든 것이 HTTPS를 통해 전송되고 hmac을 사용하고 있다면 보안 인증 시스템을 쉽게 구현할 수 있습니다. 대칭 암호를 구현하고 싶다면 Piratical Cryptography 사본을 얻어야합니다. 대칭 암호만으로 구성된 장이 너무 많아서 끔찍하게 잘못 될 수 있습니다. ssl은 키 분배를 고려해야하며, 대칭 키는 DH 키 교환을 사용합니다.
OWASP 상위 10 개, 특히 Broken Authentication and Session Management을 읽으십시오. 이것은 전체 세션에 대해 https를 사용해야하며 대부분의 웹 응용 프로그램 프로그래머는이를 인식하지 못합니다.
큰 차이점은 HMAC는 무결성을 제공하지만 개인 정보는 제공하지 않는 반면 암호화는 무결성없이 개인 정보를 제공한다는 것입니다. 많은 사용 사례는 모두이 필요하지만 어디에도 무결성이 필요하다고 생각할 수는 없습니다. HMAC는 암호화가 가능한 동반자 인 최소 요구 사항처럼 보입니다.
AES-CMAC은 어떤가? – rook