Like many I'm sure, we've received an email from Amazon stating:
We recently observed Signature Version 2 requests on an Amazon SES SMTP endpoint originating from your account.
Is there any way to identify what these calls are as we have several IAM users and large codebases and haven't yet been able to trace the origin of these calls.
I'm thinking this should be possible with CloudWatch/CloudTrail but can't see how to do this.
From a question in the AWS dev forum
If your existing smtp credentials were created via console, the creation date (visible in IAM console) can be an indication of Signature v2 usage, as smtp users created via the SES console before Feb 2019 were Signature v2 signed. Credentials created in the SES console after this date are signed using Signature v4.
You can't use CloudTrail to audit SES send events because SES only delivers management events to CloudTrail, as mentioned here.
You can't use SES event publishing because it doesn't contain the request details that triggered the send.
As mentioned on this AWS forum thread, according to an AWS representative they are working on a way to track SigV2 usage, however that's not too helpful considering they will begin to throttle SigV2 requests in 10 days.
So currently, the best way to identify credentials still using SigV2 is to:
Regenerate all credentials created in the SES console
Generate SigV4 SES credentials from all IAM credentials that may be using SES and compare them to the SES credentials that you are actually using.
Related
In our project we are using API Gateway to get authenticated by Cognito User Pool.
Now, we are checking instead of hiting API Gateway can we directly hit Cognito for authenticating users.
So, wanted to check if there is any API of AWS cognito-idp admin-initiate-auth to get the tokens without using the CLI command?
Please refer to the link here. You will also find more information about using this API in one of the language-specific AWS SDKs.
For a complete list of all Amazon Cognito API references, refer here
Firebase admin is only available for admin or users also to send notification to other users?
Actually i am little bit confused in send notification from one user to another and which data is used like on the basis of user receiver uid or receiver fcm token.
firebaser here
Calls to the FCM API to send messages require that you specify the FCM server key in your code. As its name implies, this key should only be used in server-side code, or in an otherwise trusted environment. The reason for this is that anyone who has the FCM server key can send whatever message they want to all of your users.
So sending messages to users is indeed only possible from a trusted environment, either through the Admin SDK, or the REST APIs. See How to send one to one message using Firebase Messaging for more.
I am using AWS Cognito for authentication in my application. Cognito provides fully client-side authentication. But, we need to store credentials in .env file which is accessible from the browser.
Is it secure to use AWS Cognito for authentication, if I am building an enterprise application and security is important for me?
For AWS cognito the authentication happens at server side. Not on the client side. At the client side we are creating the opportunity for the user to log via his credentials, then the credentials will be sent to AWS Cognito for authentication. Which results in a accept or reject.
Cognito itself is a service that you can build a secure identity foundation on - but not in the way you're proposing it.
Storing static credentials to 3rd party APIs in something that can be easily accessed by (un)authenticated users is a terrible security practice.
The security of Cognito is not your biggest problem, my advice would be to first find a better solution for your static credentials. Sometimes static credentials like API keys can't be avoided, but you should never expose them to your end users. Store them in something like the AWS Secrets Manager or the Systems Manager Parameter Store and retrieve them when you need them. Only store them in memory if possible and never send them to your clients.
I have a web service that users can sign into and so forth. I'd like to setup AWS API Gateway to allow the users to interact with the service via APIs. As the user management / password management is already in the system I don't want the user to have to go to another system.
I first looked at Cognito user pools but I couldn't automate fully the user creation / verification process, AWS in a support ticket said the user would have to verify the email separately. They then suggested to use a Lambda function to setup authorisation.
I've created a Lambda function and the API Gateway is authorizing however it looks like only one variable is sent for authorization, the Identity token. If I did this my Lambda function could find from my service that the key is valid but it's not really associated for a user.
What I'm after is a way to provide a user with a client id and passkey from my system (I can generate all of that), the user then does a request to the API Gateway end point with the client id and passkey, gateway sends the client id and passkey to the lambda function that calls my system for verification, Lambda returns the valid policy, API Gateway then sends the request to my service with either the client ID or some other identifier thats come back from the policy so my system knows the requesting client.
What would be the best way to achieve this without taking the user to a seperate system (Cognito)?
Turns out that your timing might have just been a Day or so early. What you would have experienced with custom authorizers before is the TOKEN authorizer. Today they noticed expanded support for custom authorizers with a new REQUEST authorizer type. The new REQUEST type supports a much expanded dataset for authorizing requests, such as request parameters, headers, query strings, and more. Check out the Custom authorizer types for further information.
Can we integrate AWS cognito to authenticate API calls to our back-end? I was planning to use cognito access token which would be given to a reverse proxy server to create a JWT by value for back-end micro services. But I could not find any method to check the AWS token for validity. Any suggestions?
Thanks :)
Amazon Cognito was not designed to secure developer built APIs and I would caution you from using only the Amazon Cognito token to secure your API.
That being said, the vended Amazon Cognito token is a normal JWT signed using asymmetric encryption. This thread on the AWS forums has some example code in C# that another customer was able to use to verify the token.
Update 2015-07-09 AWS has announced Amazon API Gateway. Using API Gateway you can build a REST interface to your existing API (or to AWS Lamdba functions) secured with credentials retrieved via an Amazon Cognito authflow. See this blog post for additional announcement details.
You can retrieve the JWT tokens after authenticating users using Cognito. Pass the Access or ID token (depending on usecase) to your backend app and decode the token using any standard JWT decoder libraries.
Here is an article with sample code for reference explaining the process.