The near wallet login callback only provides ?account_id=<cyberfeng.testnet>&all_keys=<public-keys> and the receiving side cannot verify the request is authentically coming from NEAR wallet. Checking the referrer header is unreliable as a hacker can use curl or other http clients to send fake requests
A signature or something that can be verified would be ideal
Does this exist?
Partial Answer:
I've since learned that the preferred method for user verification is to:
Send a wallet.near.org request for the user to add a function access key to their account.
You'll then have the function access key available to your websites local storage
You can then use that function access key to sign requests as the user for the specified function. You can also verify the key was added to their Near Name account which confirms access to their identity.
Unfortunately this method requires:
The user to pay a small transaction fee
The User to add an access key to their account
The requester to specify a target contract for the function access key
Outstanding Question:
Is there a simple way to sign a transaction with the local storage access key held at wallet.near.org and return that result so that I can query the users keys & verify that an existing key signed the transaction.
Why:
It's gasless - My new users have limited or 0 funds
I don't want to train users to add unnecessary access keys to their accounts
I don't need function access. I just need to securely verify their identity
Related
I have stuck in here and couldn't find a solid solution.
I use PHP in server-side and Vanilla JS in the client side.
In server-side, I'm generating a auth token (https://www.pubnub.com/docs/general/basics/manage-access) for current logged in user's channel to make him able to read his channel messsages by the following code:
I'm also generating a new one when the key timeout so all OK with the generation.
But my problem is starts here:
I'm passing the key into the client like this:
And user is getting access to the channel. But the thing is, I'm passing this auth key to the client-side. Which is someone that get this user's auth token; can setup their own client and can read messages that sent to this user.
How can I deal with that?
And another one:
I'm publishing to a channel in PHP like this. But I'm able do to that without setting auth token. I'm sure auth token system is working because when I pass wrong auth key to the client it's giving 403 forbidden. But however, I'm able to publish to channel without auth key in here. Is this because it's server-side?
Thanks!
Googled everything...
someone that get this user's auth token; can setup their own client and can read messages that sent to this user
This authorization strategy is the same as JWT. How will someone get this auth token? If you are using a secure connection to your server (TSL, aka https), and your PHP server is secured, then that is all you can do. This is the internet :)
Now how secure is the end user's machine? Are they susceptible to phishing or other schemes that might allow a hacker to gain access to their machine? Humans are the easiest thing to hack and you can't really do anything to secure them ;)
So as far as PubNub is concerned with security, you are doing exactly what very large companies have been doing for over 10 years with PubNub. The question is how secure is your server that a hacker can't get access to your code and data and get your PubNub secret key. In my 9+ years at PubNub, I've never known this to happen.
granting permissions on your channel
You are granting too many permissions but it doesn't have any negative side effects.
read - subscribe (receive messages), fetch (messages from history), and some presence stuff (get/set state, here now)
write - publish (send messages)
get and set - this is for PubNub Objects only which is different than pub/sub.
Again, no harm comes from granting permissions that have no effect on the resources you are granting to but it adds to the size of the auth token (just a little bit in this case).
able do to that without setting auth token
When you do setToken you are setting that on the pubnub object that you use to invoke PubNub operations. The PubNUb SDK automatically adds the auth token as a query parameter in the request. So it is being passed automatically for you.
Open your browser console, select the Network tab, and look at any PubNub request/url. You will see the query parameter names auth and the value is your auth token.
PubNub Secret Key give you all access
The secret key gives your server the ability to grant permissions (generate an auth token) AND it gives your server all access to all things in your PubNub key set. Don't let that secret key get compromised.
I'm trying to encrypt my sensitive data for an application. For the key generation part, I'm using crypto/pbkdf2. I'm generating the encryption key on the fly based on the user supplied password. When a user is created, that's when I'm encrypting the corresponding data of the user with the user's supplied password. However, whenever that particular user tries to access a resource, I've to decrypt the data before showing it to the user. Where do I get the password from, everytime an endpoint is called by that user to access a resource?
Note: I'm storing the hashed password of the user in the database schema, also I don't want to store the encryption password anywhere!
The typical solution to this is called token-based authentication (or in OAuth terms, Resource Owner Password Credential Flow).
Create a "login" endpoint that will derive the encryption key from the supplied username/password and exchange it for a (time-limited) "access token", storing it in a key-value store with TTL support (e.g. etcd, Redis).
Then each subsequent request will need to supply the access token (e.g. in the Authorization header), which is then used to retrieve the encryption key from the key-value store.
As JWT tokens are sent over the headers to authenticate uses, a user can just inspect the web call in chrome dev tools and copy paste the token and use it to access the exposed API.
For example, if I am using this token to create a record, a malicious user can use the same token (by using the above mentioned way) to create a new record in Database.
How can I stop this from happening? Is using Token Encryption with public key of server the way to stop this?
Token represents user identity. It is normal, that user can view his own token.
Token is validated on the server. Normally there is is no easy way to fake a token. Use cannot generate a new token on his own.
Communication between browser and server should be done via TLS. Then no third party will be able to see the token.
If your user gives access to his browser to somebody else, then yes, the other person can potentially access the token and used it later on on another computer, it this token is not expired yet. But this is not specific to the token, this is like giving access to your password to smb else.
Several steps can be taken as given below:
You should use https connection instead of http connection. This will encrypt your message which is sent to server or received from server. So if a man in the middle catches your packet, he can't do anything because message is encrypted.
Also add a short time validity for jwt token depending your app behavior.
Add an appropriate key size for your self-signed token validation. AES keys shorter than 128 bits, or RSA keys shorter than 1024 bits for legacy apps.2048 bits encryption now a days popular.
HSM (Hardware Security Module) can be introduce for signing and encryption task while key are not accessible from OS or software level.
You should be digging deep for more here[cheat sheet for jwt token OWASP].
My project has the requirement to access the yammer data using the given REST API using server side script(mainly PHP) and not involve a client side login using yammer's OAuth dialog.
I have gone through this document:
https://developer.yammer.com/docs/oauth-2
but this says, we requires user interaction.
What I wanted was can I generate a client_id and client_Secret to further generate access token to make API call out, but in all these processes I only use the authenticated users username and password in my server-side script.
Can anyone suggest a solution or is a client-side interaction required by design?
Thanks in advance!!
You have to have a user authorize the application at least once. This is just the nature of the OAuth implementation and you can't work around it. Having users go through the OAuth flow is considered a best practice.
If you have an OAuth token for a verified admin of Yammer, you can use impersonation to get tokens for end users without them interacting with the OAuth flow.
The below from Microsoft blogs might help you & added source at the end of answer.
Obtain a Verified Admin token for your application in one of the following 2 ways
a. Create the app with a Verified Admin account and then in the app’s Basic Info page, click “Generate a developer token for this application.” Note that you’ll need to use this app’s info in the JS SDK and any subsequent calls.
b. Use the process outlined at https://developer.yammer.com/docs/test-token with a Verified Admin account to get an OAuth token for that VA account. Note that you must use the app info used to generate this token in all future steps.
Obtain the current user’s email address in the server-side script.
Using the VA token obtained in step 1 to authenticate, pass the user’s email address to our Get User by Email Address endpoint documented at https://developer.yammer.com/docs/usersby_emailjsonemailuserdomaincom, and then process the response
a. If the call to the API endpoint returns a 200 OK response, first check the “state” field to make sure the user is “active” and if so, store the “id” field that’s returned and go to step 4
b. If the call returns a 404 or a state other than “active,” direct the user to finish creating and activating their account however you like.
Once you have the user’s ID, you can pass it to our Impersonation endpoint to obtain a pre-authorized OAuth token for that user. This endpoint is documented at https://developer.yammer.com/docs/impersonation and must use the VA token obtained in step 1 to authorize the call, and the consumer_key of your JS SDK app.
You now have an OAuth token for the current user. When generating the code being passed to the browser, have the client side JS SDK code first call yam.platform.getLoginStatus and if there’s no active session and you have a token from step 4, pass that token to yam.platform.setAuthToken($tokenFromStep4, optional_callback_function_if_desired(response)). If you don’t have a valid token, direct the user to finish setting up their Yammer account.
Continue making JS SDK calls as you normally would, without needing the user to authenticate.
Source: https://blogs.technet.microsoft.com/askyammer/2016/11/04/preauthorizing-the-yammer-js-sdk/
I want to use OAuth JWT token for authorization. By some reasons (osgi container) I can't use spring-oauth-security.
In the readme of spring-oauth-security I have found a quote:
The JSON Web Token (JWT) version of the store encodes all the data about the grant into the token itself (so no back end store at all which is a significant advantage).
https://github.com/spring-projects/spring-security-oauth/blob/master/docs/oauth2.md
I am absolutely don't catch "no back end store at all". There are two cases in jwt:
symmetric key or shared secret (HMAC);
Verifier key is a shared secret and is available by /token_key URL.
Question 1: I should store shared secret on server for each registered user. Why "no back end store at all"?
asymmetric key (RS/ES);
/token_key returns public key (without principal).
Question 2: But why we use only one public key for all users? It is unable to generate more than one private key for the same public key in rsa, isn't it? Only one pair private key - public key is allowed in RSA.
I don't understand a flow and why "no back end store at all".
You do not use different keys per user but per Identity Provider.
Identity Provider signs a JWT with a key and you are able to validate it for each user without a backend lookup. For JWT validation you only need a key related to the Identity Provider - even if you store it on some DB, you could fetch it once and cache it. For assymetric keys, OIDC even defines a URL to fetch the public key(s) used for signature.
The key is used to trust the Identity Provider and thus implicitly the identities it provides.
This is quite good article on the topic:
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/