OAuth2 인증을 사용하여 개인 데이터를 보호하는 방법은 무엇입니까?

Question

사용자 인증을 위해 Google의 OAuth2 인터페이스를 사용하도록 웹 사이트를 설정 중입니다. 웹 사이트는 암호화하려는 각 사용자와 관련된 개인 데이터를 저장합니다.

웹 사이트에 대한 자체 인증 방법을 구현 한 경우 각 사용자의 데이터를 강력하게 보호 할 수 있도록 사용자의 자격 증명 (사용자 암호 포함)에서 키를 쉽게 파생시킬 수있었습니다. 하지만 OAuth2를 사용하면 일정 기간 동안 해당 사용자 권한을 부여하는 액세스 토큰 만받을 수 있다고 생각합니다. 문제는 액세스 토큰 값이 시간이 지남에 따라 변경된다는 것입니다.

OAuth2가 보안 키를 파생시키는 데 사용할 수있는 사용자에게 연결된 불변의 비밀을 제공 할 수있는 방법이 있습니까? 아니면 OAuth2를 사용하여 안전한 영구 비밀을 생성하는 다른 방법이 있습니까?

--- 편집 --- 질문과 의견, 여기에 몇 가지 생각이 고려해야 할에 대한 응답으로

:

모든 사용자 정보가 항상 강력한 암호화와 사용자 인증으로 보호해야한다

• - 우리가 웹 사이트 & 데이터베이스 해킹에 관한 많은 뉴스 기사를 읽는 이유는 개발자가 "정말로 보안해야합니까?"라고 대답하기 때문입니다. "아니오 - 우리가 데이터베이스에 액세스 할 수 없기 때문에 보안은 어렵습니다. , 등 ". 해커가 데이터베이스 등을 다운로드합니다. 바이러스는입니다. 신용 카드, 전자 메일 주소, 전화 번호, 암호를 입력하고 이름을 지정하면 손상 될 수 있습니다.
• 실제 암호는 두 가지입니다. 하나는 누군가의 머리에 저장된 암호이고 다른 하나는 인증 된 사용자 (예 : 물리적 토큰) 만 액세스 할 수있는 강력한 임의 값입니다. 보안 키가 전자 메일 주소에서만 파생 될 수 있다고 생각하거나 데이터베이스에 암호를 저장해야하는 경우 보안을 실제로 이해하지 못합니다.

나는 OAuth 제공 업체가 OAuth 클라이언트에게 사용자와 클라이언트에 안전하게 연결된 불변 값을 제공 할 수 있는지 여부를 알아 내려고 노력했는지를 추측합니다. 이는 키로만 잠금을 해제 할 수 있습니다. OAuth 제공자는 사용자의 비밀 (인증 비밀번호)과 클라이언트의 비밀 (OAuth 프로토콜에서 사용됨)의 조합을 사용합니다. 클라이언트는이 값을 사용하여 사용자 데이터에 대해 적절한 수준의 보안을 제공 할 수 있습니다.

물론이 구현은 악용에 완벽하지는 않지만 올바르게 구현되면 OAuth 스키마의 우수 사례를 사용하면서 데이터를 보호하는 합리적인 방법을 제공 할 수 있습니다.

Answer 1

토큰의 포인트는 토큰을 사용하여 사용자에 대한 Google 정보를 얻을 수 있다는 것입니다. 같은 이메일 주소로

https://developers.google.com/+/api/oauth

사용자가 당신이 그들의 정보에 액세스 할 수 있다고 가정 : 초기 인증하는 동안, 당신은 당신이 사용자에 대한 특정 정보에 액세스하려는 사용자에게, 그리고 구글합니다 , 당신은 google에서 그 때 그들의 이메일 주소를 얻을 수있다. 이메일 주소가 있으면 사용자의 비밀 키를 생성하여 사용자 테이블에 저장하고 데이터를 암호화하는 데 사용할 수 있습니다. 그런 다음 다시 로그인하면 전자 메일 주소를 찾아 해당 키를 찾을 수 있습니다.

불변 정보가 '비밀'인 것이 특별히 필요합니까? 아니면 사용자를 식별하는 데 필요한 열쇠입니까?

저장하려는 정보가 정말로 비공개이며 사용자 데이터에 액세스 할 수 없도록하려는 경우 사용자에게 암호화 된 BLOB를 저장하기 만하면됩니다. 사용자가 데이터를 다운로드 한 후에는 해당 키를 사용하여 클라이언트 측 데이터를 해독 할 수 있습니다.

Answer 2

첫 번째 질문 : 일부 토큰에서 암호화 키를 추출하려는 이유가 무엇입니까?

토큰과 암호화 키는 독립적으로 유지 될 수 있으며 고유 ID로 식별되는 사용자와 연관 될 수 있습니다. 사용자 인증은 자격 증명 또는 개방형 ID 인증 또는 기타 다른 방법을 통해 필요한 모든 방법으로 수행 할 수 있습니다. 그러나 일단 사용자가 인증되면 암호 해독 API는 인증 된 사용자와 관련된 암호 해독 키를 가져 와서 암호 해독을 수행 할 수 있습니다.

