Microsoft Dynamics GP "Encrypted" Using Caesar Cipher 206
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."
andnothingofvaluewaslost (Score:3, Funny)
The weakness of encryption is justified by the non-importance of the asset it protects.
Re:andnothingofvaluewaslost (Score:4, Insightful)
From TFS:
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.
Sorry, if you're actually going to say that a lot of consumer credit cards aren't valuable or important, you're going to have to provide just a teensy bit more justification.
Re: (Score:3, Insightful)
I think the GP means the cards are all probably maxed out, blocked/revoked, or both.
Re: (Score:2)
Ok, what if you applied the logic from Hitch-Hiker's Guide to the Galaxy that currency is a figment of the imagination?
Re: (Score:2)
And what evidence is there of that?
The economy?
PCI-DSS (Score:4, Informative)
Re: (Score:2)
Actually, that's not the case - I don't believe that PCI mandates "good" encryption, just encryption. Besides, one thing that it absolutely does mandate, at least for service providers (the portion of PCI I'm most familiar with), is that your database be in a different, firewalled, network segment than your application server. So even if GP is creating accounts on the DB server, nobody other than the application should be able to just connect to it anyway. Of course, having just gone through our audit, I
Re:PCI-DSS (Score:4, Informative)
I don't believe that PCI mandates "good" encryption, just encryption.
As of 1.1 (the only document I have handy), the requirement is "Strong cryptography, such as Triple-DES 128-bit or AES 256-bit". I'm sure it only got more stringent after that.
Re: (Score:2)
Re: (Score:2)
How do you know the company running the satellites isn't using Microsoft products? ;)
Re: (Score:2)
And what value do assets have?
Value itself is an illusion, other than what value we give something. Beauty is in the eye of the beholder.
So if most of the world agrees that these numbers have value, they do, whether or not the assets are physical. Oh yes, things can be real without being physical -- or how would you feel if everything you ever created inside a computer was wiped out in a hard disk crash?
Unless you're going to claim that all currency is an illusion, you're again going to have to provide a lo
Re: (Score:2, Insightful)
Re: (Score:2)
Except that the "illusionary" numbers can be very easily converted into tangible assets.
Not a substitution cipher (Score:2)
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.
Re: (Score:3, Informative)
Re:Not a substitution cipher (Score:5, Insightful)
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.
Re:andnothingofvaluewaslost (Score:5, Informative)
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
obligatory (Score:5, Funny)
et tu brutus?
Re:obligatory (Score:5, Informative)
You need to use the vocative case there, not the nominative.
Re:obligatory (Score:4, Informative)
Re:obligatory (Score:5, Interesting)
"You need to use the vocative case there, not the nominative."
ie; "Brute." (pronounced "Brut-AY"
Getting back to the main story, let me add "Doh!" That's a major back door. And Microsoft, wanting to be our gatekeepers in so many ways and even with this big security initiative they've been trying to get everyone to believe they are on, is just sort of sluffing it off with their usual sheepish "Well, its not likely to actually happen." nonsense.
Re: (Score:2, Informative)
Re: (Score:3, Funny)
"Infamy! Infamy! They've all got it in fa me!" (Carry On's version)
Re: (Score:2, Informative)
Re: (Score:2)
There, fixed that for you. Universally accepted as what he would have said today to mean the same thing as he did then, whether by speaking the first half of a Greek curse or just by turning his eyes away from his traitorous friend.
Re: (Score:2)
Did Ceaser invent this cipher? It's THAT old? er, wait... [wikipedia.org]
Great Ceaser's ghost! But whoa...
Wow. Prior art? I'll bet they tried to patent it.
Re: (Score:2, Informative)
Yes, you are. http://www.imdb.com/title/tt0079470/ [imdb.com]
Whoosh
Re:obligatory (Score:5, Funny)
And to make it clearer:
[Brian is writing graffiti on the palace wall. The Centurion catches him in the act]
Centurion: What's this, then? "Romanes eunt domus"? People called Romanes, they go, the house?
Brian: It says, "Romans go home. "
Centurion: No it doesn't ! What's the latin for "Roman"? Come on, come on !
Brian: Er, "Romanus" !
Centurion: Vocative plural of "Romanus" is?
Brian: Er, er, "Romani" !
Centurion: [Writes "Romani" over Brian's graffiti] "Eunt"? What is "eunt"? Conjugate the verb, "to go" !
Brian: Er, "Ire". Er, "eo", "is", "it", "imus", "itis", "eunt".
Centurion: So, "eunt" is...?
Brian: Third person plural present indicative, "they go".
Centurion: But, "Romans, go home" is an order. So you must use...?
[He twists Brian's ear]
Brian: Aaagh ! The imperative !
Centurion: Which is...?
Brian: Aaaagh ! Er, er, "i" !
Centurion: How many Romans?
Brian: Aaaaagh ! Plural, plural, er, "ite" !
Centurion: [Writes "ite"] "Domus"? Nominative? "Go home" is motion towards, isn't it?
Brian: Dative !
[the Centurion holds a sword to his throat]
Brian: Aaagh ! Not the dative, not the dative ! Er, er, accusative, "Domum" !
Centurion: But "Domus" takes the locative, which is...?
Brian: Er, "Domum" !
Centurion: [Writes "Domum"] Understand? Now, write it out a hundred times.
Brian: Yes sir. Thank you, sir. Hail Caesar, sir.
Centurion: Hail Caesar ! And if it's not done by sunrise, I'll cut your balls off.
Re: (Score:3, Informative)
What makes this scene even funnier to me is John Cleese was a teacher at one point.
Re: (Score:2)
http://www.youtube.com/watch?v=XbI-fDzUJXI [youtube.com]
But... (Score:5, Funny)
Re: (Score:3, Interesting)
Re: (Score:2, Funny)
This is better --- preceding message encrypted with rot26.
Re:But... (Score:4, Interesting)
I guess the question is, how many people even know what rot13 is these days?
I mean, really, my rot13 script's nearly 20 years old and I'll bet I use it less than once a year these days...
% ls -l bin/script/rot13
-rwx------ 1 jgreco user 64 Nov 11 1991 bin/script/rot13*
%
Re:But... (Score:4, Funny)
Proper security measures (Score:2)
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...
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
I guess the question is, how many people even know what rot13 is these days?
I guess the question is, how many people know what tr is these days?
Re: (Score:3, Funny)
Re:But... (Score:5, Informative)
Ohg vg'f jnl zber frpher gung jnl
But it's way more secure that way
(mad cryptoquote skillz)
Re: (Score:3, Informative)
If you're using any sort of skill to decipher that, you're doing it wrong.
http://www.rot13.com/ [rot13.com]
I have a fix for this. (Score:5, Funny)
::gasp:: (Score:2, Funny)
A Microsoft product with security problems? Say it ain't so, Joe!
Re:::gasp:: (Score:5, Insightful)
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?
My guess is ITAR, the market and standards (Score:5, Insightful)
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.
Re: (Score:3, Informative)
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).
I'm sure as heck no Microsoft fan, but they've been exporting strong cryptographic components for a long time now, and not in an open source format. Please reference the following materials for further guidance on this topic:
Export of cryptography in the United States [wikipedia.org]
International Traffic in Arms Regulations 2009 [state.gov]
Sure, you can't export this stuff to Iran, North Korea, etc, but there are very few real obstacles aside from that. This is pure and simple failure on Microsoft's part, on the most basic le
Re: (Score:2)
The slowness comes in when you want features like asymmetric cryptography. Features that are not required here.
Re: (Score:2)
The practical difference between a Caesar cipher and DES is that the Caesar cipher is faster so more transactions can be performed.
Umm, no?
Caesar, and substitution-based ciphers in general, are so easy to break that they're given as puzzles in the daily newspapers (some aphorism is encrypted with a substitution cipher; you need to figure out what it is). Basically, you know the frequencies with which various letters, pairs of letters, etc. appear in English text; so you can compute the frequencies with which the characters in the ciphertext appear and determine a correspondence that way.
DES, on the other hand, mangles the statistics p
Re: (Score:3, Insightful)
DES is sufficiently weak that it is possible to build a home-grown cluster that can break a DES key in minutes. Yes, DES is "strong" in the sense that the algorithm itself has no significant flaws that anyone can detect, but when dealing with a credit card system where it's quite plausible that each card could have a thousand dollars available on it on average, obtaining 500 cards would cover the cost of the EFF's DES-breaking machine and therefore cover the costs. Everything else would be sheer profit for
Re: (Score:2)
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.
Actually, RC4 is not that much slower than Casear, mainly because is implemented sort of like Caesar with extra steps to modify the substitution table at runtime. OpenSSL can do RC4 on modern hardware faster than 300 MB/s. Even though it is as a "combiner" stream cipher and as such tricky to actually use securely, it would be much better than the probably ad-hoc implemented Caesar.
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 mean like their official ones [microsoft.com]? They could have used their own crypto API, but they didn't.
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.
You are right - this is 50% of the
Re: (Score:2)
You are right - this is 50% of the problem here. The other 50% is MS just being lazy.
Well, yes. If the IT managers can't tell the difference between Caesar cipher and AES, then it is arguably lazy to use Caesar. Mind you, less work done for the same income from sales equals more profit. And in a world (and stockmarket) driven by profit margins, voluntarily cutting those margins makes no business sense. (It's why the highest-risers in the stockmarket are also the high-risks and also the ones tied to companie
Re: (Score:2)
Depends on your definition of "not that long ago." Since 2000, the US has lifted many restrictions on export. What MS used is a simple cipher that they've used since Roman times (hence the name Caesar). Even if
Re: (Score:2)
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 o
Re:::gasp:: (Score:4, Informative)
Microsoft Dynamics GP used to be Great Plains Software. It was purchased by Microsoft in 2001.
The security is a relic of the program originally created by Great Plains Software. Although Microsoft should have fixed this, it was never Microsoft's idea in the first place.
MS is working on integrating GP with Active Directory.
I'm all for MS Bashing, but seriously...
Who do people blame for Flash? Adobe...but it was Macromedia (or SmartSketch if you want to go way back) that unleashed the plague upon the human race...
Re:::gasp:: (Score:5, Insightful)
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.
Re: (Score:2)
sorry not just Closed source
http://www.debian.org/security/2008/dsa-1571 [debian.org]
remember that gem???
http://digitaloffense.net/tools/debian-openssl/ [digitaloffense.net]
"All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected."
A good little write up.
Sorry but i have to say that these are both on par with each other.. both have very large and bad effects.
one is close source the other is open source.
I will give you that you see things like this far more often
Re: (Score:2)
Indeed (Score:2)
The Big Lie (Score:2)
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 [zdnet.com], 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
Re: (Score:2)
This is a massive downright idiotic flaw! How the HELL did this make it into a product?
Simple -- MS believes in security through obscurity. I doubt anyone or anything will ever teach them that it's bullshit, expect more of the same.
But give them credit, their interfaces are pretty. Unusable, but pretty.
Incredible. (Score:5, Informative)
So, this Microsoft product uses what amounts to the same "encryption" that the CVS pserver protocol uses. Hilarious.
Re:Incredible. (Score:4, Insightful)
Well, that's what I mean. pserver is insecure and never pretends to be anything more than it is--a barebones security mechanism that won't thwart anyone with a genuine interest in stealing passwords. All it would do is keep someone from *accidentally* seeing somebody else's password if they were monitoring network traffic. That's about it.
That Microsoft is using basically the same thing to secure a corporate accounting system that holds genuinely sensitive data is both terrifying and laughable.
Doubly secure (Score:2)
They'll issue a patch next tuesday to improve security the ROT13 way - running data through the algorithm twice.
Most ERP systems do not have the data encrypted (Score:5, Insightful)
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).
Re:Most ERP systems do not have the data encrypted (Score:5, Insightful)
The news here is they were claiming to be using encryption, but really were not. Regardless of whether or not encryption is needed in the first place, you don't mislead your customers like that.
Re: (Score:2)
The news here is they were claiming to be using encryption, but really were not.
Hail! [wikipedia.org]
In cryptography, a Caesar cipher, also known as a Caesar's cipher, the shift cipher, Caesar's code or Caesar shift, is one of the simplest and most widely known encryption techniques.
Re: (Score:3, Informative)
Classical ciphers, in discussions about modern computing, can't reasonably be considered on the same footing as modern ciphers. Using a classical cipher is no better than not using a cipher at all, hence no encryption.
But hey, this is slashdot where pedantry passes for insightfulness, so what the hell.
Re: (Score:2)
But hey, this is slashdot where pedantry passes for insightfulness, so what the hell.
This is some new level of pedantry. I saw that they did use "encryption", but quickly wrote off Caesar's Cipher as any sort of "real" encryption.
I mean, you have a PEDANTIC BITCH telling you that she agrees that you didn't need to be more explicit.
But then, hey, perhaps for the individual being pedantic enough to complain, Caesar's Cipher is still an effective encryption system.
Re: (Score:2)
A certain amount of pedantry is of course always good fun but I agree, this is just too much.
Re: (Score:2, Insightful)
They are. Just not very strong encryption.
Re: (Score:2)
Microsoft has $50,000,000,000 in the bank that says you're wrong. Honestly, at this point I don't know what else their customer could expect.
Re: (Score:2)
> ...you don't mislead your customers like that.
The customers for this product are PHBs. They want to be misled.
Re:Most ERP systems do not have the data encrypted (Score:4, Informative)
You should never give any direct access to your ERP database to anybody
That's slight overkill. I would encourage you to create proper database users, and grant them select/update/insert/delete rights only as appropriate. If you need per-column permissions, create views that hide those columns, and if they need read/write access, provide instead-of triggers on those views to support their needs.
The main reasons I would encourage you not to let users have direct access:
1) Users don't know what they're seeing, they don't know which lookup tables to join to, or they don't understand how the data's organized. They'll write their own reports, come to the wrong conclusions, convince management of their erroneous beliefs, and you'll have to clean up the mess. "I got my data from the database" shouldn't be good enough.
2) Most ERP products (really, most database-backed products) are not built to keep themselves truly logically consistent without the help of some outside application layer. There are lots of reasons for that: developers are taught that databases are just for storage, they don't want to learn procedural SQL, they're trying to be database-agnostic the only way they know how, ... Giving users write access means they can easily get all the data out of synch (I don't just mean foreign keys here, thank you) by performing only half of a complex operation the application layer would have guaranteed fully done.
Re: (Score:3, Interesting)
To be honest, it sounds like neither anonymous nor yourself have dealt with ERP systems at a database level. I'll give you a brief overview of why none of that works. First, there are six companies in my database and they do over 100 million in transactions every year. That database is 60,000 tables and there are only six users of the system. The database is only accessible from an accounting or management VLAN for obvious reasons. Going through and figuring out 10s of thousands of tables, triggers, procedu
Re: (Score:2)
It's true, I wasn't the DBA for Lawson (on Oracle.) But it was fun to discover how much it kept of its Cobol roots, down to the "padding" fields that you would traditionally leave in records so you could add fields later without having to rewrite the files. (They were still occasionally used that way, even inside Oracle.) I love legacy code. Fun times.
Number of tables isn't exactly an excuse in itself, though the fact that they're poorly documented might be. My current database has (truly) over a thousand d
Re:Most ERP systems do not have the data encrypted (Score:4, Informative)
Yes but this is GP we are talking about there really is no "Application Server" the clients all connect to the database! The users running the client therefore must have access to connect to the database and do DML queries on many objects. Any users that actually need to run the application and not some limited web front end you have built or something are SQL users. The only real workaround is to only allow database connections from selct hosts and have one of those hosts be a terminal server. The best part is the GP application has lots bugs when running under terminal services!
My encryption method... (Score:5, Funny)
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.
Re:My encryption method... (Score:4, Funny)
It took me a while, but I managed to decode your message.
Confirm the following transmission, "Snape kills Dumbledore."
The ramifications are going to be industry wide if this is true!
Re: (Score:2)
Cannot confirm. Contains false information.
Re: (Score:2)
Confirm the following transmission, "Snape kills Dumbledore."
Dammit! At least put a spoiler warning before you post something like this. Now there's no point in me reading the last book of Robert Jordan's Wheel of Time series.
If a wordpress site dies and noone is around? (Score:5, Informative)
Here's a text only cache [googleusercontent.com] of the page.
Full Article (Score:5, Informative)
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
Re:Full Article (Score:5, Interesting)
Re: (Score:2)
On one hand I would like to believe you since my company will be rolling out a Dynamics deployment at some point in the future; on the other hand, you guys used a substitution cipher and called it "encryption". The fact that you're an MVP and you say some stuff is kind of meaningless in the face of such a gigantic failure.
Re: (Score:3, Interesting)
Ok, What the FUCK. I was going to say this wasn't even a story and that the poster had no clue on .NET, then I read THIS:
http://blogs.msdn.com/developingfordynamicsgp/archive/2008/10/02/why-does-microsoft-dynamics-gp-encrypt-passwords.aspx [msdn.com]
THIS is your argument? What version it is? All your talking about is application security.
Look, the poster isn't the greatest .NET programmer out there (Plenty of built in stuff for encryption in .NET), but come on. A two byte substitution cipher? All you have to do i
Re:Full Article (Score:4, Informative)
About your AD comment, it's been brought up, but AD isn't the be-all-end-all of security.
From:
http://blogs.msdn.com/developingfordynamicsgp/archive/2009/12/09/do-we-really-want-windows-authentication-for-microsoft-dynamics-gp.aspx [msdn.com]
"One major drawback to switching authentication modes is audit trails. AX and SL have made the move from SQL auth to Windows Auth. In doing so, they destroyed the audit trail at the database level. All DB updates are made by one user making it a massive challenge to determine who made a change to financial data. Many of the AX and SL companies we work with get dinged for this in each audit."
Well they've got work to do before July 1st.... (Score:2)
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 a
Microsoft's latest encryption (Score:4, Funny)
Heytay areway oinggay otay useway Igpay Atinlay!
Re: (Score:3, Informative)
I disagree with your implementation of the Igpay Atinlay algorithm as described in RFC PL.
"They" is properly encrypted as "Ey-thay", as "th" is a single phoneme.
Of course, if you're sticking to the MICROSOFT implementation of going simply with orthographic characters, and you want to be non-standard with proper implementations, then go ahead.
Re: (Score:3, Funny)
Who the fuck are they giving mod points to anymore?
INFORMATIVE? This was total "out of my ass" bullshit. ... *shrugs and goes back to her alcohol*
Microsoft engineers (Score:3, Funny)
This is the community's fault (Score:2)
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.
This is not the least bit surprising (Score:2)
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 appli
Re: (Score:2)
Re: (Score:2)
SO you suggest not doing it becasue it's "hard" and thatno one cna mangae encryption keys?
Are you stupid?
It's not hard.
people get into databases they aren't`
suppose to be in all the time
and managing an encryption key is trivial.
Re: (Score:2)
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.
*** Irony, Microsoft did use XOR *** (Score:2)
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.
Re: (Score:3, Informative)
Re: (Score:2)