평소처럼 Steve Gibson과 관련된 모든 것을 한 트럭에 담아 가져 가세요. 필수 attrition.org 링크 .

Gibson의 프로토콜 설명을 살펴 보겠습니다.

• 로그인 근처에 표시된 QR 코드 프롬프트에는 사이트에 대한 인증 서비스의 URL이 포함됩니다. URL에는 안전하게 생성 된 긴 임의의 숫자가 포함되어 있으므로 로그인 페이지의 모든 프레젠테이션에 서로 다른 QR 코드가 표시됩니다. (암호화 서클에서는이 긴 난수를 “nonce”라고합니다.)

• 스마트 폰의 SQRL 인증 앱은 사용자가 입력 한 사이트의 도메인 이름을 암호화 방식으로 해시합니다. “의 마스터 키를 사용하여 사이트 별 공개 키 쌍을 생성합니다.

• 앱은 사이트 별 개인 키를 사용하여 QR 코드에 포함 된 전체 URL에 암호화 방식으로 서명합니다. URL에 보안 긴 임의 번호 (논스)가 포함되어 있으므로 서명은 해당 사이트와 QR 코드에 대해 고유합니다.

• 앱은 QR에 보안 HTTPS POST 쿼리를 실행합니다. 사이트에 대한 인증 서비스 인 코드의 URL입니다. POST는 사이트 별 공개 키와 QR 코드 URL의 일치하는 암호화 서명을 제공합니다.

• 인증 웹 사이트는 다른 콘텐츠없이 표준 HTTP “200 OK”를 반환하여 POST 쿼리를 수신하고 확인합니다. SQRL 앱은 사용자가 서명 한 QR 코드가 성공적으로 제출되었음을 확인합니다.

• 인증 사이트에는 사용자를 통해 로그인 페이지에서 돌아온 임시 값이 포함 된 URL이 있습니다. 또한 해당 URL의 암호화 서명과 사용자의 사이트 별 공개 키가 있습니다. 공개 키를 사용하여 서명이 URL에 유효한지 확인합니다. 이는 서명을 생성 한 사용자가 공개 키에 해당하는 개인 키를 사용했음을 확인합니다. 서명을 확인한 후 인증 사이트는 사이트 별 공개 키로 현재 인증 된 사용자를 인식합니다.

The 가장 눈에 띄는 점은 사용자가 ” 마스터 키 “를 사용한다는 것입니다. 프로토콜을 올바르게 읽고 있다면 해당 단일 마스터 키가 사용자의 전체 온라인 ID를 제어합니다 …

아마도이 마스터 키는 응용 프로그램 데이터베이스의 사용자 전화에 저장됩니다. 마스터 키를 훔치기 위해 특별히 고안된 악성 코드의 형태로 거대한 공격 벡터를 열어줍니다.

그러면 암호가 손상되었을 때 일어나는 일과 마스터 키를 훔칠 때 일어나는 일의 차이를 비교해 보겠습니다. 암호 관리자에 저장된 길고 고유하며 매우 임의의 암호에 대한 좋은 암호 관행을 따르고 있다고 가정하면 암호가 손상되면 단일 암호를 변경하기 만하면됩니다. 마스터 키가 손상되면 어떻게됩니까? 마스터 키가 도용되었음을 인식하려면 인증 한 모든 사이트를 어떻게 든 가져와야합니다. 유일한 문제는 사용자 이름이나 사이트와 같은 다른 인증 수단이 없기 때문입니다. 이메일 주소, 마스터 키를 취소하려는 것이 실제로 귀하임을 사이트가 어떻게 알 수 있습니까?

Gibson에서 나오는 모든 것과 마찬가지로이 SRQL 체계는 결함이 매우 많으며 기존에 비해 이점을 제공하지 않습니다. 방법.

Comme nts

• ” ‘ 우수한 암호 관행을 따르는 경우 “는 큰 경고이며 대부분의 네티즌은 그렇게하지 않습니다 ‘.SQRL ‘ 약속의 일부는 사용자가 ‘ 모범 사례를 파악해야하는 필요성을 줄이는 것입니다. 또한 SQRL 사양은 마스터 키가 마스터 암호로 암호화되어 저장되도록 요구하며 무차별 대입이 불가능합니다 (한 번의 시도에 ~ 60 초가 걸리도록 조정 됨). SQRL은 대역 외 인증을 촉진하기 때문에 암호를 얻는 것은 종종 중요하지 않습니다 (즉, 해킹 된 컴퓨터 키 로깅이 항상 도움이되는 것은 아닙니다 ‘). 따라서 완전한 손상의 결과는 높지만 손상 가능성은 다소 낮습니다.
• SQRL에는 아직 해결해야하는 결함이있을 수 있지만 주장 은 인증에 대한 기존 접근 방식에서 발견 된 여러 문제를 해결하고이를 주장하는 SQRL에 대한 비판은 ” 혜택이 없습니다. “는 주장이 맹목적으로 받아 들여질 것으로 기대하는 대신 이러한 주장에 대한 반박을 포함해야합니다.
• > Gibson에서 나온 모든 것과 마찬가지로 ,이 SRQL 체계는 매우 결함이 있으며 기존 방법에 비해 이점을 제공하지 않습니다. — 이것은 ‘ 질문에 답하는 데 도움이되지 않는 것 같으며 실제로 누가 기술을 제안했기 때문에 기술에 문제가 있다고 생각합니다. 결함으로 언급 한 몇 가지 사항은 실제로 ” 사양 “에 의해 해결되었습니다. 예를 들어 SQRL 자체는 ‘ 마스터 키가 저장되는 방식을 언급하지 않지만 Steve Gibson ‘의 의견은 모바일 예를 들어 클라이언트는 실행하는 데 평균 60 초가 걸리는 scrypt를 사용하여 마스터 암호로 암호화합니다.
• Gibson은 마스터 키의 보호를 명시 적으로 처리합니다.
• Hold on a 둘째. 도난당한 SQRL 마스터 키를 도난당한 LastPass 키 중 하나 와 동일시합니다. ‘ 복호화 된 전체 LastPass 비밀번호 데이터베이스 가 도난당하는 것과 동일시하는 것이 더 나은 비유가 아닐까요?

