☰

oAuth는 어떻게 더 안전합니까?

tag-icon • tag-icon security oauth2
oAuth는 어떻게 더 안전합니까?

Google의 IMAP 메일과 같은 많은 서비스가 사용자 ID/비밀번호 인증에서 oAuth를 사용하는 방식으로 전환되었습니다.

oAuth는 더 많은 모니터링 리소스를 갖춘 대규모 기업에서 제공하는 서비스 외에 어떻게 더 안전합니까?

답변1

기술적 이점은 다음과 같습니다.

  • OAuth의 "초기 인증" 부분은 웹 사이트를 통해 수행되므로 단순한 비밀번호보다 다른 인증 요소를 더 쉽게 요청할 수 있습니다. 예를 들어 TOTP 일회성 코드나 U2F 키를 요청할 수 있습니다. (필요한 경우 reCAPTCHA를 사용할 수도 있습니다.)

    • 일반적으로 이는 입력하는 비밀번호가 웹 브라우저에만 표시되며 메일 앱에서는 실제로 표시되지 않음을 의미합니다.

      요즘 Google은 특히 호스트 프로그램에 비밀번호를 공개하도록 만들 수 있는 "내장" 브라우저 내에 인증 페이지가 로드되는 것을 방지하는 데 더욱 적극적입니다. (이전 GNOME 버전은 당시 OAuth2를 지원하지 않았던 특정 Google API를 사용해야 했기 때문에 이 작업을 반합법적으로 수행했습니다.)

    • 또한 웹사이트를 사용하면 UI가 실제 웹 기반 서비스와 더 일관되게 유지되고 새로운 사용자 정의 다단계 인증 방법을 개발하는 것보다 앱에서 구현하기가 다소 더 간단해집니다.

      (사용자 정의 텍스트가 포함된 여러 프롬프트를 표시할 수 있는 "KeyboardInteractive" 인증 방법이 있는 SSH와 비교해 보세요. 기본 비밀번호+OTP 또는 키 쌍+OTP에서는 괜찮지만 2FA의 경우 전반적으로 다소 서투릅니다. 많은 기업이 실제로 종료합니다. OAuth2 토큰 또는 Kerberos 티켓과 매우 유사한 방식으로 단기 SSH 키 쌍을 사용하는 시스템을 구현합니다. 회사 SSO 웹 사이트를 통해 인증하여 당일 SSH 키를 얻습니다.)

  • 메일 클라이언트에 발급된 토큰은 특정 서비스(범위)(이 경우 IMAP 및 SMTP)에만 액세스할 수 있습니다. 예를 들어 드라이브 파일이나 YouTube 기록에 액세스하는 데 사용할 수 없습니다.

    • 이는 서비스 제공자 측에서 남용될 가능성이 있지만(예: Google은 사용자가 100명이 넘고 메일 관련 범위에 액세스하려는 OAuth2 앱에 대해 값비싼 "검증"을 요구함).

    • 수동으로 생성된 "앱 비밀번호"~할 수 있었다또한 특정 서비스로 제한되지만 해당 기능을 효과적으로 사용하는 사람은 거의 없습니다. 예를 들어 GitHub 액세스 토큰을 사용하면 가능하지만 어떤 앱에 어떤 범위가 필요한지 결정하는 데(종종 시행착오를 거쳐) 너무 많은 정신적 노력이 필요하므로 가능한 모든 범위가 활성화되면 많은 토큰이 생성됩니다...

서비스 제공업체에는 다음과 같은 "심층 방어" 이점도 있습니다.

  • 실제 서비스는 실제 비밀번호(새로 고침 토큰도 – 단기 액세스 토큰만 해당)를 수신하지 않으므로 한 서비스가 손상되더라도 다른 서비스에 액세스하기 위한 자격 증명을 수집할 수 없습니다("측면 이동"?).

    • 이는 Active Directory의 Kerberos 티켓 사용이나 엔터프라이즈 SSO 시스템의 SAML 어설션 사용과 매우 유사합니다.

      이러한 모든 시스템에서는 사용자 데이터베이스에 대한 액세스가 필요한 모든 서비스 대신(모두 중요한 대상임) KDC 또는 IdP만이 특권적인 위치에 있게 됩니다.

답변2

나는 적어도 몇 가지 가능한 긍정적인 점을 볼 수 있습니다.

  1. 비밀번호 재사용 가능성이 줄어듭니다. 비밀번호를 더 많이 입력할수록 심각한 유출 가능성이 높아지고, 비밀번호를 재사용하면 다른 사이트도 위험에 처하게 됩니다.
  2. 다수의 사이트에 대한 접근권한을 한 번에 신속하게 철회할 수 있는 중앙권한을 제공합니다. 사이트는 Google에 의해 "액세스 토큰"만 제공되므로 모두 고유할 수 있으며 개별적으로 또는 한꺼번에 취소될 수 있습니다.
  3. 이는 사이트에서 비밀번호 변경을 처리하고 비밀번호를 안전하게 저장해야 할 필요성을 숨깁니다. 비밀번호를 받지 못한 경우 비밀번호를 일반 텍스트로 저장할 수 없습니다. 일부 사이트에서는 그랬거나 지금도 그렇게 하고 있을 것입니다.
    그들~해야 한다여전히 토큰을 안전하게 처리하지만 위반이 발생한 경우 프로세스가 더 간단합니다. OAuth 제공업체에 위반 사실을 알리면 다음에 사용자가 인증할 때 새 토큰을 받을 때까지 토큰이 취소됩니다.

OAuth 제공업체의 보안이 필요하지만 한 곳에서 비밀번호를 재설정하는 것이 50~500개 사이트에서 비밀번호를 재설정하는 것보다 훨씬 쉽습니다.

관련 정보