쿠키 보안 - 로그인 유지 관련

페이스북은 로그인 유지하기 라는 기능을 가지고있다.

이를 구현하기 위해서는, 쿠키가 필수적이다. 헌데 

쿠키는 참으로 보안에 취약하기때문에.. 보안강화를 위한 방법을 찾아보았고 

아래 아티클의 아이디어를 기반으로 많은 모듈이 존재한다는걸 알았다. 

링크 : http://jaspan.com/improved_persistent_login_cookie_best_practice

좀 정리를 해보겠다. 저자는 먼저 Charles Miller's 님께서 디자인한 로그인유지 방법에 대해 아래처럼 

나열해 놓았다.

Charles Miller's 가 제시한 로그인유지(쿠키를이용한) 절차

 

1. When the user successfully logs in with Remember Me checked, a login cookie is issued in addition to the standard session management cookie.[2]
2. The login cookie contains the user's username and a random number (the "token" from here on) from a suitably large space. The username and token are stored as a pair in a database table.
3. When a non-logged-in user visits the site and presents a login cookie, the username and token are looked up in the database.
   1. If the pair is present, the user is considered authenticated. The used token is removed from the database. A new token is generated, stored in database with the username, and issued to the user via a new login cookie.
   2. If the pair is not present, the login cookie is ignored.
4. Users that are only authenticated via this mechanism are not permitted to access certain protected information or functions such as changing a password, viewing personally identifying information, or spending money. To perform those operations, the user must first successfully submit a normal username/password login form.
5. Since this approach allows the user to have multiple remembered logins from different browsers or computers, a mechanism is provided for the user to erase all remembered logins in a single operation.

1. 유저가 '로그인유지'버튼 체크후 정상 로그인시, 표준 세션관리 쿠키에 '로그인 쿠키'가 생성됩니다. 

2. 로그인 쿠키는 적절히 큰 범위내에 1)유저이름, 2)랜덤숫자('토큰')을 포함합니다.

   유저이름 과 토큰은 DB의 동일한 열에 저장됩니다.

3. 미로그인 유저(로그인 쿠키를 가진)가 사이트에 방문시, 해당 유저이름과 토큰을 DB에 존재하는지 조회합니다.

1. 만약 동일한내용이 존재한다면, 유저는 로그인유저로 간주됩니다. 사용된 토큰은 DB에서 제거됩니다. 새로운 토큰을 생성하고 데이터베이스에 유저네임과 함께 DB에 저장합니다.

그리고 새로운 로그인 쿠키를 유저에게 발급합니다. 

3. 만약 동일한 내용이 존재하지 않는다면, 로그인 쿠키는 무시됩니다.

4. 오직 이 메카니즘만을 통해 인증된 유저는, 확실히 보호된 정보 또는 기능(패스워드 변경, 개인정보 보기, 결재관련 등)에는 접근이 허용되지 않습니다. 해당 기능이 작동하기 위해서는 

유저는 필수로 먼저 완벽하게 기본 로그인 폼에서 유저명과 패스워드 인증을 통과해야 합니다. 

5. 이접근 방법은 유저가 다른 브라우저 또는 컴퓨터에서 다중 '로그인유지'를 가능하게 합니다.

    이 메카니즘은 유저가 모든 '로그인 유지(혹은쿠키)'를 제거할수 있도록 제공되어집니다.

 

* 번역 태클은 언제든 환영함다. 제 영어 실력이 개 후룩이거등요 ㅜ_ㅜ 

어쨌든 위 내용을 더 간략히 정리해보면..  

1) 로그인(로그인유지 버튼 체크) 성공 시 유저이름,토큰(랜덤생성된)을 DB저장 후 쿠키 발급! 

2) 미로그인(로그인쿠키가진) 유저가 사이트 접속시, 쿠키의 유저이름,토큰을 이용하여 

    DB조회하고, 있다면 토큰(기존토큰 재거후 재생성)및 쿠키 DB에 새로 저장,쿠키 재발급.

    없다면 무시! 