이 방법을 사용하면 잠재적으로 사용자가 Stackoverflow에서하는 것과 비슷한 사용자로 여러 개의 열린 ID 계정을 연결할 수 있습니다. 내 Stackoverflow 사용자와 내 야후, 페이 스북 및 Google 계정을 연결할 수 있으며 이러한 공급자 중 하나를 사용하여 로그인 할 수 있습니다. 내가 원하면 언제든지 그 계정을 분리 할 수 ​​있습니다. 하지만 그건 내 Stackoverflow 프로필 및 데이터에 영향을 미치지 않습니다.

따라서 상수가 아니며 계속 변경되는 항목에서 키를 파생시키는 것은 좋지 않습니다. 대신, 그들을 분리 보관하십시오.

Answer 3

OAuth2 엔드 포인트 (이 경우 Google)를 제공하는 인증 서비스에서 얻을 수있는 각 사용자에 대해 지속적인 보안 (임의) 키가 필요합니다.

OAuth2 프로토콜 자체는 이러한 값을 제공하지 않습니다. 인증 서버는 상수가 아닌 생성 된 값을 사용합니다. 그러나 OAuth2는 리소스 서버에서이 값을 제공하는 것을 금지하지 않습니다 (사용자 아이디, 전자 메일 등과 함께). 기본적으로 OAuth2를 사용하면 원하는 방식으로 데이터를 보호 할 수 있지만 현재 사용중인 Google은 이러한 유형의 상수 값을 제공하지 않습니다.

사용자가 다른 임의의 키를 제공하기 때문에 Google 및 Facebook과 같은 몇 가지 계정을 관련시킬 수 있다면이 기능이 작동하지 않습니다.

자격 증명에서 암호를 파생 시키면 암호를 다시 설정하면 사용자 계정이 다시 설정됩니다.

또한 이메일과 같은 데이터를 이러한 방식으로 암호화하면 현재 로그인 한 사용자가 없어도 암호를 해독 할 수 없게됩니다. 따라서 이메일 뉴스 레터는 사실상 불가능합니다. SQL의 데이터도 조회 할 수 없습니다.

• 전혀 중요한 데이터를 보관하지 마십시오, 또는 그것을 해시 저장 :

  난 단지 몇 가지 대책을 제안 할 수있다. 암호는 해시되어야하며 암호화되지 않아야합니다. CC 번호를 저장하지 말고,이를 나타내는 토큰을 저장하십시오.

• 다른 데이터 소스에 저장된 키로 암호화를 사용하십시오. 이로 인해 최소한의 보안이 추가됩니다. 공격자는 DB 복사본뿐만 아니라 암호화 키도 가져와야합니다.
• 데이터가 암호화되어 있으므로 더 이상 데이터베이스에 저장하지 않아도됩니다. 암호화 된 데이터를 파일이나 다른 소스에 저장할 수 있습니다. DB에서보다 안전합니다 (SQL 주입 등의 위험이 없음)

Answer 4

나는이 동일한 문제를 겪어 왔습니다. 지금까지 나는 그 주위에 안전한 방법을 찾을 수 없습니다.

기본적으로 시스템에 액세스하고 데이터를 해독하기 위해 자격 증명을 유도하는 데 사용할 수있는 암시 적 플로우와 함께 제공되는 사이트 당 무작위로 생성 된 비밀이 필요합니다.

데이터를 보호하고 싶기 때문에 데이터를 검색하는 방법과 해독 할 방법 중 한 가지 방법으로 클라이언트에 소금/해시를 쓸 수 있습니다.

아아, 그렇지 않습니다.

나는 OAUTH의 기본 범위에 일에서 자격 증명을 유도 할 수 있고 그 나에 대해 데이터를 보호 할 수 있지만 크로스 사이트 취약점에 대한 사용자 활짝 열려 잎, 게다가, 개인 식별 정보가있게 가난한 비밀.

가장 좋은 점은 암시 적 플로우 oAuth2를 사용하여 사용자의 전자 메일 주소를 획득하고 무작위로 클라이언트 측 암호를 생성 한 다음 사용자가 비밀 키 (복구 키)를 전자 메일로 보내고 secret를 localStorage에 저장하도록하는 것입니다 . 소금/암호 + 해시 범위 변수를 해싱하여 데이터 액세스, 암호화 및 해독에 필요한 자격 증명 클라이언트 측 (사용자가 로그인해야 함)을 파생시킵니다.

사용자가 자신의 localStorage를 지우는 경우 복구 이메일의 링크를 클릭해야 비밀이 다시 localStorage에 저장됩니다.

이것은 취약점의 범위를 클라이언트에 되돌려 놓았지만 공용 컴퓨터 (마지막으로 로그인 한 사람을 알아야하고 localStorage 토큰에 액세스해야 함)에 강하고 복구가 가능하며 사용자가 약하게 요구합니다 플러그 인 인젝션 공격과 물리적 접근 + 사용자에 대한 공격에 여전히 취약합니다.

업데이트 : 일부 oAuth 확장 (hello.js, 폴더 API)을 사용하여 사용자 계정의 키를 파일로 저장하기로 결정했습니다. 구현하려면 일부 권한과 일부 API가 필요하지만 실행 가능한 것으로 보입니다.