전반적으로이 프로토콜은 기존 기술에 비해 보안을 강화하지 않는 것으로 보입니다. 온라인에서 귀하의 신원을 보호 할 수있는 최선의 방법을 찾고 있다면 이는 의심의 여지없이 아닙니다 . 하지만 장단점을 살펴 보겠습니다.

장점

” 공유 악의적 인 웹 사이트가 한 사이트에 제공된 인증을 사용하여 다른 사이트에 로그인 할 수 없다는 좁은 의미의 비밀번호입니다.

인증 토큰에 대한 무차별 대입 공격은 다음과 같습니다. 불가능합니다.

사용자 인증 정보는 컴퓨터에 저장되지 않습니다. 이렇게하면 작은 하위 집합으로부터 사용자를 보호 할 수 있습니다. 특히 컴퓨터에서 암호를 훔치는 공격으로부터 보호됩니다. 하지만 모든 종류의 세션 도용이나 브라우저 탈취 공격으로부터 보호되지 않으며 이제 전화 관련 공격에 또한 취약합니다. 나중에 자세히 설명합니다.

단점

이 기술은 MITM 공격 및 사회 공학에 위험 할 정도로 취약합니다. 아마도 암호를 포함하여 사용중인 다른 인증 체계보다 더 많을 것입니다. 인증 단계와 로그인 시작 단계는 사용자에게 표시되는 방법이나 위치에 관계없이 표시되는 모든 QR 코드에 대해 전화기가 올바르게 인증된다는 점에서 본질적으로 연결이 끊어집니다.

예를 들어, 피싱 사이트는 사용자 대신 공격자가 로그인하는 인증 된 로그인 QR 코드를 표시 할 수 있습니다. Gibson은 사용자가 인증하는 동안 전화 앱에서 은행이나 상점 또는 사이트의 이름을 볼 수 있으므로 공격을 막기 위해 충분한 경계를 할 것이라고 확신합니다. 역사는 이것이 가능성이 없음을 시사하며, 더 합리적인 기대는 앱에서 올바른 이름을 보는 것이 사용자가 전화에서 친숙한 로그인 요청을 트리거 할 수 있었기 때문에 사이트가 합법적이라고 생각하도록 사용자를 잘못 안심시킬 수 있다는 것입니다. 비밀번호 보안과 관련하여 이미 사용자의 머리에 부딪힌주의가 반드시 이와 같은 새로운 인증 기술로 이어지지는 않습니다. 따라서이 앱은 본질적으로 사회 공학에 대한 저항력이 떨어집니다.

이 기술은 인증과 신원을 모두 자주 분실 또는 도난당하는 물리적 객체로 결합합니다. 이런 의미에서 ” 비밀번호 라기보다는 여권과 비슷합니다. 휴대 전화를 소유 한 사람은 갑자기 배타적으로 귀하의 신원을 소유하게됩니다. 공격자가 귀하를 가장 할 수있을뿐만 아니라 두 번째 휴대 전화에 두 번째 사본이없는 경우 ( 가능성이 낮음) 이제 자신을 식별하는 능력을 잃었습니다.인증 키는 취소 할 수 없으므로 각 사이트에서 대역 외 복구 없이는 ID를 복구 할 수 없습니다. 대역 외 복구가 존재하더라도 두 명의 사용자 (하나는 신원을 소유하고 다른 하나는없는 사용자)를 만나면 사이트 운영자가 귀하를 신뢰해야하는 이유를 파악하기 어려울 수 있습니다.

이 기술은 다른 인증 토큰을 수동으로 생성하지 않는 한 모든 인증 토큰을 단일 키로 결합합니다 . 이로 인해 하나의 키가 공격자에게 매우 육즙이 많은 표적이됩니다. 또한, 키는 휴대 전화에 저장되어 있으며, 일반적으로 장치는 우스꽝스럽게 내부 보안 기능을 가지고 있습니다. 비정상적으로 수분이 많은 대상과 표준 이하의 보안을 결합하는 것은 안전하지 않습니다.

대안

이 계획의 가장 문제가되는 측면은 사용 가능한 대안과 비교하여 얼마나 열악한 지입니다.

현재 보편적으로 허용되는 가장 안전한 옵션은 lastpass, keepass 및 기타 브라우저 통합 암호 시스템입니다. 특히 클라이언트 측 암호화는 제 3자를 신뢰해야하는 필요성을 줄여줍니다. 그리고 더 중요한 것은 브라우저 통합으로 인해 피싱이 사실상 불가능 해집니다 . LastPass 또는 KeePass는 올바른 도메인에서 제공되는 경우에만 암호를 입력합니다. 즉, 악성 사이트가 나타나면 사용자는 “암호에 액세스 할 수 없습니다.

또한 LastPass는 최근에 기능을 추가했습니다. 이는 사용자가 전 세계적으로 고유하지 않은 암호를 변경하도록 유도합니다. 이는 암호 재사용을 방지하는 데 도움이됩니다. 즉, Gibson의 기술이 제공하는 보안 체계가 암시하는 추가적 불안감없이 현재 기존 사이트에서이 도구를 사용하여 쉽게 얻을 수 있다는 의미입니다.

전화 또는 유사한 장치를 사용하는 기존의 2 단계 인증 체계는 현재 사용자 로그인을 보호하는 데 도움이되며, 장치를 도난 당하더라도 즉시 신원 도용에 취약하지 않도록합니다. 2 단계 인증의 보안은 다른 장치없이 도난 당하면 장치 나 암호를 사용할 수 없다는 사실에 있습니다. Gibson의 기술은 2 단계 체계에 포함되는 데 크게 저항하므로 이러한 수준의 보호 기능을 제공합니다. 사용할 수 없습니다.

TL; DR :

Gibson의 인증 기술은 또한 부과하는 추가 보안 비용을 극복하기에 충분한 이점을 제공하지 않습니다. 이러한 비용은 계획 자체의 근본적인 부분이며 전체 설계를 폐기하지 않고는 해결할 수 없습니다.

아무것도 아닌 것보다 낫다고 주장 할 수는 있지만 그렇게한다고 주장 할 수는 없습니다. 우리가 이미 가지고있는 것보다 낫습니다.

Gibson의 업데이트

