양식 기반 웹사이트 인증에 대한 최종 가이드 [닫기]

08-06-2019
|

문제

웹사이트에 대한 양식 기반 인증

우리는 스택 오버플로가 매우 특정한 기술적 질문에 대한 리소스일 뿐만 아니라 일반적인 문제의 변형을 해결하는 방법에 대한 일반적인 지침을 제공해야 한다고 믿습니다."웹사이트에 대한 양식 기반 인증"은 이러한 실험에 적합한 주제입니다.

여기에는 다음과 같은 주제가 포함되어야 합니다.

로그인 방법
로그아웃하는 방법
로그인 상태를 유지하는 방법
쿠키 관리(권장 설정 포함)
SSL/HTTPS 암호화
비밀번호를 저장하는 방법
비밀 질문 사용하기
사용자 이름/비밀번호 기능을 잊어버렸습니다.
사용 논스 방지하기 위해 크로스 사이트 요청 위조(CSRF)
오픈아이디
'기억하기' 체크박스
사용자 이름과 비밀번호의 브라우저 자동 완성
비밀 URL(공개 URL 다이제스트로 보호됨)
비밀번호 강도 확인
이메일 검증
그리고 더 많은 것에 대해 양식 기반 인증...

다음과 같은 내용은 포함되어서는 안 됩니다.

역할 및 권한 부여
HTTP 기본 인증

다음을 통해 우리를 도와주세요:

하위 주제 제안
이 주제에 관한 좋은 기사 제출
공식 답변 편집

해결책

1부:로그인 방법

인증을 위해 서버측 스크립트에 값을 게시하는 로그인+비밀번호 HTML 양식을 작성하는 방법을 이미 알고 있다고 가정합니다.아래 섹션에서는 건전하고 실용적인 인증을 위한 패턴과 가장 일반적인 보안 함정을 피하는 방법을 다룹니다.

HTTPS로 갈 것인가, 아니면 HTTPS로 하지 않을 것인가?

연결이 이미 안전하지 않은 한(즉, SSL/TLS를 사용하여 HTTPS를 통해 터널링됨) 로그인 양식 값은 일반 텍스트로 전송됩니다. 이를 통해 브라우저와 웹 서버 사이를 도청하는 사람은 누구나 로그인을 읽을 수 있습니다. 을 통해.이러한 유형의 도청은 정부에서 일상적으로 수행되지만 일반적으로 우리는 다음과 같이 말하는 것 외에 '소유' 전선에 대해서는 다루지 않을 것입니다.중요한 것을 보호하려면 HTTPS를 사용하세요.

본질적으로 유일한 현실적인 로그인 중 도청/패킷 스니핑으로부터 보호하는 방법은 HTTPS 또는 다른 인증서 기반 암호화 체계(예: TLS) 또는 입증되고 테스트된 시도-응답 체계(예: 디피-헬먼기반 SRP). 다른 방법은 쉽게 피할 수 있습니다 도청 공격자에 의해.

물론 약간 비실용적이라면 어떤 형태의 이중 인증 체계(예:Google Authenticator 앱, 물리적 '냉전 스타일' 코드북 또는 RSA 키 생성기 동글).올바르게 적용하면 보안되지 않은 연결에서도 작동할 수 있지만 개발자가 SSL이 아닌 2단계 인증을 기꺼이 구현할 것이라고 상상하기는 어렵습니다.

(하지 마세요) 자체 JavaScript 암호화/해싱 롤업

웹사이트에 SSL 인증서를 설정하는 데 드는 비용과 기술적인 어려움을 감안할 때 일부 개발자는 보안되지 않은 회선을 통해 일반 텍스트 로그인이 전달되는 것을 피하기 위해 자체 브라우저 내 해싱 또는 암호화 체계를 적용하려는 유혹을 받습니다.

이것은 고귀한 생각이지만 본질적으로 쓸모가 없습니다. 보안 결함) 위의 방법 중 하나와 결합되지 않는 한, 즉 강력한 암호화로 회선을 보호하거나 검증된 시도-응답 메커니즘을 사용하는 것(이것이 무엇인지 모르는 경우에는 그것이 무엇인지 알아두십시오) 디지털 보안 분야에서 증명하기가 가장 어렵고, 설계하기가 가장 어렵고, 개념을 구현하기가 가장 어렵습니다.

비밀번호를 해싱하는 것은 사실이지만 될 수 있다 에 대하여 효과적인 비밀번호 공개, 재생 공격, Man-In-The-Middle 공격/하이재킹에 취약합니다(공격자가 브라우저에 도달하기 전에 보안되지 않은 HTML 페이지에 몇 바이트를 삽입할 수 있는 경우 JavaScript에서 해싱을 간단히 주석 처리할 수 있습니다). 또는 무차별 대입 공격(공격자에게 사용자 이름, 솔트 및 해시 비밀번호를 모두 전달하므로).

인류에 대한 보안 문자

보안문자 특정 범주의 공격을 방지하기 위한 것입니다.인간 조작자 없이 자동화된 사전/무차별 시행착오.이것이 실제 위협이라는 점에는 의심의 여지가 없습니다. 그러나 CAPTCHA가 필요하지 않고 원활하게 처리할 수 있는 방법, 특히 적절하게 설계된 서버 측 로그인 제한 체계가 있습니다. 이에 대해서는 나중에 논의하겠습니다.

CAPTCHA 구현은 동일하게 생성되지 않습니다.인간이 해결할 수 없는 경우가 많으며, 대부분은 실제로 봇에 대해 효과가 없으며, 모두 값싼 제3세계 노동력에 대해 효과가 없습니다(에 따르면). OWASP, 현재 노동 착취 요율은 테스트 500개당 12달러입니다. 일부 구현은 일부 국가에서 기술적으로 불법일 수 있습니다(참조: OWASP 인증 치트 시트).CAPTCHA를 사용해야 하는 경우 Google의 리캡차, 정의상 OCR이 어렵고(이미 OCR로 잘못 분류된 도서 스캔을 사용하기 때문에) 사용자 친화적이 되기 위해 매우 열심히 노력합니다.

개인적으로 저는 CAPTCHAS를 짜증나게 생각하는 경향이 있으며, 사용자가 여러 번 로그인에 실패하고 제한 지연이 최대치에 도달한 경우 최후의 수단으로만 사용합니다.이는 수용할 수 있을 만큼 거의 발생하지 않으며 시스템 전체를 강화합니다.

비밀번호 저장/로그인 확인

