Link to API
There is a param "nonce":
An additional security element must be passed into the post:
nonce - All requests must also include a special nonce POST parameter with incrementing integer. The integer must always be
greater than the previous requests nonce value.
Of course I can implement it via integer param and perform ++ operation each time I use it, but what to do if this value is less than it is required and it causes request error? For example if it was reset for example after application reinstall?
Suddenly I found a solution:
#((int)[[NSDate date] timeIntervalSince1970])
I saw in php they use microtime() function. I hope my function will give the same result
Related
Trying out Stormpath's njwt package for handling JWTs as per this answer by #robertjd.
While trying to see what the various error messages are when verify()ing a token, changed a single character (the last one) of a token expecting the verification to fail, but to my surprise it passed and showed the contents of the token correctly.
More precisely, I changed the last character from an A to a B. This seems to not be the general case, since making other single character changes leads to the expected JwsParseError with message Signature verification failed. I tried this with both the default HS256 and with HS512.
Is that behavior legitimate for JWTs i.e. that the last char is redundant and doesn't affect the verification checksum? Or is it an issue in the njwt library?
Sub-question to njwt's maintainers: in getting back the token after verification, the header's algo property always has a value of none. I see in your source code that you explicitly set it so. Why is that?
Update: regarding the sub-question for the "algo": "none" in njwt's callback of verify(), it seems that "none" signifies that the digital signature is not included, which is the case when we get the token in the callback. Correct me if I'm wrong.
This is due to the base64 (technically, base64url) encoding, which is defined in RFC 4648. The low-order bits of the final (non-padding) character in the encoded data might not be used, so changing from A to B might not have a material effect on the decoded value.
Try changing any character but the last :)
When I try to generate access token using:
https://www.linkedin.com/uas/oauth2/accessToken?grant_type=authorization_code&code=xxxxxxxxxxx&redirect_uri=http%3A%2F%2Fws-100945%3A9080%2FArtisWeb%2Findex.html&client_id=xxxxx&client_secret=xxxxx
it's throwing error as:
{"error_description":"missing required parameters, includes an invalid
parameter value, parameter more than once. : Unable to retrieve access
token : appId or redirect uri does not match authorization code or
authorization code expired","error":"invalid_request"}.
Could you guide me on this issue?
The URL itself looks correct so it must be the code that is expired or reused. Make sure the code is used immediately after you receive it and use it only once.
Also make sure that you URL-encode in fact all parameter values, including client_id and client_secret if/since they may contain URL-unsafe characters like '&' and ' '.
How would you think a hacker is doing the following, and how would you prevent (looking for some helpfull links, keywords or assessment of the sitution)?
Their is a website where users can register and get an invitation Email. The invaitation link (https) contains the token. It looks like 'https://www.example.com/token/123456' (123456 is the token).
It seems that a day after my users clicked on this link, someone else uses the same links too.
How is this possible and how can I prevent this sort of hack?
Thanks
EDIT:
Sorry I should have given more information. I can eliminate the opinion that it is not just a try of random token variations. Why? The exact token is used a day after one of the user had use the link. The token is a hash token of more that 20 characters.
They can just run a script to try any numerical value in the token value.
it's easy. How long is your token? I would also suggest using a hash token rather than a simple numerical one to limit automatic processing, as the "hack" is scripting to try a number, gets a result - store the result, and then number = number + 1;
Edit: What evidence do you have you've been hacked? What happens in your script once someone has clicked the token link?
A simple logic to apply could be:
define a string pattern. like: secretconstant%email
hash the string and now you have the token (and save it)
create your invitation url with the token
If someone call your service with random token you can reject them because your information system don't have saved that token.
Then if you have the token you must discard it so the link will not be valid anymore.
You could check also if the email used in the registration is the same used for calculate the token.. so you may block the registration!
I have two questions:
Q1: Why does OAuth2 require params to be ordered and encoded (for 2-legged)?
All it has to worry about is the matching signature in both the end for the given data(query string).
We can just check the signature generated using the query string.(e.g ?a=1&b=2). Since the signature is generated based on the secret key which is known only to the client and provider, we can only consider the query string without any ordering/encoding.
So, what's the advantage in doing ordering/encoding and then creating the signature?
Q2: How can this signature save me from man-in-the middle attack?
If I have to make a request like this to my server from a client:
increaseUserPoints?userId=1&pointsToAdd=5&appId=x&token=XYZ
Now the token XYZ will be always same, so a hacker could keep posting the same request to increase points. Since the generated token from the given appId is the same, the server will allow this. How is this case handled?
Q1: Ordering the query parameters brings sanity to the HMAC.
Let's say you have two parameters: 'pointsToAdd' and 'appId'. Using the query string pointsToAdd=X&appID=y creates a different HMAC to appID=y&pointsToAdd=X. Because both you and the server need to generate the same HMAC to verify the requests having unordered query parmeters plain fails.
Q2: This saves you from an attack because only you and the server know how to sign your request.
You have a secret key, and only you and the server knows it. This key signs the request. If the HMAC doesn't match according to this secret key, the request fails.
Because all parameters have been used to create the HMAC the request is secure from MITM attacks — a hacker can't change, add or delete any query parameters, or the server will produce a different HMAC when it attempts to authorise and the request fails.
I'm trying to get Twitter authentication working on my ASP.NET site. When you create the app on the Twitter website, you have to specify a callback URL, which for sake of argument, I have set to http://mydomain.com
I've read the oAuth 1.0a spec, and to override this callback URL with your own custom one you have to send the oauth_callback parameter in the request_token phase (url-encoded of course).
So my request URL looks like this:
http://twitter.com/oauth/request_token?oauth_callback=http%3A%2F%2Fmydomain.com%2Ftwittercallback
Supposedly, if all goes to plan, in your response data, you are supposed to receive a new parameter of oauth_callback_confirmed=true in addition to your token and token secret parameters.
However, my response comes through as:
oauth_token=MYTOKEN&oauth_token_secret=MYTOKENSECRET
I know I haven't given you guys the greatest amount to go on, but I'm at my wits end as to why I am not receiving the oauth_callback_confirmed parameter. Without this, my application keeps defaulting back to the callback URL hard-coded on the Twitter website. Please if anyone could help me out, I will be eternally grateful!
Thanks,
A.
I've read the oAuth 1.0a spec, and to
override this callback URL with your
own custom one you have to send the
oauth_callback parameter in the
request_token phase (url-encoded of
course).
So my request URL looks like this:
http://twitter.com/oauth/request_token?oauth_callback=http%3A%2F%2Fmydomain.com%2Ftwittercallback
just because YOU read the spec doesn't mean that TWITTER read it. :P
kidding - this is essentially correct - but the way twitter likes to receive this data is a little different (and not well documented).
the way i've found to get the oauth_callback to confirm is as follows: specify the oauth_callback in the parameters of the request function, NOT within the URL.
python example (using oauth2):
''' Create our client.'''
client = oauth.Client(consumer)
''' do the request '''
resp, content = client.request(request_token_url,"POST",body=urllib.urlencode({'oauth_callback':callbackURL}))
''' note that it's called "body" in this particular OAuth function for Client but in OAuth Request object it's called "parameters." YMMV depending on programming language/ library of course. '''
this is ALSO the only way i've managed to get an oauth verifier back. supposedly one should not have to specify the callback URL every time, since we provide it in app settings...but experience seems to indicate otherwise.
finally, please be aware that at leg 3 you have to do the same thing AGAIN - this time including the oauth_verifier as well as the callback URL in the parameters.
hope this helps - can't begin to tell you how much effort i put into figuring this out.
good luck!
J
I've used this guide to set up my PC to be used as the callback location. Basically you set up your hosts file in a certain way, clear your cache and add a couple of Firefox registry values. At the end when you are debugging an oauth call the redirect comes back to your local PC.
As I said it worked for me.
<?php
// oauth-php example
$token = OAuthRequester::requestRequestToken(
$consumer_key,
$user_id,
array('oauth_callback'=> urlencode($callback_uri))
);
?>