Gibson은 최근 주요 비판이 되었기 때문에 피싱에 대한 추가 보호를 발표했습니다. 그들의 보호는 다음과 같습니다 : “QR 코드, 휴대 전화 등을 사용하지 않고 대신 시스템에 인증 에이전트가있는 경우 (예 : 브라우저 내), 서버는 인증 여부를 확인할 수 있습니다. 응답은 인증 요청과 동일한 IP에서 나옵니다. 이것은 훌륭하고 좋지만이 프로토콜의 전체 목적은 사용자의 신원을 휴대폰으로 이동하는 것입니다. 프로토콜을 사용하는 유일한 안전한 방법이 프로토콜의 핵심을 사용하지 않는 것이라면 그런 다음 우리가 달성하려는 작업을 다시 생각해야합니다.

이론적으로 휴대 전화가 알고있는 경우에만 휴대 전화를 계속 사용할 수 있습니다 . 컴퓨터와 동일한 IP를 사용하고 있다는 사실을 알 수 있습니다. 물론 “컴퓨터의 IP 주소를 모르기 때문에 알 수 없습니다.

더 나은 솔루션

앞서 언급했듯이 인증 조치가 브라우저에있는 경우 그러면 전체 피싱 문제가 노력이나 확인없이 즉시 해결됩니다. 사이트의 인증 토큰이 도메인 이름과 연결되어 있고 브라우저가 이겼 기 때문에 능력이 가장 낮은 사용자라도 “잘못된 사이트에 대한 인증을 속일 수 없습니다.” t 잘못된 도메인에 대한 인증을 허용합니다. 이것은 현재 이미 사용되고있는 기술이며 완전 자동이며 사이트의 협력이나 사용자의 지능이 필요하지 않습니다.

이 방법은 두 번째 인증 요소를 요구하여 강화할 수 있습니다. (예 : 휴대 전화의 시간에 따라 변하는 키) 이미 사용 가능하고 현재 사용 중이며, 목적지 사이트 또는 회사의 실수로부터 사용자를 보호합니다.

브라우저 측 인증이 클라이언트 워크 스테이션 공격에 취약하다는 우려는 사실이지만 브라우저가 손상되면 도 마찬가지입니다. 어떤 인증 메커니즘을 사용하더라도 해당 브라우저를 안전하게 사용할 수 있습니다.멀웨어 작성자는 초 보안 기술을 사용하여 사용자가 직접 인증 할 때까지 기다린 다음 필요한 트래픽을 ” 소유 한 계정이 잘못 표시되지 않도록합니다. SQRL이나 다른 인증 시스템은 손상된 브라우저의 사용자를 보호 할 수 없으며, 도어록이 집 화재로부터 사용자를 보호 할 수있는 것 이상입니다. 내화성 잠금 장치를 구입하는 것은 해결책이 아닙니다.

다음 위치

명의 도용으로부터의 절대적 보호 보장 그런 다음 Fido U2F 토큰을 살펴보십시오.이 표준은 SQRL이 부족한 부분에 빛을 발하고 MITM (예 : 피싱) 공격에 대한 면역성을 보장합니다. 사용자뿐만 아니라 채널도 인증하므로 “(a) 귀하의 계정은 토큰 없이는 인증 될 수 없으며”또한 (b) 귀하의 토큰은 연결된 시스템에 대한 연결을 인증하는 데만 사용될 수 있습니다. 자세한 내용은 이 답변 을 참조하세요.

댓글

• 첫 번째 요점에 대해 : 내가 아는 한, 이것은 생각한 것이고 한 가지 옵션은 인증되는 웹 사이트가 리디렉션을 담당하도록하는 것입니다. 따라서 로그인하면 공격자가 아닌 실제 은행 ‘ 페이지로 리디렉션됩니다. 두 번째 요점에 관해서는 LastPass와 같은 도구 사용자에게도 동일한 일이 발생합니다. 일부 보호 메커니즘 (예 : PIN)을 설정하지 않는 한 모든 비밀번호도 도용됩니다. ‘ SQRL에 대해 동일하지 않은 이유는 무엇입니까? 또한 사양에서 알 수있는 한 사용자는 종이 (QR 코드)에도 자신의 신원을 백업 할 수 있습니다.
• 세 번째 요점 : 그렇지 않은 대부분의 사용자도 마찬가지입니다. ‘ 여러 웹 사이트에서 단일 사용자 이름 / 비밀번호를 사용하여 비밀번호 관리자를 사용하지 마십시오. 또는 ” ID “가 여러 웹 사이트에 분산되어 있지만 단일 위치 (LastPass ‘ 서버, 1Password 데이터베이스 등). 따라서 ‘ 실제로 SQRL 결함이 아닙니다. 대체로 SQRL에 대해 더 많이 읽을수록 현재 대안과 비교하여 더 많은 이점을 볼 수 있습니다. Steve Gibson에 대해 말씀 하셨지만 SQRL은 정말 저에게 좋은 대안 인 것 같습니다.
• ” 이미주의를 기울였습니다. 암호 보안과 관련된 사용자가 반드시 이와 같은 새로운 인증 기술로 변환되는 것은 아닙니다. . . ” 이것은 훌륭한 포인트이며 이미 마케팅에 패배했습니다. QR 코드는 잠재적 인 공격 벡터가 아니라 작업을 수행하는 쉬운 방법으로 간주됩니다. 최소한 사용자 이름 / 암호 쌍은 마케팅 도구가 아닌 인증 메커니즘으로 가장 먼저 사용되었습니다.
• @jpkrohling : 암호 관리자와 관련하여 이러한 소프트웨어의 대부분의 사용자는 마스터 암호를 저장하지 않는 것 같습니다. 그들이 얼마나 위험한지 알고 있기 때문입니다. 안전한 위치에 마스터 비밀번호의 실제 사본이 하나 있지만 전자 사본은 없습니다. 내 마스터 암호에 대한 액세스 권한을 부여하는 공격은 사이트 암호를 손상시키는 공격과 다르며 가능성이 훨씬 적습니다. (주로 내 비밀번호 데이터베이스를 공격하는 것은 대규모 침해 사이트가 아닌 개인적으로 나를 공격하기 때문입니다.)
• @jpkrohling LastPass와 KeePass는 마스터 비밀번호를 어디에도 저장하지 않습니다. 비밀번호 데이터베이스를 잠금 해제하는 데 ‘ 사용되었지만 저장되지는 않았습니다. ‘ 이는 모든 곳에서 사용되는 단일 키와 근본적으로 다릅니다.

