VSS Password Guidelines

A customer recently asked, “In most VSS articles, the recommendation is for the VSS password to match the domain password. In short, since the VSS users database is (a) difficult to secure from VSS users, and (b) passwords are stored plain-text, I wondered if this is really a good idea. “ 

This query prompted me to generate the following password guidelines for VSS.  If you have other suggestions, please add a comment. I am not a security expert, by any means. Also, Andrew provides a great primer on Safe Computing that is a must-read.

SourceSafe Password Guidelines

1.      Don't use the same computer password twice.  Your domain password should differ from your VSS password.

2.      Include one number and one character in your password.

3.      Don't leave your passwords on a post-it on your monitor.

4.      Be paranoid.

5.      Change passwords for the guest and Admin users as soon as you create a new VSS database.

6.      Don't forget the Admin user's password...ever.

7.      Strictly limit access to the Admin user's password.  One Admin is safest.  Two Admins is wise (see Rule #4).  Three Admins is neither safe nor wise.

8.      Write your password down in at least two places...in case you lose one of them or forget where it is.

9.      Don't send your password by email, IM, or pigeon. Most pigeons have links to sophisticated underworld crime syndicates. If you don’t believe this, go rent Ghost Dog: The Way of the Samurai.

If your network is secure, your SourceSafe databases are secure as well.  In Avoiding the VSS Login Prompt, I warned that, “team members should be FORBIDDEN to use the same password in VSS as they do for their network account since anyone with administrative access to the VSS database can obtain it.“  This statement is true, but only partially so.  It’s partially true because VSS Passwords are encrypted.   Nonetheless, a knowledgeable insider with unlimited time can do amazing things.  If in doubt, see rule #4.

For more information about how to optimize the security of your VSS databases, see VSS Security Tip and Introduction to Visual SourceSafe Database Security.

[minor edit on 1/22 at 1310hrs by KorbyP)

This posting is provided "AS IS" with no warranties, and confers no rights.

Comments (30)

  1. I haven’t ever met anyone else who as actually seen Ghost Dog… great movie.

  2. What about password length?

    And shouldn’t number (2) be "Include at least one number and one character in your password"?

  3. runtime says:

    VSS might be safe from intruders, but your data is never safe. I’ve used VSS on a couple projects and the database corrupts itself about once a week, resulting in data loss. No wonder Microsoft does not use VSS internally for its own projects.

  4. Adam Weigert says:

    I use NTFS permissions to secure the user accounts and data.

    I basically have a group for our only VSS database called "default". Only people in their have the rights to use VSS. Of course they could come in and wipe out the database easily but its a manner of inner-trust.

    The way I secure the user accounts it that I give only the user who is supposed to login to that account access to their USER directory. I do not use passwords since I use NTFS security.

    I am pretty sure this was the recommended method for creating a team environment in VSS.

  5. The VSS development team’s databases (and my documentation database) are all set up like Adam’s. An individual user can associate a VSS password with their domain name-derived VSS username if they want, but doing so is not required.

  6. Mike Perrin says:

    ….if you have VSS Admin, Tools/Options "Use network name for automatic user log in" selected (which is the default), and the name of the currently logged on user matches the name in soucesafe, then VSS doesn’t use the password at all…!

  7. Yo runtime,

    1) You can prevent and/or identify and fix data corruption issues in your SourceSafe database by running the Analyze utility. I posted a script that automates the process in http://blogs.msdn.com/korbyp/archive/2003/07/16/54063.aspx.

    2)The SourceSafe team has and I am told will continue to hunt down and eliminate or mitigate data corruption issues. I apologize for any inconvenience you may have experienced in the past and assure you that your concerns are being heard.

    For the record, This blog is provided "AS IS" with no warranties, and confers no rights.

  8. Robert Cowham says:

    In a time of need, the FAQ below allowed me to reset the admin password for a VSS database:


  9. jledgard says:

    I might also suggest using a Password generator. Some versions of windows (server I think) ship with them and you can find a bunch of good ones googling as well.


  10. Louis Parks says:

    Writing a password generator isn’t too tough either. In .NET simply do Guid.NewGuid.ToString()…if need be, cut off a certain length.

  11. anas says:

    i forgot Admin password of VSS

    which is defaul password of VSS Admin

  12. Anas, the default VSS Admin password is an empty string. You probably have a non-empty password for Admin accont and may need to find some way to reset it.

    Anyway, here is my 2c about VSS passwords:

    1) As Korby said, don’t use domain passwords or Windows login passwords for VSS user accounts. VSS does not keep the password in clear text and it doesn’t send it in clear text over the wire either; it stores instead a hash of the password. It is practically impossible to reverse the hash and guess the exact initial password (believe me, I’ve tried :-)). However, I’ve seen cases when users writing VSS automation programs hardcode their passwords in their program sources, or do similar mistakes that could disclose the VSS password and therefore the domain password, too. So, better be safe than sorry, and pick a different passowrd.

    2) It is futile to use complicated schemes in VSS passwords generation (like choosing a guid), so don’t do that. Guids are hard to memorize and will require writing the password on paper (not a good security practice). Besides, a determined hacker or knowledgeable insider could guess an alternate password in seconds. I’d use instead password combinations that are harder to guess with a direct dictionary attack (and not simple words or names, etc).

    3) Being paranoid and keeping the VSS passwords safe is a good practice, but don’t rely on VSS passwords or VSS project rights as security measure for VSS databases. There are tools out there that allow reseting VSS passwords (and if you’re smart you don’t even need a tool). Instead, ALWAYS SECURE VSS DATABASES USING NTFS AND FILE SHARE PERMISSIONS. That’s the only safe way. Don’t give Windows access to a database folder to someone who doesn’t need it.


  13. Takume says:

    We lost the VSS Admin password since the previous colleagues left. Are there any method we can reset the password ? If no .. how we can do the admin tasks?

  14. ecommerce says:

    Thank you so much for this great post  about <a href="http://autofinancing.builtfree.org/ecommerce.html"”>http://autofinancing.builtfree.org/ecommerce.html" title="ecommerce">ecommerce</a> and [URL=http://autofinancing.builtfree.org/ecommerce.html]ecommerce[/URL]

  15. Mothers says:

    Hello, good site and interesting design!

    <a href=" http://xanaxsale.tdfsf.info/xanax-sales.html ">xanax sales</a>
    <a href=" http://tramadolbuy.sauiu.info/tramadol-sales.html ">tramadol sales</a>


Skip to main content