웹 사이트에 "기억하기"를 구현하는 가장 좋은 방법은 무엇입니까? [닫은]

510

웹 사이트를 방문 할 때마다 로그인 할 필요가 없도록 사용자가 클릭 할 수있는 확인란을 웹 사이트에 갖기를 원합니다. 이것을 구현하기 위해 컴퓨터에 쿠키를 저장해야한다는 것을 알고 있지만 그 쿠키에는 무엇이 포함되어 있습니까?

또한이 쿠키에 보안 취약점이 존재하지 않도록주의해야 할 일반적인 실수가 있습니까? 여전히 '기억하기'기능을 제공하면서 피할 수 있습니다.

security cookies remember-me

— Vort3x
소스

5

확인 stackoverflow.com/questions/549/... (상단 답의 일부 II)

— 서리가 내린 Z

ASP.NET을 사용하는 경우 codeproject.com/Articles/779844/Remember-Me

— Believe2014에서 30:14의

1

Security SE에는 매우 유용한 정보가 있습니다 ~ security.stackexchange.com/questions/19676/…

— b1nary.atr0phy 10

splattne이 현재 허용하는 답변은 지나치게 복잡합니다. 임의의 소스에서 +16 바이트 토큰을 작성하고 해시 한 후 해시 + 계정 ID를 데이터베이스에 저장하십시오. 그런 다음 HTTPS + httpOnly 쿠키로 사용자 (base64로 인코딩 된)에게 토큰을 보내십시오 (따라서 Javascript가 액세스하거나 도용 할 수 없음). 이 방법으로 아무도 토큰을 추측하거나 잘못된 추측으로 사람들을 로그 아웃 할 수 없지만 데이터베이스가 해킹 된 경우에도 데이터베이스에서 토큰을 사용할 수있는 사람은 없습니다 (해시 됨). 따라서 원래 클라이언트 (또는 브라우저 저장소에서 토큰을 훔친 사람)만이 사용할 수 있습니다.

— Xeoncross

536

향상된 영구 로그인 쿠키 모범 사례

여기에 설명 된이 전략 을 모범 사례 (2006) 또는 여기에 설명 된 업데이트 된 전략 (2015)으로 사용할 수 있습니다.

사용자가 Remember Me를 선택한 상태에서 로그인 하면 표준 세션 관리 쿠키 외에 로그인 쿠키가 발행 됩니다.
로그인 쿠키 는 시리즈 식별자와 토큰을 포함합니다 . 시리즈와 토큰은 적당히 넓은 공간에서 추측 할 수없는 난수 입니다. 둘 다 데이터베이스 테이블에 함께 저장 되며 토큰은 해시됩니다 (sha256은 양호).
로그인하지 않은 사용자가 사이트를 방문하여 로그인 쿠키를 제시 하면 데이터베이스에서 시리즈 식별자가 조회됩니다 .
1. 경우] 시리즈 식별자가 존재하는 상기의 해시 토큰 일치 시리즈 식별자 해시는 사용자 고려되는 인증 . ㅏ새로운 토큰은 토큰에 대한 새로운 해시 이전 기록을 통해 저장, 생성, 새로운 로그인 쿠키는 사용자 (이 다시 사용에 괜찮아에 발행 된 일련의 식별자 ).
2. 시리즈가 있지만 토큰이 일치하지 않으면 도난 으로 간주됩니다. 사용자에게 강력한 경고 메시지가 표시되고 모든 사용자의 기억 된 세션이 삭제됩니다.
3. 사용자 이름과 시리즈가 없으면 로그인 쿠키가 무시됩니다. 됩니다.

이 접근 방식은 심층 방어를 제공합니다. 누군가가 데이터베이스 테이블을 유출하면 공격자는 사용자를 가장 할 수있는 문을 열 수 없습니다.

— 플랫
소스

20

또한보십시오 : stackoverflow.com/questions/549/… 당신은 '개선 된'버전을 읽을 수 없습니다

— Jacco

8

이것의 문제점은 쿠키가 사용자 이름을 쿠키에 노출시키는 것이지만 Gmail이하는 일입니다. 왜 시리즈 ID와 토큰이 필요합니까? 더 큰 토큰이 좋지 않습니까?

