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
njdsptpgu tvdlt!
No sigs in BETA. Beta SUCKS.
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).
don't worry it happens all the time thats why i use a specially modified linux distro for myself
They should be using Beowulf cluster of 10,000 4GB encrypted USB drives. God, I would pay money to see something like that....
I judt got a nre Kinesis keybiartf so please excusr ant egregiou typos.
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
OXYMORON.
This was moderated down last week on a lame story about Microsoft providing first "security" patches to their goverment "customers".
Thanks in advance.
Yours In Akademgorodok,
Kilgore Trout, C.I.O.
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)
Quick question: Where'd you buy that computer? Wasn't with Newegg, by any chance, was it? They clearly use MS products at least for the frontend (ASP), but that's really no guarantee one way or the other.
The only way you could not be that "naive" is if you simply don't use your credit card online, in which case, how do you know what your bank is using?
Don't thank God, thank a doctor!
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.
I think that this article is a little misleading. The encryption that is being discussed here is well known to be weak, and is only used for the system password, it's not used for the integrity of the system at all.
The article links to a blog here, which talks about the encryption of the SQL login passwords, which is a completely different thing, which does not use a simple substitution cipher. A couple different locations that encryption is used are being confused here.
I usually use xor to encrypt my data, and to be really sure I run the encryption twice. ^C
If I remember right, I could sniff the login password from a TCP/IP exchange between SQL client and server and the password was also just a letter substitution. It's been a few years, but I just sent it something like 'aaaaa' then 'bbbbb' and looked for the difference in packet - the change was the same-length as my test password and repeated the same character the exact # of times.
from 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
to 45 2F 6E 40 3C DF 10 71 4E 41 DF AA 25 7D 31 3F
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.
Some moons ago my former firm was assesing solutions for LDAP/Kerberos .
One MS based solution was the front runner (I don't know why, we guessed that the person responsible for selecting the solution was a golf buddy of a MS reseller, but I digress), until one of our UNIX guys, utterly pissed off with the lame security revies, passed a fine comb through the whole thing.
To make the tale short, he found that MS sofware had been writing important security information in the registry, in clear text.
Needless to say the MS based solution was dropeed in favour of a Sun's Solaris one.
To this day it remains a mistery why people keep insisting in trusting MS wares for mission critical or sensitive stuff.
In some contexts it might be acceptable to do this. Basically you just want to prevent casual viewing of passwords in the database or configuration files. Since TFA is currently slashdotted I'm reserving my right to laugh and be judgemental until I get a better picture of the context.
Keep in mind even the worlds best encryption algorithm are useless if the keys are stored next to the data they are protecting. Nobody uses startup passwords because we're all too lazy so even if strong encryption were to have been deployed how much of a difference would it have made?
SSH is only secure after taking the leap of faith. Shadow files with todays latest algorithms are still subject to offline attack and therefore must be concidered insecure. There are plenty of piss poor bad security practices in use by virtually everyone and while it might take more computer time to recover it does not make the materially better than rot13.
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.
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!
Get an Amiga. XPK (a dynamically loaded shared library for letting any app use whatever encryption and/or lossless compression libraries happen to be available on the system) has been around since the mid 1990s.
[troll]Using a platform older than the Amiga, such as Mac OS 10.6 or Windows 7 or Ubuntu 10.04? Then just upgrade to Amiga OS 3.1, or backport XPK to your less spiffy OS.[/troll]
It really is a good idea and you'd think everyone else would have something like it by now. Well, for crypto, they sort of do, just not as cool; I think Linux and OpenBSD (and therefore, probably many others) supply crypto APIs by the kernels, and they'll use crypto hardware if available. And for compression, everyone just links in zlib. It's only on Windows that everyone is fucked, and being fucked is part of the day to day reality of that platform in every other way too, so it's not like there's something special about crypto.
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.
Simply NSFW.
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?
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.
Speaking as someone that actually ADMINISTERS a Great Plains system, and knows how the security system works there, trust me this is a non issue.
A bit of background: Great Plains is a two teir system - client software talking to a SQL Database, these days, SQL Server. (Originally, CTree and a bunch of other databases)
To stop end users accessing the database directly (e.g., using SQL tools), the passwords are encrypted - i.e., whatever password you type in to GP is encrypted and then used to log into SQL Server. Thus, users don't know their real SQL Server password and cannot connect to the company database using SQL tools.
Let me repeat that - A base user CANNOT CONNECT TO THE DATABASE USING SQL TOOLS. Thus, they don't have access to SY02400.
(Yes, I fully realise that a three tier model with security enforced in the server tier would be easier, but remember that this product predates that model. And there are a number of advnatages of that model that I wish GP had, but that's another story.)
(There's an execption if they're logging in as 'sa', but if they're logging in as sa, it's game-over anyway.)
Also, the system password isn't used for anything. Normally that security model is switched off and a proper 'user has access to screen' model is used. (Heck, usually those screens are only accessable to the 'sa' user anyway.)
And don't suggest AES - that's all for encrypting the database below the application in case the DBA is incompetent and loses the back-up tapes on the bus.
That's the singular most informative post in the whole discussion.
"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.