We Keep Coding

Error: Credential is missing for AssociateSoftwareTokenCommand with AWS CognitoIdentityProviderClient Javascript SDK

BLUF: I would like to set up software token association in AWS Cognito in a user-facing JavaScript application (using AWS SDK) and am struggling with 'Credential is missing' errors.
I am trying to create an application using AWS Cognito using the Javascript SDK and the CognitoIdentityProviderClient that requires the user to use a software token MFA.
I can sign up and confirm the user using the SignUpCommand and I can generate a successful response for the user with InitiateAuthCommand using username/password login (first time logging in). At that point I then need to process an MFA_SETUP challenge which requires the use of a separate AssociateSoftwareTokenCommand flow to generate the secrets and responses.
I would expect to be able to let the end user, while logging in through their browser, issue the command to associate the software token themselves after successfully entering their username/password for the first time.
The problem I run in to is that I get the following error when issuing the AssociateSoftwareTokenCommand:
Error: Credential is missing
at SignatureV4.credentialProvider (runtimeConfig.browser.js:16)
at SignatureV4.<anonymous> (SignatureV4.js:169)
at step (tslib.es6.js:102)
at Object.next (tslib.es6.js:83)
at tslib.es6.js:76
at new Promise (<anonymous>)
at __awaiter (tslib.es6.js:72)
at SignatureV4.signRequest (SignatureV4.js:165)
at SignatureV4.<anonymous> (SignatureV4.js:85)
at step (tslib.es6.js:102)
Some vigorous Googling and looking through StackOverflow this method requires a credential object in the Client configuration, however this credential, as far as I can tell from Google/SO/AWS SDK docs, requires me to create an IAM object and generate keys / a secret key.
My application (built with React) is mostly single-app/browser based and I am trying to avoid additional server-side logic to act as a middleman if possible - and obviously don't want to go dropping secret keys into user-facing interfaces.
My questions then are:
Am I able to do this directly in my React App without action exposing credentials?
Is a server side middleman/proxy the only way for me to safely associate a software token?
Or is there perhaps some aspect of these credentials I am overlooking?
The offensive lines of code are simple (I can get the valid session key, no problem):
const client = new CognitoIdentityProviderClient({ region: AWS_REGION });
const command = new AssociateSoftwareTokenCommand({Session: session });
const response = await client.send(command)
Other searches have shown me that the credentials: {} object would then go in the client configuration object, which part I understand, I just don't want to put that on the client side with secret keys, etc.
Thank you for any assistance.

Slack API not returning private channels

