test: [M3-9913] - Replace mock data that resembles real secrets

[cliu-akamai]

Description 📝

Replace mock data that resembles real secrets

Changes 🔄

List any change(s) relevant to the reviewer.

• Add mockDataPrefix to indicate the secrets are fake.

How to test 🧪

pnpm cy:run -s "cypress/e2e/core/account/oauth-apps.spec.ts,cypress/e2e/core/account/personal-access-tokens.spec.ts,cypress/e2e/core/account/third-party-access-tokens.spec.ts,cypress/e2e/core/account/two-factor-auth.spec.ts,cypress/e2e/core/parentChild/token-scopes.spec.ts"

[linode-gh-bot]

Cloud Manager UI test results

:small_red_triangle: 1 failing test on test run #1 ↗︎

:x: Failing	:white_check_mark: Passing	:arrow_right_hook: Skipped	:clock1: Duration
1 Failing	652 Passing	4 Skipped	141m 6s

Details

Failing Tests
	Spec	Test
:x:	bucket-create-multicluster.spec.ts	Cloud Manager Cypress Tests→Object Storage Multicluster Bucket create » Object Storage Multicluster Bucket create

Troubleshooting

Use this command to re-run the failing tests:

pnpm cy:run -s "cypress/e2e/core/objectStorageMulticluster/bucket-create-multicluster.spec.ts"

[jdamore-linode]

@cliu-akamai on second thought, I think the main purpose of this ticket is to identify hard coded mock data that might be mistaken by e.g. security researchers as real sensitive data, and I'm not sure we have to do anything at all to these calls to randomString/randomHex.

I'm guessing you looked pretty closely at the tests to identify all these mocks, did you happen to come across any hardcoded mock secrets? If not we might be able to close this

[dmcintyr-akamai]

Thanks @cliu-akamai, this looks good!

On one hand, it might be a little bit tedious/clunky to have to import these consts and do string manipulation like this every time we want to mock a secret and whether there's any risk we might forget to do this the next time we mock a secret-like value, but on the other hand we might do this so infrequently that it doesn't matter.

Have you thought about setting up a new randomSecret util (or maybe 2 utils, randomStringSecret/randomHexSecret) that does this automatically or do you think that might be overkill?

@dmcintyr-akamai what are your thoughts?

where would the mock tokens appear that would appear to be actual secrets to security researchers? if they're looking thru our codebase, they wouldnt find any, so i dont think that's a concern. and all these changes are in the /cypress directory, so this doesn't appear to be an issue in the production codebase (i hope). if it's worrisome that

Thanks @cliu-akamai, this looks good!

On one hand, it might be a lbit tedious/clunky to have to import these consts and do string manipulation like this every time we want to mock a secret and whether there's any risk we might forget to do this the next time we mock a secret-like value, but on the other hand we might do this so infrequently that it doesn't matter.

Have you thought about setting up a new randomSecret util (or maybe 2 utils, randomStringSecret/randomHexSecret) that does this automatically or do you think that might be overkill?

@dmcintyr-akamai what are your thoughts?

i guess i would add a randomPassword utility and extract cassie's code into it like: const randomPassword = (length) => { mockDataPrefix['secret'] + randomHex(length - mockDataPrefix['secret'].length) } and call it like: randomPassword(64).

[dmcintyr-akamai]

this is probably beyond the scope of this task, but i think the biggest risk of actual secrets being made public would be from our forks. is there a way to scan https://github.com/dmcintyr-akamai/manager etc?

[github-actions[bot]]

This PR is stale because it has been open 15 days with no activity. Please attend to this PR or it will be closed in 5 days