Slashdot Mirror
Microsoft Dynamics GP "Encrypted" Using Caesar Cipher
scribblej writes "Many large companies use Microsoft's Dynamics GP product for accounting, and many of these companies use it to store credit card numbers for billing customers. Turns out these numbers (and anything else in GP) are encrypted only by means of a simple substitution cipher. This includes the master system password, which can be easily selected and decrypted from the GP database by any user. Quoting: '[Y]ou DON'T HAVE TO GIVE ACCESS TO THE DYNAMICS DATABASE. What that means is if you create a base user in GP, that user can log into the SQL server and run a select statement on the table containing the "encrypted" GP System password. Not good.'"
Update: 05/22 02:57 GMT by T : The original linked post has been revised in a few places; significantly, the following has been added as a correction: "By default, GP gives the user access to the DYNAMICS database but the user CANNOT login to the SQL server using SQL Enterprise Manager."
et tu brutus?
#fuckbeta #iamslashdot #dicemustdie
Ohg vg'f jnl zber frpher gung jnl
They should hire some of them "too smart for their own good" Googlers.
"I'm just here to regulate funkiness."
So, this Microsoft product uses what amounts to the same "encryption" that the CVS pserver protocol uses. Hilarious.
Check out my world simulator thingy.
Yeah, but this isn't a security flaw due to an oversight or simple mistake. This is a massive downright idiotic flaw! How the HELL did this make it into a product?
I don't know if this is any news at all. Most ERP systems do not have the data in the database encrypted at all. You should never give any direct access to your ERP database to anybody. If absolutely necessary, just create a view in another DB schema and give a read access to it only to selected users (so they could access for example the inventory information useing excel/access).
I figure that the variation of Caesar Cipher, ROT13, was easy to decipher so for maximum security, I always run it through the ROT13 encoder twice before I send it. Hell, I'm encoding this message in that method now so it will have to take a bit of cunning for you to read this comment. So if you've managed to read this, congratulations, you are qualified to work in Microsoft's security department.
Here's a text only cache of the page.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
Sorry... I didn't expect /. to pick this up, and didn't really warn Chris Kois that I'd submitted it. My fault.
Below is the original article:
I use the term "encryption" loosely in this article. As you read on, you'll realize why...
I've been doing some work on a plugin for Microsoft Dynamics GP, which is an accounting system aimed at Medium sized to Large businesses. To give you an idea of what type of application this is: There are companies that pay somewhere around $10,000-$15,000 to consultants or VARS (Value Added Resellers) to implement a Microsoft Dynamics GP solution for their business. Many of the VARs have their own plugins and solutions for Microsoft Dynamics GP, usually written in .NET or Dexterity. The process of installing and maintaining GP is an industry all it's own and it's not cheap for a company to maintain this accounting system.
I've been searching for the "encryption algorithm" or at least some way other way to "encrypt" data in GP in some other way than within Dexterity code. I was really hoping that there would be some .NET library that would do this for me, but I was never able to find anything that would help me do this. So, I became interested in what type of "encryption" this is. Somewhere (I can't remember where) I found something that indicated that the it's a symmetric key encryption algorithm. The message boards were not much help either. Anywhere I went, I basically saw this same type of statement, "the encryption algorithm is a closely guarded secret".
Today, while doing some testing, I noticed something with data that we were saving to a field which utilizes the GP "encryption". The plugin I was testing puts data in an encrypted field (not that it needs to because it's not sensitive in nature), and I was testing with the same values each time. As I would expect, I saw the same data stored in the field in the database for each row in the table. However, I noticed that one of the entries was different, by 2 characters. That seemed very odd to me. After looking at it some more and conducting some more tests, it looks like I simply miskeyed my test data, but it prompted me to take another look at this.
After trying a couple different combinations of test data, it became very obvious that changing only one character in the test data appeared to only alter 2 characters of the encrypted data. So I ran through a battery of tests, and came up with this:
Yep, it's basically your run-of-the-mill Substitution cipher. The worst part, there's evidence all over the place that this was a VERY weak encryption algorithm for awhile, but nobody seemed to pay any attention to it when people were asking how they could reset passwords of users in the database (Post 1 - Post 2)
I did some more searching, because there is ABSOLUTELY NO WAY THAT I AM THE ONLY ONE THAT SAW THIS... I found a good write up on the MSDN blogs that explains pretty well how the GP encryption was used (here).
The article is evidence to support a theory that I have, which is after GP moved to SQL server authentication, the encryption method didn't seem to be needed any longer so they never replaced. I don't know if the word was released to developers and integrators that the "encryption algorithm" wasn't ideal for storage of sensitive information, but I don't know how many plugins or customizations use it either.
EXCEPT.... Microsoft still uses it for their GP system password, which is the password needed to get to the Security Roles/Tasks and all the User Security related forms while in GP. What's even worse, if you create a new user, you have to give the user explicit rights to the company or companies you want the user to access, but you DON'T HAVE TO GIVE ACCESS TO THE DYNAMICS DATABASE. What that means is if you create a base user in GP, that user can log into the SQL server and run a select statement on the table containing the "encrypted" GP System password... Not good...
I created a
Not that long ago, competent security was a criminal offense to export. It still is, unless the code is Open Source (and we all know how Microsoft loves Open Source). The practical difference between a Caesar cipher and DES is that the Caesar cipher is faster so more transactions can be performed. You could do more leaving things in plain-text, but regulations usually require encryption of some sort for this kind of data. However, those same regulations don't usually stipulate any particular strength of encryption, so Caesar becomes ideal. The high throughput will sell better and the absence of security means it evades export controls. You end up with the largest possible market.
If there was a recognized, official (or even semi-official) standard API and ABI for cryptography libraries, ITAR would be less of an issue. You could swap out any crypto library in any product and swap in an alternative. You could then use any crypto library (and therefore any crypto algorithm) you liked.
If standards better-mandated what level of security was required, weak algorithms would never be used. No corporation would dare risk the penalties and so no vendor would dare supply soft crypto.
The market's preference for high throughput is perfectly reasonable, but it is often unwilling to invest in security - which is why there are so many issues of this kind. If corporations were more willing to invest in securing their systems, say by using hardware crypto engines to get the high throughput they needed, they would be able to use essentially bullet-proof algorithms without harming the amount of data they could manage.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
And storing credit card details in this way is in direct violation of the PCI-DSS which as a merchant the companies will have attested that they are in compliance with. If they get caught or worse leak data then there are severe financial penalties.
Heytay areway oinggay otay useway Igpay Atinlay!
Whether the folks at Microsoft wrote this themselves, or whether they instead paid $1.1 billion for this software 9 years ago it is still pretty much the same thing. Either way this makes the folks at Microsoft look like amateurs. This is precisely the sort of thing that only closed source proprietary software can get away with.
Whoever coded the "encryption" routine really dropped the ball. SQL Server supports AES encryption on individual fields. The first result of a Google search for "sql server field encryption" points to an MSDN article with code examples of how to use AES-256 encryption.
How do these things keep happening? There have to be mistakes on so many levels. Whoever developed the spec obviously was clueless. The person who coded the spec was probably clueless, and/or didn't have the authority to do things the right way. The tools to make these applications secure are available. You'd think that a Microsoft coder using a Microsoft database could use the Microsoft solution properly.
The more I deal with corporate America and the people who find themselves in charge of projects, the more I believe that competence really is a Bell curve with the center of the curve being INCOMPETENT, the far left is DISABLED. How do these people sleep at night? The only thing that I can figure is that they really are ignorant. If I do something half assed, it bugs me. It keeps me up at night. So either these people just don't give a rats ass and are working in a culture that lacks accountability, or they are completely ignorant and are working in a culture that lacks accountability. A friend of mine once told me, "Most people don't do the right thing because it is the right thing. They do the right thing because they fear the consequences of getting caught doing the wrong thing." Every where I look in society, there are fewer and fewer consequences.
I have the displeasure of working with Great Plains regularly, and this isn't surprising at all.
A couple of points for the panic stricken:
1. Great Plains uses SQL logins and it hashes the passwords of users created from within GP. Since 9.0, it salts this hash using the sql server name. A GP user other than sa can NOT login to SQL Enterprise Manager with their GP credentials. That encryption has NOT been broken (yet). (That WOULD be a real problem.)
2. The ability to decrypt the System password is useless if you can't query the system password from the database. If your users have the ability to query any table in the database directly, then you have a bigger problem than weak encryption.
3. GP overlays role and task based security on top of the SQL login mechanism. Having the decrypted System Password is less useful if your application user doesn't have the ability to reach the User Setup or Security Options menus. These menus should be turned off for everyone not in the GP PowerUser role.
Is this great for GP? No. Neither is it the harbinger of the apocalypse.
-ellie