최근 몇 년간 우리가 목격한 널리 알려진 해킹 및 사용자 데이터 유출 이후 이는 마침내 상식이 되었을 수도 있지만 다음과 같이 말해야 합니다.데이터베이스에 비밀번호를 일반 텍스트로 저장하지 마세요.사용자 데이터베이스는 정기적으로 해킹되거나 SQL 주입을 통해 유출되거나 수집됩니다. 원시 일반 텍스트 비밀번호를 저장하는 경우 로그인 보안이 즉시 종료됩니다.

그러면 비밀번호를 저장할 수 없는 경우 로그인 양식에 게시된 로그인+비밀번호 조합이 올바른지 어떻게 확인합니까?대답은 다음을 사용하여 해싱하는 것입니다. 키 파생 함수.새 사용자가 생성되거나 비밀번호가 변경될 때마다 비밀번호를 가져와서 Argon2, bcrypt, scrypt 또는 PBKDF2와 같은 KDF를 통해 실행하여 일반 텍스트 비밀번호("올바른 말 배터리 스테이플")를 무작위로 보이는 긴 문자열로 바꿉니다. , 이는 데이터베이스에 저장하는 것이 훨씬 안전합니다.로그인을 확인하려면 입력한 비밀번호에 대해 동일한 해시 함수를 실행합니다. 이번에는 솔트를 전달하고 결과 해시 문자열을 데이터베이스에 저장된 값과 비교합니다.Argon2, bcrypt 및 scrypt는 이미 해시와 함께 솔트를 저장합니다.이것을 확인해보세요 기사 자세한 내용은 sec.stackexchange를 참조하세요.

솔트를 사용하는 이유는 해싱 자체만으로는 충분하지 않기 때문입니다. 해시를 보호하기 위해 소위 '소금'을 추가하는 것이 좋습니다. 무지개 테이블.솔트는 정확하게 일치하는 두 개의 비밀번호가 동일한 해시 값으로 저장되는 것을 효과적으로 방지하여 공격자가 비밀번호 추측 공격을 실행하는 경우 전체 데이터베이스가 한 번에 검색되는 것을 방지합니다.

사용자가 선택한 비밀번호는 충분히 강력하지 않기 때문에 비밀번호 저장에 암호화 해시를 사용해서는 안 됩니다(예:일반적으로 충분한 엔트로피를 포함하지 않음) 해시에 액세스할 수 있는 공격자가 비밀번호 추측 공격을 비교적 짧은 시간 내에 완료할 수 있습니다.이것이 KDF가 사용되는 이유입니다. "열쇠를 늘려라", 즉, 공격자가 비밀번호를 추측할 때마다 해시 알고리즘이 여러 번 반복됩니다(예: 10,000회). 이로 인해 공격자는 비밀번호를 10,000배 더 느리게 추측하게 됩니다.

세션 데이터 - "Spiderman69로 로그인되어 있습니다."

서버가 사용자 데이터베이스에 대한 로그인 및 비밀번호를 확인하고 일치하는 항목을 찾으면 시스템은 브라우저가 인증되었음을 기억하는 방법이 필요합니다.이 사실은 세션 데이터의 서버측에만 저장되어야 합니다.

세션 데이터에 익숙하지 않은 경우 작동 방식은 다음과 같습니다.무작위로 생성된 단일 문자열은 만료되는 쿠키에 저장되며 서버에 저장되는 데이터 모음(세션 데이터)을 참조하는 데 사용됩니다.MVC 프레임워크를 사용하는 경우 이는 의심할 여지 없이 이미 처리되었습니다.

가능하다면 브라우저로 전송될 때 세션 쿠키에 보안 및 HTTP 전용 플래그가 설정되어 있는지 확인하십시오.HttpOnly 플래그는 XSS 공격을 통해 읽는 쿠키에 대한 일부 보호 기능을 제공합니다.보안 플래그는 쿠키가 HTTPS를 통해서만 다시 전송되도록 보장하므로 네트워크 스니핑 공격으로부터 보호합니다.쿠키의 값은 예측할 수 없어야 합니다.존재하지 않는 세션을 참조하는 쿠키가 표시되는 경우 해당 값을 즉시 교체하여 방지해야 합니다. 세션 고정.

2부:로그인 상태를 유지하는 방법 - 악명 높은 "기억하기" 확인란

영구 로그인 쿠키("기억하기" 기능)는 위험 구역입니다.한편으로는 사용자가 처리 방법을 이해하면 기존 로그인만큼 안전합니다.반면에, 공용 컴퓨터에서 사용하고 로그아웃하는 것을 잊었으며, 브라우저 쿠키가 무엇인지, 쿠키를 삭제하는 방법을 모르는 부주의한 사용자의 손에는 엄청난 보안 위험이 있습니다.

개인적으로 저는 정기적으로 방문하는 웹사이트에 대한 영구 로그인을 좋아하지만 이를 안전하게 처리하는 방법을 알고 있습니다.사용자가 이를 알고 있다고 확신한다면 깨끗한 양심으로 영구 로그인을 사용할 수 있습니다.그렇지 않다면 로그인 자격 증명을 부주의하게 관리하는 사용자가 해킹을 당하면 스스로 책임을 져야 한다는 철학에 동의할 수 있습니다.우리가 사용자의 집에 가서 모니터 가장자리에 늘어놓은 비밀번호가 적힌 손바닥을 유발하는 포스트잇을 모두 찢는 것과도 다릅니다.

물론 일부 시스템에서는 그럴 여유가 없습니다. 어느 계정이 해킹당했습니다.그러한 시스템에서는 지속적인 로그인을 정당화할 수 있는 방법이 없습니다.

영구 로그인 쿠키를 구현하기로 결정한 경우 수행 방법은 다음과 같습니다.

먼저, 시간을 내어 읽어 보세요. Paragon Initiative의 기사 주제에.여러 요소를 올바르게 가져와야 하며 이 기사에서는 각 요소를 훌륭하게 설명합니다.
가장 일반적인 함정 중 하나를 다시 말씀드리자면, 데이터베이스에 영구 로그인 쿠키(토큰)를 저장하지 말고 해시만 저장하세요! 로그인 토큰은 비밀번호와 동일하므로 공격자가 데이터베이스에 접근하면 일반 텍스트 로그인-비밀번호 조합인 것처럼 토큰을 사용하여 모든 계정에 로그인할 수 있습니다.따라서 해싱을 사용하십시오(다음에 따라). https://security.stackexchange.com/a/63438/5002 영구 로그인 토큰을 저장할 때 약한 해시는 이 목적에 적합합니다.

3부:비밀 질문 사용