I'm trying to obtain a list of private channels in Slack (on a per-user basis is fine), but I'm having trouble seeing this information. I installed my application into the workspace in Slack originally and got an OAuth token in the form xoxp-4............
App OAuth token
When I try to use the slack API (node SDK) then I only get the publicly listed channels.
await new WebClient(`xoxp-4.....`)
.conversations
.list({ exclude_archived: true })
).channels
I get the same if I try using the Slack API tester to grab a channel list.
User OAuth token
I've followed the OAuth 2.0 process to obtain a token for a given user (myself). I think I've done all this correctly (here's a response):
{
ok: true,
access_token: 'xoxp-4.........',
scope: 'identify,bot,commands,channels:history,groups:history,im:history,mpim:history,channels:read,emoji:read,groups:read,im:read,search:read,team:read,users:read,users:read.email,usergroups:read,users.profile:read,chat:write:user,chat:write:bot,links:read',
user_id: 'UD......',
team_name: '............',
team_id: '.......',
scopes: ['identify',
'bot',
'commands',
'channels:history',
'groups:history',
'im:history',
'mpim:history',
'channels:read',
'emoji:read',
'groups:read',
'im:read',
'search:read',
'team:read',
'users:read',
'users:read.email',
'usergroups:read',
'users.profile:read',
'chat:write:user',
'chat:write:bot',
'links:read'
]
}
Interestingly I discovered this provides me with exactly the same OAuth token if I goto the application management (I assume because it was me who installed the app to the workspace).
Obviously, because it's the same token, I don't get permissions to see the private channels still, even though as far as I'm aware I should be able to do everything I can do as a user?
Can anyone point me to what I might be missing?

The reason why you do not get the private channels is that you are not requesting them.
The conversations.list method will return public channels by default only. To also get private channels you need set the parameter types accordingly. e.g. types = public_channel,private_channel.
Similar with calling channels.list. Channels.list will only return public channels. If you want to get the private channels you need to call groups.list. (note that private channels are called groups in the API for historical reasons).
In general I would recommend using conversations.list, which is more powerful and the recommended approach to get all types of conversations.

App API design advice specifically around security

I'm building an app and would like some feedback on my approach to building the data sync process and API that supports it. For context, these are the guiding principles for my app/API:
Free: I do not want to charge people at all to use the app/API.
Open source: the source code for both the app and API are available to the public to use as they wish.
Decentralised: the API service that supports the app can be run by anyone on any server, and made available for use to users of the app.
Anonymous: the user should not have to sign up for the service, or submit any personal identifying information that will be stored alongside their data.
Secure: the user's data should be encrypted before being sent to the server, anyone with access to the server should have no ability to read the user's data.
I will implement an instance of the API on a public server which will be selected in the app by default. That way initial users of the app can sync their data straight away without needing to find or set up an instance of the API service. Over time, if the app is popular then users will hopefully set up other instances of the API service either for themselves or to make available to other users of the app should they wish to use a different instance (or if the primary instance runs out of space, goes down, etc). They may even access the API in their own apps. Essentially, I want them to be able to have the choice to be self sufficient and not have to necessarily rely on other's providing an instance on the service for them, for reasons of privacy, resilience, cost-saving, etc. Note: the data in question is not sensitive (i.e. financial, etc), but it is personal.
The user's sync journey works like this:
User downloads the app, and creates their data in the process of using the app.
When the user is ready to initially sync, they enter a "password" in the password field, which is used to create a complex key with which to encrypt their data. Their password is stored locally in plain text but is never sent to the server.
User clicks the "Sync" button, their data is encrypted (using their password) and sent to the specified (or default) API instance and responds by giving them a unique ID which is saved by the app.
For future syncs, their data is encrypted locally using their saved password before being sent to the API along with their unique ID which updates their synced data on the server.
When retrieving synced data, their unique ID is sent to the API which responds with their encrypted data. Their locally stored password is then used to decrypt the data for use by the app.
I've implemented the app in javascript, and the API in Node.js (restify) with MongoDB as a backend, so in practice a sync requests to the server looks like this:
1. Initial sync
POST /api/data
Post body:
{
"data":"DWCx6wR9ggPqPRrhU4O4oLN5P09onApoAULX4Xt+ckxswtFNH/QQ+Y/RgxdU+8+8/muo4jo/jKnHssSezvjq6aPvYK+EAzAoRmXenAgUwHOjbiAXFqF8gScbbuLRlF0MsTKn/puIyFnvJd..."
}
Response:
{
"id":"507f191e810c19729de860ea",
"lastUpdated":"2016-07-06T12:43:16.866Z"
}
2. Get sync data
GET /api/data/507f191e810c19729de860ea
Response:
{
"data":"DWCx6wR9ggPqPRrhU4O4oLN5P09onApoAULX4Xt+ckxswtFNH/QQ+Y/RgxdU+8+8/muo4jo/jKnHssSezvjq6aPvYK+EAzAoRmXenAgUwHOjbiAXFqF8gScbbuLRlF0MsTKn/puIyFnvJd...",
"lastUpdated":"2016-07-06T12:43:16.866Z"
}
3. Update synced data
POST /api/data/507f191e810c19729de860ea
Post body:
{
"data":"DWCx6wR9ggPqPRrhU4O4oLN5P09onApoAULX4Xt+ckxswtFNH/QQ+Y/RgxdU+8+8/muo4jo/jKnHssSezvjq6aPvYK+EAzAoRmXenAgUwHOjbiAXFqF8gScbbuLRlF0MsTKn/puIyFnvJd..."
}
Response:
{
"lastUpdated":"2016-07-06T13:21:23.837Z"
}
Their data in MongoDB will look like this:
{
"id":"507f191e810c19729de860ea",
"data":"DWCx6wR9ggPqPRrhU4O4oLN5P09onApoAULX4Xt+ckxswtFNH/QQ+Y/RgxdU+8+8/muo4jo/jKnHssSezvjq6aPvYK+EAzAoRmXenAgUwHOjbiAXFqF8gScbbuLRlF0MsTKn/puIyFnvJd...",
"lastUpdated":"2016-07-06T13:21:23.837Z"
}
Encryption is currently implemented using CryptoJS's AES implementation. As the app provides the user's password as a passphrase to the AES "encrypt" function, it generates a 256-bit key which which to encrypt the user's data, before being sent to the API.
That about sums up the sync process, it's fairly simple but obviously it needs to be secure and reliable. My concerns are:
As the MongoDB ObjectID is fairly easy to guess, it is possible that a malicious user could request someone else's data (as per step 2. Get sync data) by guessing their ID. However, if they are successful they will only retrieve encrypted data and will not have the key with which to decrypt it. The same applies for anyone who has access to the database on the server.
Given the above, is the CryptoJS AES implementation secure enough so that in the real possibility that a user's encrypted data is retrieved by a malicious user, they will not realistically be able to decrypt the data?
Since the API is open to anyone and doesn't audit or check the submitted data, anyone could potentially submit any data they wish to be stored in the service, for example:
Post body:
{
"data":"This is my anyold data..."
}
Is there anything practical I can do to guard against this whilst adhering to the guiding principles above?
General abuse of the service such as users spamming initial syncs (step 1 above) over and over to fill up the space on the server; or some user's using disproportionately large amounts of server space. I've implemented some features to guard against this, such as logging IPs for initial syncs for one day (not kept any longer than that) in order to limit a single IP to a set number of initial syncs per day. Also I'm limiting the post body size for syncs. These options are configurable in the API however, so if a user doesn't like these limitations on a public API instance, they can host their own instance and tweak the settings to their liking.
So that's it, I would appreciate anyone who has any thoughts or feedback regarding this approach given my guiding principles. I couldn't find any examples where other apps have attempted a similar approach, so if anyone knows of any and can link to them I'd be grateful.

I can't really comment on whether specific AES algorithms/keys are secure or not, but assuming they are (and the keys are generated properly), it should not be a problem if other users can access the encrypted data.
You can maybe protect against abuse, without requiring other accounts, by using captchas or similar guards against automatic usage. If you require a catcha on new accounts, and set limits to all accounts on data volume and call frequency, you should be ok.
To guard against accidental clear-text data, you might generate a secondary key for each account, and then check on the server with the public secondary key whether the messages can be decrypted. Something like this:
data = secondary_key(user_private_key(cleartext))
This way the data will always be encrypted, and in worst case the server will be able to read it, but others wouldn't.
A few comments to your API :) If you're already using HTTP and POST, you don't really need an id. The POST usually returns a URI that points to the created data. You can then GET that URI, or PUT it to change:
POST /api/data
{"data": "..."}
Response:
Location: /api/data/12345
{"data": "...", "lastmodified": "..." }
To change it:
PUT /api/data/12345
{"data": "..."}
You don't have to do it this way, but it might be easier to implement on the client side, and maybe even help with caching and cache invalidation.

