질문의 마지막 부분과 관련하여 : 아니요, 안전하지 않은 인증 시스템을 사용하는 것은 결코 용서할 수 없습니다. 컴퓨터 보안과 관련하여 사용자는 거의 깨닫지 못합니다. 사용자는 자신의 Google 게임, Facebook 계정, 은행 계좌 등에 사용하는 것과 동일한 암호를 작은 게임에 사용합니다. 인터넷 보안 습관을 잘못 사용하는 것이 잘못이라고 주장하더라도 귀하의 게임이 사용자의 로그인 자격 증명을 도용하기위한 공격 경로로 사용될 경우 책임을 져야합니다. 더 잘 아는 개발자로서 유일한 윤리적 옵션은 인증 프로세스를 올바르게 보호하거나 전혀 갖지 않는 것입니다.
원치 않는 관련 조언으로, 사용자는 게임에 등록 할 필요가 없습니다. 그들은 당신의 게임을 충분히 나쁘게 플레이하고 싶다면 그렇게 할 수 있지만, 아직 다른 Freaking Login에 가입하면 많은 잠재적 인 플레이어를 몰아 낼 수 있습니다. 특히 모든 종류의 전자 메일 확인 등이 필요한 경우 사용자는 모든 단일 사이트, 서비스 및 게임에 대해 새 계정을 만들지 못합니다. 가능하면 로그인을 전혀하지 않거나 사용자가 이미 계정을 가지고있는 기존의 타사 인증 서비스를 사용하십시오. 그런 식으로 더 많은 선수가 생깁니다. 인앱 구매를 계획하고 있다면 트리플이됩니다.
웹 게임
특히 전통적인 게임에서도 작동하지만 웹 게임에 널리 사용되는 옵션은 웹 기반 타사 인증 서비스를 사용하는 것입니다. Facebook과 Google에는 인증을 위해 잘 문서화 된 API (표준화 된 API를 기반으로하는 iirc)가 있습니다. 브라우저 창을 열고 사용자를 자신의 서비스로 안내 할 수있는 기능이 필요하지만 대부분의 콘솔 이외의 플랫폼에서는 물론 웹 게임에는 적합하지 않습니다.
이러한 서비스는 유선으로 로그인 트래픽을 암호화하고 로그인 자격 증명을 안전하게 저장하고 사용자 로그인을 확인하는 복잡한 모든 세부 사항을 처리합니다. 그런 다음 게임 서버는 사용자로부터 쿠키를받는 프로토콜 부분 만 구현하면되고 쿠키가 유효한지 인증 서비스에 요청합니다. 대부분의 경우 간단한 HTTP로 수행 할 수 있습니다.
나는 대부분의 전통적인 멀티 플레이어 게임이 그렇지 않다고 주장하지는 않지만 대부분의 온라인 캐주얼 웹 게임이 그렇게한다고 주장합니다.
웹 (비웹) 게임의 경우 브라우저 (Awesomium, Chromium Embedded Framework 또는 웹킷을 널리 사용하는 방법)를 내장하거나 외부 브라우저를 호출하여이 로그인 절차를 쉽게 수행 할 수 있습니다. 인증 쿠키를 제거하고 위에서 언급 한 라이브러리 중 하나를 포함시키는 것보다 쉽지는 않습니다.
이 방법의 전형적인 예는 모든 Facebook 게임입니다.
HTTPS를 사용하는 전통적인 게임
로그인을 위해 간단한 HTTPS 서비스를 사용하는 것이 점점 일반화되고 있습니다. 많은 게임들이 커스텀 프로토콜을 사용하지만 이것들은 대부분 불완전합니다 (보안 로그인이 있지만 계정을 생성 / 업데이트 할 수있는 안전한 방법이 없기 때문에 어쨌든 HTTPS 서비스가 필요합니다).
맞춤 SSL 인증서를받을 필요조차 없습니다. 하위 도메인을 제공하고 와일드 카드 SSL 인증서를 사용하는 온라인 앱 호스팅 제공 업체가 있습니다. 인증 서비스는 mygame.someservice.com에 배치 할 수 있습니다. mygame.someservice.com은 일부 서비스가 유지 관리하는 * .someservice.com 와일드 카드 인증서에 의해 보호됩니다.
여기서 아이디어는 사용자가 서비스에 로그인하여 고유 한 세션 쿠키를 생성 한 다음 사용자가 주 게임 서버에 전달할 수 있다는 것입니다. 그런 다음 서버는 로그인 시스템에 쿠키가 요청 된 사용자에게 유효한지 묻습니다. 일반적으로 쿠키에는 시간 이 매우 짧으며 초 단위 (예 : 15-30)이며 일반적으로 한 번 사용하면 무효화되므로 재생 공격이 불가능합니다.
클라이언트 내부에서 유선으로 결제 정보를 보내려는 경우 HTTPS가 가장 권장되는 옵션입니다. 그러나이를 위해 타사를 사용하는 것이 훨씬 좋습니다. 암호처럼 단순한 것을 확보하는 것이 너무 많은 일이라고 생각한다면 신용 카드 번호를 저장하고 처리하기위한 최소한의 (정직하게는 적절하지 않은) PCI 준수 규칙을 준수하려고한다고 생각조차하기를 원하지 않습니다. 사용자가 이미 보관하고있는 신뢰할 수있는 타사 결제 서비스를 사용하도록하면 판매 실적이 향상됩니다.
메인 게임 서버에서 로그인 서비스를 분리 할 때 얻을 수있는 장점 중 하나는 게임과 관계없이 외부 기능을 사용자 계정에 연결할 수 있다는 것입니다. 웹 사이트에 일부 계정 기능 (아바타보기 등)이 있거나 Facebook 계정을 계정에 연결하도록 허용하거나 단일 기본 계정 플랫폼 (예 : Mass Effect의 Galaxy at War 기능)을 공유하는 여러 게임이있을 수 있습니다. 삼).
인증을 위해 HTTPS를 사용하는 인기있는 예제 게임은 Minecraft입니다.
기본 클라이언트 게임을 사용한 타사 웹 인증
기본 클라이언트에서 Facebook Connect 또는 Google과 같은 타사 서비스를 사용할 수 있습니다. 예를 들어 Facebook은 Google과 마찬가지로 iOS 및 Android 용 기본 SDK를 가지고 있습니다. 일부 서비스에는 기존 PC 클라이언트를위한 기본 SDK가 있습니다.
대상 서비스에 기본 SDK가없고 웹 브라우저를 사용해야하는 경우 게임에 브라우저를 포함시킬 수 있습니다. 그러나 일부 사용자는 내장 브라우저를 사용하여 로그인 정보를 입력하는 것을 신뢰할 수 없습니다.
외부 브라우저를 사용할 수도 있습니다. 이것을 해제하는 몇 가지 방법이 있습니다. 일부는 다른 것보다 약간 더 많은 OS 통합이 필요합니다. 일부는 주 게임 서버와 함께 (또는 최소한 연결 가능한) 외부 웹 서비스가 필요합니다. Facebook과 Google에는 일반적으로 인증 된 URL이 필요하기 때문에 (거의) 모든 경우에 이러한 프로토콜을 사용하려면 공개 웹 사이트 방문 페이지가 필요합니다.
가장 쉬운 방법은 아니지만 가장 안전하고 신뢰할 수있는 방법은 기본 웹 사이트를 통해 클라이언트의 로그인 요청을 반송하는 것입니다. 클라이언트는 인증 된 게스트 사용자로 주 게임 서버에 연결하고 고유 한 세션 토큰을받습니다. 게임 서버는이 상태에서 클라이언트가 실제로 많은 것을 할 수 있도록 허용하지 않습니다. 게임은 플레이어가 누구인지 알지 못하므로 플레이어는 아직 채팅하거나 경기를 시작할 수 없습니다.
그런 다음 클라이언트는 게임 도메인의 로그인 URL을 가리키는 외부 브라우저를 시작하여이 세션 토큰을 URL의 매개 변수로 전달합니다. 그런 다음 사이트는 Facebook / Google의 일반적인 로그인 핸드 셰이크를 거칩니다.
이 시점에서 웹 서버는 사용자가 로그인했음을 알고이를 클라이언트에서받은 세션 토큰과 연결할 수 있습니다. 그런 다음이 확인은 게임 서버와 통신하여 클라이언트의 인증되지 않은 게스트 연결을 인증 된 사용자 세션으로 올릴 수 있습니다. 가능한 경우 웹 서버가 게임 서버와 직접 통신하도록하여 수행 할 수 있습니다. 또는 게임 서버는 보류중인 게스트 연결의 인증 상태를 위해 웹 서버를 주기적으로 폴링 할 수 있습니다. 또는 클라이언트는 정기적으로 웹 서버를 폴링하여 로그인이 완료되었는지 확인하고, 웹 서버에서 확인을 요청하도록 게임 서버에 신호를 보낼 수 있습니다.
이 모든 웹 서버 게임 서버와 통신 할 수있을 것을 요구하지만, 어떤 이는 놀랄 일이 안 귀하의 게임 서버가 필요합니다 타사 인증 서비스, 외부 세계와 통신 할 수 있도록.
이 인증 방법은 일부 중소 규모 MMO에서 찾을 수 있습니다.
이 모두는 PayPal, Amazon Payments, Google Wallet 등과 같은 외부 서비스를 통해 지불 요청을 할 때도 작동합니다.
직접 TLS 연결
커스텀 스트림 프로토콜을 통해 TLS 세션을 시작하는 것은 그리 어렵지 않습니다. OpenSSL, GnuTLS, NSS 및 다양한 OS 특정 라이브러리와 같은 라이브러리는 저수준 전송 / 프로토콜을 계층화하는 스트림 래퍼 API를 제공합니다. 일반적으로 래퍼 API를 통해 바이트를 공급하면 핸드 셰이크 및 암호화가 처리됩니다.
여기서 까다로운 부분은 TLS를 안전하게 사용하는 것입니다. 예를 들어 일부 공용 라이브러리는 기본적으로 신뢰할 수있는 기관의 유효한 서명 된 인증서를 요구합니다. 공통 라이브러리 중 일부는이를 요구하지만 기본적으로 어떤 권한도 신뢰하지 않습니다. 그들 중 일부는 인증서가 전혀 유효하지 않아도됩니다.
항상 유효한 인증서가 필요합니다. 유효하지 않은 인증서를 허용하면 도청을하는 공격자가 암호를 훔칠 수는 없지만 중간자 (man-in-the-middle) 공격은 여전히 허용됩니다.
이 접근 방식은 최대의 보안을 유지하면서 외부 종속성 측면에서는 절대적으로 필요합니다.
이것을 사용하는 게임의 예는 이제 가장 큰 전통적인 MMO를 포함합니다.
전통적 게임 보안
별도의 서비스를 사용하지 않고 TLS를 사용하지 않는 게임은 일반적으로 기본 게임 프로토콜에서 일종의 nonce 기반 로그인 프로토콜을 구현해야합니다. 이 방법을 사용하면 서버는 난수 (넌스)를 생성하여 클라이언트에 보냅니다. 그런 다음 클라이언트는 사용자의 비밀번호 (및 사용자 이름, 가능한 경우 다른 데이터)를 사용하여 해당 nonce를 해시하고 해당 응답을 서버로 보냅니다. 그런 다음 서버는이 해시 값을 파일에있는 자격 증명과 비교합니다. 이렇게하면 사용자 암호가 유선으로 비밀리에 유지되고 다른 많은 약한 해시 기반 로그인 체계와 같이 해시 된 암호에 대한 간단한 재생 공격을 사용할 수 없습니다.
문제는 사용자가이 프로토콜을 통해 서비스에 새 비밀번호를 안전하게 제출할 방법이 없다는 것입니다. 일반적인 구현은 서버에 일반 텍스트로 사용자의 비밀번호를 저장합니다. 이는 끔찍한 관행입니다 (서버가 해킹 된 경우 사용자는 게임에 동일한 비밀번호를 사용했기 때문에 이메일 / 페이스 북 / 은행 비밀번호를 도난 당했을 것입니다) 사용자가 그렇게하는 경향이 있기 때문에 다른 모든 곳).
해당 기본 로그인 체계의 향상된 버전이 있습니다. 가장 기본적인 (아직 안전하지는 않지만) 로그인하는 동안 서버가 nonce 값으로 비밀번호 해시 솔트를 보내는 것입니다. 이를 통해 서버는 해싱 된 (및 솔트 된) 비밀번호를 안전하게 저장하는 동시에 로그인하는 동안 클라이언트가 동일한 해시를 생성 할 수 있습니다. 이를 통해 침입자는 특정 사용자의 암호에 대한 염분을 얻을 수 있지만 원래의 해시 된 암호 (로그인하는 동안 유선으로 전송되지 않음)를 얻지 않으면 특히 유용하지 않습니다. 암호를 생성 / 업데이트하는 동안 클라이언트는 해시 된 암호 전체 (소금 포함)를 보내 공격자가 스니핑 할 수 있습니다. 사용 된 해시 함수가 충분히 강하면 (예 : sha-2 / 512) 순수한 무차별 강제 실행이 불가능합니다. 공격자는 여전히 취약한 암호를 쉽게 무차별 공격 할 수 있습니다 (따라서 최소 암호 길이, 문자 / 숫자 / 기호의 최소 배포 및 알려진 / 명백한 / 약한 암호의 사전과 비교하는 것이 중요합니다). 공격자가 여전히 해시 된 암호를 얻을 수 있다는 사실은 보안되고 암호화 된 채널을 통해 전체 암호 교환을 수행하는 것이 더 안전한 이유입니다.
많은 인기있는 게임 네트워킹 라이브러리가이 프로토콜의 일부 선택적 형식을 구현합니다. 나는 SmartFox가 그러한 예 중 하나라고 생각하지만, 깊이 살펴 보지는 않았습니다 (일반적으로 그러한 라이브러리 인증 시스템을 무시하고 HTTPS 방법을 사용합니다. 구현하기가 간단하고 상당히 강력하기 때문에). 초기의 웹이 아닌 많은 인터넷 게임들도이 접근 방식을 사용했습니다. 특히 Steam, XBL 등이 등장하기 전에 말입니다.
안전하지 않은 전통 게임
불행히도 많은 게임은 일반 텍스트로 사용자 이름 / 암호를 보냅니다. 어쩌면 그들은 암호를 해시하여 모호한 종류의 사용자를 실제 암호 (거의 충분하지는 않지만)를 보호하지만 재생 공격은 게임 서비스에 사소한 로그인을합니다.
이러지 마 무책임하고 게으르다. 이러한 로그인 방법을 대중화 한 1990 년대의 인터넷 순진은 더 이상 실용적인 변명이 아닙니다.
초기의 초기 페이스 북 플래시 및 웹 게임에서이 방법을 사용했습니다. 나는 머리 꼭대기에서 구체적인 예를 모른다. 나는 그들이 모두 오래 죽었다고 믿고 싶지만 세상은 그렇게 운이 좋지 않습니다.
인증 안함
대부분의 게임은 인증을하지 않습니다. 플레이어가 연결하고 핸들을 통해 자신을 고유하게 식별 한 후 경기가 시작됩니다. 실제 사람 중 한 명만이 "CaptainMisterDude"라고 주장 할 수 있는지 확인하는 글로벌 서버는 없습니다. 로컬 서버는 현재 연결된 플레이어 중 하나만 특정 핸들을 가지고 있는지 확인합니다. 로컬 서버는 문제 발생자를 위해 이름 기반 및 IP 기반 블랙리스트를 사용합니다. 이것은 오늘날에도 FPS 데스 매치 스타일 게임에서 일반적입니다.
계정에 영구적 인 상태가 필요하지 않은 경우 이는 해킹이나 도용에 대한 것이 없기 때문에 가장 쉬운 솔루션이며 "안전한"방법입니다. 게임 세션간에 계정 정보를 저장해야하는 경우에는이 기능이 제대로 작동하지 않습니다.
Quake는이 "사용자 인증"방법을 사용하는 게임의 예입니다.