SQRL 결함이없는 것은 아니지만, 보안 및 유용성 측면에서 오늘날 웹에서 널리 사용되는 대부분의 기본 인증 솔루션보다 확실히 우수합니다. 설명하겠습니다.

오해

먼저,이 질문에 대한 다른 답변에 존재하는 몇 가지 오해를 정리하겠습니다. 이러한 답변 중 대부분은 구식이며 SQRL 문서가 변경되기 전에 작성되었습니다. 여기에 제시된 문제를 해결하는 반면 다른 사람들은 널리 사용되는 다른 많은 기존 인증 솔루션에도 존재하는 SQRL의 결함을 과도하게 강조하면서 장점을 무시하는 것 같습니다. 여기서 몇 가지 오해를 정리하겠습니다. 우리?

신화 : SQRL이 작동하려면 QR 코드를 스캔 필요

이것은 사실이 아닙니다. QR 코드는 편리합니다. 따라서 사용자가 SQRL 클라이언트 소프트웨어를 설정하지 않은 컴퓨터에서 SQRL을 더 쉽게 사용할 수 있습니다. SQRL의 웹 사이트에는 다음과 같은 내용이 있습니다.

세 가지 방법…스마트 폰 선택 사항 :

이 시스템 개발의 원래 영감은 웹 사이트의 로그인 페이지에서 QR 코드를 스캔하는 스마트 폰 이었지만,이 모델에 조금만 추가하면 두 가지 중요한 작동 모드가 가능합니다. QR 코드 이미지를 QR 코드로 인코딩 된 동일한 URL에 대한 클릭 가능한 링크로 만듭니다. 이렇게하면 로그인하는 세 가지 방법이 있습니다.