OWIN cookie authentication get roles on client side

I'm developing an application where backend is asp.net owin based.
In Startup.cs I have IAppBuilder.useCookieAuthentication() { ... }. After successfully authenticated, current user with its roles can be accessed via HttpContext in all my web api controllers.
My javascript client side needs a knowledge about these roles in order to know how to display specific items. For example: user having administrator role can see additional tabs.
My question is: what's the best way to 'transfer' these roles to client side. Is it by writing some endpoint which will return these roles, or any other way?
Thanks

I totally agree with #cassandrad !
But if you want to access it as plain text, than you have to provide your own implementation of TicketDataFormat in the CookieAuthenticationOptions
public class CustomAccessTokenFormat : ISecureDataFormat<AuthenticationTicket>
{
// If you want to do custom serialization and encryption
public string Protect(AuthenticationTicket ticket)
{
return "UserName|Role1|Role2|..."; // your raw text serialization goes here
}
// Deserilaize and decrypt the ticket
public AuthenticationTicket Unprotect(string strTicket)
{
return new AuthenticationTicket(null, null); // deserialize the plain text here into an AuthenticationTicket object
}
}

You don't need to pass information about roles or permission in “raw” state to the client-side. Instead, you should have AuthenticationTicket — the thing that holds all information protected and encrypted. So, if you are using correct implementation of OWIN middleware, there is no need to do something by yourself — middleware will add all the necessary data to your response(inside cookies), client only need to resend this information back to the server next time when he wants to access some resources on the server.
And yes, I'm implying that you shouldn't have any information about permissions on your client-side — it is not secure.

What is with the Dreamcode idea?

The Dreamcode as described here: http://nobackend.org/dreamcode.html
That developers don't have to worry about the backend when developing web applications.
Is very interesting. However I have few question on building application logic in the front-end.
The question is, even with authentication being processed in the backend.
What are the ways to make the app logic obfuscated and not to be copied easily?
For the application models it is easy for a server to receive it. However looking with the Store and Public Store idea from Dreamcode, how can we handle fields that are not meant to be sent back to the front-end for security purposes?
For example in this Gist it show how to get object by id:
// find one object
var type = 'note';
var id = 'abc4567';
store.find(type, id)
.done(function (object) {});
The issue here is, for example I have an application that guest user can post a document and edit it later with a password. A guest user saves a document with a encrypted password in it.
When other users "views" the document from the front-end application. The Dreamcode data store will return all the fields for this document object (based on the Dreamcode specification) including the encrypted password, which is not good.
So how can we deal with making a Front-end application with Dreamcode with these potential limitations?