Questions tagged with Security, Identity, & Compliance

Content language: English

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Cognito Allow all 3 Aliases (Email, Phone, and Username)

I have a ReactJS app and am creating a user portal for that website, with user accounts managed by Cognito. I am using [amazon-cognito-identity-js](https://www.npmjs.com/package/amazon-cognito-identity-js) in my ReactJS layer to register users with a User Pool. **Specifically, I want to allow users the flexibility to log into their user accounts with phone number, email address, and preferred username as aliases.** In order to use email address and phone number as aliases, both must be verified using OTPs. In order to use the signUp API in **amazon-cognito-identity-js**, a username must be provided. In this case, this username cannot be the email address or the phone number, since both are to be used as aliases. This is per [User Pool Attributes - Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-aliases), which states: > If you select email address as an alias, Amazon Cognito doesn't accept a user name that matches a valid email address format. Similarly, if you select phone number as an alias, Amazon Cognito doesn't accept a user name for that user pool that matches a valid phone number format. Further, once the user's account is confirmed by verifying their phone number or email address, you can allow the user to set a preferred username. You cannot establish their preferred username as a username when registering: > Activate the preferred_username attribute so that your user can change the user name that they use to sign in while their username attribute value doesn't change. If you want to set up this user experience, submit the new username value as a preferred_username and choose preferred_username as an alias. Then users can sign in with the new value that they entered. If you select preferred_username as an alias, your user can provide the value only when they confirm an account. They can't provide the value during registration. So, what I'd like to get some assurance on is **what to provide Cognito for the username when calling the signUp API**. When creating users using only their email addresses as a username, you provide the email address for the username parameter when calling the signUp API. The username is then set to the supplied email address. Something must be provided for the username parameter to Cognito's signUp API, and in this case it cannot be an email address or phone number. I've tested this and whatever I provide for the username parameter can be used for logging into the user account, even after setting the preferred_username. In essence, the account can then be accessed by TWO different usernames, plus the phone and email aliases. **Is having this "original username" in addition to the other three username values considered legit and safe? Should I generate a UUID myself in the javascript code for the username parameter, using a library such as [UUID - npm](https://www.npmjs.com/package/uuid)? Or is there a different way so that the only three user IDs are limited to the phone number, email address, and preferred_username?**
1
answers
0
votes
32
views
asked 14 days ago

AWS Inspector V2 and AWS Inspector Classic findings are different

I am using Ubuntu 20.04 EC2 Instances and was investigating the difference between AWS Inspector Classic and AWS Inspector V2. There seemed to be many differences but the main one was the actual findings. With Inspector Classic a number of CVE would be found while with Inspector V2 the same instance once scanned would say `No Findings`. ### Inspector Classic finds 53 CVE's ![Enter image description here](/media/postImages/original/IM7H1iE2k8S2iL21F4CODGEQ) ### Same instance with InspectorV2 Just show `No findings` ![Enter image description here](/media/postImages/original/IMLgoOIjGzSqm7eZcT5bGH4Q) ------- With Inspector Classic I did attach a rule called `Common Vulnerabilities and Exposures-1.1`. I'm not sure what Inspector V2 actually checks against either. During my search to make this work did find that I needed the following Systems Managers manager Association needed to work `InspectorInventoryCollection-do-not-delete`. It's working now and show success for all ec2 instances. I am unsure if the `InvokeInspectorSsmPlugin-do-not-delete` Association needs to work as well. Not quite sure what this is used for but it shows skipped for all instances and when I look at the detailed status output on a specific instances is just says `InvalidPlatform`. Not sure if this is related. Can InspectorV2 actually be used to check Ubuntu 20.04 CVE's. If so how. Is there some special IAM or SSM config/setup that needs to be applied?
1
answers
0
votes
25
views
profile picture
dili
asked 14 days ago

IAM Policy Grammar - Clarification

Had a question around the policy grammar of IAM. In https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_grammar.html#policies-grammar-notes, towards the end of the grammar it says, ``` <condition_block> = "Condition" : { <condition_map> } <condition_map> = { <condition_type_string> : { <condition_key_string> : <condition_value_list> }, <condition_type_string> : { <condition_key_string> : <condition_value_list> }, ... } <condition_value_list> = [<condition_value>, <condition_value>, ...] <condition_value> = ("string" | "number" | "Boolean") ``` However, in this page https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_multi-value-conditions.html, I see the following example, ``` "Condition": { "StringEqualsIgnoreCase": { "aws:PrincipalTag/department": [ "finance", "hr", "legal" ], "aws:PrincipalTag/role": [ "audit", "security" ] }, "StringEquals": { "aws:PrincipalAccount": "123456789012" } } ``` So, shouldn't the grammar be the following? ``` <condition_block> = "Condition" : { <condition_map> } <condition_map> = { <condition_type_string> : { <condition_key_string> : <condition_value_list>, <condition_key_string> : <condition_value_list>, ... }, <condition_type_string> : { <condition_key_string> : <condition_value_list>, <condition_key_string> : <condition_value_list>, ... }, ... } <condition_value_list> = [<condition_value>, <condition_value>, ...] ``` Did I not understand correctly? If I did, which one is correct, the example or the grammar?
1
answers
0
votes
35
views
asked 18 days ago