'비밀 질문'을 구현하지 마세요..'비밀 질문' 기능은 보안 방지 패턴입니다.반드시 읽어야 할 목록에서 링크 번호 4의 논문을 읽어보세요.Sarah Palin에게 Yahoo!에 대해 문의해 보세요.이전 대선 캠페인 당시 그녀의 보안 질문에 대한 답변이 다음과 같았기 때문에 이메일 계정이 해킹당했습니다."와실라 고등학교"!

사용자가 지정한 질문이 있더라도 대부분의 사용자는 다음 중 하나를 선택할 가능성이 높습니다.

어머니의 결혼 전 이름이나 좋아하는 애완동물과 같은 '표준적인' 비밀 질문
누구나 자신의 블로그, LinkedIn 프로필 또는 이와 유사한 내용에서 알아볼 수 있는 간단한 퀴즈입니다.
비밀번호를 추측하는 것보다 대답하기 쉬운 질문입니다.괜찮은 비밀번호에 대해서는 당신이 상상할 수 있는 모든 질문이 있습니다.

결론적으로, 보안 질문은 사실상 모든 형태와 변형에서 본질적으로 안전하지 않으므로 어떤 이유로든 인증 체계에 사용되어서는 안 됩니다.

보안 질문이 실제로 존재하는 진짜 이유는 재활성화 코드를 받기 위해 이메일에 액세스할 수 없는 사용자가 몇 번 전화하는 데 드는 비용을 편리하게 절약할 수 있기 때문입니다.이는 보안과 Sarah Palin의 평판을 희생하는 것입니다.그만한 가치가 있나요?아마도 그렇지 않을 것입니다.

제4부:잊어버린 비밀번호 기능

왜 해야 하는지 이미 언급했습니다. 절대로 보안 질문을 사용하지 마세요 잊어버리거나 분실한 사용자 비밀번호를 처리하기 위해또한 사용자에게 실제 비밀번호를 이메일로 보내서는 안 된다는 것은 말할 필요도 없습니다.이 분야에서는 피해야 할 매우 일반적인 함정이 두 가지 이상 더 있습니다.

하지 않다 초기화 자동 생성된 강력한 비밀번호에 대한 잊어버린 비밀번호 - 이러한 비밀번호는 기억하기 매우 어렵기로 악명이 높습니다. 즉, 사용자는 비밀번호를 변경하거나 모니터 가장자리에 있는 밝은 노란색 포스트잇에 적어 두어야 합니다.새 비밀번호를 설정하는 대신 사용자가 즉시 새 비밀번호를 선택하도록 하세요. 어쨌든 그렇게 하고 싶습니다.(사용자가 일반적으로 비밀번호를 기록하지 않고는 기억할 수 없는 비밀번호를 저장/관리하기 위해 비밀번호 관리자를 보편적으로 사용하는 경우에는 예외가 될 수 있습니다.)
분실한 비밀번호 코드/토큰을 항상 데이터베이스에 해시하세요. 다시, 이 코드는 동일한 비밀번호의 또 다른 예이므로 공격자가 데이터베이스에 접근하는 경우를 대비해 해시해야 합니다.분실한 비밀번호 코드가 요청되면 일반 텍스트 코드를 사용자의 이메일 주소로 보낸 다음 해시하고 데이터베이스에 해시를 저장합니다. 원본을 버려라.비밀번호나 영구 로그인 토큰과 같습니다.

마지막 참고 사항:항상 '분실된 비밀번호 코드'를 입력하기 위한 인터페이스가 최소한 로그인 양식 자체만큼 안전한지 확인하십시오. 그렇지 않으면 공격자가 대신 이를 사용하여 액세스할 것입니다.매우 긴 '분실된 비밀번호 코드'(예: 대소문자를 구분하는 16개의 영숫자 문자)를 생성하는 것이 좋은 시작이지만 로그인 양식 자체에 대해 수행하는 것과 동일한 제한 구성표를 추가하는 것을 고려하십시오.

제5부:비밀번호 강도 확인

먼저 현실 확인을 위해 다음의 작은 기사를 읽어보세요. 가장 일반적인 비밀번호 500개

좋아요, 그럼 아마도 그 목록이 아닐 수도 있겠네요 표준적인 가장 일반적인 비밀번호 목록 어느 체계 언제 어디서나, 하지만 이는 시행되는 정책이 없을 때 사람들이 비밀번호를 얼마나 잘못 선택하는지를 보여주는 좋은 지표입니다.게다가 최근에 도난당한 비밀번호에 대해 공개적으로 분석된 내용과 비교해 보면 이 목록이 놀라울 정도로 유사해 보입니다.

그래서:최소 비밀번호 강도 요구 사항이 없으면 사용자 중 2%가 가장 일반적인 비밀번호 상위 20개 중 하나를 사용합니다.의미:공격자가 20번만 시도하면 웹사이트 계정 50개 중 1개가 해킹될 수 있습니다.

이를 방지하려면 비밀번호의 엔트로피를 계산한 다음 임계값을 적용해야 합니다.국립표준기술연구소(NIST) 특별 간행물 800-63 아주 좋은 제안이 많이 있습니다.이를 사전 및 키보드 레이아웃 분석과 결합하면(예: 'qwertyuiop'은 잘못된 비밀번호임) 잘못 선택된 모든 비밀번호의 99% 거부 18비트 엔트로피 수준에서.단순히 비밀번호 강도를 계산하고 시각적 강도 측정기를 보여줌 사용자에게는 좋지만 충분하지 않습니다.시행하지 않으면 많은 사용자가 이를 무시할 가능성이 높습니다.

그리고 엔트로피가 높은 비밀번호의 사용자 친화성에 대한 신선한 해석을 위해 Randall Munroe는 비밀번호 강도 xkcd 적극 권장됩니다.

트로이 헌트를 활용하세요 나는 API를 받았습니까? 공개 데이터 유출로 인해 손상된 비밀번호와 사용자 비밀번호를 확인합니다.

6부:훨씬 더 - 또는:긴급 로그인 시도 방지

먼저 숫자를 살펴보십시오. 비밀번호 복구 속도 - 비밀번호가 얼마나 오래 유지되나요?

해당 링크에 있는 표를 살펴볼 시간이 없다면 다음 표 목록을 참조하세요.

