Vault Security - Not So Good?

[mattatmilsoft]

We're in the process of evaluating Vault, and I want to make the repository available to one of our developers who works off-site. But several things concern me:

• 1) Password security seems minimal: there is no way to limit number of connect attempts, no way to enforce password length, age, etc.
  
  2) Encryption seems optional: I've read no information about encryption during transport other than the SSL option (which we don't have, and aren't planning to pay for).

So if I were going to make myself a rule about security in the current version of Vault, It might be:

"While Vault allows connections by remote users, I shouldn't use this feature. Instead, I should have remote users connect to my intranet (probably via a VPN) when they want to access Vault."

But I may be basing my conclusions on misinformation. Vault may have a whole host of security features that I'm not aware of, and my source code may not be flying plaintext across the aether. If this is the case, please enlighten me.

Matt Lowe

[lbauer]

We continue to add enhancements to Vault security. For instance, in Vault 2.0.4, we implemented a login delay when a user fails to login on consecutive attempts.

Some discussions of security and suggestions for limiting access are in these forum posts:

http://support.sourcegear.com/viewtopic.php?t=1133
http://support.sourcegear.com/viewtopic.php?t=308

[GregM]

Encryption seems optional: I've read no information about encryption during transport other than the SSL option (which we don't have, and aren't planning to pay for).

I'm not sure what option you're talking about paying for, but yes, it will use SSL if you enable it. There isn't an additional option that you have to pay for, unless you're referring to paying for an SSL certificate.

[ericsink]

We're in the process of evaluating Vault, and I want to make the repository available to one of our developers who works off-site. But several things concern me:

• 1) Password security seems minimal: there is no way to limit number of connect attempts, no way to enforce password length, age, etc.
  
  2) Encryption seems optional: I've read no information about encryption during transport other than the SSL option (which we don't have, and aren't planning to pay for).

So if I were going to make myself a rule about security in the current version of Vault, It might be:

"While Vault allows connections by remote users, I shouldn't use this feature. Instead, I should have remote users connect to my intranet (probably via a VPN) when they want to access Vault."

But I may be basing my conclusions on misinformation. Vault may have a whole host of security features that I'm not aware of, and my source code may not be flying plaintext across the aether. If this is the case, please enlighten me.

Matt Lowe

We do need more in the area of password features. In the 2.0.4 release we did implement defense against a dictionary attack (delays after a defined number of failed logins). But we still don't have features to manage password age and length, as you mention.

Since the Vault server runs under IIS, Vault relies on IIS for encryption, through SSL. In our opinion, this is not a weakness in our product, but rather, a conscious choice to use a widely deployed architecture for encryption.

Purchasing an SSL certificate is optional. You can do so, but many Vault sites use a self-signed certificate. SSL certs signed by a CA are primarily designed to for situations where clients may have reason to doubt the identity of the server (such as when people who are about to type their credit card number). In a situation like Vault, it isn't really necessary.

Anyway, SSL is a great solution, and we're quite happy with it. If you don't like the idea, I'd like to hear more of your concerns.

[mattatmilsoft]

Yes, paying for a signed certificate is what I meant when I wrote about "paying for SSL."

Purchasing an SSL certificate is optional. You can do so, but many Vault sites use a self-signed certificate. SSL certs signed by a CA are primarily designed to for situations where clients may have reason to doubt the identity of the server (such as when people who are about to type their credit card number). In a situation like Vault, it isn't really necessary.

Now I understand your reasoning.

If I'm not worried about sophisticated attacks, I should use a self-signed certificate, which gives us encryption but bypasses the cost of getting a certificate signed by a CA.

If I am worried about sophisticated attacks, I should be willing to pay for the certificate signed by a CA, and this will prevent nasty things like man-in-the-middle attacks.

This makes sense. Thanks for your help.
(Eric, I'd like to ask you another question, but I'll put it in a new thread.)

Matt Lowe

[dan]

...my source code may not be flying plaintext across the aether.

Another thing to note here is that even if you are not using SSL, the source code is never sent in plaintext. It is compressed and sent via a delta algorithm (a delta from a previous baseline, or from an empty file if there is no baseline). This can be easily decoded of course if you know the algorithm, but it isn't plaintext.

[sterwill]

It should be noted that a third-party CA doesn't prevent man-in-the-middle attacks. A correct chain of certificate trust does. An administrator can buy a certificate from a CA; the client machines have a hard-coded trust for certs signed by the CA. It's almost as easy (and, in my opinion, more secure) for an administrator to enable SSL on the server, sign his own key, export the public key to a file, distribute that file to the Vault client computers through some trusted channel (CD, floppy, VPN), and have the clients manually trust that key. The chain of trust is established both ways.