Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Shared password security - design flaw #2495
For shared password, if I understand well, the key used to encrypt passwords is splitted between a part of a key in a file and the other part stored in the database, am I correct ?
Am I correct if I say that Teampass dont use user password to encrypt or decrypt shared password ?
If so, if I gain access to the teampass interface bypassing the authentication, can I see the shared secret of a user without needing his password for deciphering purpose ?
Does password of differents roles are encrypted with differents keys ? If I can bypass the role security mecanism, can I access other shared secret that I'm not allowed to normally see ?
Other question but related :
Is it safe to backup on the same server the database (dump) and the teampass files ?
If someone gain access to my server with both the webserver and the database, will he be able to decipher every shared password of the database ?
I will try to answer the best I can hopping I have correctly understood your points.
1- Shared passwords (i.e. passwords that are not in a personal folder) are encrypted using a saltkey stored in a file that requires to be stored outside the www domain of your server.
2- Yes this is true
3- You cannot be logged if not correctly authenticated in Teampass. But if you stole a user credentials and MFA then you will be logged as the user itself. In such you have access to all shared passwords this user has access to. But you will not see his personal ones as they require the personal saltkey to be decrypted.
4- No and Yes. Teampass manages 2 kinds of passwords. The shared and personal ones.
5- This is security strategy related. It is recommend to not keep backups of sensitive data on the same environment as the Production one. This not only for hacking issue but also in case of server damage.
6- If someone get global control of your server, then yes this could be dramatic. This is why it is important to adopt the most secured practices for your server protection and also for user authentication with at least MFA enabled.
If other questions, don't hesitate.
My question is the following, if a there is a security issue, and a hacker find a way to connect to a user account without having the user password, will he see the shared secret ?
referenced this issue
Dec 9, 2018
To get a step forward,
I have the impression that shared password on TeamPass does not offer any cryptographic security, since :
On the server side :
On the client side :
I'm right about those statement ?
If so, do you intend to mitigate those problem and how ?
or this design and this level of security is the one you provide, and you don't intend to change it ?
Of course Teampass offers a cryptographic security.
If a derivation of the user password to the server key for shared encrypted data is existing, I would be pleased to learn about it, but yet I never found such. I would be pleased to implement of course such mitigation counter-measures.
If you are not sure about the ability to protect the server, only use "personal data" as its encryption relies on the user seckey. But in such condition this is not possible to share the data between several users and unless they are using a common key.But in such case, you reduce your security as if several users are knowing a key then for sure one day, one of those will write it in an insecure place and someone could steel it.
The server getting hack is one case, but password are also not protected If there is a security issue in teampass. for example a problem on authentication or role assignement. As I say, the security does not rely on the key, but only on the fact that the software does not have security issues (and all software have bugs...)
passbolt, passit, psono are example of software where the server has no way to access shared secrets.
added a commit
Dec 24, 2018
referenced this issue
Dec 24, 2018
I agree to ixeft. The derived key is a way to avoid losing everything if one take backup for both web server & database... Here is a good open source project with derived key .
Exemple of implementation : Passbolt, passit, psono !
A CVE as been opened for this issue : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1000001
This issue should be reopened
Why to open this CVE without warning me?
You need to provide the weakness that lead to authentication problem or whatever. Otherwise most software in the world are also unsafe. Opening a CVE has to be argumented with facts and proves. Here I don't see any thing like this.
The usage of a master key has never been hidden.
I'm not an expert of asymetric protocol, but I really don't see how to share a password with a team using such technology. Indeed asymetric protocol would require to encrypt the password with every team member public key. Perhaps I am wrong but in this case, I would like you to provide technical explanations if you don't mind.
I'm sorry but you didn't answer my question otherwise than saying «That is the current design» and said, if it is not safe enough for you, don't use it. Your software is called TeamPass, so the shared functionality should be considered as secured.
After that you quickly closed the issue before the discussion was over. As people from awesome-selfhosted made me realize, If I discover a weakness, I have the responsability to report it. I warned you about the problems here, but you were not taking them into consideration.
This problem is a major security design flow and I reported it, as it.
You don't need user password to unlock the master key of shared password, so if you can bypass the password verification, all shared password are recoverable. That is a weakness.
exemple of security model : https://passit.io/security-model/
For any security issue, you should contact by email so that we can have a discussion on an action plan.
You can't say I didn't contacted you. Since this is a design flaw and not a direct vulnerability, It didn't seamed to me that it was necessary to keep that secret, maybe I was wrong. I'm sorry for that. The reason I made this CVE is also because you didn't seams to realize what is the situation and didn't answered my questions.
About making a plan: I have, with other folks that looked at the code and design enough knowledge in security and cryptography to see the design flaw. But I would not rely on myself (as for today) to build a good security flow, just because it is not my main area of expertise. I try to stay realistic about my own abilities. Also, to be perfectly honest with you, since I don't use TeamPass anymore, I don't have a particular interest to get involved in development.
I advice you to get in touch with security and cryptography experts to discuss about a good design for shared password if you cannot do it yourself.
Please Reopen this issue.
OK I just want to make things clearer.
So I spent last 3 days, reading and learning about "encryption for multiple users context" and found a new "encryption model" that I will have to implement. It is based upon the one used by ownCloud which is a tool that is working with the same encryption context.
THis model relies on users public/private keys that are used to encrypt/decrypt a personal item key used to encrypt the password. It is quite smart and efficiant, with a high level of security.
I have tested successfully on Teampass and works without too much impact on performance.
I will first implement this on Teampass version 3 which will soon be in beta. It will permit me to do complete test.
This is a nice evolution and finally quite happy to have been able to found such a good evolution for Teampass.
I understand your point and I'm sorry that this CVE is putting this much pressure on your shoulder.
About the encryption model, you should put precisions on which action are made server side an which are made client side, that change a lot about the security of the whole model
All this model is performed on the server-side.
This change has a big impact on the way to handle the migration. But anyhow I will perform it.