소요됩니다 사실상 시간이 없다 주판으로 해독하더라도 약한 비밀번호를 해독하려면
소요됩니다 사실상 시간이 없다 영숫자 9자리 비밀번호를 해독하려면 대소문자를 구분하지 않음
소요됩니다 사실상 시간이 없다 복잡한 기호, 문자, 숫자, 대문자와 소문자로 구성된 비밀번호를 해독하려면 8자 미만 (데스크톱 PC는 며칠 또는 몇 시간 내에 최대 7자까지 전체 키스페이스를 검색할 수 있습니다.)
하지만 6자리 비밀번호도 해독하는데 시간이 너무 많이 걸리기 때문에, 초당 한 번의 시도로 제한되어 있다면!

그렇다면 우리는 이 숫자로부터 무엇을 배울 수 있을까요?글쎄요, 하지만 우리는 가장 중요한 부분에 집중할 수 있습니다:많은 수의 연속적인 로그인 시도를 방지한다는 사실(예:그만큼 무차별 대입 공격) 별로 어렵지 않습니다.하지만 그것을 막는다 오른쪽 보이는 것만큼 쉽지는 않습니다.

일반적으로 무차별 대입 공격에 효과적인 세 가지 선택 사항이 있습니다. (사전 공격도 있지만 이미 강력한 비밀번호 정책을 사용하고 있으므로 문제가 되지 않습니다):

선물 보안문자 N번의 시도 실패 후(지극히 짜증나고 종종 효과가 없습니다. 하지만 여기서는 반복합니다)
계정 잠금 N번 시도에 실패하면 이메일 확인이 필요합니다(이것은 DoS 공격이 일어나기를 기다리고 있음)
그리고 마지막으로, 로그인 제한:즉, N번의 시도 실패 후 시도 사이에 시간 지연을 설정합니다(예, DoS 공격은 여전히 가능하지만 적어도 그럴 가능성은 훨씬 낮고 실행하기가 훨씬 더 복잡합니다).

모범 사례 #1: 다음과 같이 실패한 시도 횟수에 따라 증가하는 짧은 시간 지연입니다.

1회 시도 실패 = 지연 없음
2번의 시도 실패 = 2초 지연
3번의 시도 실패 = 4초 지연
4번의 시도 실패 = 8초 지연
5번의 시도 실패 = 16초 지연
등.

이 방식을 공격하는 DoS는 결과적인 잠금 시간이 이전 잠금 시간의 합보다 약간 더 크기 때문에 매우 비실용적입니다.

명확히 하기 위해:지연은 ~ 아니다 브라우저에 응답을 반환하기 전에 지연됩니다.이는 특정 계정이나 특정 IP 주소에 대한 로그인 시도가 전혀 허용되거나 평가되지 않는 시간 초과 또는 불응 기간과 비슷합니다.즉, 성공적인 로그인 시 올바른 자격 증명이 반환되지 않으며 잘못된 자격 증명으로 인해 지연이 증가하지 않습니다.

모범 사례 #2: 다음과 같이 N회 시도 실패 후 적용되는 중간 길이의 시간 지연입니다.

1~4회 시도 실패 = 지연 없음
5회 시도 실패 = 15~30분 지연

이 계획을 공격하는 DoS는 매우 비실용적이지만 확실히 실행 가능합니다.또한 이러한 긴 지연은 합법적인 사용자에게 매우 짜증스러울 수 있다는 점에 유의하는 것이 적절할 수 있습니다.건망증이 있는 사용자는 당신을 싫어할 것입니다.

모범 사례 #3: 두 가지 접근 방식을 결합합니다. 다음과 같이 N번 시도 실패 후 적용되는 고정된 짧은 시간 지연 중 하나입니다.

1~4회 시도 실패 = 지연 없음
5회 이상 시도 실패 = 20초 지연

또는 다음과 같이 상한이 고정되어 지연이 증가합니다.

1회 시도 실패 = 5초 지연
2번의 시도 실패 = 15초 지연
3회 이상 시도 실패 = 45초 지연

이 최종 계획은 OWASP 모범 사례 제안(반드시 읽어야 할 목록의 링크 1)에서 따왔으며 제한적인 측면이 있더라도 모범 사례로 간주되어야 합니다.

그러나 경험상 다음과 같이 말하고 싶습니다.비밀번호 정책이 강력할수록 지연으로 인해 사용자를 괴롭히는 일이 줄어듭니다.강력한(대소문자 구분 영숫자 + 필수 숫자 및 기호) 9자 이상의 비밀번호가 필요한 경우 제한을 활성화하기 전에 사용자에게 지연되지 않은 비밀번호 시도를 2~4회 제공할 수 있습니다.

이 최종 로그인 제한 체계를 공격하는 DoS는 다음과 같습니다. 매우 비실용적이다.그리고 마지막으로 항상 영구(쿠키) 로그인(및/또는 CAPTCHA 인증 로그인 양식)이 통과하도록 허용하여 합법적인 사용자가 지연되는 일이 없도록 하세요. 공격이 진행되는 동안.그렇게 하면 매우 비실용적인 DoS 공격이 됩니다. 극도로 실용적이지 않은 공격.

또한 관리자 계정에 대해 보다 공격적인 제한을 수행하는 것이 합리적입니다. 이는 가장 매력적인 진입점이기 때문입니다.

파트 7:분산된 무차별 대입 공격

여담이지만, 좀 더 발전된 공격자는 '활동 확산'을 통해 로그인 제한을 우회하려고 시도합니다.

IP 주소 플래그 지정을 방지하기 위해 봇넷에 대한 시도 배포
한 명의 사용자를 선택하고 50,000개의 가장 일반적인 비밀번호를 시도하는 대신(제한 때문에 그럴 수 없음) 가장 일반적인 비밀번호를 선택하고 대신 50,000명의 사용자에 대해 시도합니다.이렇게 하면 CAPTCHA 및 로그인 제한과 같은 최대 시도 조치를 피할 수 있을 뿐만 아니라 가장 일반적인 비밀번호 1위가 49.995보다 훨씬 높기 때문에 성공 가능성도 높아집니다.
각 사용자 계정에 대한 로그인 요청 간격을 예를 들어 30초 간격으로 두어 레이더를 피해 이동합니다.

여기서 가장 좋은 방법은 다음과 같습니다. 시스템 전체에서 실패한 로그인 수 기록, 사이트의 잘못된 로그인 빈도에 대한 평균을 기준으로 모든 사용자에게 적용하는 상한값을 사용합니다.

너무 추상적인가요?다시 말해 보겠습니다.

