Shared password security - design flaw

[ixeft]

Hello,

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 ?

[nilsteampassnet]

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.

[ixeft]

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.

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 ?

[ixeft]

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 : If you get gain access to the server you can't considers that the password are encrypted, since you are in possession of the key.

On the client side : Since there is no system of key derivation from the user password to server key The security does not relies on a key but on the fact that there is no vulnerability on the software. Which is impossible (for any software).

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 ?

Best regards,

[ixeft]

Dear @nilsteampassnet,

Since I'm talking about a potentially critical design flaw, could you take the time to answer my question ? (But I see you are not working those last days on the project)

Regards, ixeft

[nilsteampassnet]

Of course Teampass offers a cryptographic security. It is ensured through the usage of the seckey. Now as you say, if your hacker takes possession of your server, then your system integrity is corrupted as the hacker can use this key to uncrypt the passwords. This is why it is requested to protect your server against any attacker. Currently most of the system will loose their integrity if an attacker takes its control. The only data that will be safe is the personal data as they are encrypted using a salt given by the user. Taking the postulate that several users need to access the same encrypted data, then they need a shared key to decrypt this data. This is the reason why the main seckey is required. This is only possible from server side. From the client server, there is possibility as the encryption/decryption is performed on the server itself. The seckey is never transfered to client.

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 have any example of products performing this, I would be please to study them.

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.

Greetings

[ixeft]

Now as you say, if your hacker takes possession of your server, then your system integrity is corrupted as the hacker can use this key to uncrypt the passwords. This is why it is requested to protect your server against any attacker.

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...)

If you have any example of products performing this, I would be please to study them.

passbolt, passit, psono are example of software where the server has no way to access shared secrets.

[lennyluosz]

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 . https://doc.syspass.org/en/3.0/application/encryption.html

[ixeft]

I won't say it is a good overall implementation because it is using symmetric keys. If I understood well, when you want ti change the vault key, every user needs to type the new master key :/

assymetric key would be better!

[lennyluosz]

Yes, assymetric key could be better, yet I did not find such kind of open source implementation with GUI.

[ixeft]

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

[nilsteampassnet]

Why to open this CVE without warning me? Usually it always done in a gentle way that consists in warning the developer that a CVE could be open if an action plan is not taken in short term. I don't understand your way to do this, I'm very disappointed. It ruins all my efforts I can do to maintain and improve this projet. And it is really unfair because as explained, this is indicated that a master key exists and needs to be stored. The way you wrote the CVE makes think that it is unsafe, and I totally disagree with your point.

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...)

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. I don't see how a weakness in authentication of teampass could lead to an access to all passwords. There is no link between such failure and symetric key. If you have a weakness in authentication meaning that a user can get connected with someone else account and that he knows his securitykey, then he can also has access to all passwords even with asymetric key. So such weakness is valid for most of software where there is a an authentication.

The usage of a master key has never been hidden. The only quick change at short time is to indicate the risk during installation process. At mid term, it is a full change in the implementation that I could do to change to asymetric key.

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. And what happens when a new user is created, it will be required to re-encrypt all the passwords inside the database which can lead to monstruous resources need. As already mentioned, I'm very open to improvement but please why a CVE in this case.

[ixeft]

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.

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.

This problem is a major security design flow and I reported it, as it. https://cwe.mitre.org/data/definitions/257.html I don't need to provide a zero day vulnerability to report this type of cve.

I don't see how a weakness in authentication of teampass could lead to an access to all passwords. There is no link between such failure and symetric key. If you have a weakness in authentication meaning that a user can get connected with someone else account and that he knows his securitykey, then he can also has access to all passwords even with asymetric key. So such weakness is valid for most of software where there is a an authentication.

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. If the access to shared password is derivated from user password you can't unlock shared password even if you bypass authentication.

exemple of security model : https://passit.io/security-model/

[nilsteampassnet]

For any security issue, you should contact by email so that we can have a discussion on an action plan. This is always the way it is done. You took the example of passbolt and they also have this kind of requirement. So why to open à cve without contacting me by email. Can you please contact me nils@teampass.net so that we can define à plan.

[ixeft]

Hello,

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.

Best Regards.

[lennyluosz]

Passbolt, passit, psono Thanks for sharing. Passbolt, , psono are open source for their community version, and have limited functions. Both have commercial versions. passit seems to have also limit functions from its home page, yet I did not have detailed research...

[nilsteampassnet]

OK I just want to make things clearer. I have never lowered the fact that indeed the current design flow could lead to such behavior. It is known from the start of Teampass. There is a lot of warning regarding the saltkey to be stored save. It is a fact I agree but the point here is that I'm more claiming on the way to proceed to put pressure on me with a CVE. Also saying that I don't take things into serious makes me feel bad when you realize the efforts and sacrifices I do to maintain such a project alone. I don't complain ... but you need to understand that I have to treat tickets, answer questions by email, fix bugs in current branch and in parallel I'm recoding Teampass for more responsive UI (branch 3), and all this I'm doing over nights. So it is difficult. Now I'm a big boy, and let's put this back and I want to make this product safer. So let's go ahead.

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.

I have defined it in next diagram.

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. Then I will implement it on branch 2.

This is a nice evolution and finally quite happy to have been able to found such a good evolution for Teampass.

[ixeft]

I understand your point and I'm sorry that this CVE is putting this much pressure on your shoulder. Please note that I'm adressing problems on the software, not your dedication on the product and I can imagine the quantity of work you putted into it. That great to have dedicated persons in the FOSS community.

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

[nilsteampassnet]

Thank you.

All this model is performed on the server-side. On the client side, I will still rely on AES-256 encryption for data exchange between client<>server.

This change has a big impact on the way to handle the migration. But anyhow I will perform it.