Comments (11)
If this would become a requirement, the requirement should probably be "only allow access to a key vault with consent of at least two persons", instead of "use Shamir's Secret Sharing Algorithm".
I think this could be a useful security measure in some cases, which certain companies should consider, but I would not require it.
from asvs.
Ping for @jmanico and @tghosth
from asvs.
This feels too specific to be covered for ASVS. It might be relevant for something like a secret vault cheat sheet but I think it is too detailed for ASVS.
from asvs.
@ImanSharaf - any arguments why it should be as separate requirement or some alternative solutions to mention/spotlight in other requirements?
from asvs.
@tghosth I believe Shamir's Secret Sharing can be too specific and we can have a more general thing such as "avoid the risk associated with a single individual having access to the key vault".
@elarlang I believe that works too.
from asvs.
@ImanSharaf do you have a specific requirement that you think should be modified for this?
from asvs.
I want to say that we can modify 6.4.1 and add "avoid the risk associated with a single individual having access to the key vault" but it makes it an L3 requirement. Can we have a separate requirement for this?
from asvs.
I want to say that we can modify 6.4.1 and add "avoid the risk associated with a single individual having access to the key vault" but it makes it an L3 requirement. Can we have a separate requirement for this?
Key management is really challenging. May I suggest that we focus on what to do, instead of what not to do? "Shamir's Secret Sharing" is just one method and there are many other ways to do really good scalable key management like https://code.cash.app/app-layer-encryption and similar.
There is also Blakley's secret sharing and many other sharing algorithms that are solid.
Also, Secret Sharing (SSS) Is not always needed. If you are in a scenario where you need to distribute trust among multiple parties and can't afford to have a single point of failure or a single trusted entity, SSS might be the better choice.
Sometimes, envelope encryption is just fine. If you are looking to manage encryption keys for data at rest and want the convenience of using cloud provider services with built-in auditing and compliance features, envelope encryption would be more suitable.
Also: Beyond SSS and envelope encryption, there are other key management strategies to consider, like hardware security modules (HSMs), cloud HSM, or multi-cloud key management systems, which provide hardware-backed key storage and cryptographic operations.
from asvs.
Are we sure that there is a specific risk here?
As I see it, the risk which we are trying to prevent is that a single person with enough access to get to the secret vault directly steals a key.
Firstly, I don't think it should be possible to extract the keys from the vault anyway.
Secondly, generally the multi person operation is a one-time thing as the application needs to be able to access the secret vault on an ongoing basis. Someone with this level of internal access would probably be able to access the vault via the application anyway rendering the control less valuable.
As such, I am concerned that we are mandating a very specific requirement but I'm not sure that there is a specific risk we are addressing. It feels to me like the secret sharing mechanism would be useful in certain use cases but not as something that is universally mandated
from asvs.
@ImanSharaf @jmanico what are your thoughts on my previous comment? Reproduced below:
Are we sure that there is a specific risk here?
As I see it, the risk which we are trying to prevent is that a single person with enough access to get to the secret vault directly steals a key.
Firstly, I don't think it should be possible to extract the keys from the vault anyway.
Secondly, generally the multi person operation is a one-time thing as the application needs to be able to access the secret vault on an ongoing basis. Someone with this level of internal access would probably be able to access the vault via the application anyway rendering the control less valuable.
As such, I am concerned that we are mandating a very specific requirement but I'm not sure that there is a specific risk we are addressing. It feels to me like the secret sharing mechanism would be useful in certain use cases but not as something that is universally mandated
from asvs.
We can close this.
from asvs.
Related Issues (20)
- Add requirement about usage of claims other than subject and issuer as an identifier for OpenID Connect HOT 21
- [ASVS 5.0] Fix typos, punctuation, grammar, and standardize spelling to US English HOT 3
- Fingerprinting devices/matching sessions to a device. HOT 9
- `tlmgr` sometimes fails to update
- Most recent artifacts HOT 3
- Warnings on github actions HOT 3
- `install-unx.sh` intermittent failure
- 1.2.2 "User Account" is troubling HOT 3
- 1.2.5 HOT 1
- 2.2.11 HOT 1
- 2.3.1 seems weak HOT 1
- 13.4.2 seems too broad and not testable HOT 22
- 13.5.3 rate limiting should apply to all APIs HOT 8
- client should not send longer request headers than server can accept HOT 6
- new V5 section for architecture requirements HOT 2
- Requesting Clarifying Definition in the Business Logic Section Header HOT 3
- Something amiss in requirement description for v5.0-50.5.3 HOT 4
- lowercase vs uppercase grammar (original: 6.2.1 causes capitalization inconsistency) HOT 13
- 5.1.1 - terminology, GET and POST... HOT 14
- clarifying 5.1.3 HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from asvs.