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)?
Related
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.
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 writing an application that using http request for authentication. Because of security matter, I am using WireShark to sniff the http packet to see if can steal the username and password.
When using WireShark, I got this encoded string:
TlRMTVNTUAADAAAAGAAYAHIAAADcANwAigAAAAQABABYAAAAEgASAFwAAAAEAAQAbgAAABAAEABmAQAAFYKI4gYDgCUAAAAP255D/F478qJlQoJwEti1LGgAcABzAGwAZQBlAGsAYgBvAG8AawBIAFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGao0slMmaggkTP6jJJHJUwEBAAAAAAAABaWp/E9p0QGDaAQ319vuYgAAAAACAAQASABQAAEABABIAFAABAAEAGgAcAADAAQAaABwAAcACAAFpan8T2nRAQYABAACAAAACAAwADAAAAAAAAAAAQAAAAAgAAAkOEBAmC7E+a9Pa8Y4gF0J9zeqVTsT7BCXKEhznVGMpwoAEAAAAAAAAAAAAAAAAAAAAAAACQAkAEgAVABUAFAALwAxADkAMgAuADEANgA4AC4AMQAuADEAMQAzAAAAAAAAAAAAAAAAAFq8ggyPeAnfXnSiV12/Z1Y=
I do research online, and I guess this is Base64 encoded. Then, I tried to decode from this website:
http://www.opinionatedgeek.com/dotnet/tools/base64decode/
I managed to see my username which is sleekbook, but the others still seems unknown to me. Is it because it's not Base64 encoding or it's further encrypted by some other algo as well?
am sorry for this dumb question, but am using RawCap to detect packets sent and received to learn what is sent in HTTP, and the page is a simple application made using Tornado and MongoDB, when i capture packets, i dont find the password in any packet sent.
Why? i dont use any encrypted protocole like HTTPS, it's a simple HTTP and cant see the password.
here is the file:
The result
as you can see, Mongodb answers the value of the database, and brings the password as it is saved (PBKDF2), but cant see the one sent from the first time.
Most likely, you don't see the password because the page is using HTTP basic authentication which encodes the username and password using base64. Look for a string like:
Authorization: SomeRealmName QWxhZGRpbjpvcGVuIHNlc2FtZQ==
If you're using Basic authentication, then the password is base 64 encoded. ENCODED not encrypted. Look for something like this in your packets: Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=