API 키와 암호를 사용하는 이유는 무엇입니까?

사용자에게 API 키 와 비밀을 모두 제공하는 많은 API를 발견했습니다 . 그러나 내 질문은 : 둘의 차이점은 무엇입니까?

내 눈에는 하나의 열쇠로 충분할 수 있습니다. 내가 키를 가지고 있고 나와 서버 만 알고 있다고 가정 해 보겠습니다. 이 키로 HMAC 해시를 만들고 API 호출을 수행합니다. 서버에서 HMAC 해시를 다시 생성하고 전송 된 해시와 비교합니다. 동일하면 호출이 인증됩니다.

그렇다면 왜 두 개의 키를 사용합니까?

편집 : 또는 API 비밀을 조회하는 데 사용되는 API 키입니까?

비밀 키 암호화는 동일한 키를 사용하여 메시지를 인코딩 한 다음 나중에 디코딩합니다. 따라서 "비밀"을 아는 사람 만 메시지를 읽을 수 있습니다.

RSA 보안은 2 개의 일치하는 키를 기반으로합니다. 각 사용자에 대한 공개 키가 있으며 모든 사람이이를 알고 있어야합니다. 사용자 만 알아야하는 개인 키도 있습니다. 공개 키로 암호화 된 메시지는 개인 키로 만 해독 할 수 있으며 그 반대의 경우도 마찬가지입니다.

따라서 내가 읽을 수있는 메시지를 보내려면 네트워크에서 공개 키를 가져 와서 해당 키로 메시지를 암호화하면 암호를 해독 할 수있는 유일한 사람입니다.

또는 내가 메시지를 보냈다는 것을 증명하고 싶다면 내 개인 키로 메시지를 암호화하고 (공개 텍스트 또는 다른 메시지로) 암호화 방법을 알려줄 수 있습니다. 그런 다음 내 공개 키로 메시지를 해독 할 수 있으며 읽을 수있게되면 내가 보낸 메시지임을 알 수 있습니다.

이 암호화 형식은 상당히 컴퓨터 집약적이므로 RSA 기술을 사용하여 일회성 "비밀 키"를 암호화 한 다음 비밀 키로 나머지 메시지를 암호화 한 다음 두 번째 방식으로 내 서명을 암호화하는 경우가 있습니다. 그런 다음이 프로세스를 되돌려 메시지와 서명을 읽을 수있는 경우 귀하와 귀하 만 읽을 수 있으며 내가 메시지를 보냈 음을 확인합니다.

또는

자세한 설명은이 링크를 참조하십시오.

API 키와 비밀 키는 어떻게 작동합니까?

두 개의 개별 키가 필요합니다. 하나는 귀하가 누구인지 알려주는 키이고 다른 하나는 귀하가 말하는 사람임을 증명하는 키 입니다.

"키"는 사용자 ID이고 "비밀"은 비밀번호입니다. 그들은 "키"와 "비밀"용어를 사용합니다. 그것이 그들이 그것을 구현 한 방법이기 때문입니다.

간단한 대답, 내가 올바르게 이해했다면 ...

암호화를 위해 API 키를 사용하는 경우 서비스는 누구에게 연락하는지 어떻게 알 수 있습니까? 그들은 그 메시지를 어떻게 해독할까요?

API 키를 사용하여 자신이 누구인지, 이것이 일반 텍스트로 보내는 것입니다. 누구에게도 보내지 않는 SECRET 키 . 암호화에 사용하면됩니다. 그런 다음 암호화 된 메시지를 보냅니다. 암호화에 사용 된 키를 보내지 않으면 목적이 무효화됩니다.

비밀 및 (공개) 키가 무엇인지 설명하는 답변이 있습니다. 혼란스러운 이름을 부여하는 공개-개인 키 쌍입니다. 그러나 API에 두 가지 모두가 필요한 이유는 아무도 말하지 않으며 많은 API는 하나의 비밀 만 제공합니다! 나는 또한 API 문서가 왜 두 개의 키가 있는지 설명하는 것을 본 적이 없으므로 내가 할 수있는 최선은 추측하는 것입니다 ...

요청에 공개 키만 입력하고 개인 키를 사용하여 로컬로 요청에 서명하는 것이 가장 좋습니다. 더 많은 것을 보낼 필요가 없습니다. 그러나 일부는 요청에 비밀을 가지고 도망칩니다. 좋아, 좋은 API는 TLS (일반적으로 HTTPS를 통해)와 같은 전송 보안을 사용합니다. 그러나 여전히 개인 키를 그런 방식으로 서버에 노출하고있어 어떻게 든 잘못 처리 할 위험이 증가합니다 (참조 : 최근에 발견 된 GitHub 및 Twitter의 암호 로깅 버그). 그리고 HTTPS는 이론적으로는 안전하지만 항상 구현상의 결함이 있습니다.

