Archive for January, 2007

Python 으로 다음 인증 API test.

Python 으로 간단하게 Daum 인증 API 를 테스트 해보려고 다음과 같은 코드를 “일단 작동하게”
원칙에 입각해서; 간단히 만들어 봤다. 보안문제로; 인증키나 기타 키들은 모두 일부러 예제사이트의 것으로 바꿔놨다. 혹시 테스트해 보실분은 자신의 것으로 사용하시라.


#!/usr/bin/python

import sys
import sha
import time
import hmac
import urllib
import random

LOGIN_URL = ‘https://apis.daum.net/account/login.daum’
APID = ‘ba8c53ab7970189d93a7′
APPKEY = ‘4125603e35da5d8820b07dc7b19050dbc838336b’
SIGNKEY = ‘8e4d0a924c60e65ccc38b7f9958f37ff5105f8e1′

def daum_sign_url_hmacsha1(url, signkey):
ts = time.strftime(’%Y%m%d%H%I%S’, time.gmtime())
nonce = ‘’.join([ ‘%02x’ % r for r in [random.randint(0,255) for x in range(8)]])
surl = url + ‘&ts=%s&nonce=%s’ % (ts , nonce)
return surl + ‘&sigalg=hmacsha1&sig=%s’ % hmac.new(signkey,surl, sha).hexdigest()

if __name__ == “__main__”:

if len(sys.argv) < 2:
print “usage: %s returl” % sys.argv[0]
sys.exit(0)

data = {’apid’: APID, ‘apikey’: APPKEY, ‘returl’: sys.argv[1]}

loginurl = LOGIN_URL + ‘?’ + urllib.urlencode(data)

print daum_sign_url_hmacsha1(loginurl, SIGNKEY)

만들어진 signed url 을 브라우저 주소창에 넣고 로그인폼이 나오기를 기대하며 엔터를 누른순간, 다음과 같은 에러를 받았다;;

apierror
무엇이 잘못된 것일까..

1. apikey 별로 sign key 가 발급되는데 내가 번지를 잘못찾아서 다른 apikey 를 받았다. (검색 쇼핑 블로그 여행중에 어느것을 받아야할까. )
2. referer check 를 한다. (그런데 에러코드는 sign 이 틀렸다는데?)
3. returl 이 sign 되기전에 urlencode 되면 안된다?
4. python hmacsha1 keyed hashing 에 문제가 있다;;;
5. sigkey 라는 숨겨진파라미터가 있다;;;
6. 내가 발급받은 signkey 가 아직 다음 시스템에 등록이 안됬다?

음 결과가 궁굼하신분은 아래 다음 API 포럼의 답변을 기대하시라.

http://dna.daum.net/forum/viewtopic.php?t=63
덧붙임:

결론은 -_-;

“내가 바보같이 hmac.new 에 사용될 signkey 를 hex 코드 그대로 사용했다”

입니다. signkey unhexify 하니까 아주 잘됩니다. 그런데 이번에는 인증토큰을 얻는 과정에서
unregistered apikey 에러가 나서 열심히 원인 찾고 있습니다. 포럼에도 업데이트 했구요.
아시는 분은 조언좀 부탁드립니다. ^^

OpenID 그리고 Phishing

이제는 퇴사한 야후직원이자 django 프레임웍의 공동 창시자인 Simon Willison 이 자신의 블로그에 “Solving the OpenID phishing problem” 이라는 포스트를 통해 OpenID 와 Phishing 문제에 대해 이야기를 했다.

아시다시피 Phising Attack 이라는 것은 교모하게 위장된 로그인 페이지를 통해 사용자를 속이고 낚인 사용자는 무의식적으로 패스워드를 입력하여 자신을 위험에 빠뜨리게 되는 누군가 한번은 겪어 봤을 만한 요즘 아주 흔한 abuse 패턴이다. 야후는 얼마전부터 “personalized sign-in seal” 을 통하여 이러한 문제들에 대한 해결책을 사용자에게 제시하고 있다

아주 악랄한 사용자는 OpenID identity provider 의 로그인폼을 그대로 흉내냄으로서 전형적인 man-in-the-middle-attack 을 가할 수가 있다는 점이 지적되었다. Ben Laurie 는 OpenID: Phishing Heaven” 를 통해 이런 문제를 보다 자세히 다루고 있다.

OpenID 를 통해 사용자가 Identity Provider 페이지로 redirect 되는 경우는 1. 이미 로그인은 되었지만 해당 서비스를 한번도 사용한적이 없어서 confirmation 이 필요한 경우 이거나, 2. 이미 로그인도 되었고 confirm 도 되어서 redirect 할 필요가 없는 경우이거나, 3 로그인이 필요하여 identity provider 의 로그인 페이지로 redirect 되는 경우의 세가지 중에 하나일텐데 보통 attacker 들은 3번 경우를 노리게 된다.

Simon Willison 이 제안하는 이러한 경우의 Identity Provider 들의 대처법은 다음과 같은 메시지를 사용자에게 보여주는 것이다.

To log in, please navigate to login.example.com. The page your are currently viewing should contain no links; if there are any links or this text is changed in any way you may become a victim of online identity theft.

즉, Identity Provider 는 sign-in redirect 에 대해서 로그인 폼을 바로 보여줘선 안된다 는 것이며 대신 사용자에게 귀찮지만 직접 지정된 주소로 navigate 하라고 요청하라는 것이다. (얼마나 많은 사람이 여기서 귀찮음을 느끼게 될지는 여러분의 상상에 맡기겠다.;;) 하지만 개인적으로 나는 야후의 personalized sign-in seal 이 훨씬더 효율적인 해법으로 보인다. (팔이 안으로 심하게 굽었다;;)

Jeremy 가 “The Tipping Point for OpenID” 에서 말한대로 이제는 누군가 big-player 가 OpenID 에 뛰어들때가 된 것 같은데. 모르겠다 아직 해결해야 할 난제가 많은것 같아 보이기도 하고…

World Explorer 그리고 태그맵.

일전에도 한번 소개한 “Flickr geotagging 을 이용한 attraction map” 에 이어서 이번에 야후! 버클리랩에서

이것을 본격적으로 flickr geotagged photo 와 yahoo map 을 이용해서 World Explorer 라는 이름으로 내놓았다

백문이 불여일견이다. 한번 해보시라.