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."
The weakness of encryption is justified by the non-importance of the asset it protects.
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."
A Microsoft product with security problems? Say it ain't so, Joe!
Living With a Nerd
So, this Microsoft product uses what amounts to the same "encryption" that the CVS pserver protocol uses. Hilarious.
Check out my world simulator thingy.
I wonder how long this security issue has been in Great Plains?
However long it has been, Microsoft really dropped the ball here because that acquisition was nearly ten years ago at this point.
They'll issue a patch next tuesday to improve security the ROT13 way - running data through the algorithm twice.
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?
The old saying: "Anyone can create a security system that they cannot break"
It would be very obvious to me you do not give users access to a application database. Unless it is some BI kind of application. The obfuscation in this database is only to underline this. With normal BI tools you cannot retreive data from the database since it is obfuscated.
You can access a SAP/oracle fusion DB diectly also but a good rule is NEVER TO DO THAT unless it is documented, since it is always unclear what state the tables are in and/or you need to take some extra data for your queries.
And all databases allow to grant access based on user is to a limited set of data, so normal user access controls should also appy.
Having encryption on user data in a database is a bad idea because the key storage is not as simple as you would think, and a lost encrypion key will render the data completely useless (by design!)
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.
That's when PA-DSS takes affect. And PA-DSS applies to any application that stores or transmits cardholder data (credit card number). They require all that information to be stored using "strong encryption", which is defined as either TripleDES with a 168bit Key or AES. Bunch of other rules too for anything web-based. Like for one the database storing the data cannot be connected to the internet. Requires at least 2 servers with your web facing server having 2 nics. One that connects to a DMZ or has access to the internet and the other that connects to a private local network with the database server(s).
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
This product; "Microsoft Dynamics GP" gets a lot of publicity - and since it's mostly unknown to the majority this must mean that the flaw in reality is unimportant and what will happen is that the bug gets corrected and the application gets a lot of free marketing.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
actually, nowadays even microsoft is an oxymoron. They should be renamed Bloatsoft (which is easily shortened to BS).
Whenever in an argument, remember this.
more like beowulf clusterfuck
Heytay areway oinggay otay useway Igpay Atinlay!
This piece of advanced technology obviously came from the cesarean section of their R&D department.
Ezekiel 23:20
Everyone knows that Microsoft outsources their security testing to beta testers and software pirates... you know, the Microsoft Community.
I blame the wicked smart geniuses like Paul Thurrot... he's totally the kind of wise guy who evaluates early MS products, someone who appreciates the finer parts of Microsoft security.
I'm sure he has a prepared excuse for this Microsoft fail, just like he has one for every other MS gaffe.
Where was the much-vaunted Security Development Lifecycle process (http://blogs.msdn.com/sdl/)? I guess the threat model consisted of a six month old baby pounding on a keyboard. The responsible engineer(s), PMs, and VP should be fired.
It's Linux, damnit! Pay no attention to renaming attempts by self-aggrandizing blowhards.
You are more correct than you expected. The encoding algorithm is not a Caesar Cipher algorithm. Going by the code table in the article, Microsoft simply XORs the incoming data with 0xEE. To undo the cipher, XOR again with 0xEE.
Using XOR makes for really easy coding. Instead of having an encryption and decryption function, now only one function will do both.
Going by the code table in the article, the encryption algorithm is not a substitution cipher. Microsoft's algorithm is an XOR with 0xEE. To decrypt, XOR with 0xEE again.
Beowulf is not going to help here. Beowulf is for clustering computational resources. You want to cluster storage resources, something like RAID-Z.
Yeah, kids these days are using rot26 instead. Twice as secure.
Thats a good step, but because of the improvement of computation technology in the last few years, I am am using rot104, which is four times the strength of rot26. I am planning a move to rot208 sometime this year, but it is non-inconsequential with any real volume of data. But the fact is, you need to keep ahead of the curve to insure that the alphabet soup agencies can't read your wow chat logs...
HA! I just wasted some of your bandwidth with a frivolous sig!
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?
Because the claims that Microsoft has good, or even competent, programmers, engineers and managers is at best a myth. That myth has been put to rest many, many years ago, but the marketing, astroturfing, and lobbying firms keep bringing it up again and again. Anyone repeating that is probably on the payroll of one of those firms or so dumb that they should be bitchslapped into next week for opening their mouth.
Seriously, these problems are synonymous with Microsoft and the passivity that allows them to promote bad engineering as acceptable has to stop.
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
So it looks like we have a full assessment of the situation, including an attempted backtrack by the original poster and an statement from someone acting in an official capacity with respect to the software product in question that shows that the original poster has no idea what he is talking about, and it turns out in the end that there is no issue at all here. This is all misguided hysteria and there are no security concerns at all.
Is anybody taking bets on how long it will take the editors of this news forum to issue a retraction and an apology, like any professional journalist who is at least pretending to be ethical would do at this point?
High-end Amigas used the 68040 and 68060 processor - which, IIRC, is quite capable of running Linux.
zlib is ok, but other people use szlib or other compression libraries. Huffmann encoding as a form of compression is block-based, zlib is stream-based. These are essentially also the only two types of encryption, as far as data transfer is concerned.
However, most OS' already have the concept of block devices and stream devices. In the same way that a program that operates on a streamed input and/or streamed output doesn't care what the input and/or output actually is, it shouldn't matter if the device/filter they go through is a crypto channel, a compression channel or the English Channel.
In terms of block encryption, you also need to define the encryption mode used. This, too, is nothing more than a component that has an input pipe and an output pipe. It should be pluggable. There is no logical reason for it not to be. Different block cyphers are defined for different block sizes and may have other specific restrictions and/or specific tunable options besides, but provided the I/O API allows you to use standard calls to interrogate and/or set parameters, and provided standard mechanisms are used to prevent the user from mis-matching options, this should not be a big deal.
This means that existing calls for files, sockets, messages, or what have you, could use pre-existing APIs with minor extensions to defined constants to let you have a completely standardized method of tweaking parameters and getting error codes.
If you'd rather use a library and not overload any pre-existing API, it should not be that difficult to stick to very standard methods.
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)
It doesn't have to be a household name to be important. Dynamics GP is a major player in the small and medium business ERP space so it's actually a big f***ing deal.
Anybody that's ever administered GP will tell you that its security is a complete and utter joke. It's basically non-existent, or "security through obscurity" at best.
All users are granted full access to the data in SQL Server, and security restrictions are implemented entirely in the front-end application. There's no secure application tier whatsoever - just a client application connecting to a database that's being treated as a dumb shared persistence layer. I've used MS Access to create more secure applications than GP. (Little departmental things - nothing major.)
Anybody that you have set up with access to GP thus has the ability to download SQL Server Management Studio, connect to the database server using their GP credentials (it uses SQL Server logins), and carry out all manner of hell.
Finding out that they're also using shitty encryption increases my levels of surprise and disdain by roughly 0%. Any DBA that maintains GP databases will just shrug this off with, "Yeah, you think that's bad? Take a look at this."
All your database are belong to us.
In emacs you can use M-x rot13-region (or rot13-other-window)
Or for those of you who want to make fun of emacs:
C-SPC C-e M-x rot13-region
Okay seriously I've just run out of pointless things to say.
"As the parent mentions, NO USER has DB access in an ERP system. Only the ERP system itself has access and then the ERP system manages all table and transaction access. Can anyone verify this for GP? Also, even if the system password is available to any user created in GP I don't think that matters." As far as Dynamics GP is concerned, all users set up in the system have full read/write access to all tables. The security layer comes from the encryption of the users' passwords by GP for their SQL login. This is done using a strong encryption method, not a caesar cypher. The original poster, I think, caused a bit of a stir here because I think 101 people here are mistaking the "system" password (which is a weak security password for opening certain system windows, of which all of them would be locked down by the normal security in GP anyway), and the 'sa' password, which truly does have "god" powers in the system.
Is it unfair to expect more from the world's largest software company? If we give them millions of dollars each year, and spend millions more training our people on how to use their stuff with best practices and secure it, is it too much to ask that their products be in some way better than the products of the long-haired smelly neckbeards who give us their stuff for free? If we're not getting that for our money, what are we paying them for? To dress well and take the CIO to lunch twice a year?
Help stamp out iliturcy.