You, Me and Dynamics GP
I’m starting to get questions on a recent article about Dynamics GP that got picked up by Slashdot. The actual article is at http://www.christopherkois.com/?p=448. Here is the Google cache if the site is down from the Slashdot effect http://webcache.googleusercontent.com/search?q=cache:http://www.christopherkois.com/%3Fp%3D448&hl=en&client=firefox-a&hs=lR&sa=G&rls=org.mozilla:en-US:official&strip=1.
In the article the author claims that Dynamics GP use weak encryption and the system is easily broken. The problem with this article is that much of it is ether flat out wrong or wildly overblown. The author appears to have confused the System password in Dynamics GP with the System Administrator and jumped to a number of conclusions because of it. It’s also clear that he doesn’t understand the function of the System password in Dynamics GP. As the article claims, the System password is not heavily encrypted and this has been commented on by a number of folks. I don’t even use the word encrypted when referring to it, I use the term masked.
The same scenario does NOT apply to the encryption of user logins between GP and SQL. As noted by David Musgrave and referenced in the article, the algorithm was even enhanced for v10 as part of Microsoft’s Trustworthy Computing Initiative. It’s clear to me that the author confused a number of articles and didn’t really understand how they related to Dynamics GP security. (Although David Musgrave’s was really straightforward and well written.)
To set the record straight, here is what you need to know:
1) The System password is an OPTIONAL component of GP security. It is recommended, but it is not a primary layer of defense. If security access isn’t granted to a resource through the application, knowing the system password won’t help you.
2) SQL access is required to use the method described to figure out the System password. The article falsely claims that a basic GP user can get access to the Dynamics DB via SQL. That is simply wrong. A GP login cannot be used to access SQL server directly for any of the supported versions of GP. It can’t be done with their GP password and it can be done with the substitution cipher shown on the website. In some older versions of GP this was an option. It’s not even an option today. The only exception is of course the sa password which is fundamentally a SQL password and designed to work that way.
If you are giving users direct access to SQL you have bigger issues than them getting the system password.
3) A number of people including myself have shown how to reset the system password. It’s even in my upcoming book so it’s not a big secret as the author contends. As I’ve said, it’s an optional component designed as second layer of defense.
I’ve responded on Slashdot and on the author’s post. The author moderates comments and hopefully he is big enough to put my comment through. In case it doesn’t happen or it takes a long time I’ve decided to clarify things with this post.
Feel free to email questions about this to me. Nothing like dealing with someone spreading fear, uncertainty and doubt with false statements to get me worked up on a Friday afternoon.
Update: The author has posted updates clarifying some of these points. Sadly it’s unlikely that Slashdot will pick up the corrections.
Update 2: ComputerWorld picked this up and corrected themselves very quickly. Perhaps now that the original post has been corrected this can die. Kudos to them for the fast correction.
More Updates: Inside Microsoft Dynamics GP has responded as have Mariano Gomez and Steve Endow.
