Revising 'Insecure Data Storage' Subcategories

‘Insecure Data Storage’ category seems to have some redundancy that could be eliminated:

Insecure Data Storage->Credentials Stored Unencrypted->On External Storage Insecure Data Storage->Credentials Stored Unencrypted->On Internal Storage

Insecure Data Storage->Sensitive Application Data Stored Unencrypted->On External Storage Insecure Data Storage->Sensitive Application Data Stored Unencrypted->On Internal Storage

‘Credentials Stored Unencrypted’ and ‘Sensitive Application Data Stored Unencrypted’ subcategories having identical variants could be replaced by ‘Secrets Stored Unencrypted’

Insecure Data Storage->Secrets Stored Unencrypted->On External Storage Insecure Data Storage->Secrets Stored Unencrypted->On Internal Storage

In addition to that let’s look into Insecure Data Storage->Insecure Data Storage->Password (P2) as the classification and purpose of this entry seem to be unclear.

All feedback is welcome

[dantrauner]

“Secrets” is a pretty widely-used term in this context (at least in the infrastructure world when referring to things like passwords and various other bits of sensitive information passed to an application at runtime), so I’m personally ok with its usage here.

[plr0man]

We distinguish internal(P5)/external(P4) storage based on how sensitive data can be accessed by a 3rd party e.g. a malicious app. Those specific entries do not relate well to web, server side being internal storage. Generally issues that require chaining are seen as best practices or low risk. In cases where we don’t have designated entries, issues are triaged at the ASE’s discretion. We do welcome any ideas for new entries/solutions though. We’ll make sure to discuss those internally. Outdated hashing algorithm or weak salts might be considered valid on a case by case basis, we also give the customers a chance to review best practices issues and consult the risk with the ASE.