• 스마트 폰으로 코드 스캔 : 위에서 설명한 모델에서 사용자의 스마트 폰이 웹 사이트의 로그인 페이지에 나타나는 QR 코드를 스캔하면 사용자가 해당 사이트에 로그인됩니다.
• TAP 스마트 폰의 코드 : 스마트 폰에서 웹 사이트에 로그인하려면 시각적 SQRL 코드가 URL 스타일 링크 (스킴으로 sqrl : // 사용) 인 경우 스마트 폰에 설치된 SQRL 앱은 해당 링크를 수신하고 사용자를 휴대 전화의 사이트에 안전하게 로그인합니다.
• 데스크톱 또는 노트북 화면에서 코드를 클릭합니다. : 데스크톱 또는 랩톱 시스템에서 SQRL 시스템을 사용하려면 데스크톱 SQRL 애플리케이션이 설치되고 sqrl : // 링크를 수신하도록 등록됩니다. (이는 이메일 프로그램이 mailto : 링크를 수신하기 위해 등록하는 방법과 유사합니다.)이를 통해 사용자가 스마트 폰에서 사용하는 것과 동일한 솔루션을 데스크탑에서 사용할 수 있습니다. 웹 사이트에서 SQRL 코드를 제공하는 경우 사용자는 마우스 커서로 코드를 클릭하기 만하면 로컬에 설치된 SQRL 앱이 팝업되고 SQRL 암호를 입력하라는 메시지를 표시하고 도메인을 확인한 다음 로그인합니다.

신설 : SQRL 마스터 키는 완전히 암호화되지 않고 휴대 전화에 보호되지 않은 상태로 저장됩니다.

일부 사람들이 이것을 만든 이유를 모르겠습니다. SQRL 마스터 키는 강력한 마스터 암호를 사용하여 암호 데이터베이스를 보호하는 것과 동일한 방식으로 보호됩니다. 마스터 비밀번호가없는 한 사용자의 휴대 전화를 훔쳐도 온라인 ID에 대한 액세스 권한이 자동으로 부여되지 않습니다. 키 관리에 대한 자세한 내용은 SQRL Client- 페이지에 설명되어 있습니다. SQRL 웹 사이트의 사이드 키 관리

신설 : 마스터 키를 도난 당하면 로그인 자격 증명을 변경할 수 없습니다.

이것은 또한 거짓입니다. SQRL 키가 손상된 경우 정품 계정 소유자가 로그인 자격 증명을 업데이트 할 수있는 기본 제공 방법을 제공합니다.이 기능을 ID 잠금이라고합니다.

Identity Lock은 ID 변경을 방지합니다. &는 복구를 허용합니다. 또한 “ ID 잠금 프로토콜 “(이 페이지 하단에있는 링크 블록의 4 페이지)과 같은 자세한 설명 페이지가있을만큼 충분히 중요합니다. 사용자의 ID가 웹 서버 인 SQRL c로 설정되었습니다. lient는 해당 ID를 변경할 수 할 수 없습니다 . 이는 최악의 상황이 발생하여 매우 약하고 쉽게 추측 할 수있는 암호를 사용했거나 사용자의 휴대폰 또는 데스크톱이 자신의 ID 마스터 키와 암호를 얻기 위해 해킹 당했음을 의미합니다. 악의적 인 제 3자는 사용자의 온라인 신원을 변경하여 자신의 온라인 계정에서 잠글 수 없습니다. 또한 일반적으로 오프라인 인 “ID 잠금 해제 키”를로드하면 신원의 진정한 소유자는 분실하거나 도난당한 온라인 신원을 대체하여 본질적으로 다시 가져갈 수 있습니다. 공격자의 이전 신원을 쓸모 없게 만듭니다.

그럴듯 함 : SQRL은 다음보다 피싱에 더 취약합니다. 기존 인증 솔루션

좋습니다. 사실 부분적으로 사실입니다. QR 코드를 스캔하여 SQRL을 사용하는 경우 실제로 피싱에 대한 보호가 거의 없습니다. 사용자가 브라우저의 URL 표시 줄에 표시되는 웹 사이트가 SQRL 클라이언트 앱에 표시되는 웹 사이트와 동일한 지 확인하지 않으면 공격자에 대한 로그인 세션을 승인 할 수 있습니다. 이는 여전히 비밀번호보다 낫습니다. 암호를 변경할 때까지 피셔에게 자신의 계정 (및 동일한 암호를 공유하는 다른 계정에있는 다른 계정)에 영구적으로 액세스 할 수 있지만 U2F 키와 같은 사용자의 브라우저와 통합되는 다른 솔루션만큼 좋지는 않습니다. , WebAuthn, 클라이언트 인증서 및 (특정 조건에서) 비밀번호 관리자.

그러나 로그인하는 동일한 장치에서 SQRL 클라이언트를 사용하는 경우 SQRL은 이러한 보호 조치는 SQRL 웹 사이트의 SQRL이 피싱 공격을 차단하는 방법 섹션 아래에 설명되어 있습니다.또한 SQRL을 브라우저 (플러그인을 통해)와 통합하여 WebAuthn 및 클라이언트 인증서와 같은 솔루션과 동등하게 피싱 공격에 대해 훨씬 강력한 보호를 제공 할 수 있습니다.

전체적으로 SQRL을 피싱 보호를위한 암호 관리자와 거의 같은 수준입니다. 사용자가 로그인하는 동일한 기기에 설치하면 피싱으로부터 강력한 보호를 제공 할 수 있지만 다른 기기에 설치하면 최소한의 보호를 제공합니다.

대안과 비교

이제 SQRL을 기존의 널리 사용되는 인증 솔루션과 비교해 보겠습니다.

암호

SQRL은 여러면에서 암호보다 훨씬 우수합니다. 한 번 설정하는 것이 더 편리 할뿐만 아니라 사용자는 각 사이트에 대해 서로 다른 여러 암호를 기억하거나 다시 입력하는 것에 대해 걱정할 필요가 없지만 암호 재사용, 취약한 암호, 키 로깅 및 어느 정도 피싱으로부터 보호합니다.

단점 SQRL은 암호와 비교하여 널리 사용되지 않는 웹 사이트 운영자를 위해 구현하기가 더 어렵고 초기 설정에 더 많은 시간이 필요하고 새 장치로 전송하는 데 약간의 노력이 필요하며 단일 장애 지점을 제공한다는 점입니다. 마스터 키가 도난당한 경우 모든 사용자의 계정 (이 마지막 지점은 사용자가 모든 사이트에서 동일한 비밀번호를 사용하는 경우에도 비밀번호가 적용됩니다.

비밀번호 관리자

여러면에서 SQRL은 비밀번호 관리자와 매우 유사합니다. 둘 다 사용자와 개별 서비스 간의 일종의 인증 프록시 역할을하는 단일 중앙 집중식 신뢰 앵커를 제공합니다. SQRL이 암호 관리자보다 우월하다고 생각하는 몇 가지 방법이 있습니다.

SQRL이 암호 관리자에 비해 갖는 주요 장점은 신뢰할 수 없거나 부분적으로 만 신뢰할 수있는 컴퓨터에서 사용하는 것이 더 쉽고 안전하다는 것입니다. 예를 들어, 사용자가 공공 도서관의 컴퓨터를 사용하여 웹 사이트에 로그인하려고한다고 가정합니다. 비밀번호 관리자를 사용하면 휴대 전화에서 해당 사이트의 비밀번호에 액세스하여 수동으로 컴퓨터에 다시 입력하거나 자신의 비밀번호를 다운로드해야합니다. 암호 관리자 및 암호 데이터베이스를 라이브러리 컴퓨터에 연결하고 마스터 암호를 사용하여 데이터베이스를 잠금 해제 한 다음 로그인합니다. 첫 번째 시나리오는 사용자에게 불편하며 해당 사이트에 대한 사용자의 일반 텍스트 암호를 신뢰할 수없는 컴퓨터에 노출합니다. 키로거를 포함하여 신뢰할 수없는 컴퓨터의 모든 맬웨어). 두 번째 시나리오는 불편하고 사용자의 전체 암호 해독 된 암호 데이터베이스와 마스터 암호를 신뢰할 수없는 컴퓨터에 노출하기 때문에 더 나쁩니다. SQRL을 사용하면 사용자는 신뢰할 수없는 컴퓨터 화면에서 QR 코드를 스캔하기 만하면됩니다. 이는 사용자에게 훨씬 더 편리하며 신뢰할 수없는 컴퓨터에 단일 로그인 세션 (암호와 같은 재사용 가능한 자격 증명 없음) 만 노출합니다. .

SQRL이 비밀번호 관리자에 비해 갖는 또 다른 이점은 최악의 시나리오에서 복구하기가 더 쉽다는 것입니다. 사용자의 비밀번호 데이터베이스 / 마스터 키가 도난당했습니다. 비밀번호 관리자를 사용하면 모든 사이트에서 비밀번호를 변경하기 만하면됩니다. 또한 공격자가 비밀번호를 변경하는 것에 대해 걱정해야합니다 (계정에서 사용자를 잠글 수 있음). 또한 공격자는 보유한 모든 사이트의 목록을 소유 할 수있는 이점이 있습니다. SQRL을 사용하면 마스터 키를 도난당하는 것이 여전히 끔찍한 상황이지만 공격자는 계정이있는 사이트 목록이 없습니다 (대신 추측해야합니다). ), 잠금을 위해 비밀번호를 변경할 수 없습니다. 귀하의 계정. ID 잠금 해제 키를로드하면 SQRL 클라이언트가 로그인시 방문하는 각 사이트에 대해 자동으로이를 수행 할 수 있기 때문에 각 사이트에서 로그인 자격 증명을 변경하는 것이 조금 더 편리합니다. “암호 변경”양식을 통해.)

마지막으로 SQRL은 암호를 완전히 바꾸는 목표와 관련하여 암호 관리자에 비해 작지만 중요한 이점이 있다고 생각합니다. 기존 비밀번호에 비해 SQRL을 사용합니다. 사용자가 보안이 취약하고 모든 사이트에서 동일한 비밀번호를 재사용 할 수있는 한, 이는 계속 발생할 수 있습니다. SQRL이 널리 채택되기 시작하면 사이트는 실제로 사용을 단계적으로 중단 할 수 있습니다. 암호 관리자는 작업을 위해 암호 사용에 의존하기 때문에이 작업을 수행 할 수 없습니다.

