패스키는 인증에 비밀번호를 사용하는 것보다 더 안전하고 단순한 대안입니다. 패스키 생성과 사용은 이제 다양한 플랫폼과 브라우저에서 널리 지원되고 있습니다. 비밀번호와 비교할 때, 패스키는 플랫폼이 생성하는 강력한 자격 증명과 생체 정보 확인(예: Touch ID, Face ID, PIN 또는 기기 비밀번호) 덕분에 내장된 안전성이 더 뛰어납니다. 패스키는 서버 측 정보 유출(키의 비밀 부분은 절대 기기를 벗어나지 않음)이나 피싱(각 키는 하나의 웹사이트/서비스에만 연결됨)에도 안전합니다.
기능 배포
호스티드(Hosted) 고객인 경우, 패스키 지원이 향후 며칠 내에 인스턴스에 배포될 예정입니다. 지금 바로 활성화하고 싶으시다면, 메타(meta)에서 @team에게 연락하시거나 team@discourse.org로 이메일을 보내주세요.
Discourse를 셀프호스팅(Self-hosting) 중인 경우, 해당 기능이 곧 Discourse 코어에서 기본적으로 활성화될 것입니다이 커밋 시점에 코어에서 기본적으로 활성화되었습니다. 비활성화하고 싶으시다면 Rails 콘솔을 통해 다음을 실행할 수 있습니다:
launcher enter app
rails c
SiteSetting.enable_passkeys = false
패스키는 로컬 로그인(local logins)이 활성화된 Discourse 인스턴스에서만 사용할 수 있습니다. 인스턴스가 로컬 로그인을 사용하지 않는 경우, 패스키 기능은 효과가 없습니다.
기능이 활성화되면, 사용자는 사용자 설정의 보안 탭으로 이동하여 계정에 패스키를 추가할 수 있습니다:
훌륭한 추가 기능입니다! 하지만 비밀번호로 로그인하면 보안상의 이점을 쉽게 우회할 수 있습니다. 비밀번호를 입력한 후에도 패스키를 다시 입력하라는 프롬프트가 나올 것으로 기대했지만, 실제로는 비밀번호만으로 로그인됩니다. 이는 별도의 2FA 설정에서 보안 키를 다시 등록함으로써 방지할 수 있지만, 이 방법은 직관적이지 않고 번거롭습니다.
결국 비밀번호를 완전히 비활성화할 수 있도록 할 계획이 있나요? (계정 설정 단위로 가능하면 좋겠습니다. 사이트 전체에 이를 강제하는 것은 좋은 결과로 이어지지 않을 것 같거든요.) 비밀번호와 패스키가 동시에 활성화되어 있으면 패스키의 유용성이 다소 제한되기 때문입니다. 매우 복잡한 비밀번호를 만들어 두고 절대 사용하지 않는 방식으로 어느 정도 해결할 수는 있지만, 이는 패스키의 본질을 우회하는 것에 불과합니다.
패스키 메커니즘을 제가 이해한 바로는, 접근 키를 저장하기 위해 비밀번호 관리자 같은 신뢰할 수 있는 컨테이너를 설치해 두어야 합니다. 비밀번호를 없애는 것은 모든 사용자가 이러한 관리자를 설치해 두었다고 가정하기 때문에, 그렇지 않은 사용자는 어떻게 로그인해야 하나요?
2FA를 사용하지 않는 사람들이 2FA가 필요한 사이트에 접근하는 방식과 똑같습니다 — 그냥 접근하지 않는 것이죠.
2024년 현재 비밀번호 관리 도구(어차피 이미 사용해야 합니다)의 대안으로 Chrome, Safari, Windows, iPhone, Android, Yubi 등이 모두 존재하며, 이 모든 것이 패스키와 함께 작동한다는 점을 고려하면, 이것이 실제 우려 사항은 아닙니다.
또한 모든 사용자에게 비밀번호를 없애도록 강제하자는 제안을 한 것도 아닙니다(그렇게 되는 것에 반대하지는 않지만). 하지만 패스키를 사용하는 당신(사용자)이 비밀번호를 비활성화할 수 없다면, 패스키의 목적은 훨씬 약해지고 여전히 피싱 공격에 완전히 취약한 상태가 됩니다.
제가 디스커스에 패스키를 선택했다면 더 이상 비밀번호를 사용하지 않을 텐데, 그러면 어떻게 피싱 공격을 당할 수 있죠? 비밀번호 로그인에 대한 악성 공격이나 무차별 대입 공격(브루트포스)의 위험은 남을 것이라는 점은 이해합니다. 그리고 사용자별로 이를 비활성화하라는 여러분의 제안은 타당합니다. 하지만 피싱 공격을 통해서는 불가능한 것 아닌가요?
