The encryption used is AES Cypher with Rijndael algorithm. AES is a ‘symmetric block cipher’ for encrypting texts which can be decrypted with the original encryption key. Each encryption is done using 256bits.
AES means Advanced Encryption Standard. Noticed that AES, based on the Rijndael algorithm, is the tightest security currently available (approved by the US government for classified information up to ‘Secret’ – and in in 192 or 256 key lengths, up to ‘Top Secret’). AES was adopted by NIST in 2001 as FIPS-197, and is the replacement for DES which was withdrawn in 2005.
Encryption in TeamPass is done on 2 levels.
First level consists in encrypting every transaction between the user’s computer and the server. So when a POST query is sent to the server and back to the user, the data posted is previously encrypted.
Second level consists in encrypting the data in the Database. So before saving in Database, data is previously encrypted.
As a result, the exchanges between the user and the server are secured, and the data stored in the Database are secured.
The encryption uses 2 keys.
For Database encryption, it uses a SALT key given by the administrator of TeamPass. Once some data have been encrypted, it can’t be changed any more. Indeed this SALT is the key for encrypt/decrypt the data.
For Exchange encryption, it uses a unique KEY generated automatically when User gets logged to TeamPass. This KEY is stored in a Session variable. If this key is broken and changes during a query, then the results will not be decrypted and an error would occur.
Hi! thanks for such an impresive software. I want to raise some security issues. If I compare you program to lastpass – lastpass uses the user super password for encryption and decription, your program uses the salt for it. So if the server with TeamPass is breaked, the one could find the salt, see how encrtyption, decription ist coded and so without any serious trouble get all real passwords stored in the database. User password is used only for access permissions. Breaking into LastPass server would not damage much, only if the one would brute force all passwords. So security in lastpass seems to be on a higher level. Am I right?
If the user passwords would be used for encryption/decryption it would be not possible to share them:( I think you should work in this direction. I am thinking about two servers solution.
Hi
Yes you’re right in the way that if someone get the SALt key then it is possible to uncrypt all the passwords (this will need time because salt is used with a random key … but once the algorithm understood, it goes fast).
The only passwords the “cracker” could not uncrypt is the users ones because they don’t use the SALT but the users specific salt.
I totally agree with that, but you can’t compare lastpass and teampass. Indeed the first one is dedicated to 1 person and the 2d one to a team.
That means that you can’t rely on several encryption salts because they could not be uncrypted by people other than the creator.
So by default you need a common salt in a multi-users context otherwize no way for correct decryption.
But perhaps don’t I know all the existing strategies … do you know something special that could interest me?
Nils, thanks for quick responce.
As a quick solution I am thinking about is one single salt known by all team members, so if someone breaks into server it would help him much. So every user would have to enter 2 passwords, one for permissions and one for pass encryption. the second one could be exchanged with key file, send to all team members via mail for example. the both solutions should not be hard to implement in your product.
second solution – to serve the unique salt from a second server after the user provided the right password for himself.
third solution (much theoretic) – to find a way of creation a same salt of all users and split it in 2 components: one (the way how) stored in the db for each user, and the second (the engine for using “how” and user password) to code as PHP extension (compiled c++) so no one could understand it. But this would not be open source any more)
Our web agency have to do with a lot of different passwords. The best (secure) solutions actually is keepass with single file for a team or even for a team member + shared network folder or Dropbox. I think if you implement the first proposed solution it would be the best software solution for sharing passwords in team!
Ever worked with LUKS / disk encryption (http://code.google.com/p/cryptsetup/)? The salt used for the disk encryption is encrypted with a password. Several passwords can coexist. A copy of the (different) encrypted salts is saved in the header.
If you limit user / password creation to one user (eg. admin), all users can have their own encrypted salt with their password. The salt is the same one used for encrypting keys in de database that are used by the team. Changing a user password can only be done by the user itself or the admin (an new version of the encrypted salt has to be created). Creating a new salt will result in generating new passwords for all users (and reencrypting the contents in the database).
Maybe this is a feature request, I will post it also in github.
I have to look for such possibility.
Nevertheless, such a big structural change impacts highly the existing DB. SO it has be strongly prepared
Thank you for suggestion … and Github is the good location for storing it.
Hi
Thanks for TeamPass, which is a nice software. However, the fact that the master salt is stored in clear-text on the server is a major drawback. I think I have another solution, close to the first proposal of Alex.
What about ciphering the salt for each user with their permission password ? In this way users have just one password to enter at login and the salt is deciphered and stored in the PHP session until logout.
I think I have missed something about the ciphering of the client/server exchanges. You say that these exchanges are secured by a KEY and that “This KEY is stored in a Session variable on the user’s computer”, however, PHP sessions are stored on the server side. Do you mean that the KEY is sent to the client in a cookie? If this is the case, what about if someone sniff all the traffic between the client and the server? Would it be able to decrypt the passwords sent to the client?
A solution for this last question can be the use of asymmetric keys (RSA for example, where libraries exist both in PHP and JavaScript). The server has a key pair and sends it’s public key to the client. The client generates a key pair and sends it’s public key to the server, ciphered with the server’s public key. The server decipher the client’s public key with it’s private key. Then, the server sends data ciphered with the client’s public and the client sends data ciphered with the server’s public key. If someone sniff the traffic, he is not able to decipher the messages because he has none of the private keys. Note that this technique does not prevent a man-in-the-middle attack, but it’s a more elaborated attack than a simple sniff.
I think TeamPass is one of the best open source solutions on the market, with the exception of the problem for encrypting passwords in the database.
Thank you for those very interesting posts.
1st point, you’ve seen a mistake in my text because of course the session random key is stored on the server side. I’ll correct this issue.
2d point, concerning encryption, my choice was to use AES encryption which I prefer to RSA because I know them best
The encryption in AES is stronger than a similar RSA size of bits encryption, so it uses less time of compilation when sending to server or receiving from server.
I think than you’re main complain comes from the fact that the USer has to enter a 2d salt key in order to encrypt his own items.
My point of view is that if the script uses for example the password of the user to encrypt the USer’s personal item than this is a security hole. Indeed the password is stored in the database (sure not in clear text). The advantage of a 2d salt is that it is not stored … jsut in the brain of user, which remains the best localization
So just to make things clear, 2 cases exist:
1- for common and shared items => usage of the common SALT + random session key
2- for personal items => usage of the personal SALT + random session key
I want to remember you also that if you want the items being deciphered by all users, this salt needs to be common to all users. That’s why the script needs this unique Salt.
I hope things are more clear, and many thanks for your positive comments
It’s been a while I’ve been looking for this kind of software. We often face issues when we have to share some part of our keepass database with some other team, forcing us to split the database and sometimes replicating a part of its content, rendering the password management a nightmare. I think I finally found my holy grail !
Since Stan is mentionning asymetric ciphering, I’d like to add my own salt. Why not using asymetric ciphering to encrypt password in the database.
The idea is to let a user cipher the password he’s entering for all allowed users (including himself).
Major advantages are:
* Improved security:
– No stored SALT anymore so anyone gaining access to the server would only have useless data
– Gaining access to the private key of a user only gives away the passwords he had access to
* Double intervention: Administrators are no God anymore as they need the users entering the password to encode the password for them as well. When an administrator add some user to a role, someone having access to the password have to cipher them for the newcomer. The user doing this could be, for example, a manager of the role.
Major drawbacks are:
* Exponential database usage: think of a database of 1000 password with 100 of users having all access to all passwords. This would lead to 10 000 000 rows to store all passwords. This could be mitigated using only one certificate for each role.
* Relative coding complexity: there are a lot of cases where the passwords have to be recreated: when deleting a user, when changing users in a role, …
About the time issue you’re mentioning, I have to disagree with you. I don’t think time or CPU usage is an issue when speaking about security. Well, at least, in reasonable amount of course …
Hi Nils,
great project, except the SALT thing where already a bug report is open since 11 months.
I am very unhappy to have the salt on a public web server. If there is a security bug in any server component and the server is compromised, every password is open to the attacker.
It is absolutely necessary to implement that the salt is encrypted with the users password and stored in a separate field in the user table, but it will break any external auth, like LDAP. (This is the luks way, as mentioned above)
Btw. it would be nice, if the users password hash would be also saved as a salted SHA-2/3 hash.
If this would be done, I think you deserve way more than one coffee as a donation and I am sure I am not alone with that opinion.
As soon I can afford some time, I take a look in the source and see if I can do something there to help.
Best regards,
Andreas
Hi Andreas,
Thank you for message. You know breaking the existing strategy will have a big impact on the complete source code. Nevertheless I’ve introduce in 2.1.13 the fact that salt can be totally excluded from public part of the server. Indeed you can put where you want on your server which is a big improvement compared to before.
But do not forget that TP uses also a specific table including auto generated keys that reinforce the encryption of passwords. That mean that for each Item, you have an associated unique key stored in table “keys” that is used in the encryption/decryption. So the Salt is not the only key to encrypt a password.
Actually I’m having a big reflection on major changes for 2.2 release. This reflection focuses on 2 aspects: 1st implementing PDO class instead of pure mysql, and 2d new way to manage encryption. Slimm609 (https://github.com/nilsteampassnet/TeamPass/issues/227) opened my eyes on this subject and Your comment goes also in this direction. I’m reading a lot on existing web/DB encryption and I hope I’ll be able to select a new (and good strategy) for encryption. If you have any good web pages on the subject, you’re welcome to send them ;-)
I hope I’ll be able to reach the level of expectation I’ve put on 2.2 release.
Greetings