— Dan Rosenstark

10

또한이 모델과 관련하여 공격자가 컴퓨터에 쿠키를 훔치고 쿠키를 해킹 한 컴퓨터에서 쿠키를 삭제하는 것보다 훔치는 것을 방지하는 방법. 그의 컴퓨터는 해킹 된 컴퓨터를 알 필요없이 필요에 따라 인증되고 업데이트 될 것입니까? 해킹 된 컴퓨터 사용자는 다시 로그인하여 나를 기억해야한다는 것이 유일한 변경 사항입니다. 해킹 된 사용자가이를 인식하는지 여부는 불확실합니다.

24

@HiroProtagonist 시리즈 식별자는 DoS 공격을 방지하는 것입니다. 그것 없이는 모든 사용자 이름과 유효하지 않은 토큰으로 사이트를 공격하는 스크립트를 신속하게 작성하여 사이트의 모든 사용자를 로그 아웃 할 수 있습니다.

— Chris Moschini 2018 년

6

이 솔루션은 잘못되었으며, cuncurrency를 처리하지 않습니다. 동일한 remember-me 쿠키를 사용하여 두 개의 remember-me 인증 요청이 동시에 도착하면 첫 번째는 성공하고 토큰을 변경하고 두 번째는 성공하지 못한 인증을 유발합니다. 잘못된 경보 (첫 번째 요청으로 토큰이 이미 변경 되었기 때문에). (이 상황은 브라우저가 시작되고 사이트가 두 개의 브라우저 탭으로 복원 될 때 발생할 수 있습니다.)

— slobo

9

사용자 ID와 토큰을 저장합니다. 사용자가 사이트로 돌아 오면이 두 가지 정보를 데이터베이스 항목과 같은 영구적 인 정보와 비교하십시오.

보안에 관해서는 누군가가 쿠키를 수정하여 추가 혜택을 얻을 수있는 물건을 넣지 마십시오. 예를 들어, 사용자 그룹 또는 비밀번호를 저장하지 마십시오. 보안을 우회하도록 수정할 수있는 것은 쿠키에 저장하지 않아야합니다.

— dragonmantank
소스

8

사용자 ID와 RememberMeToken을 저장하십시오. 그들이 Remember me checked로 로그인하면 새로운 RememberMeToken을 생성합니다 (표시된 다른 시스템은 나를 기억하지 않습니다).

그들이 돌아올 때 Remember me 토큰으로 찾아보고 UserId가 일치하는지 확인하십시오.

— jonnii
소스

이것은 몇 초 만에 무차별적일 수 있습니다. user_id를 1로 설정하고 모든 토큰을 무차별 적용합니다. 몇 초만에 액세스 할 수 있습니다

— 친구

4

영구 세션을 직접 조사 해보면 보안 위험에 대한 가치가 없다는 것을 알았습니다. 절대적으로 필요한 경우 사용하지만 그러한 세션은 인증이 약한 것으로 간주하고 공격자에게 가치가있는 모든 것에 대해 새로운 로그인을 강요해야합니다.

물론 영구 세션이 포함 된 쿠키를 쉽게 도난 할 수 있기 때문입니다.

쿠키를 훔치는 4 가지 방법 ( 응답에 대한 페이지의 Jens Roland의 의견@splattne ) :

비보안 회선 (패킷 스니핑 / 세션 하이재킹)을 통해 가로 채기
멀웨어 또는 상자에 대한 물리적 액세스를 통해 사용자의 브라우저에 직접 액세스
서버 데이터베이스에서 읽음으로써 (아마도 SQL 주입이지만 무엇이든 가능)
XSS 핵 (또는 유사한 클라이언트 측 익스플로잇)

— Jarl
소스

104

1. HTTPS는이를 방지하도록 설계되었습니다. 2. 로그인 상태 유지 보안 문제가 아닙니다. 더 큰 문제가 있습니다. 3. 액세스 제어 정책과 올바른 입력 위생으로 인해이를 방지 할 수 있습니다. 이 단계를 수행하지 않으면 로그인 상태 유지보다 큰 문제가 다시 발생합니다.

— Chris Moschini 2016 년