귀하의 사이트에서 지난 3개월 동안 하루 평균 120건의 잘못된 로그인이 발생했다고 가정해 보겠습니다.이를 사용하여(실행 평균) 시스템은 전역 제한을 그 3배로 설정할 수 있습니다.24시간 동안 360번의 시도 실패.그런 다음 모든 계정에서 실패한 시도의 총 횟수가 하루 이내에 해당 횟수를 초과하는 경우(또는 가속 속도를 모니터링하고 계산된 임계값에 따라 트리거하는 것이 더 좋음) 시스템 전체 로그인 제한을 활성화합니다. 즉, 모든 사용자에 대한 짧은 지연을 의미합니다. (쿠키 로그인 및/또는 백업 CAPTCHA 로그인은 제외)

나는 또한 다음과 같은 질문을 게시했습니다. 까다로운 함정을 피하는 방법에 대한 자세한 내용과 정말 좋은 토론 분산된 무차별 대입 공격을 방어하는 데 있어

파트 8:2단계 인증 및 인증 공급자

악용, 비밀번호 기록 및 분실, 키가 있는 노트북 도난, 사용자가 피싱 사이트에 로그인 입력 등으로 인해 자격 증명이 손상될 수 있습니다.전화 통화, SMS 메시지, 앱 또는 동글에서 받은 일회용 코드와 같은 대역 외 요소를 사용하는 2단계 인증을 통해 로그인을 더욱 안전하게 보호할 수 있습니다.몇몇 공급자는 이중 인증 서비스를 제공합니다.

인증은 다른 공급자가 자격 증명 수집을 처리하는 Single-Sign-On 서비스에 완전히 위임될 수 있습니다.이로 인해 문제가 신뢰할 수 있는 제3자에게 전달됩니다.Google과 Twitter는 모두 표준 기반 SSO 서비스를 제공하는 반면 Facebook은 유사한 독점 솔루션을 제공합니다.

웹 인증에 대한 필수 링크

다른 팁

최종 기사

자격 증명 보내기

자격 증명을 100% 안전하게 보내는 유일한 실용적인 방법은 다음을 사용하는 것입니다. SSL.JavaScript를 사용하여 비밀번호를 해시하는 것은 안전하지 않습니다.클라이언트 측 비밀번호 해싱의 일반적인 함정:

클라이언트와 서버 간의 연결이 암호화되지 않은 경우 수행하는 모든 작업은 중간자 공격에 취약.공격자는 들어오는 자바스크립트를 대체하여 해싱을 깨거나 모든 자격 증명을 서버에 보낼 수 있으며, 클라이언트 응답을 듣고 사용자를 완벽하게 가장할 수 있습니다.등.신뢰할 수 있는 인증 기관을 갖춘 SSL은 MitM 공격을 방지하도록 설계되었습니다.
서버가 수신한 해시된 비밀번호는 다음과 같습니다. 덜 안전하다 서버에서 추가 작업을 수행하지 않으면 중복됩니다.

다음과 같은 또 다른 보안 방법이 있습니다. SRP, 하지만 특허를 받았습니다(비록 무료 라이센스) 사용할 수 있는 좋은 구현이 거의 없습니다.

비밀번호 저장

데이터베이스에 비밀번호를 일반 텍스트로 저장하지 마세요.자신의 사이트 보안에 관심이 없더라도 마찬가지입니다.일부 사용자가 온라인 은행 계좌의 비밀번호를 재사용한다고 가정합니다.따라서 해시된 비밀번호를 저장하고 원본은 폐기하세요.그리고 비밀번호가 액세스 로그나 애플리케이션 로그에 표시되지 않는지 확인하세요.OWASP Argon2 사용을 권장합니다. 새로운 애플리케이션을 위한 첫 번째 선택입니다.이를 사용할 수 없는 경우 PBKDF2 또는 scrypt를 대신 사용해야 합니다.마지막으로 위의 항목 중 어느 것도 사용할 수 없으면 bcrypt를 사용하십시오.

해시 자체도 안전하지 않습니다.예를 들어, 동일한 비밀번호는 동일한 해시를 의미합니다. 이는 해시 조회 테이블을 한 번에 많은 비밀번호를 해독하는 효과적인 방법으로 만듭니다.대신, 소금에 절인 해시시.솔트는 해싱 전에 비밀번호에 추가되는 문자열입니다. 사용자마다 다른(임의) 솔트를 사용하세요.솔트는 공개 값이므로 데이터베이스에 해시와 함께 저장할 수 있습니다.보다 여기 이에 대한 자세한 내용은.

즉, 사용자에게 잊어버린 비밀번호를 보낼 수 없습니다(해시만 있기 때문에).사용자를 인증하지 않은 이상 사용자의 비밀번호를 재설정하지 마세요. 사용자는 저장된(검증된) 이메일 주소로 전송된 이메일을 읽을 수 있음을 증명해야 합니다.

보안 질문

보안 질문은 안전하지 않으므로 사용하지 마세요.왜?보안 질문이 하는 모든 일에는 비밀번호가 더 좋습니다.읽다 3부:비밀 질문 사용 ~에 @Jens Roland 답변 여기 이 위키에서요.

세션 쿠키

사용자가 로그인하면 서버는 사용자에게 세션 쿠키를 보냅니다.서버는 쿠키에서 사용자 이름이나 ID를 검색할 수 있지만 다른 누구도 그러한 쿠키를 생성할 수 없습니다(TODO 설명 메커니즘).

쿠키가 하이재킹될 수 있음:클라이언트 시스템의 나머지 부분과 기타 통신만큼만 안전합니다.디스크에서 읽을 수도 있고, 네트워크 트래픽을 스니핑할 수도 있고, 사이트 간 스크립팅 공격으로 제거할 수도 있고, 감염된 DNS에서 피싱하여 클라이언트가 쿠키를 잘못된 서버로 보낼 수도 있습니다.영구 쿠키를 보내지 마십시오.쿠키는 클라이언트 세션이 끝나면 만료됩니다(브라우저를 닫거나 도메인을 떠나는 경우).

사용자를 자동 로그인하려면 영구 쿠키를 설정할 수 있지만 이는 전체 세션 쿠키와 구별되어야 합니다.사용자가 자동 로그인했으며 민감한 작업을 위해 실제로 로그인해야 한다는 추가 플래그를 설정할 수 있습니다.이는 원활하고 개인화된 쇼핑 경험을 제공하면서도 금융 세부정보를 보호하려는 쇼핑 사이트에서 인기가 있습니다.예를 들어 Amazon에 다시 방문하면 로그인한 것처럼 보이는 페이지가 표시되지만, 주문을 하러 가면(또는 배송지 주소, 신용카드 등을 변경하는 경우) 확인을 요청합니다. 너의 비밀번호.

반면 은행, 신용카드 등 금융 웹사이트는 민감한 데이터만 보유하고 있어 자동 로그인이나 낮은 보안 모드를 허용해서는 안 됩니다.