3) 그리고 요 쿠키를 이용한 로그인 사용자는 중요한 정보,기능사용 불가.. 모 이런 내용임.    

에,, 위의 내용이  Miller 라는 외쿡형님이 제공한 방법이라고 하는데요.

barry jaspan 이라는 아저씨가 여기에 보안강화를 위해 로직을 조금 변경할것을 제안합니다.     

먼저 문제점을 제기 했구요, 해결책!을 같이 제시합니다. 

문제점 

 

The Problem

Miller correctly describes the many advantages of this approach. One disadvantage, however, is that if an attacker successfully steals a victim's login cookie and uses it before the victim next accesses the site, the cookie will work and the site will issue a new valid login cookie to the attacker (this disadvantage is far from unique to Miller's design). The attacker will be able to continue accessing the site as the victim until the remembered login session expires. When the victim next accesses the site his remembered login will not work (because each token can only be used one time) but he's much more likely to think that "something broke" and just log in again than to realize that his credentials were stolen. Displaying a "last login time" may help the user notice the problem but, frequently, it will go undetected.

One possible solution to this problem is to treat the presentation of an invalid login cookie as evidence of a previously successful attack. The site could then present an impossible to miss security warning and automatically invalidate all of the user's remembered login sessions. This approach would create a denial of service attack: since usernames are easy to come by or guess, an attacker could submit invalid login cookies for every user and thus disable the entire system. 

번역 -_-++)

밀러는 본인의 접근법에 대한 많은 강점을 정확하게 설명했다. 

그러나 한가지 단점이 있는데.. 만약에 어떤 '공격자(해커)' 가 완벽하게 '피해자'의 로그인 쿠키를 가져갔다면.. 그리고 이것을 사용한다면('피해자'가 다음에 사이트에 접속하기전에), 

쿠키는 정상작동 할것이고..(헉)..새로운 로그인 쿠키를 '해커'자식에게 전달할것입니돠...(ㅜ_ㅜ)

[요 단점은 밀러의 유니크한 아키텍쳐의 단점과는 거리가 멀어용..]

해커는.. 계속해서 사이트에 접속할수있게 될껍니다...언제까지?? 로그인 세션이 파기되기전까지...

해커가 접속한 후에, '피해자'님이..사이트에 접속하면 '로그인 유지기능'은 불가능하게 될것입니다. 

왜냐면 각각의 토큰은 1회용이라서 해커님이 계속 새로 생성하고있는 상태이거등요... 

그래도 '피해자'는 '음 뭔가 문제가 있낭?'.. 그리고 계속해서 접속 시도를 하겠죠. 그리곤 

곧 쿠키인증이 도난당한걸 알게될겁니다... 마지막 로그인 시간을 보여주는것은 아마 유저에게 

문제를 알려주는 방법이 될수는 있겠습니다.. 하지만 이것은 곧 차단될것입니다...  

아주 무서운 내용이군요 -_- 이런 줸장 !!! 그럼 이번엔 

해결책을 함 보겠숩니돠 

The Solution

My solution to this problem is based on the observation that since each token can only be used once, a remembered login session actually consists of a series of such tokens. When an attacker successfully steals and uses T_0 he is issued T_1, but the victim is still holding T_0. The database no longer has a copy of T_0 and thus cannot differentiate it from an arbitrary invalid token.

However, if the series of tokens is itself given an identity that must be presented along with the current token, the system can notice that the victim is presenting a valid series identifier along with an invalid token. Assuming that the series identifiers are as hard to guess as tokens, the only way a user could present a valid series identifier with an invalid token is if some other user previously presented the same valid series identifier with a valid token. This requires that two different users held the same series and token pair at the same time and therefore indicates that a theft has occurred.

이문제의 해결책은 각각의 토큰이 오직 한번씩만 쓰이는것, '로그인유지' 세션은 토큰들의 시리즈를 포함하고 있는것을 관찰한것에 베이스를 두고 있습니다.

