Windows Live ID internals

Windows Live ID(WLID)本身是一个identity provider,他负责维护用户的用户名,密码。

作为一个想使用WLID的网站,需要首先注册成为Windows Live application。注册的时候,你先需要有一个WLID! 注册的目标是双方需要有一个PSK——preshared key(WLID叫Secret Key)。这个key是用来验证WLID传回来的token的。注册的同时要求给WLID提供一个Return URL,当用户登录成功,或者logout的时候,WLID会调用这个页面,并且加上一些parameter,其中一个重要的就是stoken,这个参数含有一个WLID传回来的用户相关信息。

我也注册了一个,
return URL=http://sma01:8080/wlid/return.jsp
secret key=thisisaverylongkey
Application ID=00163FFF8000412B

WLID认证成功之后,他就redirect用户到Return URL,相当于SAML的ACS service。另外还要加上token之类的参数。 WLID给用户浏览器返回一个post form,内容如下

<html>
<head>
<noscript>
JavaScript required to sign in
<meta http-equiv=”Refresh” content=”0; URL=https://login.live.com/jsDisabled.srf?lc=1033″/>
</noscript>
<title>Continue</title>
<script type=”text/javascript”>
function OnBack(){}
function DoSubmit(){var subt=false;if(!subt){subt=true;document.fmHF.submit();}}
</script>
</head>
<body onload=”javascript:DoSubmit();”>
<form name=”fmHF” id=”fmHF” action=”http://sma01:8080/webauth/sample/webauth-handler.jsp” method=”post” target=”_top”>
<input type=”hidden” name=”stoken” id=”stoken” value=”DvJ%2BtIPK9bn%2FKlG7PjSB7FNPFEzlX5g9HtHcBGGv2r2h5s1VsnzoRlI7GnSRNK%2Bo3pn87YJCJnTi1jtKgXEh3TLxASGCSt3Okju7MK51VDXz4KGSemv%2BARYN4WJ33FIoHoZ3aVvF19wsNq2YRnM8npmfgVh5ZDVtu%2FXA9FaUqKLRAsOR377dMpDXEWSOrsRQBsmRUy7dZPdZSW4F9%2F%2Fyow%3D%3D”>
<input type=”hidden” name=”action” id=”action” value=”login”>
</form>
</body>
</html>

再看看那个token的具体内容。token首先是base64编码的byte array。前16个字节是IV,剩下来的是加密的内容。加密是用的AES,准确的说,AES/CBC/PKCS5Padding。解密之后的东西居然可以直接得到一个string,看来是iso-8859-1字符集的。顺便说一下,那个decryption key是PSK加上一个前缀”ENCRYPTION”,然后做SHA-256,获得的。没有使用PBE的PBRDF2算法,呵呵,让我平衡的很多。我自己做的也只是用SHA-1 hash两次,不过SHA-256可以一次获得16byte的key,的确很省事。

这个解密了的string的最后是一个sig的参数。显然的,这是signature,跟SAML的redirect很类似。不过SAML使用的PKI签名,WLID使用的是HMAC-SHA256 + AES。这里AES的key跟上面的不一样,是用”SIGNATURE”这个前缀+PSK,然后SHA-256获得的。

签名验证成功后,那么这个token就被trust了。里面含有这样几个参数:

appid: application id,这个id应该等于注册windows live application时候产生的一个id,也应该等于local application的id。
ts: timestamp,秒级别的一个时间戳。
uid: user id,我得到的是一个3661402d031c2a9a6e84505f34d934f0,看来是因为我没有跟windows live id patner.
flags: 一个int的标记位。程序中写的就是如果是奇数,就使用persistent cookie之类的……不是很紧要。

总之,这里WLID最终给我们提供的比较有意义的就是一个uid。这样用户就可以做sso了。WLID似乎也不给我们提供用户的姓名以及其他的信息,所以,我们只能再做一个数据库,来map用户的信息。有点讨厌,不过可能是处于privacy的考虑吧。

A simple security analysis 在我看来,似乎这里面还是有些安全问题的。其实kerberos协议早就讨论过这些问题了,为什么不做在里面呢?比如,token里面有timestamp,但是本地application如果不检查,显然很容易可以做replay attack,而且可以是很久以后的。即使检查了,也没用,token里面不含有nonce,不含有IP address,如果恶意用户可以sniffer到网络的内容,那么截获了用户浏览器发送到应用的token,也是可以立刻replay,就获得了用户的权限。即使,加了nonce,不能replay,hacker也可以shutdown用户的这个请求,给他发RST,然后大摇大摆的用用户的token去访问服务器,就ok了。这点来说,SAML也有类似的问题,所以,解决方案只能是,所有的过程必须是SSL的。查了一下SAML的文档,它是这么说的:Confidentiality MUST be provided whenever a response is communicated between a site and the user’s browser. This provides protection against an eavesdropper obtaining a real user’s SAML response and assertions. [Section 6.4.1, saml sec consideration] 呵呵,有点较真了,显然地,如果是一个mission critical的application,比如网上银行系统,所有的通讯必须SSL,否则即使认证用SSL,后面的不用,那么cookie也很可能被劫持。

发表评论

电子邮件地址不会被公开。 必填项已用*标注