You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Amazon describes the benefits of specifying an EncryptionContext as:
Additional authenticated data (AAD)
Audit trail
Authorization context
That post goes into detail about how AEAD can prevent replacement attacks (the first point) whereas the README for credstash only seems to mention points 2 and 3 as benefits for using EncryptionContexts.
The same replacement attack (swapping encrypted values) described in that post is possible against credstash. Given this I propose setting a default EncryptionContext with at least the name of the credential.
Changes to support this should be small however there would need to be an upgrade path for existing credstash users. I'm happy to open a PR making the changes but would like feedback before doing so.
Do others believe this is a genuine issue in credstash ?
If so, Would adding something similar to credstash-migrate-autoversion.py be a suitable upgrade path?
The text was updated successfully, but these errors were encountered:
It probably makes sense to have a default encryption context that contains the name and version of the credential (to prevent version-swapping as well). User-supplied encryption context could then be added to the dict.
We can have another migration script and put that and the auto-version migration script into a scripts/ directory.
It sounds like a migration script for this would just entail reading the current latest values of everything and writing new versions to DDB.
Amazon describes the benefits of specifying an EncryptionContext as:
That post goes into detail about how AEAD can prevent replacement attacks (the first point) whereas the README for credstash only seems to mention points 2 and 3 as benefits for using EncryptionContexts.
The same replacement attack (swapping encrypted values) described in that post is possible against credstash. Given this I propose setting a default EncryptionContext with at least the
name
of the credential.Changes to support this should be small however there would need to be an upgrade path for existing credstash users. I'm happy to open a PR making the changes but would like feedback before doing so.
credstash-migrate-autoversion.py
be a suitable upgrade path?The text was updated successfully, but these errors were encountered: