4 ms·

> Note that what i refer to is not about breaking any standard API but adding a secondary one that is explicitly about secret/sensitive stuff. But it still req

> Note that what i refer to is not about breaking any standard API but adding a secondary one that is explicitly about secret/sensitive stuff. But it still requires developers to use a new API. So why get them to used a half arsed security enclave when you can design a proper secrets store instead? > If the source of the data to be placed in the secure clipboard (for lack of a better name) is some encrypted storage (like a local secrets manager) or a plain text file is irrelevant here. It’s very relevant because: * clipboards are temporary which means you need to copy data into them. This creates an extra step for users to follow as opposed to applications querying the secrets store directly * clipboards don’t have RBAC unlike password stores. Which means any application with permissions to read from the clipboard can read any secret that any other application had written to it. Your solution of having an additional permissions set where you chose which applications have that permission is solved with secrets store where each application only has permission to the secrets it creates. Thus zero risk of leakage * secrets managers are encrypted, clipboard isn’t * secrets managers can store multiple secrets, a clipboard cannot. Thus you then still need to have a secrets manager to copy your password into the clipboard anyway. So why not do away with that middleman entirely? I get the incentive of wanting to “fix” the clipboard but if you’re going to introduce a new API for secrets then you might as well do it properly from the outset.

badsectoracula 5y ago
> But it still requires developers to use a new API. So why get them to used a half arsed security enclave when you can design a proper secrets store instead? Because the entire point of this is NOT to store something but to transfer something from one application to another without both applications explicitly knowing about each other (so they can't just communicate in a P2P fashion). The rest of your message is about storing data, which is not what the clipboard use is all about. Which is why i wrote it is irrelevant - you refer to something else. E.g. > clipboards are temporary which means you need to copy data into them. This creates an extra step for users to follow as opposed to applications querying the secrets store directly The API i mention is not about permanently storing data, it is explicitly about having a secure temporary store with the same(ish) UX as a clipboard but for secure data. Applications can also use a secure store for that and the data that is being copied to the secure clipboard could also come from an application that stores its own data to it from there, but again this is a separate issue, this is orthogonal to what a discuss here. > secrets managers are encrypted, clipboard isn’t This is irrelevant as the data isn't stored elsewhere outside the memory of the process that would manage the secure clipboard's functionality (and of course you could encrypt that if you'd like but IMO that'd be pointless since it'd need to be decrypted at some point anyway and these would be meant for temporary storage - regardless of you do or not encrypt it though it'd be again orthogonal to the rest of what i describe). > secrets managers can store multiple secrets, a clipboard cannot. Thus you then still need to have a secrets manager to copy your password into the clipboard anyway. So why not do away with that middleman entirely? Because this isn't about storage. > if you’re going to introduce a new API for secrets then you might as well do it properly from the outset. That'd be a "proper" solution for a different problem, hence barely a solution at all.
- deleted 5y ago
  [deleted]
- laumars 5y ago
  I get that you’re not storing something long term, but you are still storing it even if it is short term and thus presenting a risk. And you are still sharing secrets between applications thus presenting a risk. And all your suggestion is doing is offering a kludge around a solution you’ve already said is crappy, rather than switching to a robust and battle tested solution that literally every other platform already supports. If you want to pass secrets securely between applications then you use a secrets manager. It’s how Linux and macOS work. It’s how secure systems in the cloud works. And thus it makes complete sense for Windows to follow suit. We aren’t talking about some theoretical concept here. It is absolutely how passing secrets between applications should be done. If you have scepticism about this approach then you need to read up in this topic rather than pushing for a half baked kludge around something you’ve already acknowledged isn’t fit for security. Sorry if this sounds blunt but this is a solved problem you’re trying to re-engineer and your solution is worse than the industry standard in a number of ways which I’ve already highlighted. And ironically it isn’t even just worse for security but also worse for usability well (you’re creating administrative overhead with the user approving safe applications. This wouldn’t be needed with a secrets manager since each application only has visibility of its own enclave). And if you remember back to your first post, usability was the entire reason you designed this solution in the first place.
  - badsectoracula 5y ago
    I do not know why you mention Windows, i never referred to any specific platform (you mention Linux, Linux does not actually have what you describe because Linux is a kernel and what you describe is something that would live on the userland - the userland heavily relies on what software is installed and many setups, like mine, do not have such a thing). What i refer is how to provide a more secure approach to to THE SAME THING that people are already doing with clipboard copy/paste without breaking the versatility of the clipboard, workflows or even existing applications and can be supported with minimal changes in existing applications and pretty much zero re-learning by users. It is about being able to copy/paste stuff securely anything that can already be copy/pasted between applications and not just passwords or other stuff you'd need to store permanently. It can even be made to work in a backwards compatible way - with some additional though minimal effort from the user - for applications that do not support the functionality. What you refer to is having a different workflow, have applications add explicit support for the specific data mentioned and be accessed in a different way and up to the last reply you were referring to permanent storage. You ask people to change how they use software, i ask them to use a different menu option for sensitive stuff. What exactly do you think is the more likely to happen? (well, assuming anything would happen, in practice most likely nothing will change) I do not have skepticism about what you refer to, i do not even think what you refer to is wrong for the stuff it is intended for, i am just not referring to the same stuff you do.

badsectoracula 5y ago

> But it still requires developers to use a new API. So why get them to used a half arsed security enclave when you can design a proper secrets store instead? Because the entire point of this is NOT to store something but to transfer something from one application to another without both applications explicitly knowing about each other (so they can't just communicate in a P2P fashion). The rest of your message is about storing data, which is not what the clipboard use is all about. Which is why i wrote it is irrelevant - you refer to something else. E.g. > clipboards are temporary which means you need to copy data into them. This creates an extra step for users to follow as opposed to applications querying the secrets store directly The API i mention is not about permanently storing data, it is explicitly about having a secure temporary store with the same(ish) UX as a clipboard but for secure data. Applications can also use a secure store for that and the data that is being copied to the secure clipboard could also come from an application that stores its own data to it from there, but again this is a separate issue, this is orthogonal to what a discuss here. > secrets managers are encrypted, clipboard isn’t This is irrelevant as the data isn't stored elsewhere outside the memory of the process that would manage the secure clipboard's functionality (and of course you could encrypt that if you'd like but IMO that'd be pointless since it'd need to be decrypted at some point anyway and these would be meant for temporary storage - regardless of you do or not encrypt it though it'd be again orthogonal to the rest of what i describe). > secrets managers can store multiple secrets, a clipboard cannot. Thus you then still need to have a secrets manager to copy your password into the clipboard anyway. So why not do away with that middleman entirely? Because this isn't about storage. > if you’re going to introduce a new API for secrets then you might as well do it properly from the outset. That'd be a "proper" solution for a different problem, hence barely a solution at all.

deleted 5y ago
[deleted]
laumars 5y ago
I get that you’re not storing something long term, but you are still storing it even if it is short term and thus presenting a risk. And you are still sharing secrets between applications thus presenting a risk. And all your suggestion is doing is offering a kludge around a solution you’ve already said is crappy, rather than switching to a robust and battle tested solution that literally every other platform already supports. If you want to pass secrets securely between applications then you use a secrets manager. It’s how Linux and macOS work. It’s how secure systems in the cloud works. And thus it makes complete sense for Windows to follow suit. We aren’t talking about some theoretical concept here. It is absolutely how passing secrets between applications should be done. If you have scepticism about this approach then you need to read up in this topic rather than pushing for a half baked kludge around something you’ve already acknowledged isn’t fit for security. Sorry if this sounds blunt but this is a solved problem you’re trying to re-engineer and your solution is worse than the industry standard in a number of ways which I’ve already highlighted. And ironically it isn’t even just worse for security but also worse for usability well (you’re creating administrative overhead with the user approving safe applications. This wouldn’t be needed with a secrets manager since each application only has visibility of its own enclave). And if you remember back to your first post, usability was the entire reason you designed this solution in the first place.
- badsectoracula 5y ago
  I do not know why you mention Windows, i never referred to any specific platform (you mention Linux, Linux does not actually have what you describe because Linux is a kernel and what you describe is something that would live on the userland - the userland heavily relies on what software is installed and many setups, like mine, do not have such a thing). What i refer is how to provide a more secure approach to to THE SAME THING that people are already doing with clipboard copy/paste without breaking the versatility of the clipboard, workflows or even existing applications and can be supported with minimal changes in existing applications and pretty much zero re-learning by users. It is about being able to copy/paste stuff securely anything that can already be copy/pasted between applications and not just passwords or other stuff you'd need to store permanently. It can even be made to work in a backwards compatible way - with some additional though minimal effort from the user - for applications that do not support the functionality. What you refer to is having a different workflow, have applications add explicit support for the specific data mentioned and be accessed in a different way and up to the last reply you were referring to permanent storage. You ask people to change how they use software, i ask them to use a different menu option for sensitive stuff. What exactly do you think is the more likely to happen? (well, assuming anything would happen, in practice most likely nothing will change) I do not have skepticism about what you refer to, i do not even think what you refer to is wrong for the stuff it is intended for, i am just not referring to the same stuff you do.