Friendzoned and the end

I hesitated to face the fact, but finally I did that, bravely. At least I experienced that (but maybe not the last time) in my life.

I should have learned that it is extremely hard to maintain a cross-country relationship for the lack of physical presence.

Take care.

Changing Microsoft Account alias is painful

Access deined for my new alias

A short update: The recent MSDN subscription migration kills my migrated account alias too. After contacting Microsoft support, I removed legacy alias from my account, create a new Microsoft Account using my legacy alias and restored my access to the new Visual Studio Subscription portal. In the same way, I removed legacy Microsoft Account in my Azure AD, linked two separated Microsoft Accounts(legacy and new alias) and resolved my issue accessing Visual Studio Team Services.

Such inconsistency always happens, and usually remove & add will be the universal solution in most cases.

After using legacy alias for almost 7 years, I decided to replace my Microsoft Account alias with a new Outlook.com email address due to increasing security concern of Netease Mail (my previous email service provider). Though I changed alternative recovery email to my domain email after several major security incidents, it looks weird to have an @163.com email alias linked to my Microsoft account.

Okay, I changed my alias the day before yesterday. It works. I didn’t delete the old one because I want to maintain some sort of backward compatibility. It works across my personal devices without any pain.

Annoying things came afterward days later.

Let’s talk about SSO/Federated Logon

Before talking about terrible things after switching to the new alias, let’s talk about Federated Logon. Technically speaking, Federated login is an authentication workflow based on trust relationships. Suppose Identity Provider A and Application B have successfully established two-way trust relationship by service provision. When a new user login attempt occurs, B redirects authentication challenges to Identity Provider A, with necessary metadata, like secure token ID, timestamp, nonce and finally something that validates the request, for example, digital signature, even token encryption. Since Application B has its own approach to understand Identity Provider A’s payload(so does B), the communication will be secured.

When Identity Provider A completes user authentication challenges(password, client certificate, fingerprint, etc.), it signs (encrypts maybe) authenticated user claims (user ID, user name and something else) and posts to B. The workflow image of WS-Federation below represents such workflow. OAuth and OpenID Connect have similar workflow with slight differences(multiple modes to retrieve user claims).

WS-Fed workflow from docs.oasis-open.org
WS-Fed workflow from docs.oasis-open.org

Microsoft Azure, Visual Studio Team Services and most Microsoft services use OpenID Connect. Believe it or not, you use Federated Logon and SSO every day.

Microsoft Account and Azure AD Account

They are two separated systems though they have something in common. Each Microsoft Account has a CID, a unique identifier in Microsoft Account system. All Microsoft Consumer services use CID to recognize your identity. For example, your Outlook.com email account is identified using your CID.

Azure AD Account handles it differently. Each Azure Active Directory have a tenant ID to identify AAD in AAD system. Each AAD contains objects: users, groups, computers, trust relationships….and more. Each AAD user has a unique alias in a specific AAD tenant. So the coexistence of 2ea6c0b4-cc49-42b8-9f1b-3f4aa653c719\imbushuo and b5093785-af31-4819-bf75-728d4474769c\imbushuo is possible.

Microsoft Accounts can be linked into Azure AD too: during the linking procedure, a new external user from Microsoft Account will be created in an AAD tenant, so you may have 2ea6c0b4-cc49-42b8-9f1b-3f4aa653c719\bill@live.com. When Bill wants to access resources in his tenant’s AAD, he will type bill@live.com in AAD Federation Service(Work and school account), a single sign on portal for Azure AD. Later, AAD FS will redirects the authentication challenges to Microsoft Account login portal. If Bill is authenticated in Microsoft Account login portal, he will be redirected back to AAD FS, with claims provided by Microsoft Account. Finally, AAD FS will tell the application that the user is Bill.

My blog uses such login mechanism too. See my management portal to get some idea about this if you don’t understand.

But…there’s no CID in Azure AD

But there’s something just works like CID: user alias. Another mapping! Microsoft Account will be mapped to Azure AD account, then the application will use the Azure AD account identity. After changing my alias in Microsoft Account, my Azure AD user alias remains the same. So I can login into my blog management portal with the same identity:

Logged in with the same ID
Logged in with the same ID

Do you remember that federation logon can carry multiple attributes at one time? So here’s the problem. My team’s source control service, Visual Studio Team Services, seems to use email address (which changes after rotating my primary Microsoft Account alias) to identity user. After logging in with my organization account, I found that my email address didn’t change after the rotation. To make the whole thing worse, I am the account creator, hence I cannot remove my Microsoft Account in VSTS to address the issue.

In short, the primary alias rotation didn’t change my user alias in Azure AD, but applications’ behavior vary based on how they deal with user claims.

 

Seems that I have to change my alias back. Yuck.

所以我想说什么

几年前初中的班长写过随笔讲了语言的力量。那个时候他提醒了我们不恰当的说话方式可能会造成非常严重的后果。前两天我发过一篇文章, 又让我回想起这随笔。很早以前还看到过D君的一篇文章,也讲了一些因为争吵而造成的不快的事情,总之是没有这次的这么严重。

一直以来我反对一件事情:一件事情一个人说了算。在这件事情中,一言堂的后果还是蛮严重的,而且单独站在一个人的角度上看问题,别人的意见一句不听,这个我不知道说什么好。

再是今天听说另外自己犯错然后不承认让人家闭嘴的事情,唉,真是不知道说什么好。

Most recent: A to Z

http://apple.com.cn
https://azure.mirosoft.com
https://bing.com
https://facebook.com
http://harlemify.com
https://imbushuo.net/wp-admin
http://livesino.net
https://manage.windowsazure.com
http://nyanit.com
https://onedrive.live.com
https://twitter.com
https://v2ex.com
http://weibo.cn
https://www.youtube.com
http://zhihu.com

DON’T verify CAPTCHA by JavaScript

昨天中考成绩出来了。早在模拟填报志愿的时候,我们很多同学就已经发现了验证码很难完全显示。那时然后我淡定地打开Chrome的Dev Tools,查看DOM发现了一些神奇的东西。(回家是IE11)

Screenshot (171)

So, you MEAN this is CAPTCHA? WTF….

Therefore, I can EASILY parse the document, submit form, and get all the informaton I want.

Screenshot (178)

然后继续看流量。发现整个过程是明文的, including password.

Screenshot (172)

What’s more, the verification process is completed in the client side…(later I found that I could bypass the CAPTCHA by sending the HTTP request directly.)

Screenshot (174)

By using JSESSIONID, I can acquire the result(a webpage).

Then parse it, and get the final result.

Later that night(~10:20 6.21.14), I started writing the program(using C#).

Then I have a result sheet.

CONCLUSIONS

在客户端校验验证码是非常非常非常危险的(这句话很重要所以说三遍),而且Script不做混淆,业务逻辑直接暴露在客户端更加危险。

第二,Unit Testing不认真做,不是所有代码路径都得到了测试,后果很难预料。(我猜这是Behavior-Driven Development instead of Test-Driven Development

第三,都2014年了你还是XP样式还不支持IE11你好意思吗。。。。

Screenshot (180)