HTTP 기본 인증에는 어떤 인코딩을 사용해야합니까?

Question 1

RFC2617은 사용자 이름과 암호를 base64로 인코딩하라고 말하지만 base64 알고리즘에 입력하기 위해 옥텟을 만들 때 사용할 문자 인코딩은 말하지 않습니다.

US-ASCII 또는 UTF8로 가정해야합니까? 아니면 누군가이 질문을 이미 어딘가에 해결 했습니까?

Question 2

원래 사양-RFC 2617

RFC 2617 은 "ISO-8859-1"또는 "정의되지 않음"으로 읽을 수 있습니다. 당신의 선택. 많은 서버가 ISO-8859-1 (좋든 싫든)을 사용하고 다른 것을 보내면 실패하는 것으로 알려져 있습니다. 그래서 아마도 유일한 안전한 선택은 ASCII를 고수하는 것입니다.

자세한 정보와 상황 수정 제안은 "HTTP 기본 인증을위한 인코딩 매개 변수" 초안 (RFC 7617의 기반이 됨)을 참조하십시오.

신규-RFC 7617

2015 년부터는 RFC 2617을 사용하지 않는 RFC 7617 이 있습니다. 이전 RFC와 달리 새 RFC는 사용자 이름과 비밀번호에 사용할 문자 인코딩을 명시 적으로 정의합니다.

기본 인코딩은 아직 정의되지 않았습니다. Is는 US-ASCII와 호환되기 위해서만 필요합니다. 즉, UTF-8과 마찬가지로 ASCII 바이트를 ASCII 바이트로 매핑합니다.
서버는 선택적으로 다음 charset="UTF-8"과 같이 챌린지에서 추가 인증 매개 변수 를 보낼 수 있습니다 .
WWW-Authenticate: Basic realm="myChosenRealm", charset="UTF-8"
이는 서버가 사용자 이름 / 암호에 ASCII가 아닌 문자를 허용하고 UTF-8 (특히 정규화 형식 C)로 인코딩 될 것으로 예상 함을 알립니다. . UTF-8 만 허용됩니다.

완전한 버전 :

사양을 읽으십시오 . 정확한 인코딩 절차 및 지원되어야하는 유니 코드 코드 포인트 목록과 같은 추가 세부 사항이 포함 된 경우.

브라우저 지원

2018 년부터 최신 브라우저는 사용자가 사용자 이름 또는 비밀번호에 ASCII가 아닌 문자를 입력하면 일반적으로 UTF-8로 기본 설정됩니다 (서버가 charset매개 변수를 사용하지 않는 경우에도 ).

Chrome도 UTF-8을 사용하는 것으로 보입니다.
Internet Explorer에서 UTF-8을 사용하지 않음 ( 문제 # 11879588 )
Firefox는 현재 v59에 대해 계획된 변경 사항을 실험하고 있습니다 ( 버그 1419658 ).

왕국

영역 매개 변수는 여전히 심지어 RFC 7617에서 ASCII 문자를 지원합니다.

Question 3

짧은 대답 : RFC2047 (MIME)에 따라 인코딩 된 단어가 사용되지 않는 한 iso-8859-1.

더 긴 설명 :

RFC2617, 섹션 2 (HTTP 인증)는 기본 자격 증명을 정의합니다 .

basic-credentials = base64-user-pass
base64-user-pass  = <base64 encoding of user-pass, 
                     except not limited to 76 char/line>
user-pass         = userid ":" password
userid            = *<TEXT excluding ":">
password          = *TEXT

사양은 BNF의 정의에 대해 RFC2616 (HTTP 1.1)을 참조하지 않고 읽어서는 안됩니다 (위와 같이).

이 사양은 HTTP / 1.1 사양 2 의 동반자 입니다. 이는 해당 문서의 증강 BNF 섹션 2.1을 사용하며 해당 문서에 정의 된 비 터미널과 HTTP / 1.1 사양의 다른 측면 모두에 의존합니다.

RFC2616, 섹션 2.1 은 TEXT (강조 내)를 정의합니다 .

TEXT 규칙은 메시지 구문 분석기에서 해석 할 수없는 설명 필드 내용 및 값에만 사용됩니다. * TEXT의 단어는 RFC 2047의 규칙에 따라 인코딩 된 경우에만 ISO-8859-1 이외의 문자 집합의 문자를 포함 할 수 있습니다.

TEXT           = <any OCTET except CTLs, but including LWS>

따라서 RFC2047 (MIME pt. 3) 규칙 에 따라 다른 인코딩을 감지하지 않는 한 확실히 iso-8859-1입니다 .

// Username: Mike
// Password T€ST
Mike:=?iso-8859-15?q?T€ST?=

이 경우 단어의 유로 기호는 iso-8859-150xA4 에 따라 인코딩됩니다 . 이러한 인코딩 된 단어 구분 기호를 확인한 다음 지정된 인코딩을 기반으로 내부의 단어를 디코딩해야한다는 것이 제 이해입니다. 그렇지 않으면 암호가 다음과 같다고 생각할 것입니다 ( iso-8859-1로 해석 될 때 해독 될 것입니다 ).=?iso-8859-15?q?T¤ST?=0xA4¤

이것은 내 이해이며 이러한 RFC보다 더 명확한 확인을 찾을 수 없습니다. 그리고 일부는 모순되는 것 같습니다. 예를 들어, RFC2047 (MIME, pt. 3)의 4 가지 명시된 목표 중 하나는 다음을 재정의하는 것입니다.

US-ASCII 이외의 문자 집합에서 ... 텍스트 헤더 정보를 허용하는 메시지 형식.

그러나 RFC2616 (HTTP 1.1)은 iso-8859-1로 기본 설정되는 TEXT 규칙을 사용하여 헤더를 정의합니다. 이 헤더의 모든 단어가 인코딩 된 단어 (즉, =?...?=형식) 여야한다는 의미 입니까?

또한 관련이 있으며 현재 브라우저가 이것을 수행하지 않습니다. 그들은 utf-8 (Chrome, Opera), iso-8859-1 (Safari), 시스템 코드 페이지 (IE) 또는 다른 것을 사용합니다 (Firefox의 경우 utf-8의 최상위 비트 만).

편집 : 나는이 대답이 서버 측 관점에서 문제를 더 많이 본다는 것을 깨달았습니다.

Question 4

RFC를 제외하고 Spring 프레임 워크 에서 BasicAuthenticationFilter클래스는 기본값은 UTF-8 입니다.

이 선택의 이유는 UTF-8이 가능한 모든 문자를 인코딩 할 수있는 반면 ISO-8859-1 (또는 ASCII)은 그렇지 않기 때문이라고 생각합니다. 시스템에서 지원되지 않는 문자로 사용자 이름 / 암호를 사용하려고하면 동작이 손상되거나 보안이 저하 될 수 있습니다.

Question 5

로그인 프롬프트에서 ASCII가 아닌 문자를 입력 할 때 브라우저가 수행하는 작업에 관심이 있다면 방금 Firefox를 사용해 보았습니다.

각 유니 코드 값의 최하위 바이트를 취하여 everithing을 ISO-8859-1로 느리게 변환하는 것 같습니다. 예 :

User: 豚 (\u8c5a)
Password: 虎 (\u864e)

다음과 동일하게 인코딩됩니다.

User: Z (\u005a)
Password: N (\u004e)

0x5a 0x3a 0x4e base64-> WjpO