단점 측면에서 실제로 SQRL이 발생하는 상황을 생각할 수 없습니다. 암호 관리자보다 더 나쁠 것입니다. 보안. SQRL의 주요 단점은 웹 사이트 운영자의 지원이 필요하지만 비밀번호 관리자는 기존 서비스의 특별한 지원이 필요하지 않다는 것입니다. 즉, 지금 바로 암호 관리자 사용을 시작할 수 있지만 SQRL은 사이트에서이를 구현할 때까지 기다려야 사용할 수 있습니다. 이것은 채택에있어 중요한 장벽입니다.

클라이언트 인증서

SQRL이 클라이언트 인증서에 비해 가장 큰 장점은 편리하다는 것입니다. 클라이언트 인증서는 현재 설정하기가 복잡하고 컴퓨터간에 전송하기가 어려우며 동일한 인증서를 다른 사이트에서 사용할 때 개인 정보 문제가 있습니다. 이론적으로는 이러한 문제를 해결할 수있는 클라이언트 인증서를 사용하여 시스템을 구축 할 수 있지만 웹 사이트 UI 및 웹 서버와의 통합이 제대로 이루어지지 않아 해결하기 더 어려운 문제도있을 수 있습니다. browserauth.net에서 클라이언트 인증서의 유용성 문제에 대한 우수한 기사 가 이미 있으므로 여기에서 너무 자세히 설명하지는 않겠습니다.

보안 측면에서 클라이언트 인증서는 CA의 개입이 필요하다는 단점이 있습니다. 이것은 (잠재적으로) 비용이 많이 들고 타사 CA를 신뢰해야합니다. 또한 CA를 무시하고 대신 인증서를 자체 서명하도록 선택하면 처리 할 인증서 해지 문제가 있습니다. 또한 클라이언트 인증서는 사용자가 신뢰할 수없는 컴퓨터에 로그인하려고 할 때 암호 관리자와 동일한 보안 및 편의 문제를 가지고 있습니다. 그들은 자신의 인증서를 신뢰할 수없는 컴퓨터로 전송해야하는데, 이는 불편하고 잠재적으로 해당 컴퓨터의 멀웨어에 마스터 ID를 노출시킬 수 있습니다.

요컨대, 누군가 다음을 사용하여 더 나은 사용자 친화적 인 솔루션을 찾을 때까지 이러한 문제를 (적어도 대부분의) 해결하는 클라이언트 인증서는 클라이언트 인증서가 SQRL (또는 암호에 대한 심각한 경쟁자)이라고 생각하지 않습니다.

2 단계 인증

2 단계 인증

내가 이것을 언급 할 것이라고 생각했습니다. SQRL과 2 단계 인증은 상호 배타적이지 아닙니다 . SQRL은 2FA의 첫 번째 요소 인 암호를 대체합니다. OTP 코드 또는 FIDO U2F 키와 같은 다른 추가 측정 값은 SQRL과 함께 계속 사용할 수 있습니다.

WebAuthn

이제 여기 가 흥미로운 곳입니다. WebAuthn 은 웹에서 공개 키를 사용하여 사용자를 인증하는 데 사용할 수있는 표준 API 웹 사이트를 제공하도록 설계된 새로운 (SQRL보다 새로운) W3C 표준입니다. SQRL과 마찬가지로 몇 가지 다른 인증 방법 (예 : 2 단계 보안 키) 외에도 사용자의 전화를 사용하여 외부 장치에서 로그인 세션을 인증 하는 기능을 지원합니다. .

최소한 보안 관점에서 SQRL이 마침내 그 일치를 충족시키는 곳입니다. WebAuthn은 SQRL이 제공하는 암호 재사용, 취약한 암호 및 키 로깅에 대해 동일한 보호 기능을 모두 제공 할뿐만 아니라 로그인을 인증 할 때 심지어 사용자의 브라우저와 통합하여 피싱으로부터 더욱 강력한 보호를 제공합니다. 사용자가 이전에 인증 자의 클라이언트 소프트웨어를 설정하지 않은 PC 세션입니다. 이러한 상황에서 WebAuthn은 사용자가 단방향 QR 코드를 통해 사용중인 웹 사이트와 통신하는 대신 Blutooth 또는 NFC와 같은 양방향 통신 프로토콜을 사용하여 사용자의 브라우저와 직접 통신하기 때문에 가능합니다.

사용성 측면에서 보면 상황이 좀 더 복잡합니다. 적어도 표면적으로는 WebAuthn이 다시 승리합니다. W3C 표준이기 때문에 이미 여러 브라우저에서 구현되어 있습니다 이론상 사용자는 타사 소프트웨어를 설치할 필요없이 즉시 WebAuthn을 사용할 수 있습니다. 그러나 실제로는 대부분의 기존 WebAuthn 구현은 2 단계 인증의 한 형태로 사용하거나 사용자를 재 인증하는 방법으로 사용하는 데 중점을 둡니다. 이전에 다른 로그인 방법 (일반적으로 비밀번호)을 통해 동일한 기기에 로그인 한 사람. 기본 인증 요소로서 WebAuthn은 여전히 실행 가능한 구현이 부족합니다.

기타 사소한 고려 사항에는 SQRL이 건물 마스터 키를 훔친 경우 계정 키를 교체하는 t-in 방법 인 반면, WebAuthn은 웹 사이트에 의존하여 키를 취소하기위한 자체 시스템을 구현하고 WebAuthn에 특정 옵션 하드웨어 (예 : Bluetooth 또는 NFC)가 순서대로 필요하다는 사실 SQRL은 작동하는 디스플레이가있는 모든 컴퓨터에서 작동 할 수있는 반면, SQRL은 작동하는 디스플레이가있는 모든 컴퓨터에서 작동 할 수 있습니다. SQRL은 현재로서는 약간의 숨을 쉬는 공간이있을 수 있지만 WebAuthn은 브라우저 공급 업체, 사이트 운영자 및 기타 타사 조직 (예 : W3C)의 지원을 훨씬 더 강력하게 제공합니다. WebAuthn이 기본 인증 요소로 사용할 수 있도록 몇 가지 구현을 가져 오면 웹을 매우 빠르게 장악하기 시작할 것입니다.