외부 리소스 목록

웹에서 클라이언트 인증 시 해야 할 일과 하지 말아야 할 일(PDF)
많은 유용한 팁이 포함된 21페이지 학술 기사입니다.
YC에게 물어보세요:사용자 인증 모범 사례
주제에 대한 포럼 토론
비밀번호를 잘못 저장했을 가능성이 높습니다.
비밀번호 저장에 대한 소개 기사
논의:코딩 호러:비밀번호를 잘못 저장했을 가능성이 높습니다.
Coding Horror 기사에 대한 포럼 토론입니다.
데이터베이스에 비밀번호를 저장하지 마십시오!
데이터베이스에 비밀번호를 저장하는 것에 대한 또 다른 경고입니다.
비밀번호 크래킹
여러 비밀번호 해싱 체계의 약점에 대한 Wikipedia 기사.
Rainbow 테이블이면 충분합니다.안전한 비밀번호 체계에 대해 알아야 할 사항
레인보우 테이블과 이를 방어하는 방법 및 기타 스레드에 대해 토론합니다.광범위한 토론이 포함됩니다.

첫째, 이 답변이 정확한 질문에 가장 적합하지 않다는 강력한 경고입니다.확실히 최고의 답변이되어서는 안됩니다!

계속해서 Mozilla가 제안한 내용을 언급하겠습니다. 브라우저ID (또는 아마도 더 정확하게는 확인된 이메일 프로토콜) 향후 인증에 대한 더 나은 접근 방식을 위한 업그레이드 경로를 찾는 정신입니다.

다음과 같이 요약하겠습니다.

Mozilla는 다음과 같은 비영리 단체입니다. 가치 이는 이 문제에 대한 좋은 해결책을 찾는 것과 잘 일치합니다.
오늘날의 현실은 대부분의 웹사이트가 양식 기반 인증을 사용한다는 것입니다.
양식 기반 인증에는 위험이 증가한다는 큰 단점이 있습니다. 피싱.사용자는 사용자 에이전트(브라우저)가 제어하는 영역이 아닌 원격 엔터티가 제어하는 영역에 민감한 정보를 입력하라는 요청을 받습니다.
브라우저는 암시적으로 신뢰되기 때문에(사용자 에이전트의 전체 아이디어는 사용자를 대신하여 작동하는 것임) 이러한 상황을 개선하는 데 도움이 될 수 있습니다.
여기서 진행을 방해하는 주요 요인은 다음과 같습니다. 배포 교착 상태.솔루션은 그 자체로 점진적인 이점을 제공하는 단계로 분해되어야 합니다.
인터넷 인프라에 구축된 신원을 표현하는 가장 간단한 분산 방법은 도메인 이름입니다.
두 번째 수준의 신원 표현으로 각 도메인은 자체 계정 집합을 관리합니다.
“계정”양식@도메인'은 간결하며 다양한 프로토콜과 URI 체계에서 지원됩니다.물론 이러한 식별자는 이메일 주소로 가장 보편적으로 인식됩니다.
이메일 제공업체는 이미 사실상 온라인의 주요 ID 제공업체입니다.현재 비밀번호 재설정 흐름에서는 일반적으로 귀하가 해당 계정과 연결된 이메일 주소를 제어하고 있음을 입증할 수 있는 경우 해당 계정을 제어할 수 있습니다.
확인된 이메일 프로토콜은 공개 키 암호화를 기반으로 도메인 A에 계정이 있음을 도메인 B에 증명하는 프로세스를 간소화하기 위한 안전한 방법을 제공하기 위해 제안되었습니다.
확인된 이메일 프로토콜(현재 모두)을 지원하지 않는 브라우저의 경우 Mozilla는 클라이언트 측 JavaScript 코드에서 프로토콜을 구현하는 shim을 제공합니다.
확인된 이메일 프로토콜을 지원하지 않는 이메일 서비스의 경우 프로토콜을 사용하면 제3자가 신뢰할 수 있는 중개자 역할을 하여 사용자의 계정 소유권을 확인했다고 주장할 수 있습니다.그러한 제3자가 다수 존재하는 것은 바람직하지 않습니다.이 기능은 업그레이드 경로만 허용하기 위한 것이며 이메일 서비스가 이러한 주장을 자체적으로 제공하는 것이 훨씬 더 선호됩니다.
Mozilla는 신뢰할 수 있는 제3자처럼 행동하기 위해 자체 서비스를 제공합니다.확인된 이메일 프로토콜을 구현하는 서비스 제공자(즉, 신뢰 당사자)는 Mozilla의 주장을 신뢰할지 여부를 선택할 수 있습니다.Mozilla 서비스는 확인 링크가 포함된 이메일을 보내는 일반적인 방법을 사용하여 사용자의 계정 소유권을 확인합니다.
물론 서비스 제공업체는 제공하려는 다른 인증 방법 외에 이 프로토콜을 옵션으로 제공할 수도 있습니다.
여기서 추구되는 큰 사용자 인터페이스 이점은 "ID 선택기"입니다.사용자가 사이트를 방문하여 인증을 선택하면 해당 브라우저는 사이트에서 자신을 식별하는 데 사용할 수 있는 이메일 주소("개인", "직장", "정치 활동" 등)를 선택하여 표시합니다.
이러한 노력의 일환으로 추구되는 또 다른 큰 사용자 인터페이스 이점은 다음과 같습니다. 브라우저가 사용자 세션에 대해 더 많이 알 수 있도록 돕습니다. – 주로 현재 로그인한 사람이 누구인지 – 브라우저 크롬에 표시될 수 있습니다.
이 시스템의 분산 특성으로 인해 Facebook, Twitter, Google 등과 같은 주요 사이트에 대한 종속을 방지합니다.모든 개인은 자신의 도메인을 소유할 수 있으므로 자신의 ID 공급자 역할을 할 수 있습니다.

이것은 엄밀히 말하면 "웹사이트에 대한 양식 기반 인증"이 아닙니다.그러나 이는 현재의 양식 기반 인증 표준에서 보다 안전한 표준으로 전환하려는 노력입니다.브라우저 지원 인증.

저는 제가 잘 작동하는 것으로 확인된 이 솔루션을 공유하고 싶다고 생각했습니다.

나는 그것을 더미 필드 (비록 내가 이것을 발명한 것이 아니므로 내 이름을 밝히지 마십시오).

간단히 말해서:이것을 당신의 컴퓨터에 삽입하기만 하면 됩니다. <form> 유효성을 검사할 때 비어 있는지 확인하세요.