예를들어 '해커'가 쿠키(토큰:T_0)를 입수하고 이것을 사용하면, 쿠키(토큰:T_1)이 새로 생성됩니다. 

그러나 '피해자는' 여전히 쿠키(토큰:T_0)를 가지고 있지요. 데이터 베이스는 토큰:T_0의 값을

오래 가지고 있지 않을겁니다..즉..  이 것은 독단적으로(멋대로) 잘못발행된 토큰과 구별할수가 없습니다. 

그러나.. 만약 각 토큰들이 스스로 식별자(현재토큰과 같이 존재해야함)를 부여한다면?

시스템은 유저에게 '당신은 유효한 식별자와 잘못된 토큰을 가지고있습니다' 라는것을 알려줄수 있습니다. 각 시리즈 식별자가 토큰처럼 추측하기 어려운 값이라고 가정한다면, 

유저가 유효한 시리즈 식별자와, 잘못된 토큰을 가지고있을 유일한 방법은 아마도 다른 유저가 

이미 동일한 시리즈 식별자와 정상적인 토큰을 보유하고 있었다는것입다.

이것은 분명 다른 두명의 사용자가 같은 시간에 동일한 식별자 와 토큰을 가지고있었다는 것이기 때문에, 쿠키를 누군가가 가져갔다는 것입니다. 

헥헥..  힘드네요 이거 쓰는데 벌써 40분이 넘어가는듯.. 

어쨌든.. 위에 솔루션을 보면 밀러가 제안한 디자인에 '식별자' 라는 개념을 추가 했네요.

식별자는 유니크한값이고 해커가 추측하기 어려운 값으로 쓰라고 한거구.. 토큰이 재 발행되더라도 

이놈은 한유저에 대해서는 고유하게 존재하라고 합니다.. 그래야 식별할수있으니가용.. 

아마 해당로직 추가시 흐름을 보면 일케 되겠죠.

 

  1) '피해자쿠키발급' 

      - username=joy, uniquekey=saj9sjiejjksjhhakdljj, token=p8934jhlkjf8asdlfjkas 

  2) '해커쿠키 스니핑(입수)'

  3) '해커쿠키 사용'    

      - username=joy, uniquekey=saj9sjiejjksjhhakdljj, token=p23534dlfjkas

  4) '피해자쿠키사용'(도난감지)

      - username=joy, uniquekey=saj9sjiejjksjhhakdljj, token=p8934jhlkjf8asdlfjkas

 

-> (도난감지) DB조회시 uniquekey 는 같은데 잘못된 토큰 조회가 일어남. 

     즉 쿠키 도난이 생겼음이 파악됨.

 

위의 구조를 추가하여 쿠키 보안을 강화 했네요. 아래는 jaspan 님이 최종 제안한 변경된 디자인 모델입니다.

The implementation is no more difficult and requires no more resources than Miller's design. From the summary above, only items 2 and 3 change:

1. When the user successfully logs in with Remember Me checked, a login cookie is issued in addition to the standard session management cookie.[2]
2. The login cookie contains the user's username, a series identifier, and a token. The series and token are unguessable random numbers from a suitably large space. All three are stored together in a database table.
3. When a non-logged-in user visits the site and presents a login cookie, the username, series, and token are looked up in the database.
   1. If the triplet is present, the user is considered authenticated. The used token is removed from the database. A new token is generated, stored in database with the username and the same series identifier, and a new login cookie containing all three is issued to the user.
   2. If the username and series are present but the token does not match, a theft is assumed. The user receives a strongly worded warning and all of the user's remembered sessions are deleted.
   3. If the username and series are not present, the login cookie is ignored.

아거 요거 해석은 조금 있다 다시해야겠네요. 헥헥 지쳐쓰 ㅜ_ㅜ 

그럼 궁금한점. 잘못된점 있으심 바로 댓글 부탁 드림돠 감솨감솨 

[출처] 쿠키 보안 에 대하여|작성자 굿맨

출처 => http://blog.naver.com/PostView.nhn?blogId=junhwen&logNo=130145534571