하지만 실제로 대부분의 경우 API는 사람들이 자신의 서명을하는 것보다 쉽기 때문에 요청에 두 키를 모두 보냅니다. 그렇지 않으면 순수한 cURL 예제를 가질 수 없습니다! 이 경우 분리하는 것은 의미가 없습니다. 별도의 키는 나중에 API를 변경하여 활용하는 경우를 대비 한 것 같습니다. 또는 일부는 더 안전한 방법으로 수행 할 수있는 클라이언트 라이브러리를 가지고 있습니다.

그것은, 마커스 아담스의 대답의 확장하지만 내가 여기에 언급을 참조하지 않았다고 한 것은 당신의 가능성이있는 경우를 식별하고 사용자를 인증 모두에 단일 정보를 사용하지해야한다는 것입니다 타이밍 공격 ,하는 수 응답 시간의 차이를 사용하여 문자열 비교가 얼마나 멀리되었는지 추측하십시오.

"키"를 사용하여 사용자 또는 자격 증명을 조회하는 시스템을 사용하는 경우 수천 개의 요청을 보내고 데이터베이스가 찾는 데 걸리는 시간을 검사하여 시간이 지남에 따라 해당 정보를 점진적으로 추측 할 수 있습니다. 찾기) 기록. "키"가 키의 단방향 해시 대신 일반 텍스트로 저장되는 경우 특히 그렇습니다. 사용자에게 키를 다시 표시 할 수 있어야하는 경우 사용자의 키를 일반 텍스트로 저장하거나 대칭 적으로 암호화 할 수 있습니다.

두 번째 정보 또는 "비밀"이 있으면 먼저 타이밍 공격에 취약 할 수있는 "키"를 사용하여 사용자 또는 자격 증명을 조회 한 다음 타이밍 안전 비교 기능을 사용하여 값을 확인할 수 있습니다. 비밀".

다음은 해당 함수의 Python 구현입니다.

https://github.com/python/cpython/blob/cd8295ff758891f21084a6a5ad3403d35dda38f7/Modules/_operator.c#L727

그리고 그것은 hmaclib (그리고 아마도 다른 것)에 노출됩니다 .

https://docs.python.org/3/library/hmac.html#hmac.compare_digest

여기서 주목해야 할 점은 비교되는 값이 입력 문자열의 문자가 변경 될 때마다 무작위로 변경되기 때문에 이러한 종류의 공격이 조회 전에 해시되거나 암호화 된 값에 대해 작동하지 않는다는 것입니다. 여기에 대한 좋은 설명을 찾았 습니다 .

API 키를 저장하는 솔루션은 다음과 같습니다.

1. 별도의 키와 비밀을 사용하고, 키를 사용하여 레코드를 조회하고, 타이밍 안전 비교를 사용하여 비밀을 확인합니다. 이를 통해 사용자에게 키와 비밀을 다시 표시 할 수 있습니다.
2. 별도의 키와 비밀을 사용하고, 비밀에 대해 대칭적이고 결정론적인 암호화를 사용하고, 암호화 된 비밀의 정상적인 비교를 수행합니다. 이를 통해 사용자에게 키와 시크릿을 다시 표시 할 수 있으며 타이밍에 안전한 비교를 구현하지 않아도됩니다.
3. 별도의 키와 비밀을 사용하고 비밀을 표시하고 해시하고 저장 한 다음 해시 된 비밀의 일반적인 비교를 수행합니다. 이렇게하면 양방향 암호화를 사용할 필요가 없으며 시스템이 손상 될 경우 보안을 유지하는 추가 이점이 있습니다. 사용자에게 다시 비밀을 보여줄 수 없다는 단점이 있습니다.
4. 단일 키를 사용 하여 사용자에게 한 번 보여주고 해시 한 다음 해시되거나 암호화 된 키의 일반적인 조회를 수행합니다. 단일 키를 사용하지만 사용자에게 다시 표시 할 수 없습니다. 시스템이 손상된 경우 키를 안전하게 유지하는 이점이 있습니다.
5. 단일 키를 사용 하여 사용자에게 한 번 보여주고 암호화 한 다음 암호화 된 비밀을 정상적으로 조회합니다. 사용자에게 다시 표시 될 수 있지만 시스템이 손상되면 키가 취약 해집니다.

이 중 3이 보안과 편리함의 가장 좋은 균형이라고 생각합니다. 키를 발급받을 때 많은 웹 사이트에서 구현되는 것을 보았습니다.

또한 실제 보안 전문가를 초청하여이 답변을 비판합니다. 나는 이것을 또 다른 논의 포인트로 사용하고 싶었습니다.