<input type="text" name="email" style="display:none" />

비결은 봇이 필수 필드에 데이터를 삽입해야 한다고 생각하도록 속이는 것입니다. 그래서 입력 이름을 "이메일"로 지정했습니다.사용 중인 이메일이라는 필드가 이미 있는 경우 더미 필드 이름을 "회사", "전화" 또는 "이메일 주소"와 같은 다른 이름으로 지정해야 합니다.필요하지 않은 것, 사람들이 일반적으로 웹 양식에 작성하는 것이 논리적이라고 생각하는 것 같은 것을 선택하세요.이제 숨기기 input CSS 또는 JavaScript/jQuery를 사용하는 필드 - 가장 적합한 것은 무엇이든 - 그냥 ~하지 않다 입력을 설정하다 type 에게 hidden 그렇지 않으면 봇이 그것에 빠지지 않을 것입니다.

양식(클라이언트 측 또는 서버 측)을 확인할 때 더미 필드가 채워졌는지 확인하여 해당 양식이 사람에 의해 전송되었는지 아니면 봇에 의해 전송되었는지 확인하세요.

예:

인간의 경우:사용자는 더미 필드(제 경우에는 "email")를 볼 수 없으며 이를 채우려고 시도하지도 않습니다.따라서 양식이 전송될 때 더미 필드의 값은 여전히 비어 있어야 합니다.

봇의 경우: 봇은 유형이 다음과 같은 필드를 볼 것입니다. text 그리고 이름 email (또는 무엇이라고 부르든) 논리적으로 적절한 데이터로 채우려고 시도합니다.멋진 CSS를 사용하여 입력 양식의 스타일을 지정해도 상관 없으며 웹 개발자는 항상 이를 수행합니다.더미 필드의 값이 무엇이든, 그 값이 다음보다 크면 상관하지 않습니다. 0 문자.

저는 이 방법을 방명록에 다음과 함께 사용했습니다. 보안문자, 그리고 그 이후로 스팸 게시물을 단 한 건도 본 적이 없습니다.예전에는 CAPTCHA 전용 솔루션을 사용했는데, 결국에는 시간당 5개 정도의 스팸 게시물이 올라오는 결과가 나왔습니다.양식에 더미 필드를 추가하면 (적어도 지금까지는) 모든 스팸이 표시되지 않습니다.

나는 이것이 로그인/인증 양식에서도 잘 사용될 수 있다고 생각합니다.

경고:물론 이 방법이 100% 완벽하지는 않습니다.스타일이 포함된 입력 필드를 무시하도록 봇을 프로그래밍할 수 있습니다. display:none 그것에 적용됩니다.또한 모든 양식 필드를 자동으로 채우기 위해 자동 완성 기능(대부분의 브라우저에 내장되어 있음)을 사용하는 사람들에 대해서도 생각해야 합니다.그들은 더미 필드를 선택할 수도 있습니다.

더미 필드를 표시하되 화면 경계 외부에 두어 이를 약간 변경할 수도 있지만 이는 전적으로 사용자에게 달려 있습니다.

창의력을 발휘하세요!

나는 위의 답변이 "틀렸다"고 생각하지 않지만 다루지 않은 인증 영역이 넓습니다. (또는 오히려 강조점은 "사용 가능한 옵션과 거래가 무엇인지가 아니라 "쿠키 세션을 구현하는 방법"에 있습니다. -오프".

내가 제안한 편집/답변은 다음과 같습니다.

문제는 비밀번호 확인보다 계정 설정에 더 많이 있습니다.
이중 인증을 사용하는 것은 보다 영리한 비밀번호 암호화 수단보다 훨씬 더 안전합니다.
저장된 데이터가 계정 생성 및 자체 생성 (즉, Facebook과 같은 Web 2.0 스타일, Facebook, Web 2.0 스타일)이 아니라면 암호의 로그인 양식 또는 데이터베이스 저장을 구현하지 마십시오. 플리커, 등.)
1. 다이제스트 인증은 모든 주요 브라우저 및 서버에서 지원되는 표준 기반 접근 방식으로, 보안 채널을 통해서도 비밀번호를 보내지 않습니다.

이렇게 하면 브라우저 자체가 매번 통신을 다시 암호화하므로 "세션"이나 쿠키가 필요하지 않습니다.이는 가장 "가벼운" 개발 접근 방식입니다.

다만, 공공적이고 가치가 낮은 서비스를 제외하고는 이를 권장하지 않습니다.이는 위의 다른 답변 중 일부와 관련된 문제입니다. 서버 측 인증 메커니즘을 다시 구현하지 마십시오. 이 문제는 해결되었으며 대부분의 주요 브라우저에서 지원됩니다.쿠키를 사용하지 마십시오.자신이 직접 만든 데이터베이스에 아무것도 저장하지 마십시오.요청에 따라 요청이 인증되었는지 물어보세요.그 밖의 모든 것은 구성 및 타사의 신뢰할 수 있는 소프트웨어에서 지원되어야 합니다.

그래서 ...

첫째, 우리는 최초의 계정 생성(비밀번호 포함)과 이후에 비밀번호를 다시 확인하는 것을 혼동하고 있습니다.내가 Flickr이고 처음으로 사이트를 만드는 경우 새 사용자는 0 값(빈 웹 공간)에 액세스할 수 있습니다.계정을 만든 사람이 자신의 이름에 대해 거짓말을 하는지는 전혀 신경 쓰지 않습니다.병원 인트라넷/엑스트라넷 계정을 만드는 경우 모든 의료 기록에 가치가 있으므로 하다 계정 생성자의 신원(*)에 주의하세요.

이것은 매우 어려운 부분입니다.그만큼 오직 괜찮은 솔루션은 신뢰의 웹입니다.예를 들어, 귀하가 의사로 병원에 입사한다고 가정해 보겠습니다.사진, 여권 번호, 공개 키를 사용하여 어딘가에 호스팅되는 웹 페이지를 만들고 개인 키로 모두 해시합니다.그런 다음 병원을 방문하면 시스템 관리자가 여권을 보고 사진이 귀하와 일치하는지 확인한 다음 웹 페이지/사진 해시를 병원 개인 키로 해시합니다.이제부터 우리는 키와 토큰을 안전하게 교환할 수 있습니다.병원을 신뢰하는 사람이라면 누구나 그럴 수 있습니다(비밀 소스 BTW가 있습니다).시스템 관리자는 귀하에게 다음과 같은 정보를 제공할 수도 있습니다. RSA 동글 또는 기타 이중 인증.

