After checking FAQs of Securekey Concierge( company which provides authentication services) I have a doubt that there is a possibility of session replay which can compromise the login security. Here is how it works
Lets say that A is the government site to which I want to log in. Instead of creating a new user name and password for site A, I select Securekey Concierge (Say it site is B). Then from site B I pick my financial instituition where i will be logged in. Lets say it is C. So After log in C I will be redirected to the site A along with a randomly generated token where I will fill the rest of the detail to complete the first time sign in process. So the next time I sign in to site C, the same random token will be sent to site A which will recognise me and won't ask the fill in the same detail I did first time.
So my question is that I am not sure if the random token flows through site B. If it does then there is a possibility that some one on site B can use that token to impersonate me.
I known single sign on e.g. Google sign in where only two sites are involved and each time the sign is completed that first site get the info from Google session which is always different for each sign in.
But in Securekey Concierge, the same token is sent by the site C each time I log in and if this token flows through the site B which is broker site then I doubt that there could be a session replay using that token.
If any body aware of Securekey Concierge, could you please elaborate it.
Thanks
Related
I am doing SAML SSO in my project , the scenario is I am preparing SAML Auth Request URL ,there is a login page where 2 radio buttons are there for Internal/External User ,In both radio case I have to prepare SAML Auth with the IDP Urls provided to me , I was able to prepare and it redirected me to Microsoft login page ,I been given credentials in that domain to login ,the issue is one person sitting in US tries to login with the credentials was successfully able to login ,got the SAML Response and it redirected him to Redirect URL ,when I took the same credentials of him ,tries to login from my machine ,I got error like you are not authorized ,I been confused what does happen ,we are using the same credentials but machine is different ,Is there any settings in Azure Active Directory which checks NETWORK/Machine/IP as well ?
Yes, they do sign-in risk detection based on many factors.
Location is one of them.
The one you probably hit is this one: https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-risk-events#impossible-travel-to-atypical-locations.
It is impossible for this user to have traveled that large of a distance in such a short time,
so it gets flagged as suspicious and blocked.
I've had this happen as well when I signed in to an account through a VM in another continent.
It does learn typical locations over time though, so it might start working later.
The algorithm ignores obvious "false positives" contributing to the impossible travel conditions, such as VPNs and locations regularly used by other users in the organization. The system has an initial learning period of 14 days during which it learns a new user’s sign-in behavior.
You should have your own user id :)
Any help is really appreciated for the following scenario:
How Amazon.com is managing different level of authentication, once at when you visit the site and second when you go to "Your Account"-> "Login & Security" as a security feature?
User logs in (i.e. authenticates) to a website and there is no activity for 7 days. The user revisits the website then user is asked to authenticate again. This can be implemented using cookies but due to security issue, it was implemented using the session token from the server side. After 7 days, when the expired token is provided by the browser, user is challenged to re-authenticate again.
Now, the new requirement is that if the user logs in and visits "Your Account" page then,
if the user still on "Your Account" page and there is no activity for 10 minutes, then user should be challenged to re-authenticate again.
OR.
if the user comes out of the "Your Account" page and revisits the "Your Account" page after 10 minutes, then user should be challenged to re-authenticate again.
So with the token, I can manage only one time period of inactivity, how can I handle multiple states, i.e. state (7 days) and partial state (10 minutes).
What is the industry practice to handle this scenario? Don't want to use cookies as security issue. And as an SSO provider is being used for authentication, use of database will be the last option.
-- David.
How you could handle this is going to boil down to the implementation details of your current expiring session token logic.
A common way to do it is to store your session tokens in a database or in-memory cache. If that's the case, you could simply add a new column that indicates when the user opened the accounts page.
As an example, your new column could be called accountSettingsStartTime. Normally it would have no value, but when the user navigates to the accounts page, it would be populated with the current time. When the user navigates away from the accounts page, you could clear it out. Then, when you check a security token, you just need to check your standard 7 day expiry as well as checking the accountSettingsStartTime column and ensuring it's within the last 10 minutes.
Alternatively, you could give the user a whole new session token with an expiry of 10 minutes when they navigate to account settings, and enforce the usage of that token for operations that involve account settings. You could then check that token when account settings are changed and ask the user to re-authenticate if it has expired (and invalidate their standard 7 day token). Of course, this would require more effort on the client side.
As they say, there's more than one way to skin a cat :)
I'm building a web application for two different types of users, with a different registration form for each of them. I could split up those forms and send a verification e-mail after the form is validated.
But I'd prefer to have one general small form where the user enters his/her e-mail address and user type. The server then sends a verification e-mail with a link to further complete the profile, depending on the chosen user type.
Now my question is: should I include a password field in the small registration form? I have seen it before on many websites, but I can't see why I would include it. My plan is to make the user choose his/her password on profile completion. Nothing about the user will be stored until he/she completes the profile (I would securely hash the e-mail address with a timestamp in a url).
In general, the developers ask all the details including password at the time of registration and they allow to login using the same password. However, there is an open risk of unverified user can access all or some of the feature of the application. Sometimes the application also provides time frame of 24-72 hours to activate the user account, within this period user can access account with some restrictions.
For sensitive applications, you can ask for the password once the user verify the email address. So, that you are assured about the verified user.
If you are providing the feature to access the user accounts without being verified, make sure that the unverified account users can access the account with restrictions according to your application context.
Problem assumptions/conditions:
There exists a user with email foo#bar.com (unverified) in the system.
Visitor is not signed into the system (no current session, e.g. new browser).
Visitor signup/login using Google Account, through OAuth (user authorizes).
The system receives callback with uid and the email foo#bar.com [verified by Google].
I see three options here:
A. Sign in the visitor to the existing account with email foo#bar.com. This have some security implications.
B. Ask for a password [assuming there is a password in the system, this may not be the case with multiple OAuth providers] and sign them into existing account if it's valid.
C. Reject the login/signup, say email is already used, encourage user to login before connecting with Google.
What are the security risks with option #A?
What I've come up with myself:
'Anticipation attacks' could be performed, where an attacker anticipates a signup and creates an account on the system before the target does. After the target has signed up using OAuth he will have an active session on that account. Would be defeated by clearing all sessions on the account before doing #A.
When the user logged in through OAuth in Google, you can be sure that the email address you get back from Google really belongs to that user. So the thing you seem to worry about is that the user already known on your system by that email address does not own that email address. That should have been caught by the time he signed up, with an email conversation. But if it isn't, you might want to reset the password and send an email to the genuine user that you did so, and for what reasons. You may also want to log the user out if he is currently logged in. The user can still access his data, but only through his OAuth login session, or by responding to the email. The email should state that it is a precaution, as there is no way to find out if it really is the same person.
An "accidental attack" can happen too:
In step 1, the user who signed up with address foo#bar.com, in fact intended to type fuu#bar.com, but typed a typo: foo instead of fuu.
Now, the Google user signs up with Oauth and foo#bar.com, and in this way hijacks the account of the step-1 user. Accidentally :-) because of a typo made by the step-1 user.
So, either the step-1 user can anticipate-attack the Google user, or the Google user can accidentally-attack the step-1 user. (I cannot think of any other attacks at least not right now.)
There is website A, with its pool of users. There is a separate website B, which sells digital goods.
I want to allow users of website A to make a purchase from website B, without registering or visiting B.
Given that site A has an agreement with site B to pay the bill on a monthly basis, how can you authorize purchases without opening a vulnerability for malicious attackers?
The first solution which come to my mind, storing a master password to authorize single user purchase, is a security nightmare, but I can't thing anything better. Any ideas?
You can use SAML (http://en.wikipedia.org/wiki/SAML) for this purpose.
Site A will have username/password and other information to authenticate end users. After authentication, site A can send users to site B and site B will call a service exposed by site A to confirm that user is indeed sent from site A.
E.g.
user 'abc' logins on site A
user clicks on something (on site A) to buy something from site B
Site A generates some random and unique token for this action.
User is sent to Site B (usually by POST on a form that points to site B). One of the form fields would be this token
Site B calls some service on Site A to validate the token and to retrieve username for which token was generated. Service might return other things like purchase limit for this transaction.
It is VERY important that the whole communication happens over SSL. This will help mitigating Man-in-the-middle attacks.