Caveats

SQRL은 아직 개발 중입니다. 따라서이 답변에 제시된 자료는 변경 될 수 있습니다. 개발이 계속됨에 따라이 답변의 일부 취약점과 불확실성이 해결 될 것으로 기대합니다. 대부분의 논의는 현재 grc.com의 SQRL 뉴스 그룹 에서 진행되고 있습니다.

SQRL은 사용자 이름 문제에 대한 편리한 솔루션입니다. / password paradox. (예 : 편의 / 보안 절충) 타사를 사용하지 않고 . 가장 널리 사용되는 인증 모델 (사용자 이름 & 비밀번호)에 대한 간단한 대안을 제공하며 가상 보안에 영향을주지 않습니다. 오늘날 사용되는 일반적인 인증 모델 중 iv id = “aee6b5eca9″가 여전히 보안에 관심이있는 한 실질적으로 안전합니다. >

다른 의견에 어느 정도 동의하지만 몇 가지 장점이 있다고 생각합니다.

SQRL을 활성화하려면 마스터 키를 만들어 휴대 전화에 저장해야합니다. . 끝난. 그 순간부터 “SQRL”을 사용하는 모든 웹 사이트에 로그인 할 수 있습니다.추가 정보를 제공하지 않기로 결정하는 한 익명 로그인이됩니다.

자신의 인증서로 작업하는 것보다 훨씬 쉽습니다. 또는 명시적인 사용자 계정 생성 (유효한 이메일 주소 제공을 요청할 수 있음). 은행, 아마존, … 계정에 동일한 마스터 키를 사용하지 않을 수도 있지만, 특히 이러한 “여기에 뭔가를 게시하고 싶습니다”상황에 대해서는 완벽합니다. 더 이상 “여기에 게시하고 싶은 사이트를 Google이나 Facebook 또는 어떤 사이트 에나 알려주십시오.”

댓글

• I ‘이게 타당한 지점인지 확실하지 않습니다. ‘ 익명 로그인을 허용하려는 경우 애초에 로그인해야하는 이유는 무엇입니까? 간단한 보안 문자만으로도 스팸을 방지 할 수 있습니다.
• 익명 로그인은 귀하이기 때문에 귀하의 신원에 대한 정보 제공을 거부 할뿐입니다. 아무도 스푸핑 할 수 없습니다.
• Windows CardSpace를 반쯤 다시 해시하는 것처럼 들립니다.
• 또는 로그인 한 적이없는 사용자로 로그인하는 경우 보안 문자가 표시됩니다.
• ” SQRL을 활성화하려면 마스터 키를 생성하여 휴대폰에 저장해야합니다. ” 실제로는 ‘ 그럴 필요가 없으며 sqrl : // URL을 열 수있는 PC 소프트웨어가 필요합니다.

SQRL은 획기적인 개선 사항을 제공하지 않습니다. QR 코드는 짧은 콘텐츠 배포에 유용한 광학 바코드 형식입니다. 더 이상은 없습니다.

SQRL이 해결하려는 “자동 로그인”상황은 모바일에 저장된 클라이언트 인증서를 대신 사용할 수 있습니다.

p>

가상적으로 HTTPS 페이지의 QR 바코드는 서버에서 이전에 알려진 클라이언트 인증서 (또는 유사한 자격 증명)의 서명 또는 암호화 된 버전을 반환 할 수 있지만 그 이유는 무엇입니까? 자격 만료를 위해? 사이트는 만료 된 자격 증명을 직접 거부 할 수 있습니다.

그래서 제가 가진 가장 큰 보안 문제 프로토콜은 사각 휠의 재발 명 입니다.

Update

새 답변과 댓글을 읽고 SQRL과 유사한 작업을 수행하는 것이 얼마나 쉬운 지 지적하고 싶습니다. 성숙한 기존 기술 의 간단한 자동화 :

1. 웹 사이트에서 보안 문자 또는 이와 유사한 “I”ma human “인증을 요청합니다. 사용자가이를 준수 (게시)하면 웹 사이트에서 HTTP 403.7 - Client Certificate Required 또는 바닐라 403 오류를 반환합니다.
2. 사용자 정의 403 페이지는 설정하기에 충분히 쉬우 며 매우 예쁘고 사용자 친화적 일 수 있습니다. 많은 웹 사이트의 “Adobe Reader 필요”프롬프트와 유사한 방식으로 아래에 필요한 기능을 부트 스트랩 할 수도 있습니다.
3. 사용자 지정 403 페이지에는 사용자 지정 브라우저 플러그인이 반응하는 일부 마크 업이 포함되어 있습니다. 이 사용자 정의 플러그인을 “SQRL 준수”의 정신으로 “S403L 준수”라고 부르겠습니다.
4. S403L 플러그인은 일반적인 암호화 된 브라우저 인증서 캐시 (또는 세 번째)에서 보호되는 표준 클라이언트 인증서를 생성합니다. 브라우저의 키 저장소 암호화가 좋지 않은 경우 파티 캐시). 플러그인은 클라이언트 인증서에 대한 표준 CSR을 생성하고 CSR을 403 마크 업에 지정된 URL로 보냅니다 (예 : <s403l ref="https://www.example.com/S403L" />).
5. S403L 호환 서버는 사용자의 session_id (쿠키 또는 쿼리 문자열에서 검색 됨)를 사용하여 1 단계에서 연속성을 생성 한 다음 서버에서 서명 한 CSR을 반환합니다. 일반 서버 인증은 서버에서 서명 한 (따라서 1 단계에서 요구 한 등록 기준을 충족하는) 모든 클라이언트 인증서를 수락합니다.
6. S403L 플러그인은 서명 된 클라이언트 인증서를 브라우저의 캐시에 저장합니다. 그런 다음 플러그인 지원이없는 표준 브라우저는 인증서가 만료 될 때까지 표준 SSL / TLS 방식으로 서버에 “자동 로그인”할 수 있습니다.

“모바일”및 “시각적”특성 SQRL은 분리 된 2 단계 인증을 제공하지 않으며 인터넷을 탐색하려면 하나가 아닌 두 대의 컴퓨터가 필요하기 때문에 잘못된 방향입니다. 데스크탑의 USB 웹캠을 자체 모니터로 지정하지 않는 한.