그러나 이것은 많은 번거롭고 웹 2.0도 아닙니다.그러나 이는 자체 생성되지 않은 귀중한 정보에 액세스할 수 있는 새 계정을 생성하는 유일한 안전한 방법입니다.

Kerberos 및 SPNEGO(신뢰할 수 있는 제3자를 통한 Single Sign-On 메커니즘)는 기본적으로 사용자가 신뢰할 수 있는 제3자를 대상으로 확인합니다.(참고로 이것은 어떤 식으로든 신뢰할 수 없는 것이 아닙니다. OAuth)
SRP - 신뢰할 수 있는 제3자가 없는 일종의 영리한 비밀번호 인증입니다.하지만 여기서 우리는 "비록 비용이 더 들더라도 이중 인증을 사용하는 것이 더 안전하다"는 영역으로 들어가고 있습니다.
SSL 클라이언트 측 - 클라이언트에게 공개 키 인증서를 제공합니다(모든 주요 브라우저에서 지원되지만 클라이언트 시스템 보안에 대한 의문이 제기됨).

결국에는 보안 침해로 인한 비용과 보다 안전한 접근 방식을 구현하는 데 드는 비용이 균형을 이룹니다.어느 날, 우리는 제대로 된 것을 보게 될 수도 있습니다 PKI 널리 받아들여지기 때문에 더 이상 자체 인증 양식과 데이터베이스가 필요하지 않습니다.어느 날...

해싱할 때 MD5와 같은 빠른 해시 알고리즘을 사용하지 마세요(많은 하드웨어 구현이 존재함).SHA-512와 같은 것을 사용하십시오.비밀번호의 경우 해시가 느릴수록 좋습니다.

해시를 더 빨리 생성할수록 무차별 대입 검사기가 더 빠르게 작동할 수 있습니다.따라서 해시가 느리면 무차별 대입이 느려집니다.느린 해시 알고리즘으로 인해 더 긴 비밀번호(8자리 이상)에 대한 무차별 대입 공격이 실용적이지 않습니다.

현실적인 비밀번호 강도 추정에 대한 좋은 기사는 다음과 같습니다.

Dropbox 기술 블로그 » 블로그 아카이브 » zxcvbn:현실적인 비밀번호 강도 추정

인증 시스템과 관련하여 제가 가장 좋아하는 규칙은 다음과 같습니다.비밀번호가 아닌 비밀번호 문구를 사용하세요.기억하기 쉽고 깨지기 어렵습니다.더 많은 정보: 코딩 호러:비밀번호 대암호 문구

심층적인 방어를 바탕으로 제가 사용한 제안 하나를 추가하고 싶습니다.관리자를 위해 일반 사용자와 동일한 인증 시스템을 가질 필요는 없습니다.높은 권한을 부여하는 요청에 대해 별도의 코드를 실행하는 별도의 URL에 별도의 로그인 양식을 가질 수 있습니다.이것은 일반 사용자에게 완전히 고통스러운 선택을 할 수 있습니다.제가 사용한 방법 중 하나는 실제로 관리자 액세스를 위해 로그인 URL을 뒤섞고 관리자에게 새 URL을 이메일로 보내는 것입니다.새 URL은 임의로 어려울 수 있지만(임의의 매우 긴 문자열) 모든 무차별 대입 공격을 즉시 중지합니다. 하지만 관리자가 유일하게 불편한 점은 이메일에 있는 링크를 따라가는 것입니다.공격자는 더 이상 POST를 수행할 위치를 알지 못합니다.

이에 대해 답변으로 답변하는 것이 최선인지 의견으로 답변하는 것이 최선인지 모르겠습니다.나는 첫 번째 옵션을 선택했습니다.

포잉에 관해서 제4부:잊어버린 비밀번호 기능 첫 번째 답변에서는 타이밍 공격에 대해 설명하겠습니다.

에서 비밀번호를 기억하세요 공격자는 잠재적으로 이메일의 전체 목록을 확인하고 시스템에 등록된 이메일을 탐지할 수 있습니다(아래 링크 참조).

잊어버린 비밀번호 양식과 관련하여 일부 지연 기능을 사용하여 성공적인 쿼리와 실패한 쿼리 간의 시간을 동일하게 하는 것이 좋은 생각이라고 덧붙이고 싶습니다.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

나는 매우 중요한 의견을 하나 추가하고 싶습니다:-

"안에 기업, 내부 net 설정'에 따라 전술한 내용이 전부는 아니더라도 대부분 적용되지 않을 수 있습니다!

많은 기업에서는 URL을 통해 구현된 사실상 "기업 애플리케이션"인 "내부 전용" 웹사이트를 배포합니다.이러한 URL은 다음을 수행할 수 있습니다. (아마도 ...) "회사 내부 네트워크" 내에서만 해결됩니다. (어떤 네트워크에는 마술처럼 VPN에 연결된 모든 '로드 워리어'가 포함됩니다.)

사용자가 상기 네트워크에 정상적으로 연결되면 해당 사용자의 신원은 ("입증") [이미 ...] "결정적으로 알려져" 있으며, 그들의 허락도 마찬가지입니다. ("권한 부여") 특정 일을 하기 위해 ...와 같은 ..."이 웹사이트에 접속하려면."

이 "인증 + 승인" 서비스는 LDAP와 같은 다양한 기술을 통해 제공될 수 있습니다. (마이크로소프트 오픈디렉토리), 또는 Kerberos.

귀하의 관점에서 보면 다음과 같은 사실을 알 수 있습니다.저것 누구나 귀하의 웹사이트에 합법적으로 접속한 사람 ~ 해야 하다 환경이 마술처럼 포함 된 환경 ...] A "토큰"과 동행하십시오. (즉. 그러한 토큰이 없다는 것은 즉각적인 근거가 되어야 합니다. 404 Not Found.)

토큰의 가치는 당신에게 의미가 없습니다. 하지만, 필요한 경우 귀하의 웹 사이트가 "(LDAP...등)"에 대해 그리고 모든(!) 당신이 가질 수 있는 질문.즉, 당신은 ~ 아니다 ~을 이용하다 어느 "집에서 재배 한 논리." 대신, 당신은 권위를 문의하고 그 평결을 암시 적으로 신뢰합니다.

어 허 ...그것은 상당히 "야생적인 인터넷"으로부터의 정신적 전환.

사용 오픈아이디 커넥트 또는 사용자 관리 액세스.

아무것도 하지 않는 것보다 더 효율적인 것은 없기 때문입니다.

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

제휴하지 않습니다 StackOverflow