Going around Single Sign On

0 投票
最新提问 用户: (120 分)

I have an application where our domain users can register their domain account via an Active Directory interface. They can then unlock their account or reset their password via this application. These two "functionalities", the registration/administration & the unlock/reset, take place on different servers. The whole process of unlocking or resetting uses two-factor authentication via a token app on the mobile phone. The only way to link the token to the app is by scanning a QR code (or typewriting the code) which is shown in the registration process. So far so good.

Now it can happen that we have to reset the mobile phone of a user completely, for example for sending it to repair. Even with a backup, the data in the token app cannot be restored. So far, the only possibility to get the QR code back, is to completely delete the registration in our service and re-register again, thereby generating a new QR code. The process of registration takes a while, as you have to think of several security questions (and answers). This is not very user-friendly.

My task now is to implement a function that allows you to show the QR code. This page can be accessed from the "administration" page each user has for their account. The whole site uses single sign on, which of course makes sense, as you don't want to enter the password every time you want to edit a security question for example.

With single sign on, every person can walk up to another user's computer and if it isn't locked, show and scan their QR code, change the security questions so they know the answers, reset the victim's password and log into their account. This has to be prevented of course, as it poses a huge security risk.
My approach was to prompt the user's credentials and check whether the user is the same as via SSO by clearing IE's authentication cache via JavaScript. I use the Windows Security window for the credential validation. This way, I don't have to worry about the AD interface.

Windows Security windows

To check if it's the same user that logged in, I use a cookie with the username from SSO. Then, in the controller, I check if it's equal to User.Identity.Name. If not, I set the cookie with the username from SSO and the rest of the response:

if (cookie.Value.equals(User.Identity.Name))
    // do some irrelevant stuff
    return View();
    Request.Cookies["cookieName"] = User.Identity.Name;
    Response.AppendHeader("Connection", "close");
    Response.StatusCode = 401;
    Response.StatusDescription = "Unauthorized";
    Response.Write("Unauthorized Access");

This works just fine. There is one problem though: If you click on cancel in the Windows Security window, you'll be redirected to a "unauthorized access" page. You can then, however, refresh the page and TADA! Single Sign On logged you in automatically and you or the attacker can therefor see the QR code.

How can I go around SSO in this specific scenario? So far I have only found solutions saying that I should turn off SSO which would affect the whole application.

I know this is a long question, my English might not be clear in some cases and I possibly left out some information unintentionally. Feel free to ask for more information.

发表于 用户: (100 分)
The QR code page could require not only the standard IsAuthenticated flag but also another indication that the user passed a change account password challenge with a sliding expiration. however, I would have to think of the best way to persist/clear that information.
发表于 用户: (100 分)
Could you check the LastLogon of the principal when determining if access should be granted?
发表于 用户: (120 分)
@RossBush - You mean comparing the given credentials to the LastLogon instead of the SSO?
发表于 用户: (100 分)
Your SSO is going to have validity if it is the user at the desk or some nefarious actor with credentials. I don't see why the two credentials have to match. The QR process is based on the current users credentials, which change after the password challenge, right? So even if someone took control and re/authenticated with their own credentials the QR would only be good for the current user, the bad user, right? I could be missing something.
发表于 用户: (120 分)
@RossBush - I see your point. It makes perfect sense. I will have to discuss this at the next meeting with the application owner, though, as this isn't specified in the change. But there are more factors that would speak for this solution. I'll let you know about the results of the meeting. Thanks alot :)

登录 或者 注册 后回答这个问题。

欢迎来到 Security Q&A ,有什么不懂的可以尽管在这里提问,你将会收到社区其他成员的回答。