Hi all,

Somecustomers asked me in the past if there was any API toverify if a password meets Windowscomplexity requirements. Unfortunately there is no such API. We could implement our own if we know the requirements of the password filter used in our machines.

The default password filter (passfilt.dll) in Windows checks for the following:

1) Not contain significant portions of the user's account name or full name.
2) Be at least six characters in length.
3) Contain characters from three of the following four categories:
a) English uppercase characters (A through Z).
b) English lowercase characters (a through z).
c) Base 10 digits (0 through 9).
d) Non-alphabetic characters (for example, !, $, #, %).

See the following articles for details:

Passwords must meet complexity requirements of the installed password filter (Windows 2000)

Passwords must meet complexity requirements (Windows Server 2003)

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

Hi all,

If you read CryptAcquireContext documentation, you'll see that setting pszContainer to NULL allow us to use a default key container.

Microsoft recommends that every application creates its own key container instead of the default one, because key containers can only contain one key or key pair for each key type. That is, it can have one session key, or one public-private key pair. If two or more apps use the default key container, and each stores a key pair there, the last app to write the keys overwrites the previous keys. If the other app has already encrypted data with the previous keys, the data is lost because the overwritten keys are not recoverable. A reasonable key container naming scheme would include your company name, product name, and possibly a version or incremented counter as a serial number. An alternative to this scheme would be togenerate a GUID and use it as key container name. Just don't lose the GUID so that you don't lose the location of your keys!

To obtain a GUID for your app you may i.e.use UUIDGEN.EXE tool (included in Platform SDK or Visual Studio Tools) or use the API (CoCreateGuid, UuidCreate).

More info here: CryptAcquireContext() use and troubleshooting.

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

Hi all,

When we try to access a key container, CryptAcquireContext may return NTE_BAD_KEYSET (or error # 0x80090016 or -2146893802 or "Keyset does not exist") for the following two reasons:

1) key container doesn't exist. You may repeat the call to CryptAcquireContext, but this time using CRYPT_NEWKEYSET flag to create a new key container.

2) user doesn't have permission to open the key container. If you need to find out where the key container is in order to set additional permissions, this post may help: Key Containers: Basics.

Let's imagine for a sec that we are already calling CryptAcquireContext with CRYPT_NEWKEYSETflag after the first call to CryptAcquireContext fails with error NTE_BAD_KEYSET, and this second call fails with error NTE_EXISTS (or error # 0x8009000F or -2146893809 or "Object already exists").First we try to open the container and we fail, then we try to create it and it already exists. NTE_BAD_KEYSET means in this casethat the user doesn't have permissions to open the key container, and not that it doesn't exist.

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

Hi all, welcome back,

The following .NET 2.0sample shows how to get security info from a folder to find out the permissions for users/groups on it:

using System;

using System.IO;

using System.Security.AccessControl;

using System.Security.Principal;

namespace ConsoleApplication1

{

    class Program

    {

        static void Main(string[] args)

        {

            // Variables

            //

            string strFolderPath = "";

            DirectoryInfo dirInfo = null;

            DirectorySecurity dirSec = null;

            int i = 0;
            try

            {

                // Read the path to the directory

                //

                do

                {

                    Console.Write("Enter existing directory > ");

                    strFolderPath = Console.ReadLine();

                } while (!Directory.Exists(strFolderPath));
                // Get the ACL of the directory

                //

                dirInfo = new DirectoryInfo(strFolderPath);

                dirSec = dirInfo.GetAccessControl();
                // Show the ACEs of the ACL

                //

                i = 0;

                foreach (FileSystemAccessRule rule in dirSec.GetAccessRules(true, true, typeof(NTAccount)))

                {

                    Console.WriteLine("[{0}] - Rule {1} {2} access to {3}",

                    i++,

                    rule.AccessControlType == AccessControlType.Allow ? "grants" : "denies",

                    rule.FileSystemRights,

                    rule.IdentityReference.ToString());

                }

            }

            catch (Exception ex)

            {

                Console.Write("EXCEPTION: ");

                Console.WriteLine(ex.Message);

            }

            Console.WriteLine("\n<

>");

            Console.Read();

        }

    }

}

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

Hi all, welcome back,

CryptAcquireContext API will fail with error #2 or ERROR_FILE_NOT_FOUND if:

1) the user's profile is not loaded, as we saw in my post RSACryptoServiceProvider fails when used with ASP.NET.

2) AppData registry value in the following registry key is not present or is misconfigured:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

As we saw in the other post I mentioned above, private keys are protected by DPAPI (Data Protection API).DPAPI needs to find the Application Data directory where the Master Key is stored. DPAPI willread the directory from AppData value and will use the Master Key to protect CryptoAPI private keys or EFS private keys, for instance.

Note that similar errors may occur for the same reasons:

1. CryptProtectData API fails with ERROR_FILE_NOT_FOUND.

2. Encrypting a file/folder with EFS via Windows Explorer fails with "The system cannot find the file file specified".

Note that Security Bulletin MS04-011 changed the registry key where the path could be found. Previous one was in here:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

I hope this helps.

Regards,

Alex (Alejandro Campos Magencio)