비밀번호의 보안 취약점과 사용성 문제는 잘 알려져 있습니다. 비밀번호는 사용자가 기억하는 정보이므로 잊어버릴 위험이 있으며, 실제로도 자주 발생합니다. 따라서 이메일은 비밀번호 초기화를 위한 백업 수단으로 널리 사용되고 있습니다.
이메일 역시 많은 문제가 있습니다. 비밀번호와 마찬가지로, 사람들은 대개 여러 서비스에서 동일한 이메일 주소를 재사용하여, 해당 이메일이 특정 서비스에서 노출될 경우 프라이버시 위험을 초래합니다. 또한, 이메일 서버에 개인 식별 정보를 제공하지 않고 이메일 주소를 얻는 것은 점점 더 어려워지고 있습니다. 스팸 메일을 억제하기 위해(그리고 아마도 사용자에게 광고를 더 쉽게 타겟팅할 수 있기 때문에) 무료 이메일 서비스는 일반적으로 특정 개인과 쉽게 연결할 수 있는 전화번호를 제공하도록 요구합니다. 유료 이메일 서비스는 전화번호를 요구하지 않을 수 있지만, 개인 식별 정보 없이 서비스에 비용을 지불하는 것도 어렵고, 유료 이메일 서비스 구독에 의존하는 것은 재정적 상황의 변화에 취약합니다. 또한, 오늘날에는 이메일 서버를 안정적으로 자체 호스팅하는 것이 어렵습니다. 프라이버시 문제 외에도, 여러 서비스에서 이메일 계정을 재사용함으로써 발생하는 중앙 집중화는 이메일 계정이 탈취될 경우 수많은 다른 계정까지 탈취될 수 있는 보안 위험을 초래합니다.
오늘날에는 서비스 가입 또는 인증에 비밀번호나 이메일이 필요하지 않습니다. Discourse는 이미 FIDO와 TOTP를 지원하지만, 가입과 인증을 위해 여전히 비밀번호와 이메일 주소를 요구합니다. Discourse가 FIDO와 TOTP를 우선시하여 비밀번호와 이메일을 선택 사항으로 만들 수 있다면 좋겠습니다.
FIDO를 이용한 1인자 인증은 매우 편리할 수 있지만, 단일 FIDO 토큰의 분실 또는 파괴에 취약하며, 이는 이메일 주소 없이 비밀번호로 가입하는 경우의 문제와 유사합니다. 이를 해결하기 위해, 가입 시 FIDO, TOTP, 비밀번호의 어떤 조합이든 최소 두 가지 인자를 제공하도록 요구하는 방안을 제안합니다. 이메일 및 비밀번호 없는 인증을 원하는 사용자는 Yubikey와 같은 두 개의 FIDO 로밍 인증기를 등록하기만 하면 됩니다. 계정 접근을 잃지 않도록 최소 두 개 이상의 인자를 등록하도록 사용자에게 권장(특히 관리자의 경우 잠재적으로 필수로)할 수 있습니다.
요즘 Windows Hello, Apple Touch & Face ID, Android 등을 통해 FIDO 플랫폼 인증기가越来越多的 디바이스에 내장되고 있기 때문에, 이 이메일 없는 가입 시스템은 Yubikey와 같은 전문 로밍 인증기 하드웨어를 소유하지 않은 비기술적 사용자들도 사용할 수 있을 것입니다. 사용자는 FIDO 플랫폼 인증기와 비밀번호로 가입할 수 있습니다. FIDO 플랫폼 인증기를 이용한 1인자 인증은 이러한 설정에서 원활하게 작동할 수 있습니다. 그러나 이는 새 디바이스에서 인증할 때 사용성 문제를 야기합니다. 새 디바이스에는 FIDO 플랫폼 인증기가 없으므로, 새 디바이스 설정을 위해 비밀번호에만 의존하는 것은 안전하지 않기 때문입니다. 이를 해결하기 위해, Matrix가 새 클라이언트를 인증하는 방식과 유사한 워크플로우를 제안합니다. 사용자는 새 디바이스에서 해당 디바이스의 FIDO 플랫폼 인증기(새 인자)와 비밀번호(이미 등록된 인자)를 사용하여 로그인할 수 있습니다. 이는 실제로 로그인을 수행하지는 않지만, 계정에서 새 FIDO 인증기를 승인하기 위한 요청을 생성합니다. 이후 새 디바이스의 UI는 사용자가 이미 등록된 디바이스에 로그인하여 새 디바이스를 승인하도록 안내합니다. 모바일 디바이스에 FIDO 플랫폼 인증기가 내장되어 있으므로, 이는 전문 로밍 인증기 하드웨어 없이도, 또는 공공 키오스크와 같은 임의의 디바이스를 사용할 수 있는 능력을 희생하지 않으면서도 안전한 인증을 실제로 사용할 수 있게 해줄 수 있습니다.
저는 어제 Yubikey를 수령한 직후 이 익명 가입 및 인증 시스템을 고안했습니다. 이 방식을 구현하는 시스템이 있는지 저는 알지 못합니다. Discourse와 같이 성숙하고 이미 널리 배포된 웹 애플리케이션이 이메일이나 기타 개인 식별 정보 없이 인터넷을 사용할 수 있는 미래를 개척하는 모습을 보고 싶습니다.
아마도 사실일 겁니다. 하지만 당신이 제안하는 시스템으로 로그인할 사람들이 비밀번호 관리자를 모른다고 상상하기는 어렵습니다. 저는 약 10년 동안 비밀번호 관리자를 사용해 왔고, 여러 개의 FIDO 키를 보유하고 있으며, Google Authenticator도 사용하고 있습니다. 그래서 당신이 제안하는 것이 정확히 무엇인지 잘 이해가 가지 않습니다.
최소한 몇몇 엔터프라이즈 고객이 원하지 않는 한, 이런 시스템이 추가될 가능성은 낮아 보입니다. 인증 시스템에 대해 잘 아는 사람이 최소 50시간 이상, 적절한 명세서가 있다면 그 두 배 정도가 걸릴 것으로 추정됩니다. 과거에 일부 기능을 수행할 수 있는 keybase와 통합하려는 시도가 있었지만, 큰 진전이 없었다고 생각합니다.
이전에는 이메일이 없는 시스템을 만드는 것이 얼마나 어려울지 과소평가했습니다. not-email.invalid 호스트名的 이메일을 가진 사용자를 위해 다른 식별자를 사용하는 것이 가능할 것입니다. 사람들이 Ethereum을 사용하도록 유도할 수 있다면 Sign-In with Ethereum 플러그인이 원하는 기능을 수행할 수 있을 것입니다. 하지만 유사한 방식도 작동할 수 있습니다. 신원을 확인하는 어떤 방식이든 필요합니다.
다양한 웹앱을 다루면서 느낀 바로는, 스팸 봇이 Gmail이나 기타 이메일 주소를 만드는 데 큰 어려움을 겪지 않습니다. 제 사이트에서도 임시 메일이나 일회용 이메일 주소를 차단하지 않고 있습니다. 또한 이메일 주소(또는 유효하지 않은 이메일 주소) 없이 가입을 허용하는 다른 포럼 소프트웨어/포럼들도 있는데, 제가 확인한 바로는 이로 인해 문제가 발생하지 않았습니다. 따라서 이메일 주소를 봇/DoS 공격 계정 범람을 방지하는 큰 장벽으로 보지 않습니다.
하지만 어떤 측면에서 그렇게 생각하실 수 있다는 점은 이해합니다. 이메일 주소 없이 가입을 허용하면 후속 문제가 많이 발생할 수 있습니다. 만약 봇 공격과/또는 DoS 공격이 대규모로 발생하여 수많은 포럼 계정이 생성된다면 어떻게 될까요?
그 경우 스팸 방지 조치가 필요합니다. 하지만 이러한 조치는 이메일이 선택적인 포럼 인스턴스와 이메일이 필수적인 포럼 인스턴스 사이에 차이가 없습니다.
왜냐하면 스팸러들도 오늘날에는 대량으로 생성되거나 해킹된 이메일 주소에 접근할 수 있기 때문입니다. 그들은 임시 이메일 제공업체를 사용하거나, 도메인 이름을 구매/도용하여 스팸성 포럼 설정을 위해 전용 이메일 서버를 구축할 수도 있습니다.
이메일 사용/미사용 사용자 모두에게 동일한 질문이 제기됩니다. 이번 토론을 위해 이론적인 질문을 나열해 보겠습니다.
X일 이후에 생성되었고, 로그인 시간이 X분 미만이며, 게시글이 0개인 모든 계정을 어떻게 확인합니까? 아마도 봇 계정일 것입니다. 이 모든 계정을 찾아 삭제하고 싶습니다.
가입을 수락하기 전에 사용자 정의 질문/퍼즐/CAPTCHA/기타 무언가를 추가하는 방법은 무엇입니까?
관리자 패널에 대량 가입 스팸을 처리할 수 있도록 관리자가 새 가입자를 쉽게 승인/비승인할 수 있는 간편한 버튼이 있었으면 좋겠습니다.
패스키가 널리 사용되면서, 이제 많은 서비스들이 비밀번호 없이 가입할 수 있는 옵션을 제공하고 있습니다. 이렇게 하면 비밀번호를 만들 필요가 전혀 없습니다. 비밀번호를 사용하면 패스키의 보안 이점을 무효화하게 됩니다. 마찬가지로, 이메일을 복구 수단으로 사용하는 경우 모든 계정의 보안이 이메일 계정의 보안에 좌우됩니다. 비밀번호나 이메일을 요구하는 것은 사용자 보안과 사생활 보호에 좋지 않으며, 새 이메일 계정을 만드는 것이 얼마나 쉬운지도 고려해야 합니다. 경험상 이메일 요구 조건은 봇이 포럼에 스팸을 뿌리는 것을 전혀 막지 못합니다. 서비스가 과거에 이메일을 요구했던 주요 이유는 비밀번호를 잊었을 때 계정을 복구할 수 있도록 하기 위해서였지만, 패스키를 사용하면 비밀번호 관리자에 저장되어 여러 기기間で 동기화됩니다. 또한 하나의 계정에 여러 패스키를 추가할 수 있어, 사람들이 비밀번호를 잊는 문제를 거의 완전히 해결할 수 있습니다. 비밀번호 없이 가입할 수 있는 사이트의 예시는 다음과 같습니다:
Target은 이메일/비밀번호 옵션 없이 패스키만으로 가입을 지원하고, Discourse는 이메일 또는 SSO를 통한 이메일 사용을 강제합니다. Kayak(솔직히 그 도메인 이름은 정말 싫어요 )은 Google SSO만 사용하는데, Discourse는 이미 이 기능을 제공하고 있습니다.
따라서 지금 남은 질문은 Target이 사용하는 것과 유사한 옵션을 제공할 수 있는가 하는 것입니다. Kayak 방식은 이미 있으니요(저는 가입을 Google 사용자만 가능하도록 제한하지는 않겠지만, 이건 제 개인적인 의견입니다).
만약 Target 사용자가 예를 들어 iPhone에서 Android로 기기 변경을 한다면 어떻게 되나요?
)은 Google SSO만 사용하는데, Discourse는 이미 이 기능을 제공하고 있습니다.