API 보안 : SSL 및 HTTP 기본 인증과 서명
웹 앱용 API를 디자인 할 때 하위 도메인을 '사용자 이름'으로 사용하고 API 키 / 공유 비밀을 생성합니다. 첫째, 사용자 이름으로 하위 도메인을 사용해도됩니까? 다른 키 생성의 이점이 보이지 않습니다.
다른 API는 다음 두 가지 중 하나를 수행하는 것 같습니다.
- SSL과 함께 HTTP 기본 인증 사용
모든 요청에서 사용자 이름은 하위 도메인에 설정되고 암호는 API 키에 설정됩니다. SSL을 사용하고 있으므로 스푸핑으로부터 안전해야합니다.
주목할만한 API : Google Checkout , Freshbooks , GitHub , Zendesk
- 공유 비밀을 사용하여 요청 서명 생성
일반적으로 키 / 값 쌍을 주문하고 공유 암호와 함께 HMAC-SHA1을 사용하여 서명을 생성하면됩니다. 그런 다음 서명은 요청과 함께 전송되고 다른 쪽 끝에서 확인됩니다.
주목할만한 API : Google Checkout , Amazon AWS
추신 : 실수가 아닙니다. Google Checkout은
편집 : OAuth 2가 SSL을 통해 사용자 이름 / 암호를 전송하기 위해 서명을 삭제하고 있다는 것을 읽으십시오.
무엇을 선택할지에 대한 의견이 있으십니까? SSL 대 서명?
SSL을 통한 HTTP 기본 인증은 내 연구에서 완벽하게 안전합니다.
결국 SSL (엄격히 TLS)을 사용한다는 것은 전송 계층이 암호화된다는 것을 의미하며이를 통해 전달되는 모든 정보가 안전하고 변조되지 않았다고 가정 할 수 있습니다.
따라서 서명을 생성하지 않고 사용자 이름과 암호를 전달하는 것으로 충분합니다.
이고르의 대답은 전적으로 사실이 아닙니다. TLS는 전송 계층이 암호화되고 안전함을 보장하지만 클라이언트가 디지털 서명의 형태로 "강력한 암호화"를 사용하여 인증하는 상호 인증과 함께 TLS를 사용하는 것만 큼 안전하지는 않습니다. 이것이 TLS를 통한 기본 인증보다 나은 이유는 두 가지입니다.
암호는 암호이며 지구상의 70 억 명 중 3 명이 완전히 무작위 인 30 자 암호를 사용한다고 가정합니다. 나머지 우리는 엔트로피가 훨씬 적은 것을 선택했습니다. 따라서 공격자가 디지털 서명 대신 암호를 사용하는 서비스를 무차별 대입하는 것이 훨씬 쉽습니다.
클라이언트 측 디지털 서명의 경우 일반적으로 개인 키에 액세스하기위한 암호도 포함되어 있다고 주장 할 수 있습니다. 그러나 이것은 여전히 기본 인증을 사용하는 것과는 훨씬 다른 상황입니다. 먼저 개인 키는 클라이언트 컴퓨터의 리소스로 상주하므로 복구하더라도 모든 사람이 아닌 한 사람에게만 영향을 미치고 두 번째는 일반적인 키의 경우 PKCS # 12와 같은 컨테이너 형식에는 키에 액세스하는 데 사용되는 암호 기반 암호화도 있습니다. 이러한 알고리즘은 공격자의 속도를 늦추어 단위 시간당 무차별 대입 시도 비율을 낮추도록 특별히 설계되었으며, 이는 다시 디지털 서명의 이점입니다.
TLS Basic Auth가 설정하고 사용하는 것이 훨씬 더 편리하다는 것은 의심의 여지가 없지만 높은 보안 환경에서는 항상 사용자 / 암호 솔루션보다 "강력한 암호화"를 선호하므로 문제가 될만한 가치가 있습니다.
OpenSSL의 Heartbleed 문제는 API 보안을 위해 SSL에만 의존하는 잠재적 인 함정을 보여줍니다. API의 사용 및 SSL 전송이 손상된 경우 영향에 따라 Emboss의 답변에 언급 된대로 추가 보안 조치를 취해야 할 수 있습니다.
어떤 형태의 비밀이있는 한 하위 도메인을 사용자 이름으로 사용해도됩니다.
공유 비밀 사용의 이점은 요청을 수행하는 '당사자'가 비밀을 알 필요가 없으며 요청을 수행하기 위해 서명 만 알면된다는 것입니다. 예를 들어 사용자가 브라우저를 통한 요청을 허용하도록하려는 경우 유용합니다.
S3를 사용하면 서명을 생성하고 브라우저로 보내고 브라우저에서 S3로 직접 업로드 할 수 있습니다.
두 가지 이점이 모두있는 HTTP Digest를 사용할 수도 있습니다. 브라우저는 Digest 및 Basic을 지원하고 일반 텍스트 비밀번호는 유선으로 전송되지 않으므로 브라우저에서 API를 쉽게 테스트 할 수 있습니다.
"SSL을 통한 HTTP 기본 인증은 내 연구에서 완벽하게 안전합니다."라고 말씀 하셨기 때문에 security.stackexchange.com에서 언급 한 몇 가지 사항을 지적하고 싶습니다. 아래의 3 번과 4 번 항목은 REST API에 거의 유효하지 않지만 실제로 구현 방법에 따라 다르다고 주장 할 수 있습니다.
"HTTP 기본 인증에는 몇 가지 문제가 있습니다.
- 암호는 base64 인코딩 (일반 텍스트로 쉽게 변환 할 수 있음)으로 유선을 통해 전송됩니다.
- 각 요청에 대해 암호가 반복적으로 전송됩니다. (더 큰 공격 창)
- 암호는 최소한 창 / 프로세스 길이 동안 웹 브라우저에 의해 캐시됩니다. (서버에 대한 다른 요청 (예 : CSRF)에 의해 자동으로 재사용 될 수 있습니다.)
- 사용자가
요청 하면 비밀번호가 브라우저에 영구적으로 저장 될 수 있습니다 . (이전 포인트와 동일
하며 공유 머신에서 다른 사용자 가 도난 당할 수도 있습니다 .)
그중 SSL을 사용하면 첫 번째 문제 만 해결됩니다. 또한 SSL은 웹 서버가 내부 라우팅, 서버 로깅 등 일반 텍스트 비밀번호를 볼 때까지만 보호합니다.
따라서 전체 그림을 보는 것이 중요합니다. HTTPS는 전송중인 암호를 보호합니까? - 예.
충분합니까? 일반적으로 아닙니다. (항상 아니오라고 말하고 싶지만 사이트가 무엇이고 얼마나 안전해야하는지에 따라 다릅니다.) "
아무도 주요 요점을 실제로 다루지 않았기 때문에 오래된 스레드에 응답
SSL / TLS는 MiM 공격에 점점 더 취약한 것으로 입증 된 신뢰 체인에 의존하기 때문에 모든 PKI와 마찬가지로 근본적으로 결함이 있습니다 .
인증 기관이 해킹 당했으며 해킹 당할 수 있습니다. 그 중 한 가지 예 는 모든 인증서가 해지 된 것으로 확인되기 전에 CA가 몇 달 동안 손상된 DigiNotar 사례입니다. 그 동안이란 정부는 google.com, facebook.com, twitter.com 등에 대해 완벽하게 유효한 SSL 인증서를 위조했습니다.
지정되지 않은 "보안 목적"을 위해 모든 트래픽을 즉시 해독하고 다시 암호화하는 Zscaler와 같은 회사 프록시 필터링 도구입니다. 이 질문 / 답변을 참조하십시오.
가장 일반적인 SSL 구현 (openSSL)의 버그는 항상 발견됩니다 (하지만 시간이 지남에 따라 상황이 개선되어야합니까?).
따라서 큰 플레이어는 SSL에만 의존하는 것을 좋아하지 않습니다.
이 경우 HMAC 토큰 은 기밀성을 제공하지 않지만 누가 당신을 염탐하는 사람이 당신의 자격 증명으로 요청 을 위조 하는 것을 허용하지 않을 것입니다. 이는 기본 인증을 통해 전달했다면 사소한 일입니다.
PKI 모델의 대안 은 인증서의 진위를 확인하기 위해 단일 기관에 의존하지 않고, 알려진 신뢰할 수있는 피어의 대다수가 제공하는 의견에 의존하는 신뢰 웹입니다.
This model isn't still perfect though as it's subject to the notorious 51% attack exactly like for the Bitcoin Blockchain (that is an example of a distributed trusted model)
'program story' 카테고리의 다른 글
| Vim에 자동으로 일치하는 중괄호 삽입 (0) | 2020.11.21 |
|---|---|
| "localhost"포트 25에서 메일 서버에 연결하지 못했습니다. (0) | 2020.11.21 |
| 모바일 사파리 : 입력 필드의 Javascript focus () 메서드는 클릭으로 만 작동합니까? (0) | 2020.11.21 |
| JAX-RS에 대한 @PATCH 어노테이션을 갖는 방법은 무엇입니까? (0) | 2020.11.21 |
| console.log 대신 angular의 $ log를 사용하는 이유는 무엇입니까? (0) | 2020.11.21 |