Using Wireshark I have seen that the iOS Philips Remote TV app talking to my Philips TV running their new os Saphi sends some HTTP requests with an authorization header looking like this on the wire:
Authorization: Basic 1:ZmVay1EQVFOaZhwQ4Kv81ypLAZNczV9sG4KkseXWn1NEk6cXmPKO/MCa9sryslvLCFMnNe4Z4CPXzToowvhHvA==
I believe that “1” is the userid and separatet from the long password with a “:”.
In Wikipedia I have read that
The Authorization field is constructed as follows:
The username and password are combined with a single colon (:).
The resulting string is encoded into an octet sequence using a variant of Base64.
The authorization method and a space (e.g. "Basic ") is then prepended to the encoded string.
For example, if the browser uses Aladdin as the username and OpenSesame as the password, then the field's value is the base64-encoding of Aladdin:OpenSesame, or QWxhZGRpbjpPcGVuU2VzYW1l.
Then the Authorization header will appear as:
Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l
I therefore wonder if the Authorization header used in this app is valid - skipping, what it looks like, the encoding step 2 above?
The header you posted violates RFC 7235, which forbids a colon (:) in an authorization token:
Authorization = credentials
credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]
token68 = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "~" / "+" / "/" ) *"="
As you noted correctly, Basic authentication encodes to Base64 after combining the username and the password. The sample you posted contains valid Base64 after the colon, but it decodes to some binary garbage.
It’s likely that the developers of this Philips software have mistakenly labeled a custom authentication scheme as Basic. This is not an uncommon error. A typical case is when a token is sent without Base64, as in Basic MySecretToken123.
Related
Trying to get an access token for an API so I can use R to pull the data. The documentation I'm using has the following instructions:
The following POST request shows the format of an Axon Evidence token request:
POST /api/oauth2/token HTTP/1.1
Host: api.evidence.com
Content-Type: application/x-www-form-urlencoded
grant_type: client_credentials&partner_id={partner ID}&client_id={client ID}&client_secret={client secret}
Note: ensure that you use URL-encoded forms for all parameter values. The client secret is base64 encoded and therefore usually end in an equals sign (=), which must be encoded as %3D. Additionally, if you use a manual REST client for testing, ensure that you know whether the client is automatically performing URL encoding. For more information, see Resources.
I'm trying to request a token using the httr package with the instructions above and it doesn't seem to be working. I'm using:
Token_Response <- POST("https://api.evidence.com/", body = "POST /api/oauth2/token HTTP/1.1
Host: api.evidence.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&partner_id={partner ID}&client_id={client ID}&secret={client secret}")
Unfortunately I can't make this question reproducible for security reasons, but I'm hoping it's just a syntax problem on my end.
You don't usually work directly with the body or headers when using HTTR. The function can do most of the formatting of the request for you. A proper translation would look more like
url <- "https://api.evidence.com/"
partnerId <- "my partner ID"
clientId <- "my client ID"
clientSecret <- "my client secret"
token_Response <- POST(url,
encode="form",
body=list(
grant_type = "client_credentials",
partner_id = partnerId,
client_id = clientId,
secret = clientSecret
)
)
I used a few variables for clarity but you could put the values directly in the function call if you like.
Hi Guys Im currently capturing some traffic from an android application, but the requests it is sending out to server seems encrypted. Would you guys know how to decrypt such requests? Or is that impossible to do?
platform=android&version=1.0.31&lang=en&requestId=44&time=1485552535566&batch=%5b%7b%22id%22%3a177205%2c%22time%22%3a1485552512601%2c%22name%22%3a%22collectResource%22%2c%22params%22%3a%5b155%5d%2c%22hash%22%3a1948904473%7d%5d&sessionId=674937_bc59a16eae9e1559b2e60ae068baf4e7
That's not encrypted, it's encoded. Do a search for "online url decode". In your example you will get:
platform=android&version=1.0.31&lang=en&requestId=44&time=1485552535566&batch=[{"id":177205,"time":1485552512601,"name":"collectResource","params":[155],"hash":1948904473}]&sessionId=674937_bc59a16eae9e1559b2e60ae068baf4e7
The %xx are url encoded hex values. For example %22 is the hex version of the double quote character. I think that if you use javascript or other tool to decode the url encoding or manually change all % strings to the equivalent characters, you will see that the message is really just url encoded plain text.
Its going to be impossible to provide a reproducible example for this as it has to do with accessing a particular API - apologies in advance. I am trying to access the edinburgh fringe festivals API through R. The documentation says the following:
Authentication
An access key is required for all requests to the API and can be
obtained by registration. This key, combined with the signature
explained below, is required to get any access to the API. If you do
not provide an access key, or provide an invalid key or signature, the
server will return an HTTP 403 error.
Your secret token is used to calculate the correct signature for each
API request and must never be disclosed. Once issued, it is never
transmitted back or forward. The API server holds a copy of your
secret token, which it uses to check that you have signed each request
correctly.
You calculate the signature using the HMAC-SHA1 algorithm:
Build the full API request URL, including your access key but excluding the server domain - eg /events?festival=book&key=12345. See
the note below on URL encoding.
Calculate the hmac hash of the url using the sha1 algorithm and your secret token as the key.
Append the hex-encoded hash to your url as the signature parameter
URL encoding in queries
You should calculate the signature after URL-encoding any parameters -
for example, to search for the title "Mrs Brown" you would first build
the URL /events?title=Mrs%20Brown&key=12345 and then sign this string
and append the signature.
Signature encoding
Some languages - notably C# - default to encoding hashes in UTF-16.
Ensure your signature is encoded in plain ASCII hex or it will not be
valid.
What I have tried so far is below:
library(digest)
library(jsonlite)
source("authentication.R") # credentials stored here
create the query string
query <- paste0('/events?festival=demofringe&size=20&from=1&key=', API_KEY)
create the hashed query
sig <- hmac(SECRET_SIGNING_KEY, query, algo="sha1")
create the final url
url <- paste0('https://api.edinburghfestivalcity.com', query, '&signature=', sig)
submit to the API
results <- fromJSON(url)
and I get the error:
Error in open.connection(con, "rb") : HTTP error 417.
I'm not sure that the signature is ASCII encoded as per the documentation. Does anyone know how to debug this situation? I have tried iconv() to try and convert the encoding and when I call Encoding() on the character object it returns "unknown". I have also tried saving both files in RStudio with "save with encoding" set to ASCII and I have tried sourcing the authentications with encoding = "ASCII".
Incidentally when I paste the final url into a browser, I get the following error:
Invalid Accept header value. ['application/json', 'application/json;ver=2.0'] are supported
That's a server error. It should understand that
Accept: application/json, text/*, */*
Matches application/json. Note that instead of modifying jsonlite, it is beter to manually retrieve the response form the server, and then feed it to jsonlite.
library(httr)
library(jsonlite)
req <- GET(your_url, accept("application/json")
json <- content(req, as = 'text')
data <- fromJSON(json)
In the end, I solved this problem by editing the jsonlite::fromJSON() function. namely the line
curl::handle_setheaders(h, Accept = "application/json, text/*, */*")
I changed to
curl::handle_setheaders(h, Accept = "application/json")
I then also had to point to the internal functions with jsonlite:::. Now it works fine.
I am trying to do oauth 2 with Paw. It doesn't appear to be encoding my Client ID and Client Secret correctly. My server expects username:password format. I have tried it in the same field, separate, with same results.
Example
Input = VjE6MHJ:SjZvR24=
Base 64 encode result = `VmpFNk1ISjpTalp2UjI0PQ==
Paw result = VmpFNk1ISjpTalp2UjI0JTNE
The base 64 result works and returns a token, but Paw does not as it is encoded wrong.
It's a late answer, sorry! It seems like the only difference is that the = sign at the end of your password, is URL encoded by Paw, while your server doesn't expects a URL encoded value.
According to the OAuth 2 spec / 2.3.1. Client Password, we need to URL encode the Client ID and Client Secret. Then the question is, should we also encode the = sign? It's not very clear from the spec. Have you tested with other clients (maybe client implementation of OAuth, in JS/Swift/Python/Java)?
What exactly is the difference between following two headers:
Authorization : Bearer cn389ncoiwuencr
vs
Authorization : cn389ncoiwuencr
All the sources which I have gone through, sets the value of 'Authorization' header as 'Bearer' followed by the actual token. However, I have not been able to understand the significance of it. What if I simply put the token in the Authorization header?
Then the service receiving the header would not know how to interpret it. Instead of bearer, it could also be basic for example in which case the encoded string is a base64 encoded username/password instead of a token.
There are a number of authentication schemes possible. Which one is used is indicated by the identifier in the header.