이 질문은 길이가 약간 다른 형태로 다루어졌습니다.
RESTful 인증
그러나 이것은 서버 측에서 해결합니다. 이것을 클라이언트 쪽에서 봅시다. 하지만 그렇게하기 전에 중요한 전주곡이 있습니다.
자바 스크립트 암호화는 희망이 없다
이에 대한 Matasano의 기사는 유명하지만 여기에 포함 된 교훈은 매우 중요합니다.
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
요약:
- 중간자 공격은 암호화 코드를 사소하게 대체 할 수 있습니다.
<script>
function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script>
- MITM (Man-in-the-Middle) 공격은 SSL 이외의 연결을 통해 모든 리소스를 제공하는 페이지에 대한 사소한 공격입니다.
- SSL을 사용하면 실제 암호화를 사용하게됩니다.
그리고 내 자신의 목록을 추가하려면 :
- 성공적인 XSS 공격으로 인해 SSL을 사용하는 경우에도 공격자가 클라이언트 브라우저에서 코드를 실행하게 될 수 있습니다. 따라서 모든 해치가 중단 된 경우에도 공격자가 실행 방법을 찾으면 브라우저 암호화가 여전히 실패 할 수 있습니다 다른 사람의 브라우저에있는 모든 자바 스크립트 코드
이것은 JavaScript 클라이언트를 사용하려는 경우 많은 RESTful 인증 체계를 불가능하거나 어리석게 만듭니다. 한번 보자!
HTTP 기본 인증
무엇보다도 HTTP 기본 인증. 가장 간단한 구성표 : 모든 요청마다 이름과 암호를 전달하십시오.
물론 모든 요청마다 Base64 (가역적으로) 인코딩 된 이름과 암호를 전달하기 때문에 SSL이 절대적으로 필요합니다. 전화를 듣는 사람은 누구나 사 용자 이름과 비밀번호를 추출 할 수 있습니다. "Basic Auth is insecure"인수의 대부분은 "Basic Auth over HTTP"에서 나온 것입니다.
브라우저는 기본 제공되는 HTTP 기본 인증 지원을 제공하지만, 추악하기 때문에 추악하기 때문에 앱에 사용해서는 안됩니다. 그러나 대안은 JavaScript에서 사용자 이름과 비밀번호를 숨기는 것입니다.
이것이 가장 RESTful 한 솔루션입니다. 서버는 상태에 대한 지식이 필요하지 않으며 사용자와의 모든 개별 상호 작용을 인증합니다. 일부 REST 애호가 (대부분은 짚맨)는 어떤 종류의 상태를 유지하는 것이 이단이며 다른 인증 방법을 생각하면 입에서 거품을 일으킬 것이라고 주장합니다. 이런 종류의 표준 준수에는 이론적으로 이점이 있습니다. Apache가 기본적으로 지원합니다. 원하는 경우 객체를 .htaccess 파일로 보호되는 폴더에 파일로 저장할 수 있습니다!
문제 ? 클라이언트 측에서 사용자 이름과 비밀번호를 캐싱합니다. 이로 인해 evil.ru에 더 나은 균열이 발생합니다. 가장 기본적인 XSS 취약점조차도 클라이언트가 자신의 사용자 이름과 암호를 악의적 인 서버로 전송시킬 수 있습니다. 비밀번호를 해시하고 솔트하여이 위험을 완화하려고 시도 할 수 있지만 다음을 기억하십시오. JavaScript Crypto is Hopeless . 앞에서 언급했듯이 브라우저의 기본 인증 지원에 영향을 미치지 만이 위험을 완화 할 수 있습니다.
HTTP 다이제스트 인증
jQuery로 다이제스트 인증이 가능합니까?
보다 "안전한"인증은 요청 / 응답 해시 챌린지입니다. 제외 자바 스크립트 암호화 가망 이 더 HTTP 기본 인증보다 복잡하지만 만드는 없으며, 그것은 단지 SSL을 통해 작동하고 당신은 여전히 클라이언트 측에서 사용자 이름과 암호를 캐시 할 수 있도록, 더 이상 보안 .
추가 서명 매개 변수를 사용한 쿼리 인증.
nonse 및 타이밍 데이터로 매개 변수를 암호화하고 (반복 및 타이밍 공격으로부터 보호) 또 다른 "보안"인증. 이것의 가장 좋은 예 중 하나는 OAuth 1.0 프로토콜입니다. 이는 내가 아는 한 REST 서버에서 인증을 구현하는 아주 놀라운 방법입니다.
http://tools.ietf.org/html/rfc5849
그러나 JavaScript 용 OAuth 1.0 클라이언트는 없습니다. 왜?
JavaScript Crypto는 희망이 없습니다 . JavaScript는 SSL없이 OAuth 1.0에 참여할 수 없으며 클라이언트의 사용자 이름과 비밀번호를 로컬에 저장해야합니다. 이는 다이제스트 인증과 같은 범주에 있습니다. HTTP 기본 인증보다 복잡하지만 더 안전하지는 않습니다 .
토큰
사용자는 사용자 이름과 비밀번호를 보내며, 요청을 인증하는 데 사용할 수있는 토큰을 얻습니다.
사용자 이름 / 암호 트랜잭션이 완료 되 자마자 민감한 데이터를 버릴 수 있기 때문에 이는 HTTP 기본 인증보다 조금 더 안전합니다. 토큰이 "상태"를 구성하고 서버 구현을 더 복잡하게 만들기 때문에 RESTful도 적습니다.
여전히 SSL
문제는 토큰을 얻기 위해 여전히 초기 사용자 이름과 비밀번호를 보내야한다는 것입니다. 민감한 정보는 여전히 타협 할 수있는 JavaScript에 영향을줍니다.
사용자의 자격 증명을 보호하려면 공격자가 JavaScript를 사용하지 않도록해야하며 여전히 유선으로 사용자 이름과 암호를 보내야합니다. SSL이 필요합니다.
토큰 만기
"이 토큰이 너무 길면 버리고 사용자를 다시 인증하게하십시오"와 같은 토큰 정책을 시행하는 것이 일반적입니다. 또는 "이 토큰을 사용할 수있는 유일한 IP 주소는 XXX.XXX.XXX.XXX"입니다. 이러한 정책 중 다수는 매우 좋은 아이디어입니다.
파이어시 핑
그러나 SSL이없는 토큰을 사용하는 것은 여전히 '사이드 재킹'이라는 공격에 취약합니다 : http://codebutler.github.io/firesheep/
공격자는 사용자의 자격 증명을 얻지 못하지만 여전히 사용자 인 것처럼 가장 할 수 있습니다.
tl; dr : 암호화되지 않은 토큰을 유선으로 전송한다는 것은 공격자가 해당 토큰을 쉽게 탐색하여 사용자 인 것처럼 가장 할 수 있다는 의미입니다. FireSheep는 이것을 매우 쉽게 만드는 프로그램입니다.
더 안전한 별도의 영역
실행중인 응용 프로그램이 클수록 민감한 데이터 처리 방식을 변경하는 일부 코드를 삽입 할 수없는 것이 절대적으로 어렵습니다. CDN을 절대 신뢰하십니까? 광고주? 자신의 코드 기반?
신용 카드 세부 사항에 공통적이며 사용자 이름과 암호에 덜 일반적입니다. 일부 구현자는 응용 프로그램의 나머지 부분과 별도의 페이지에 '민감한 데이터 입력'을 유지합니다. 사용자를 피싱하기가 어렵습니다.
쿠키 (토큰을 의미)
인증 토큰을 쿠키에 넣는 것이 가능하며 일반적입니다. 이것은 토큰으로 auth의 속성을 변경하지 않으며 더 편리한 것입니다. 이전의 모든 주장이 여전히 적용됩니다.
세션 (여전히 토큰을 의미합니다)
세션 인증은 단지 토큰 인증이지만 약간 다른 점이 있지만 약간 다른 것 같습니다.
- 사용자는 인증되지 않은 토큰으로 시작합니다.
- 백엔드는 사용자의 토큰에 연결된 '상태'개체를 유지 관리합니다.
- 토큰은 쿠키로 제공됩니다.
- 응용 프로그램 환경은 세부 정보를 추상화합니다.
그러나 그 외에도 토큰 인증과 다르지 않습니다.
이것은 상태 저장 서버에서 일반 ol RPC의 경로를 따라 더 나아가는 상태 객체를 사용하여 RESTful 구현에서 더 멀어집니다.
OAuth 2.0
OAuth 2.0은 "소프트웨어 B가 소프트웨어 X가 사용자 X의 로그인 자격 증명에 액세스하지 않고 소프트웨어 X가 사용자 X의 데이터에 액세스하는 방법"문제를 검토합니다.
구현은 사용자가 토큰을 얻는 표준 방법 일 뿐이며 타사 서비스에서 "이 사용자와이 토큰이 일치하면 현재 데이터를 얻을 수 있습니다."
그러나 기본적으로 OAuth 2.0은 토큰 프로토콜 일뿐입니다. 다른 토큰 프로토콜과 동일한 속성을 나타냅니다. 토큰을 보호하려면 SSL이 필요합니다. 토큰 생성 방식 만 변경됩니다.
OAuth 2.0이 도움을 줄 수있는 두 가지 방법이 있습니다.
- 다른 사람에게 인증 / 정보 제공
- 다른 사람으로부터 인증 / 정보 얻기
그러나 그것이 올 때, 당신은 단지 ... 토큰을 사용하고 있습니다.
질문으로 돌아 가기
따라서 귀하가 묻는 질문은 "토큰을 쿠키에 저장하고 환경의 자동 세션 관리가 세부 정보를 처리하도록해야합니까, 아니면 Javascript로 토큰을 저장하고 해당 세부 정보를 직접 처리해야합니까?"입니다.
그리고 그 답은 행복 합니다.
그러나 자동 세션 관리에 대한 것은 당신을 위해 무대 뒤에서 많은 마술이 일어나고 있다는 것입니다. 종종 이러한 세부 사항을 직접 관리하는 것이 더 좋습니다.
저는 21 살이므로 SSL은 그렇습니다
다른 대답은 다음과 같습니다. 모든 것을 위해 https를 사용하면 뇌물이 사용자의 비밀번호와 토큰을 훔칩니다.