I have been looking at techniques to secure an API for use in an android/iphone app or website application.
I have found one technique which I like but am unsure about if it is a good or what is wrong with it (aside from being a pritty long process).
Processing (users side initially):
First a salt is created by hashing the users password.
Then a signature is created by hashing the requested url (with username appended on the end via a query string) and the salt.
Lastly a token is created by hashing the username and the signature.
The token is passed inside a header to the server (everytime).
First Request:
The first request must be for the validate endpoint and include the device_id as a query string.
The same processing (as above) is done on the server and if the token matches that sent from the user than the device_id is stored in the database and is assigned to that username for future reference (the device id is found in the requested url) and is used to verify the username/device thereafter.
All subsequent requests:
The processing must take place on the users end and servers end for every request now with the token being different everytime (as the requested url changes).
No code is included as it is not written yet.
Your authentication model is a shared secret authentication. In your case your user's password serves as the shared secret. You need to ensure you have a secure way for getting the password to the user and server ahead of time. In order to sign the request you create a message with all your request headers and data. Then hash that request. Then that hash (token) will be passed with the request. The server will perform the same signing and hashing process on the server and ensure the tokens match.
In your example your sound like you want to create the token with this pseudo code:
Token = hmac-sha1( Hash(Pasword + Salt) + RequestUrl + UserName )
Your way is not bad but I would compare your method to Amazon's REST Auth model and implement a closer version of what they have detailed. http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html
Their implementation:
"Authorization: AWS " + AWSAccessKeyId + ":" + base64(hmac-sha1(VERB + "\n"
+ CONTENT-MD5 + "\n"
+ CONTENT-TYPE + "\n"
+ DATE + "\n"
+ CanonicalizedAmzHeaders + "\n"
+ CanonicalizedResource))
They have good reasons for including some fields that you have left out, including but not limited to:
The timestamp is to prevent replay attacks.
The content-MD5 is to prevent prevents people tampering with the request data (relevant to
POST and PUTS)
Related
I am currently working on integrating Google OAuth and need to verify if the user created a new session or re-using their existing session. Unfortunately the "amr" inside the id_token seems to be hard-coded as always rba. Due to this reason, i am investigating if session_state can be validated or verified for a new session establishment.
Specification
https://openid.net/specs/openid-connect-session-1_0-16.html#rfc.section.4.1
I was able to confirm that session_state is newly generated for re-established sessions. However, since the session_state is not inside the id_token, there is no means to verify its authenticity.
As per the spec, the session_state is calculated using
var ss = CryptoJS.SHA256(client_id + ' ' + e.origin + ' ' +
opbs + [' ' + salt]) [+ "." + salt];
In that case, can someone point me how to get the opbs or are there better mechanisms to verify the new session establishment in Google OAuth?
Recently, I was able to get MD5 authentication working for XMPP streams in Swift IOS following the instructions on the following two websites (I used the CC-MD5 function of Apple's CommonCrypto C library for the actual hashing):
http://wiki.xmpp.org/web/SASLandDIGEST-MD5
http://www.deusty.com/2007/09/example-please.html
I'm searching for a similar explanation for how to get other hashed SASL authentication schemes working, especially SCRAM-SHA1. I have found the official RFC5802 document but I'm having a lot of trouble understanding it (it is not specific to XMPP either). I would appreciate a simpler explanation or some simple readable code (C, PHP, C++, Javascript, Java) specific to XMPP authentication that doesn't use libraries for anything other than the actual hashing.
I'm interested in understanding the process and am not looking to use the ios XMPP-Framework. Any help would be appreciated.
SCRAM-SHA-1
The basic overview of how this mechanism works is:
The client sends the username it wants to authenticate as.
The server sends back the salt for that user and the number of iterations (either by generating them or looking them up in its database for the given username).
The client hashes the password with the given salt for the given number of iterations.
The client sends the result back.
The server does a variation of the hashing and sends it result back to the client, so the client can also verify that the server had the password/a hash of the password.
The cryptographic algorithms you'll need are SHA-1, HMAC with SHA-1 and PBKDF2 with SHA-1. You should look up how to use them in your language/framework, as I don't recommend implementing them from scratch.
In detail
First normalize the password (using SASLprep), this will be normalizedPassword. This is to ensure the UTF8 encoding can't contain variations of the same password.
Pick a random string (for example 32 hex encoded bytes). This will be clientNonce.
The initialMessage is "n=" .. username .. ",r=" .. clientNonce (I'm using .. for string concatenation).
The client prepends the GS2 header ("n,,") to the initialMessage and base64-encodes the result. It sends this as its first message:
<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="SCRAM-SHA-1">
biwsbj1yb21lbyxyPTZkNDQyYjVkOWU1MWE3NDBmMzY5ZTNkY2VjZjMxNzhl
</auth>
The server responds with a challenge. The data of the challenge is base64 encoded:
<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
cj02ZDQ0MmI1ZDllNTFhNzQwZjM2OWUzZGNlY2YzMTc4ZWMxMmIzOTg1YmJkNGE4ZTZmODE0YjQyMmFiNzY2NTczLHM9UVNYQ1IrUTZzZWs4YmY5MixpPTQwOTY=
</challenge>
The client base64 decodes it:
r=6d442b5d9e51a740f369e3dcecf3178ec12b3985bbd4a8e6f814b422ab766573,s=QSXCR+Q6sek8bf92,i=4096
The client parses this:
r= This is the serverNonce. The client MUST ensure that it starts with the clientNonce it sent in its initial message.
s= This is the salt, base64 encoded (yes, this is base64-encoded twice!)
i= This is the number of iterations, i.
The client computes:
clientFinalMessageBare = "c=biws,r=" .. serverNonce
saltedPassword = PBKDF2-SHA-1(normalizedPassword, salt, i)
clientKey = HMAC-SHA-1(saltedPassword, "Client Key")
storedKey = SHA-1(clientKey)
authMessage = initialMessage .. "," .. serverFirstMessage .. "," .. clientFinalMessageBare
clientSignature = HMAC-SHA-1(storedKey, authMessage)
clientProof = clientKey XOR clientSignature
serverKey = HMAC-SHA-1(saltedPassword, "Server Key")
serverSignature = HMAC-SHA-1(serverKey, authMessage)
clientFinalMessage = clientFinalMessageBare .. ",p=" .. base64(clientProof)
The client base64 encodes the clientFinalMessage and sends it as a response:
<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
Yz1iaXdzLHI9NmQ0NDJiNWQ5ZTUxYTc0MGYzNjllM2RjZWNmMzE3OGVjMTJiMzk4NWJiZDRhOGU2ZjgxNGI0MjJhYjc2NjU3MyxwPXlxbTcyWWxmc2hFTmpQUjFYeGFucG5IUVA4bz0=
</response>
If everything went well, you'll get a <success> response from the server:
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289
</success>
Base64 decoded this contains:
v=pNNDFVEQxuXxCoSEiW8GEZ+1RSo=
The client MUST make sure the value of v is the base64 encoding of the serverSignature.
Extras
This is the basic version of the algorithm. You can extend it to do:
Channel binding. This mixes in some information from the TLS connection to the procedure to prevent MitM attacks.
Hashed storage. If the server always sends the same salt and i values, then the client can store only saltedPassword instead of the user's password. This is more secure (as the client doesn't need to store the password, just a hard to reverse salted hash) and faster, as the client doesn't need to do all the key stretching every time.
The server can also use hashed storage: the server can store only salt, i, storedKey and serverKey. More info on that here.
Possibly, also adding SCRAM-SHA-256 (though server support seems non-existent).
Pitfalls
Some common pitfalls:
Don't assume anything about the length of the nonces or salt (though if you generate them, make sure they are long enough and cryptographically random).
The salt is base64 encoded and can contain any data (embedded NULs).
Not using SASLprep may work fine for people using ASCII passwords, but it may completely break logging in for people using other scripts.
The initialMessage part of the authMessage does not include the GS2 header (in most situations, this is "n,,").
Test vectors
If you want to test your implementation, here are all the intermediate results for the example from the RFC:
Username: user
Password: pencil
Client generates the random nonce fyko+d2lbbFgONRv9qkxdawL
Initial message: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
Server generates the random nonce 3rfcNHYJY1ZVvWVs7j
Server replies: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096
The salt (hex): 4125c247e43ab1e93c6dff76
Client final message bare: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
Salted password (hex): 1d96ee3a529b5a5f9e47c01f229a2cb8a6e15f7d
Client key (hex): e234c47bf6c36696dd6d852b99aaa2ba26555728
Stored key (hex): e9d94660c39d65c38fbad91c358f14da0eef2bd6
Auth message: n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
Client signature (hex): 5d7138c486b0bfabdf49e3e2da8bd6e5c79db613
Client proof (hex): bf45fcbf7073d93d022466c94321745fe1c8e13b
Server key (hex): 0fe09258b3ac852ba502cc62ba903eaacdbf7d31
Server signature (hex): ae617da6a57c4bbb2e0286568dae1d251905b0a4
Client final message: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
Server final message: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
Server's server signature (hex): ae617da6a57c4bbb2e0286568dae1d251905b0a4
I am using revel to build my webapplication and trying to write authentication module.
I finished with sign up part and now heading to write sign in part.
I read about security part on The definitive guide to form-based website authentication and will use this recommendation.
What I am really do not know is, how sign in works. I am imaging that the process works like this:
User write username and password into the html form and press sign in
Server receive request and the controller will check, if user information match with data on database.
If yes, how continue.
The third point is where I am staying. But I have some idea how could works and not sure, if is the right way.
So when sign in information match with the database, I would set in session object(hash datatype) key value pair signed_in: true. Everytime when the user make a request to the webapplication, that need to be authenticated, I would look in the session object, if signed_in is true or not.
This is the way I would do, but as I mentioned above, I do not know if it is the right way.
Yes like #twotwotwo mentioned, give it the user id and also a role.
So server side rendered flow: Step 1
user sends username (or other identifier) and secret.
using scrypt or bcrypt the secret is checked against the stored salted hash in the database
if it matches you create a struct or a map
serialize struct or map into string (json, msgpack, gob)
encrypt the string with AES https://github.com/gomango/utility/blob/master/crypto.go (for instance). Set a global AES key.
create a unique cookie (or session) identifier (key)
store identifier and raw struct or map in database
send encrypted cookie out (id = encrypted_struct_or_map aka the encrypted string)
On a protected resource (or page): Step 2
read identifier from cookie
check if id exists in db
decode cookie value using AES key
compare values from cookie with stored values
if user.role == "allowed_to_access_this_resource" render page
otherwise http.ResponseWriter.WriteHeader(403) or redirect to login page
Now if you wanted you could also have an application-wide rsa key and before encrypting the cookie value sign the string with the rsa private key (in Step 1). In Step 2 decode with AES key, check if signature valid, then compare content to db stored content.
On any changes you have to update the cookie values (struct/map) and the info in the database.
I have a standard API set up in which clients are verified by hashing the request body with the private key attributed to the provided public key, and comparing it to the value of hash in the query string.
E.g., request body is "THIS IS REQUEST BODY", they would set hash as sha256('THIS IS REQUEST BODY'.PRIVATE_KEY), and then the server would do the same thing to validate it.
How can I secure this authentication process if the request body is empty? The hash would be the hashed value of the private key, and could then be re-used for similar "empty" requests by anyone listening to the traffic.
I'm assuming that the only answer will be "require content in the request body", but maybe I'm missing something obvious.
First off, don't do HASH(DATA + KEY). There are known vulnerabilities with it. This is precisely what HMAC is designed for. So your hash would be:
hash = HMAC(sha256, data, privateKey)
Now, the typical way of handling your question (how to prevent replay attacks) is by adding a randomizing factor to each request. There are a few ways to do this, but one that works well is a nonce based approach. So:
nonce = random(16)
now = time()
data = api_data + '|' + nonce + '|' + now
hash = HMAC(sha256, data, privateKey)
apiCall = data '&nonce=' + nonce + '&time=' + now + '&sig=' + hash
Then, on the receiving side, you keep track of the list of nonce's seen in the past 30 seconds. If you get one that you've seen, then reject the api call (as that would be a replay attack). If you get one that's more than 30 seconds old, reject the api call.
if (now < time() - 30) {
return false;
} else if (nonceExists(nonce)) {
return false;
}
addNonce(nonce);
data = api_data + '|' + nonce + '|' + now
myhash = HMAC(sha256, data, privateKey)
if (myhash == hash) {
return api_data;
}
return false;
And then you can purge the databases on nonce's every 30 seconds (on a cron job) or every week, doesn't really matter. Depends on how active your API is.
The key here though is that you want to keep track of the nonce's while they are valid, otherwise you'd be vulnerable to replay attacks...
Why not use timestamp with the request. That will make the messages unique. Either you have time synchronization or you could send the timestamp in in plain text with the request to verify at the server.
I have finished my app and then tried it on 3 FB accounts and it was ok,
but the 4th have a permanent error (it cannot get an access token):
com.restfb.exception.FacebookOAuthException: Received Facebook error response of type OAuthException: Expected 1 '.' In the input between the postcard and the payload.
I tried to remove the app and install it again on this account a few times and nothing changed.
I use Java and restFB client.
This is the code where i get the access token:
if (request.getParameter("code") != null) {
String code = request.getParameter("code");
String url = "https://graph.facebook.com/oauth/access_token?"
+ "client_id=" + clientId + "&" + "client_secret="
+ clientSecret + "&" + "code=" + code + "&" + "redirect_uri="
+ redirectURL +"&type=web_server";
String accessToken=readUrl(url).split("&")[0].replaceFirst("access_token=", "");
//....
}
I saw here someone with the same error, he said that the solution was:
replacing "|" with "%257C" which made my access token invalid"
I couldn't really understand what he means.
Embarrassing as it is -- I'll be honest in case it helps someone else:
When I got this error message, I had accidentally copy/pasted a Google access_token (e.g. ya29.A0A...) into a Facebook graph API route. :)
It's probably worth logging the response to the /oauth/access_token request and the value you extract for use as the access token.
For the account that doesn't work, check whether the /oauth/access_token response includes other parameters before access_token. IIRC I've seen responses like
expiry=86400&access_token=AAAxxxx
Check to ensure you are verifying the "code" parameter returned by Facebook before signing the request, not the "access token". That was the mistake I made.
I experience the same issue, and after debugging my only conclusion was that when this message is thrown it might just be the token is expired or invalid. Checking with a freshly generated token should not throw this error.