암호와 인증서 간의 균형은 보안 커뮤니티에서 잘 정의되어 있습니다. 암호는 인간의 두뇌에 적합하지만 인증서는 적합하지 않습니다. 인간의 두뇌 ( 보통 )이지만 미친 엔트로피 및 우수한 PKI 관리 기능 (만료 , 해지, 정책 확장 등). SQRL은 어느 캠프에도 깔끔하게 맞습니다. 그리고 “인간적이지 않은 컴퓨터 진영으로 표류하는 경우-기존 X.509 기능을 반복하기 위해 수년간의 개발 및 보안 분석을 거쳐야합니다.

댓글

• >는 모바일에 저장된 클라이언트 인증서를 대신 사용할 수 있습니다.— 단,이 기술은 모바일과 데스크톱 모두에서 수년 동안 존재하며 ‘ 원하는 것만 큼 널리 보급되지 않았습니다. 클라이언트 인증서와 달리 SQRL은 ‘ ” SQRL ID “. 원하는 경우 원하는만큼 많은 ID를 만들 수 있습니다. 즉, 클라이언트 인증서와 비교할 때 장점은 인증 프로토콜 ‘ 측에서 익명 성을 갖는다는 것입니다.
• @jpkrohling 클라이언트 인증서에 대한 일반적인 오해입니다. 사용하려면 신원 공개가 필요합니다. 이는 전 세계적으로 상호 교환 가능한 신뢰 체인을 사용하기위한 상업용 서명 기관의 요구 사항입니다. 실제로 클라이언트 인증서는 원하는 기준 (CAPTCHA, 이전 계정, 보안 문자)을 충족 한 후 클라이언트가 만들고 특정 서버에서 서명 한 익명의 CSR 일 수 있습니다. 기타). 인증서에는 기본 제공 만료가있을 수도 있습니다. Type 40-L QR 바코드는 원하는 경우 1KB X.509 클라이언트 인증서를 발송 / 저장할 수 있습니다.
• 알겠습니다. 이러한 관점에서 클라이언트 (예 : 모바일 앱)는 사용자가 등록하는 각 웹 사이트에 대해 클라이언트 인증서를 생성 할 수 있습니다. 이것은 일부 정보를 해싱하는 것보다 비용이 많이 들지만 흥미로운 솔루션이 될 수 있습니다. 어쨌든, 나는 여전히 SQRL이 쓸모없는 것보다 더 나쁘다는 당신의 주장에 동의하지 않습니다.
• 나는 아마도 그 문구에 가혹했고 그것을 제거 할 것입니다. 하지만 저는 ‘ SQRL을 협상 된 클라이언트 자격 증명을 배포하는 더 섹시한 방법으로 보지 않습니다. 그리고 성숙한 인증 체계로 해결 된 미묘한 문제 중 일부를 ‘ 해결하지 않은 것입니다. 비밀번호 관리자는 지루하지만 ‘ ‘ 편집증이 있기 때문에 브라우저 통합에 신경 쓰지 않습니다.) 웹 사이트는 암호화 된 키 저장소에서 각 원샷 비밀번호를 공유합니다. 저는 ‘ 멋진 새 해시 / 인증 체계에 대해 걱정할 필요가 없습니다. 암호 관리자가 암호를 생성하는 데 사용하는 PRNG / TRNG의 품질 만 있으면됩니다.
• @LateralFractal ‘이 새로운 것인지 아닌지 누가 신경 쓰나요? SQRL은 제 1자가 제 2 자 또는 제 2 자의 보안을 침해했을 수있는 제 3 자에게 자신의 비밀을 노출하지 않는 사용자 친화적 인 인증을 허용합니다 ‘. ‘ 지금까지 아무도 해결할 수 없었던 실제 문제를 해결하려는 시도입니다.

첫 번째 질문에 답하고 싶습니다. “제가 생각할 수있는 문제 중 하나는 QR 리더가 손상된 경우 www.google.com을 표시하는 것입니다. www.nsa-super-secret-place.gov/123 “대신 :

마스터 키는 웹 사이트 주소 (FQDN)와 함께 HMAC의 시드로 사용됩니다. 따라서 QR 코드가 완전히 다른 URL을 인코딩 할 수 있지만 프로토콜은 일반적으로 www.google.com (예시)으로 전송되는 인증 코드를 표시하지 않습니다.

둘째, 많은 기여자들은이 아이디어를 실현할 때 핵심 목표를 잊어 버렸습니다.

1. 제 3자를 사용하지 않음으로써 익명 성
2. 사용 편의성
3. 신뢰할 수없는 컴퓨터에서 비밀 자격 증명을 입력 할 필요가 없습니다.

프로토콜이 이러한 문제를 모두 해결한다고 생각합니다!

그러나 실제로 첫 번째 obectjive에서 왔습니다. 제 3자가 인증에 관여하지 않는 경우 인증 세부 정보를 어떻게 취소 할 수 있습니까? 또한 마스터 키의 보안은 명백한 문제입니다. 나는 이것이 칩과 같은 HSM에서 미래의 모바일 장치에 의해 잘 보호 될 것이라고 생각합니다. 그때까지 키는 암호로 보호되는 파일 핀 모바일 장치 일 뿐이지 만 PBDKF2는 실제로 강제로 강제하는 것이 매우 느리다는 것을 보장합니다.

댓글

• 다시이 아이디어에 대해 새로운 ‘은 무엇입니까? 지금은 없어진 Windows CardSpace의 원시적 인 변형 인 것 같습니다.
• 예, CardSpace에 대해 맞습니다. 그리고 마이크로 소프트가 소유 한 U-Prove도 있습니다. 문제는 당신이 신뢰하지 않는 컴퓨터 (인터넷 카페 나 친구 컴퓨터)에서 CardSpace 나 U-Prove를 어떻게 사용 하느냐하는 것입니다. 그것이 Steve가 추가 한 것입니다.
• 아, 좋습니다. ‘가 제가 놓친 것입니다. 사용자 키에 대한 취소 메커니즘이없는 비스타 터라는 @TerryChia에 여전히 동의합니다.
• @Xander 사용자 키에 대한 취소 메커니즘이 있습니다 . grc.com/sqrl/idlock.htm