Is anonymous credentials in Hyperledger Indy similar to zero knowledge proof (ZKP)?
https://github.com/hyperledger/indy-anoncreds
Nathan Aw
Yes! /indy-anoncreds are a type of ZKP based upon the Idemix protocol.
In Anonymous credentials, by Dmitry Khovratovich, it is explained:
We say that credentials are unlinkable if it is impossible to correlate the presented credential across multiple presentations. Technically it is implemented by the Prover proving with a zero-knowledge proof that he has a credential rather than showing the credential.
See /awesome-indy#IDEMix-ZKP- for more information
The credentials generated in Hyperledger Indy are verifiable credentials. It is powered by Identity Mixers. Another interesting feature in revocable credentials which is a important addition to the older implementation of identity mixers.
Related
I am trying to wrap my head around the authentication architecture of serverless web applications using a solution such as Firebase and Google Identity Platform (GIP). In server-based architectures, we typically set an HTTP only cookie with the authentication details, which prevents XSS attacks or malicious chrome extensions from reading this information.
In my experiments with GIP, I noticed the SDK stores the response from GIP in IndexedDB, and it's straightforward to extract the access token, refresh token, and other useful user details. If I understand correctly, actors with access to these tokens can impersonate the user.
Doesn't this make this approach more vulnerable than its server-based counterpart if code injection is a viable attack vector?
EDIT
I found this article in the official documentation that discusses the benefits of HTTP only session cookies over ID Tokens and shows how to create them.
As suggested, by john hanley in the comment above please move this question to Stack Exchange Information Security
If the client browser is subject to code injection, then nothing is secure in the browser.
Yes, tokens can permit user impersonation. Since those tokens are OAuth they have short lifetimes (3,600 seconds).
OIDC Identity Tokens have an audience that restricts their usage to a single service.
Do you have a proof of concept extracting those tokens and using them elsewhere?
There are many writeups about the strengths and weaknesses of cookies and IndexedDB. Understanding the security weaknesses requires clearly identifying the environment. I recommend that you move this question to Stack Exchange Information Security: security.stackexchange.com
Also as frank suggested, have a look at Firebase App Check and its server-side security rules.
How can I validate a username/password against Azure AD without showing a UI? I have an autonomous processes running (think Windows Service or scheduled task) where the username and password are stored in a configuration table.
Since there is no "user at the wheel" so to speak, we can't use the normal method that shows the Azure login page (https://login.microsoftonline.com/{tenantId}).
1. Just make it work, no changes approach (Not Recommended)
You can try to get a token using Resource Owner Password Credentials Grant. (ROPC might be the least secure among all the different grants supported and brings potential attack risks. Also note that ROPC doesn't work with MFA and has issues with federated authentication users or may not work in those cases at all)
I don't think there is any method/endpoint available to specifically validate the username/password, but the workaround is if either username or password is incorrect, you will get an exception from the token endpoint when using ROPC, otherwise you get back a valid token which means credentials are good.
You can read about how to get a token using ROPC here:
Resource Owner Password Credentials Grant in Azure AD OAuth
2. Suggested Approach, some changes required (Recommended)
This might feel a little inconvenient at beginning, but it will be well worth the effort from a security standpoint. Note that this approach as well as the first one will meet your requirement of not going through normal login page as well.
Since there is no "user at the wheel" so to speak, we can't use the
normal method that shows the Azure login page
(https://login.microsoftonline.com/{tenantId}).
As you mention that the autonomous process is like a Windows Service or Scheduled task, from Azure AD and OAuth 2.0 perspective your process looks like a Daemon service. So instead of using a username/password credentials directly from configuration, which violates security best practices, you should be looking at using Client Credentials Grant. It's strongly advised NOT to collect/manage/store end user credentials (or create old world Service Accounts) directly in your applications.
You can read about it in detail here: OAuth 2.0 Client Credentials Grant with Azure AD.
Also visit this documentation for all Azure AD app types and scenarios, specifically those listed for Daemon apps. Link
To put it very briefly, your process gets represented by a registered application in Azure AD and for credentials part you can use:
a. Client ID + Client Secret Key (provided by Azure AD specifically for your application. you can generate more than one secret keys for different purposes with different expiration etc.). Sample C# code with Client Secret
b. Client ID + Certificate (pass a JWT that you need to create and sign with the certificate you registered as credentials for your application). Sample C# code with Certificate
I'm using VS2013 and Web API 2 to create a self-hosted (using OWIN), RESTful service over SSL using token authentication. Although I'm not a novice developer, this is my first time looking at ASP.NET technologies, so please keep that in mind.
I've got everything more-or-less working except for the authentication and authorisation parts. I fully understand the difference of authenticating a user (who is this user?) and authorising an already authenticated user to access a resource (can this user access this particular resource?).
A very simple overview of my auth process is as follows (makes some assumptions for brevity):
An unknown client connects to the API, e.g. GET api/values.
The server responds with a 401 and this response header: "WWW-Authenticate: Token".
Upon seeing this, the unknown client knows to connect to a different API endpoint here: POST api/auth (routed to the Login function), supplying the username and password.
The server will try to figure out if this is a valid user and can accept or reject the user depending on the validity of the credentials.
(Rejected) The server returns an error status code (403?). End of process.
(Accepted) The server creates a random token (e.g. a GUID) and stores it against the user record. Then it sends the token to the client.
The now authenticated client reconnects to the API, GET api/values, and this time also supplies the token.
The user returns the resource data to the client.
...
The user can log out by connecting to the same API as he used to log in: POST api/auth (this time, his request will be routed to the Logout function). This will remove the token from the server and the client will also have to remove its own token.
As you can see, this is a relatively simple process, but I can't find any concrete and simple examples to understand how best to achieve this with a self-hosted Web API 2.
I don't need to register users or do any password/roles management, etc. and there is no external authentication. All valid users have the same rights to access the resources and they're already created in the system by a separate process over which I have no control (I can only read their credentials for validation). Most examples I found are talking about security frameworks that I don't need, so I've ruled out using any of the following: Basic Authentication, Windows Authentication, Forms Authentication, Individual Accounts, ASP.NET Membership/Identity, OAuth, Thinktecture or any other security framework.
I've read articles about authenticating in a message handler and others about authentication in a custom Authorize attribute filter, while others even suggest I should use the new (in Web API 2) IAuthenticateFilter attribute. This is very confusing. Can you please advise on a very simple way to achieve my auth objectives? Any specific code examples will be greatly appreciated, even if they're just skeleton implementation or pseudocode. I just need some ideas to get me started.
After a lot of googling, I found this article on CodeProject: http://www.codeproject.com/Articles/630986/Cross-Platform-Authentication-With-ASP-NET-Web-API. While this is not Web API 2 or self-hosted, it has given me a number of ideas on how to proceed.
Someone also posted a comment to that CodeProject article referencing a NuGet package that may interest anyone looking for something similar: https://www.nuget.org/packages/WebApiTokenAuth. In my case, it is a bit much.
Finally, in addition to the authentication options mentioned in the question, there's also the option to write an OWIN middleware to do authentication if self-hosting using OWIN (as per the official MS recommendation). However, I plan to implement this particular form of token authentication with a message handler, as there's more support for this method available than for writing OWIN middleware.
I am being tasked with writing an asp.net web app that will use ADFS for authentication. However, at one stage in the application users will have to re-authenticate and supply their username and password again.
Can this be done with ADFS?
The ASP.NET app can be an active client to the STS as well as a passive one. When you need to step up, provide some input fields and ask the user for additional proof of who they are. Using the WSTrustChannelFactory, pass this info (and possibly the original token) to the STS to get a new token that is fresher and contains claims that are sufficient to authorize the the higher value transaction.
What is the goal of the re-authentication, i.e., what does the user need to prove?
I'm presuming the application wants a sign-in token with a recent authentication timestamp (within, say, the last 10 seconds), so that the application is reasonably sure that the client system is really still under that same user's control.
(Watch out for clock differences between your web server and your AD FS server, by the way.)
In the coming months I will be investigating a similar scenario, and my current idea is to use the SessionAuthenticationModule.SessionSecurityTokenReceived Event, as described in this blog post by Vittorio Bertocci. However, that cannot be the entire solution, since this only forces AD FS to give out a token, but it does not force AD FS to give out a token with a recent authentication timestamp.
So no answer yet, but perhaps these hints help.
This article describes a "step-up" procedure that might help you in this scenario. I haven't used it though, so I can't comment in detail. It looks very close to what you are trying to do.
Reducing TokenLifetime property makes you to re-authenticate users. suppose by TokenLifetime is by default is 60 min but it shows popup before 20 mins. but there may be data loss
For ASP.NET using WIF, you are using WS-Federation as the protocol to interact with ADFS and get a token. Within this, you can specify wrefresh=0 in the sign-in request to ADFS. When this is sent, ADFS ignores any prior cookie state (web SSO) and does a fresh authentication and so a new token will be issued to the app. In the case of intranet domain joined machine case, this will be silent.
To have user interaction, you can do one of 2 things
For 2012R2, I recommend that you use MFA and the app can request MFA by requesting for MFA in this 'step-up' scenario. See http://blogs.msdn.com/b/ramical/archive/2014/02/18/under-the-hood-tour-on-multi-factor-authentication-in-ad-fs-part-2-mfa-aware-relying-parties.aspx
Outside of this, you can also force username/password auth and combine it with wrefresh=0. This ensures that prior SSO state is ignored and U/P auth is performed.
Thanks
//Sam (#MrADFS)
Hi I am going to do a web service. Now our customers are going to be able to call the method from their interface. I been thinking what I should do for authentication, I been reading and can not really decide. I want to pass username and password to the method.
Do you got any advice?
Common authentication schemes are well-defined and, while not perfect, are known entities. The worst thing you can do is "roll your own" in security.
I assume by your comment "pass username and password to the method", you mean you would like to have access to the credentials used to access your web service. This is fine, but don't pass credentials as parameters to your method.
Based on your description, basic authentication over SSL should provide you sufficient protection for your application. This would work in a non-trusted environment (i.e. across unknown networks) and should be easy enough to implement on the client-side.