Contrary to earlier reports which have since been corrected on this Blog there is not a security vulnerability in Microsoft Dynamics GP. Further detail can be found on this blog site http://blogs.msdn.com/gp/
We’ve had some questions today about how the Dynamics GP System Application Password is stored within the database, and whether that method is sufficiently secure. Let’s take a look and clear up any misconceptions about the safety and security of the business application data. The Microsoft Dynamics GP application provides a very clear and complete security model in conjunction with SQL Server. The biggest risks to any SQL Server or database, regardless of its content, are improper management of the SQL Server system account password and inappropriate management of Windows Authenticated user accounts. Following good password- and account-management standards is the best way to protect any SQL server or database system from harm.
While it is true that behind the successful passing and validation of the Dynamics GP System Password, you can get to things such as User Account Creation, Security Task/Roles and other application-based setup items, you have to be a validated user already logged into Dynamics GP in order to take advantage of those features. The ability to simply translate a single stored piece of data using a custom database function that you wrote is not available to a standard Dynamics GP user and would require a higher level of access to the SQL Server itself (at least dbo level or higher) to create and execute the custom function.
Stepping back to take a look at the bigger picture, there are two different and separated levels of security that are applied and used within Dynamics GP. The first level of security is at the SQL Server itself. Because the Dynamics GP application does not use Windows Authenticated accounts to gain access to the SQL Server — a Dynamics GP login can’t be used to log into SQL Server directly, in other words — any attempt to gain access to that business application data using that access model will not be successful, unless the SQL Administrator were to specifically grant access to the SQL Server and then to the databases themselves.
The Dynamics GP access method to the SQL Server is based on SQL Login accounts. These user accounts are typically created within Dynamics GP. In order to create these types of accounts, the user must be logged into Dynamics GP using the SQL Server system account, or a separate SQL Login account that possesses the appropriate SQL Server permissions, to create SQL Logins and grant access to database roles. So why would the newly created Dynamics GP user account be granted access to the Dynamics database at creation? There are, in fact, specific and secure reasons.
When creating a user account within Dynamics GP, not only do you need to have the correct SQL Server permissions to take such an action, the Dynamics GP application takes advantage of the SQL Server password enforcement policies. These password policies, if enforced on the customer’s domain, enforce rules for password expiration, password strength (which includes required characters, length and/or blank passwords) and changing next password on login. So as an administrator with the appropriate access to the SQL Server, an administrator can create the appropriate Dynamics GP user accounts and also provide a password for those users.
When the user accounts are created within Dynamics GP, the password entered in the Create User window passes through two levels of encryption. The first level of encryption is the Dynamics GP encryption algorithm ( it should be noted, the substitution -cipher method is not used), and is encrypted through our Dexterity runtime engine — not the business application code. When a user account is created at the SQL Server level, the password then goes through an additional password encryption. This user account password is only stored in the SQL server and not within the Dynamics GP related databases.
If a SQL Server Administrator chooses to create the Dynamics GP SQL logins outside of the application (which is an available option but not recommended), the user account passwords will only contain the SQL Server level of encryption. If the SQL Server Administrator chooses that option they are indeed putting their SQL data at risk, because this account can be used to gain access to the SQL Server (outside of Dynamics GP) and the appropriate databases would be available through any type of ODBC or .Net connection. This would be an area of concern that should be closely monitored and considered a security risk.
That said, if user accounts are created outside of Dynamics GP, the application is aware of and can detect what we would call “invalid” password states, which occur whenever an externally created SQL user account might be used to login into Dynamics GP. During the login process for Dynamics GP, the application detects if the password that was entered by the end user is “blank” or “plain text,” which translates to “accounts created in SQL Server only” or prior to Dynamics GP 9.0. If this situation is detected, the end user is immediately prompted with a Change User Password dialogue box and is forced to reset their password. By doing so, Dynamics GP places its own security encryption on the password and then sends the change down to SQL Server for updating. Using this method keeps the access to the business data secure and intact from access outside of Dynamics GP. In addition, because of the double encryption that takes place at the password reset, you are no longer able to use a Dynamics GP user account to create a connection to the SQL Server.]
The second level of security applied and used is the application security setup and, specifically, the business application setup that is required within Dynamics GP. The primary design behind this setup is to allow:
1. A separation of duties and administration between the SQL Server and Dynamics GP application (if required by company policy)
2. Administration capability for a single person or team
This design can provide business application administrators – the people who manage Dynamics GP –with the capabilities to create application users, grant access to company databases and build/maintain the access to Dynamics GP application modules, functional windows and reports that are contained within the application without having to involve the SQL Server Administrator in those tasks. In order to administer these features and functions while keeping the functions separate from the rest of the application, an Application System Password is required. The intent behind this System Password was never to provide true data encryption services, but to provide the ability to lock down the Dynamics GP setup and configuration options. Because of this, the password isn’t using the strongest encryption method available — and if the password were to be compromised, it would offer no access to the SQL Server or to a Dynamics GP user account.
So in order to be a threat, a would-be attacker would have to first gain access to the SQL Server with the appropriate security access, and have access to the Dynamics database, and have the ability to create the user defined function — just to crack the Dynamics GP System password. After assessing all of these requirements, the issue paints a picture of larger security issue in managing the SQL Server than the simple encryption algorithm used on the application system password.
Thanks for listening!
The Dynamics GP Team