When a user want to register his device, the relying party provide some parameters which are :
a challenge,
appID,
Version of protocol
The user performs then a "user presence test" by touching the button on his device sending those informations :
dictionary RegisterResponse {
DOMString registrationData;
DOMString clientData;
};
Relying party do what he has to do with those informations and the process is finished !
But I do not understand the following part. Based on the specifications of U2F protocol :
Registration Request Message - U2F_REGISTER
This message is used to initiate a U2F token registration. The FIDO Client first contacts the relying party to obtain a challenge, and then constructs the registration request message. The registration request message has two parts:
The challenge parameter is the SHA-256 hash of the Client Data, a stringified JSON data structure that the FIDO Client prepares. Among other things, the Client Data contains the challenge from the relying party (hence the name of the parameter).
The application parameter [32 bytes]. The application parameter is the SHA-256 hash of the application identity of the application requesting the registration. (See [FIDOAppIDAndFacets] in bibliography for details.)
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-raw-message-formats.html
At which step this part is run ?
Thank you in advance !
You are talking about registration so linking a key to an account. To register a key:
The user types in name/password and posts to the server.
The server replies with RegisterRequestData (created with the server side u2f library).
The client side uses library function u2f.register which gives the request to the U2F device and gets back a RegisterResponse (json with the device registration info). This is send back to the server.
The server gives the reply to the serverside u2f library and saves the DeviceRegistration.
Authentication/login is similar but with the server sending DeviceRegistration + challenge to the client which uses u2f.sign and returns the DeviceResponse.
A schema that makes it clear I think:
https://developers.yubico.com/U2F/Libraries/Using_a_library.html
Related
We are switching our notifications infrastructure to use new GCM 3.0 registration mechanism using Instance ID API. Previously we were using old mechanism using GCMRegistrar.register() method.
The problem we have is that we have noticed that if device was registered with old GCMRegistrar, after update and registering with new Instance ID API, both registration tokens are valid and can receive notifications.
I expected old registration token to be deactivated and that our push server would receive canonical registration ID when sending notification to old token (as described here GCM registering with two different working registration ids), especially that application version has changed, but such case seems not to happen.
Is this correct behavior of GCM? Is there any way we can detect on push server that device received new token (without unregistering from app)?
I have finally received an answer from Google support regarding my issue. It turned out that this was intended behavior:
What you observed is in the intended behavior due to the need to support backward compatible
registration ID.
We recommend you to flag the old registration ID from gcmregistrar() and don't use that to send anymore once you have the registration token from getToken(). (I believe you probably has implemented a solution to detect such)
Our solution was to simply remove old registration tokens from our push server before registering new user.
We did not use GCMRegistrar.unregister() as we observed that it was able to unregister new tokens (obtained via getToken()).
UPDATE:
I just wanted to provide a quick update to anyone interested in this subject.
It seems that this issue was fixed as when we tested our registration mechanism recently, it turned out that new GCM tokens replace (and unregister) old tokens.
Registration token may change upon certain scenarios even going forward. While cononical registration ID is also a good idea. Use tokenRefresh as shown here as well.
#Override
public void onTokenRefresh() {
// Fetch updated Instance ID token and notify our app's server of any changes (if applicable).
Intent intent = new Intent(this, RegistrationIntentService.class);
startService(intent);
}
Suggesting based on this line "it is needed for key rotation and to handle special cases" in method reference.
When asking this question I am looking for guidance with implementation of my own AuthenticationProvider. By that i mean the following:
Till now i have learned that Spring Security ask the AuthenticationProvider object if the user is authenticated or not. Currently i am using the
DaoAuthenticationProvider wich process the username and the password that is beeing returned by my own custome UserDetailService. All works great!
Spring support a lot of different AuthenticationProvider's for example there is one for LDAP, Jdbc, DAO (as mentioned above) and i was even able to find one for Kerberos. However there is no authentication provider for SRP, thus the need to write one.
My question is here the following:
When we use the DaoAuthenticationProvider i.e. user/password authentication, we have a html form where the username and password are entered and then a button is responsible for submiting those 2 parameters. Bought barameteres are transfered over some transport channel to the server i.e. with one click we are able to send all of the data within the same http reqest i.e. all that is needed for the authentication. That can be seen in the UsernamePasswordAuthenticationFilter. Here the method "attemptAuthentication" takes "HttpServletRequest request" which includes username and password. Till now all good.
public Authentication attemptAuthentication(HttpServletRequest request, HttpServletResponse response) throws AuthenticationException {
...
}
Well, in the simple in SRP we have also a form that has a username and password, except the password !!!MUST!!! not be transfered over the network. In order to achieve that constrain a "discussion" between the client and the server has to take place i.e. the following parameters must be exchanged.
1) username (I),
2) a value called "A"
3) a value called "B"
4) a value called "M1"
5) a value called "M2"
Well, let us assume that there is a filter called "SrpAuthenticationProcessingFilter" how should the filter look like if the new authentication protocol was more like a conversation by that i mean from the RFC 5054.
Client Server
Client Hello (I) -------->
Server Hello
Certificate*
Server Key Exchange (N, g, s, B)
<-------- Server Hello Done
Client Key Exchange (A) -------->
[Change cipher spec]
Finished -------->
[Change cipher spec]
<-------- Finished
Application Data <-------> Application Data
Here we have a client that needs to
a) send first his username (I)
b) then the server needs to respond with a value B. (N,g,s are not really necessary in this case)
c) the client sends it's "value A"
d) the the client uses that value B from the server and based on that value calculates a key.
e) the server calculates the key as well based on the value A.
f) the client sends value M1 to the server.
g) the server gets the M1 value and based on a formula which has the M1 value as argument, he is able to verify if the keys
match, if the calculated keys of the bought sides match then the
user is authenticated, and the product i.e. the shared key could
be used further for other processing.
In a contrast to username and password authentication those are 7 steps not one. And 3 of those needs to happen before the SrpAuthenticationProcessingFilter. Now i am aware that there is a possibility to send the username together with the "value A" thus shortening the number of steps, but i would like to strictly follow the RFC. Never take the easy way right?
The question really is where do i place that code which is responcible for the ping pong (conversation) between the client and the server i.e. the first 3 steps a,b and c mentioned above. Should it place them in a SrpEntryPoint object, or somewhere else. if else then were in the context of SpringSecurity?
One way i can thing of solving this is using websockets, but i would also like to make that authentication independent from any layer 5-7 protocol such as websockets, http, spdy etc. . That means that the first implementation should be be trough simple http request/responce and then with any other protocol.
So the structure that could be the right one in order to implement SRP currently is:
SRPAuthenticationEntryPoint implements org.springframework.security.web.AuthenticationEntryPoint - this basically says what should be done if a request for a protected resource gets in, but the user is not authenticated yet. Here we can place a redirect in the case the resource has not been authenticated. Maybe this is also the place which is responsible for the steps a,b,c not sure if that is the right place. Request guidance and information!!
SrpAuthenticationProcessingFilter extends GenericFilterBean. SrpAuthenticationProcessingFilter exists to make partial validation for example to check if the srp paramters received a correct and corrspoding to the srp parameters that the server sets. Here it is important to mention that SrpAuthenticationProcessingFilter is not doing any username validation i.e. that needs to happen in one step before the SrpAuthenticationProcessingFilter is beeing called, maybe that is the SrpEntryPoint or some other step that i do not know how to call it yet. SrpAuthenticationProcessingFilter has a method "doFilter" in which the second structure is beeing created i.e. SrpAuthenticationToken.
SrpAuthenticationToken extend org.springframework.security.authentication.AbstractAuthenticationToken. That token in my understanding is something similar ot the DAO object, the token maps all field needed for sucessefull authentication. When partially validated parameters are populated into the SrpAuthenticationToken that SrpAuthenticationToken is passed to the authenticat method of the org.springframework.security.authentication.AuthenticationManager interface i.e. something like that
myAuthentication = authenticationManager.authenticate(SrpAuthenticationToken);
depending on which Authentication Provider is configured in the Spring Security config then the SrpAuthentication provider is called in our case i.e.:
#Autowired
public void registerAuthentication(AuthenticationManagerBuilder auth) throws Exception {
auth
.authenticationProvider(sRPAuthenticationProvider);
}
SRPAuthenticationProvider - implements org.springframework.security.authentication.AuthenticationProvider. Over here the steps d,e,f and g are being validated and compared. If something wrong happens then throw new BadCredentialsException("Invalid username/password/Verifiere") exception.
SrpSessionValidator - this one is responsible only for validating particular parameters of the Srp session and would be called from SrpAuthenticationProcessingFilter as well as in one step before the SrpAuthenticationProcessingFilter in order to validate if the username exists in the database at all.
I only have a general idea how to implement that Srp authentication, and thus i would like some comments if that makes sense at all and if SRPAuthenticationEntryPoint is the right place for the steps a,b and c. It does not feel like the right place to me.
Any feedback is greatly appreciated.
regards,
Tito
Addition1 (21 November 2014) -> As an aswer to the question "where to place that code which is responsible for the ping pong (conversation) between the client and the server i.e. the first 3 steps a,b and c " the answer to that would be most likely a standard (i will call it negotiation) filter which will take that job.
Now I would like to rephrase the question i.e. before the authentication is complete and before the M1 and M2 messages are received i.e. steps 1 2 and 3. Where do i place that object? I.e. it should be a place where the object should live for example for 60 seconds and then be automatically deleted in case no M1 and M2 messages has been received. I mean some object before the "SecurityContextHolder" object. I just do not know what is the name of that object/context related to spring security, also i do not know if such construct exists at all?
My approach would be to use AJAX to run the first parts of the protocol up to the creation of A and M1 at the client then post those to the server as the login credentials and check those using Spring Security.
To see how this works there is a junit-js test which runs mutual authentication between a javascript client object and a java server object using Thinbus over at TestSRP6JavascriptClientSessionSHA256.js (note the maven build runs this unit test using the JDK javascript runtime):
// note the following exchange is written in javascript calling client js and invoking server java which is run by JUnit-JS using the JDK javascript runtime so it shows both sides of the full authentication in one unit test method
// normal login flow step1a client: browser starts with username and password given by user at the browser
client.step1(username,password);
// normal login flow step1b server: server starts with username from browser plus salt and verifier saved to database on user registration.
var B = server.step1(username, salt, v);
// normal login flow step2a client: server sends users salt from user registration and the server ephemeral number
var credentials = client.step2(salt, B);
// normal login flow step2b server: client sends its client ephemeral number and proof of a shared session key derived from both ephermal numbers and the password
var M2 = server.step2(credentials.A, credentials.M1);
// normal login flow step3 client: client verifies that the server shows proof of the shared session key which demonstrates that it knows actual verifier
client.step3(M2);
Clearly the javascript client starts with only username and password. The server uses the username to resolve the salt and generates a random B. The client is given salt and B from the server and generates its random A and the M1 which is the password proof. The server step2 which takes M1 as a parameter is the server checking the user password proof and it will throw an exception if the proof is bad. The server then sends M2 which is the server proof that it has the user verifier v which is done to prevent a fake server spoofing the real server.
There is a demo of a browser doing SRP to a Java server over AJAX using Thinbus over at thinbus-srp-js-demo. You could re-use the JAX RS with AJAX approach (e.g. Spring MVC AJAX) to perform the first steps up to the creation of A+M1 at the client then post those to Spring Security using the login form post and have Spring Security verify A+M1 by running step2 on the server object as shown in the junit-js test. Then your AuthenticationManager could resolve the server object created by AJAX from a concurrent map keyed by username.
One minor note is that I would consider checking the server proof M2 as optional if you are using HTTPS to a server. If you are not using HTTPS then server spoofing means they can give the user a page which sends the password and ignores a bad M2; so the M2 proof doesn't provide security in the context of webpages. A mobile app which packages the html/js into a native app using something like phone gap would benefit from an M2 check; it can be added into the page after the user is logged in to be checked by the trusted code.
There is a spring security SRP implimentation at https://bitbucket.org/simon_massey/thinbus-srp-spring-demo
The readme page says:
A salient feature of the integration is that there are no changes to
the standard spring security authentication path other than to
configure the custom SrpAuthenticationProvider.
It also says:
Spring Security does not expose the user HTTPSession to the
AuthenticationProvider. So demo code uses a Guava cache with a timeout
to hold the SRP6JavascriptServerSession for the brief period of the
login exchange. As of Thinbus 1.2.1 the session is serialisable so an
alternative approach for a large stateless website would be to hold
the SRP6JavascriptServerSession object in the DB rather than in an
in-memory cache.
I am facing to a trouble with 2 adapters based authentication. My app is agenda (hybrid app). All adapter's functions must be protected by security.
my app uses adapters based authentication, like written in samples on DeveloperWorks.
My first adapter (loginAdapter) is dedicated for login (beginning of the mobile app). I developed a handler (handlerLogin, mobile side) with methods isCustomResponse, handlechallenge, etc.. This adapter works.
This adapter allows to get a userId from login and password.
As soon as connected, the user can download his agenda. The mobile calls an other adapter based auth (calendarAdapter). I have an other handler (handlerCalendar) with methods (isCustomResponse, handlechallenge).
When the mobile calls the method getCalendarData (protected method, CalendarAdapter), the server detects that the user is not registered for this adapter, that is why the server send an error (structure authrequired + errorMessage) via the function onAuthRequired.
At this step, all works fine.
Actually, the trouble comes from, that, the first handler (handlerLogin) catches this error, whereas it schould be the second handler (handlerCalendar).
Given that it is catched by the handlerLogin, isCustomResponse and handlechallenge are called, and I do not have the expected result ! I do not know why.
Why it is not catched by the handlerCalendar ?
I verified my code, variable's names, files, etc.. All things are ok.
For informations, I first declared the handlerLogin before the CalendarLogin.
Do you have any ideas, suggestions ??
Thank you in advance
It looks like you used the same realm.
The isCustomResponse function job is to find out if this challenge-handler should take care of this specific request. If you use the same realm for both adapters then the 2 challenge-handlers will react to it.
CONTEXT:
I have an Ember.js 1.1.0-beta.1 application that exchanges JSON data with a Rails-API server (Rails 4). JSON data exchange is accomplished with Ember-Data 1.0.0-beta.2 and Active Model Serializers 0.8.1 (AMS). I'm using the default recommended configurations for both Ember-Data and AMS, and am compliant with the JSON-API spec.
On any given RESTful call, the client passes the current authentication token to the server. The authentication token is verified and retired, and a new authentication token is generated and sent back to the client. Thus, every RESTful call accepts an authentication token in the request, and provides a new authentication token in the response that the client can cache and use for the next RESTful call.
QUESTION:
Where do I put the authentication token in each request and response?
Should it be part of each object's JSON in request and response? If so, where is the token placed in the existing object's JSON structure (which has nothing to do with authentication)?
Or should they be placed in the HTTP header for each request and response object?
What is "The Ember Way" that one might eventually expect to find in the new Ember Guides Cookbook?
MORE CONTEXT:
I'm already familiar with the following links:
#machty 2 Embercasts: http://www.embercasts.com/episodes/client-side-authentication-part-2
#wycats tweet: https://twitter.com/wycats/status/376495062709854209
#cavneb 3 blog posts: http://coderberry.me/blog/2013/07/08/authentication-with-emberjs-part-1
#simplabs blog post: http://log.simplabs.com/post/53016599611/authentication-in-ember-js
...and am looking for answers that go beyond these, and are specific to Ember-Data + AMS.
With the exception of the need to pass a new token back to the client in the response via Ember-Data, assume my client code is otherwise similar to the #machty Embercast example on GitHub: https://github.com/embercasts/authentication-part-2/blob/master/public/js/app.js
Thank you very much!
I've got a similar stack - ember, ember-data and rails-api with AMS. Right now, I'm just passing the authentication token (which I store in localStorage) in a header (though you could pass it on the query string) by modifying the RESTAdapter's ajax method.
My initial thought would be to avoid resetting the token on every request. If you're particularly concerned about the token being sniffed, it might be easier to just reset the token on the server at a regular interval (say, 10 minutes). Then, if any request from the client fails due to an old token, just fetch the new token (by passing a'reset token' that your server gives you at login) and replay the initial request.
As for where to put the token, there isn't really an "Ember Way" - I prefer passing it in a header since passing it in the query string can mess with caching and is also more likely to be logged somewhere along the way. I'd definitely avoid passing it in the request body - that would go against what ember-data expects, I'd imagine.
I have built something similar, although I do not reset the token unless the user signs out.
I would not put it in the request body itself - you are just going to pollute your models. There probably is no Ember way since this is more of a transport issue. I pass the token using a custom HTTP header and/or a cookie. The cookie is needed to authorize file downloads, which can not be done through ajax, although the cookie works for ajax calls too. In your case I would use a cookie and have the server set it to the new value each time. However, your scheme of resetting the token on each JSON request is not going to work on simultaneous requests. Is this really necessary? If you use TLS you probably don't need to worry so much. You could also timeout the token so that if there are no requests for 10 minutes a new token is generated.
I'm trying to use the ldap_sasl_bind_s method from the Microsoft LDAP C SDK, with GSSAPI as the authentication mechanism. ldap_sasl_bind_s expects the credentials as a BERVAL structure, which is opaque.
Given a username (or a DN) and a password, how do I get to the BERVAL structure that I'm supposed to pass to ldap_sasl_bind_s?
The examples I've found so far
are from other LDAP C SDKs - not the one from Microsoft
use ldap_sasl_bind_s when SIMPLE authentication is desired - but I need to use GSSAPI
use ldap_sasl_interactive_bind_s when other SASL authentication mechanisms are desired. However, there is no ldap_sasl_interactive_bind_s in the Microsoft SDK.
As a side note, the goal is to be able to bind over SASL to a variety of LDAP servers; for now: ActiveDirectory and OpenLDAP.
Any pointers will be greatly appreciated.
I managed to perform an LDAP SASL bind over GSSAPI, using ldap_sasl_bind_s. For those interested, here are some pointers.
For an abstract description of the actions a client and server need to perform during a GSSAPI SASL authentication, "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism" RFC should be read; specifically, the 'Client Side of Authentication Protocol Exchange' section is of interest, because it gives an indication of the sequence of actions we need to perform to successfully bind to an LDAP server over Kerberos.
The credentials ldap_sasl_bind_s expects - their form and their meaning - depend on the actual authentication mechanism being used, which in our case is Kerberos.
In the Microsoft SDK, Kerberos is available through SSPI - which is roughly the Microsoft implementation of GSSAPI; the methods that are relevant for our particular case are: AcquireCredentialsHandle, InitializeSecurityContext, DecryptMessage, EncryptMessage
An LDAP SASL bind over Kerberos has 3 phases.
Phase 1
Call AcquireCredentialsHandle and InitializeSecurityContext.
Important notes here:
pass to AcquireCredentialsHandle a pointer to a SEC_WINNT_AUTH_IDENTITY structure containing the actual credentials (realm, username, password), or NULL if the credentials of the current thread are to be used
the target name should be an SPN mapped to the account under which the LDAP server is running
when calling InitializeSecurityContext, mutual authentication must be requested.
If all important arguments are correct - valid credentials, valid SPN, NULL input token - the InitializeSecurityContext call should return SEC_I_CONTINUE_NEEDED and properly fill the output token. The contents of this output token should go in the BERVAL structure ldap_sasl_bind_s expects as client credentials.
Call ldap_sasl_bind_s with the output token from InitializeSecurityContext as client credentials. If all arguments are correct - empty DN, GSSAPI as the mechanism name - the actual call should return LDAP_SUCCESS and the most recent LDAP error for the LDAP session should be LDAP_SASL_BIND_IN_PROGRESS.
As a side note, the most recent LDAP error for an LDAP session can be discovered by calling ldap_get_option on the session, with LDAP_OPT_ERROR_NUMBER as the option.
Phase 2
After the successful call to ldap_sasl_bind_s, its last argument points to a BERVAL structure containing the server credentials. The content of this BERVAL structure should now be used as the input token for the second call to InitializeSecurityContext.
This second call to InitializeSecurityContext should return SEC_OK and an empty output token.
This empty output token should be used as the client credentials for another call to ldap_sasl_bind_s. This second call to ldap_sasl_bind_s should return LDAP_SUCCESS, with the most recent LDAP error for the LDAP session being LDAP_SASL_BIND_IN_PROGRESS.
Phase 3
After the second successful call to ldap_sasl_bind_s, its last argument points to a BERVAL structure containing server data. This server data should be given as input to DecryptMessage. As specified in the previously mentioned RFC, the decrypted data must be 4 bytes long.
The client should build its reply according to the information in the same RFC.
Note: In my case, I omitted the authorization id mentioned in the RFC. To my understanding, an empty authorization id leads to the authentication id being used for authorization as well.
The reply the client built should then be passed as input to EncryptMessage. The output of the EncryptMessage call should then be passed as the client credentials for the third and final call to ldap_sasl_bind_s.
Note: The MSDN documentation for using EncryptMessage under Kerberos seems to be incomplete. Google's Code Search should assist with a working example. Also, for a working example of the flow described above, Samba's source code can be consulted.
I found the problem.
According to this thread ( https://groups.google.com/group/microsoft.public.active.directory.interfaces/browse_thread/thread/9c13fe85e520f0b4/820a136e032946e9?pli=1) there is a bug with ldap_sasl_bind_s returning empty server credentials in Windows XP. I have tested my application under Windows 2008 Server and the credentials are properly returned.
Article from Sun and MSDN. Probably if you can try creating a sample program you may get the answers
Another One
PseudoCode
struct berval cred;
char mechanism[BUFSIZ];
getline( mechanism, sizeof(mechanism), stdin, "mechanism? " );
getline( passwd, sizeof(passwd), stdin,"credentials? " );
cred.bv_val = passwd;
cred.bv_len = strlen( passwd );
rc = ldap_sasl_bind_s( ld, dn, mechanism, &cred, NULL, NULL, NULL );