×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Microsoft Dynamics GP "Encrypted" Using Caesar Cipher

kdawson posted more than 3 years ago | from the no-safety-in-numbers dept.

Bug 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

206 comments

Wow. (-1, Redundant)

Anonymous Coward | more than 3 years ago | (#32294050)

Just... wow.

Re:Wow. (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#32295060)

How come nobody ever asks if microsofties are too smart for their own good?

andnothingofvaluewaslost (3, Funny)

Anonymous Coward | more than 3 years ago | (#32294052)

The weakness of encryption is justified by the non-importance of the asset it protects.

Re:andnothingofvaluewaslost (3, Insightful)

SanityInAnarchy (655584) | more than 3 years ago | (#32294202)

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:andnothingofvaluewaslost (2, Insightful)

jd (1658) | more than 3 years ago | (#32294242)

I think the GP means the cards are all probably maxed out, blocked/revoked, or both.

Re:andnothingofvaluewaslost (0)

SanityInAnarchy (655584) | more than 3 years ago | (#32294448)

And what evidence is there of that?

I mean, by now they may well be, but that would be because of this system, so "andnothingofvaluewaslost" still doesn't fit.

Re:andnothingofvaluewaslost (0)

Anonymous Coward | more than 3 years ago | (#32294260)

Clearly, consumers who are naïve enough to do trade with a company that uses Microsoft products have only themselves to blame.

And how would I know? (0)

SanityInAnarchy (655584) | more than 3 years ago | (#32294422)

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?

Re:andnothingofvaluewaslost (1)

e4g4 (533831) | more than 3 years ago | (#32294446)

What, do you live in a windmill powered cabin in the woods? Unless you live completely off the grid (impossible, in your case, as you post to slashdot) nearly every company you do trade with uses Microsoft products.

Re:andnothingofvaluewaslost (0, Troll)

Anonymous Coward | more than 3 years ago | (#32294948)

No fucking shit, Sherlock. Any other nuggets of wisdom you'd care to share?

Re:andnothingofvaluewaslost (0)

negRo_slim (636783) | more than 3 years ago | (#32294386)

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.

They are not valuable, nor at they important. They are numbers representing the illusion of assets.

Re:andnothingofvaluewaslost (1)

SanityInAnarchy (655584) | more than 3 years ago | (#32294508)

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 lot more justification than just flippantly discarding them. And if you are going to claim that all currency is only the illusion of value, that has its own problems.

Re:andnothingofvaluewaslost (2, Insightful)

ooshna (1654125) | more than 3 years ago | (#32294846)

Your right so to stand by your point please post any and all Credit card numbers with expiration dates and the little 3 digit code on the back. Oh also your full name thank you.

PCI-DSS (4, Informative)

realxmp (518717) | more than 3 years ago | (#32294434)

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.

Re:andnothingofvaluewaslost (1)

JonahsDad (1332091) | more than 3 years ago | (#32294366)

This shouldn't be a problem for US customers. Anyone breaking the encryption can be found guilty via DMCA, right?
Standard IANAL line.

Not a substitution cipher (1)

Cassini2 (956052) | more than 3 years ago | (#32295112)

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.

obligatory (4, Funny)

girlintraining (1395911) | more than 3 years ago | (#32294058)

et tu brutus?

Re:obligatory (4, Informative)

XanC (644172) | more than 3 years ago | (#32294192)

You need to use the vocative case there, not the nominative.

Re:obligatory (4, Interesting)

interval1066 (668936) | more than 3 years ago | (#32294788)

"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:obligatory (2, Informative)

Anonymous Coward | more than 3 years ago | (#32295026)

Actually it is pronounced "BruH-tEH". The "AY" pronunciation at the ending is an english barbarism. I guess that conquering only the south half of the island was a mistake. Maybe next time.

Re:obligatory (0)

Anonymous Coward | more than 3 years ago | (#32294194)

s/brutus/brute/g

Or am I completely missing the joke here?

Re:obligatory (5, Funny)

Kilrah_il (1692978) | more than 3 years ago | (#32294372)

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:obligatory (2, Informative)

Gilmoure (18428) | more than 3 years ago | (#32294576)

What makes this scene even funnier to me is John Cleese was a teacher at one point.

Re:obligatory (2, Funny)

jd (1658) | more than 3 years ago | (#32294224)

"Infamy! Infamy! They've all got it in fa me!" (Carry On's version)

Re:obligatory (0)

Anonymous Coward | more than 3 years ago | (#32294990)

'Tu quoque, Brute, fili mi!'

there, fixed that for ya

-- Pedantic Coward

Re:obligatory (2, Informative)

uglyMood (322284) | more than 3 years ago | (#32295230)

Kai su, teknon? - There, fixed that for you. Not universally accepted, but he certainly didn't utter Shakespeare's line.

But... (5, Funny)

the_one_wesp (1785252) | more than 3 years ago | (#32294060)

Ohg vg'f jnl zber frpher gung jnl

Re:But... (3, Interesting)

the_one_wesp (1785252) | more than 3 years ago | (#32294130)

I disagree with this being off topic. Perhaps, though, if /.ers are too hasty to recognize a quick rot13, that justifies why MS thinks they can do the same with their products... o.O

Re:But... (2, Funny)

Anonymous Coward | more than 3 years ago | (#32294184)

This is better --- preceding message encrypted with rot26.

Re:But... (3, Interesting)

jgreco (1542031) | more than 3 years ago | (#32294200)

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... (3, Funny)

Dancindan84 (1056246) | more than 3 years ago | (#32294376)

Yeah, kids these days are using rot26 instead. Twice as secure.

Proper security measures (1)

TiggertheMad (556308) | more than 3 years ago | (#32295270)

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...

Re:But... (1)

negRo_slim (636783) | more than 3 years ago | (#32294410)

Thanks to my rot13 encoded TrueCrypt container, I can proudly say I use it every day and haven't felt this secure on the internet in years!

Re:But... (2, Informative)

langelgjm (860756) | more than 3 years ago | (#32294728)

In vim, g?G will perform rot13 from the cursor position to the end of the document; g?$ to the end of the line, etc.

Re:But... (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#32294368)

Granted, it's bad, but there's no reason to bring the impending awakening of Cthulhu into this!

Oh, wait.

I have a fix for this. (5, Funny)

2names (531755) | more than 3 years ago | (#32294062)

They should hire some of them "too smart for their own good" Googlers.

::gasp:: (1, Funny)

Pojut (1027544) | more than 3 years ago | (#32294066)

A Microsoft product with security problems? Say it ain't so, Joe!

Re:::gasp:: (4, Insightful)

DavidR1991 (1047748) | more than 3 years ago | (#32294122)

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 (4, Insightful)

jd (1658) | more than 3 years ago | (#32294416)

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:My guess is ITAR, the market and standards (2, Informative)

palegray.net (1195047) | more than 3 years ago | (#32294848)

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 level imaginable concerning data protection.

Re:My guess is ITAR, the market and standards (0)

Anonymous Coward | more than 3 years ago | (#32295088)

Some of your statements about export are incorrect unless there have been very recent changes to US export laws. (I assume you are referring ot US laws, but laws in some other countries are similar.) In general: 1) Even open source is still controlled once you compile it and use it in a product. 2) Being able to swap out the library is called "crypto with a hole" and will prevent you from getting an export license. There is one glaring exception to those rules but they are the reason the attempt to get NIST certification for the Unix crypto library failed on the first few attempts. The examiners weren't having any of that "compile your own code and just plug the library into your application" nonsense.

Re:My guess is ITAR, the market and standards (1)

raddan (519638) | more than 3 years ago | (#32295108)

You can have nigh-unbreakable ciphers that are just as fast as ROT13. XOR is a single operation on most processors.

The slowness comes in when you want features like asymmetric cryptography. Features that are not required here.

Re:::gasp:: (3, Informative)

Jazz-Masta (240659) | more than 3 years ago | (#32294932)

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:: (1)

Linker3000 (626634) | more than 3 years ago | (#32294954)

Fear not, Microsoft have just announced a patch that updates the encryption/decryption algorithms to add ROT13 and XOR to the process..

Indeed (1)

mr_death (106532) | more than 3 years ago | (#32295006)

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.

Shocked! (-1, Troll)

MightyMartian (840721) | more than 3 years ago | (#32294068)

I'm shocked, I tell you, shocked! Microsoft have a poorly secured product. I never thought I would have seen it in my lifetime!

Re:Shocked! (1)

Z00L00K (682162) | more than 3 years ago | (#32294478)

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.

Incredible. (4, Informative)

gorzek (647352) | more than 3 years ago | (#32294100)

So, this Microsoft product uses what amounts to the same "encryption" that the CVS pserver protocol uses. Hilarious.

Re:Incredible. (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32294356)

pserver was never intended to hold secure information or be a secured server.

There are CVS servers that use SSL encryption, kinda like blaming HTTP for being insecure, despite anything which involves your credit card number being done over HTTPS.

Re:Incredible. (3, Insightful)

gorzek (647352) | more than 3 years ago | (#32294390)

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.

Great Plains (1, Interesting)

Anonymous Coward | more than 3 years ago | (#32294112)

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.

Re:Great Plains (1, Interesting)

Anonymous Coward | more than 3 years ago | (#32294498)

GP has encryption? Well that beats SL (Solomon), where social security numbers are stored in cleartext.

In fact I'm pretty sure the "recommended" Windows authentication method (vs. the Master60SP method) gives basic users full read/write access to the database by default.

Doubly secure (1)

egcagrac0 (1410377) | more than 3 years ago | (#32294128)

They'll issue a patch next tuesday to improve security the ROT13 way - running data through the algorithm twice.

Re:Doubly secure (0)

Anonymous Coward | more than 3 years ago | (#32294860)

About 10 people already beat you to the rot26 gag above.

Most ERP systems do not have the data encrypted (5, Insightful)

Anonymous Coward | more than 3 years ago | (#32294142)

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 (0)

Anonymous Coward | more than 3 years ago | (#32294326)

Too bad you weren't first post; it sounds like you're actually a DBA or something.

Re:Most ERP systems do not have the data encrypted (5, Insightful)

Sir_Lewk (967686) | more than 3 years ago | (#32294338)

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:Most ERP systems do not have the data encrypted (1)

negRo_slim (636783) | more than 3 years ago | (#32294452)

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:Most ERP systems do not have the data encrypted (2, Informative)

Sir_Lewk (967686) | more than 3 years ago | (#32294632)

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:Most ERP systems do not have the data encrypted (1)

snowgirl (978879) | more than 3 years ago | (#32294946)

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:Most ERP systems do not have the data encrypted (0)

Anonymous Coward | more than 3 years ago | (#32294702)

Well, the ERP I work on is encrypted via stupidity.

Freaking cluster tables. WTF is this - 1974?

Re:Most ERP systems do not have the data encrypted (2, Insightful)

Paradise Pete (33184) | more than 3 years ago | (#32295250)

The news here is they were claiming to be using encryption, but really were not.

They are. Just not very strong encryption.

  • Man: I came here for some good encryption.
  • Microsoft: No you didn't. You came here for encryption.
  • Man: Encryption isn't just substitution.
  • Microsoft: It can be.
  • Man: Encryption is a connected series of mathematical operations intending to establish obfuscation.
  • Microsoft: Look, if I encrypt for you I must substitute for the original text.
  • Man: Yes, but it isn't just a simple one-to-one mapping.
  • Microsoft: Yes it is.
  • Man: No it isn't.
  • Microsoft: Yes it is.
  • Man: No it isn't.
  • Microsoft: Yes it is.
  • Man: Look, I've had enough of you.
  • Microsoft: No you haven't.

Re:Most ERP systems do not have the data encrypted (3, Informative)

Unordained (262962) | more than 3 years ago | (#32294538)

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:Most ERP systems do not have the data encrypted (1, Interesting)

Anonymous Coward | more than 3 years ago | (#32294666)

That's a very good point. I have all kinds of access to my companies ERP tables through SAP (though we don't store credit cards). The advantage here to using a cipher AT ALL is that those people who should have access can work with these tables as neccessary without seeing private information. Makes sense to me. However, the article claims that all tables are available to any user created in GP? I find that hard to believe. The article says that the user does not need to be granted DB access and therefore it has DB access. 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. I don't know MS Dynamics in specific, but in SAP the "root" user (SAP*) has a well-known default password (PASS). Now, there's a LOT of background for doing this and for a long time now it is recommended to change the default password, disable automatic SAP*, lock the user, change the validity date and remove all profiles from this account. In other words, there should be NO POSSIBLE way to EVER use this account in a production environment. I hope that is the same for the MS GP system user... Can anyone verify?

Re:Most ERP systems do not have the data encrypted (3, Informative)

DarkOx (621550) | more than 3 years ago | (#32294764)

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!

Another solution (0, Offtopic)

Itninja (937614) | more than 3 years ago | (#32294168)

They should be using Beowulf cluster of 10,000 4GB encrypted USB drives. God, I would pay money to see something like that....

Re:Another solution (1)

raddan (519638) | more than 3 years ago | (#32295172)

Beowulf is not going to help here. Beowulf is for clustering computational resources. You want to cluster storage resources, something like RAID-Z [sun.com] .

My encryption method... (5, Funny)

Eberlin (570874) | more than 3 years ago | (#32294198)

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... (3, Funny)

Cylix (55374) | more than 3 years ago | (#32294418)

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:My encryption method... (1)

MartinSchou (1360093) | more than 3 years ago | (#32294992)

Confirm the following transmission, "Snape kills Dumbledore."

Cannot confirm. Contains false information.

It's true (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32294246)

The old saying: "Anyone can create a security system that they cannot break"

You do not give users acces to a application DB (1)

leuk_he (194174) | more than 3 years ago | (#32294248)

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!)

Re:You do not give users acces to a application DB (1)

geekoid (135745) | more than 3 years ago | (#32294510)

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.

Full Article (5, Informative)

Anonymous Coward | more than 3 years ago | (#32294270)

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 function that you can use to decrypt GP "encrypted" data. You can find it here. If you create the function on the SQL server, you can then retrieve the Master password by running this query:

select dbo.[fn_Decrypt_Value] (PASSWORD, 16) from DYNAMICS.dbo.SY02400

I did ALOT of searching to see if anyone had reported this in the past, but I found no indication of this ever being found. I don't know if this is a "REAL" discovery, but I would think it's worth knowing. I hope you found this informative!

Other References:

Microsoft Dynamics GP Table Structure Overview

Re:Full Article (0)

Anonymous Coward | more than 3 years ago | (#32294392)

Of course I ripped out the table where he says "came up with this:" thanks to the /. filter. I put the comment explaining I'd done this inside LT GT symbols because I'm made of fail.

Re:Full Article (5, Interesting)

mpolino (1816870) | more than 3 years ago | (#32295252)

I'm a Microsoft MVP for Dynamics GP and this line "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... " is completely false. GP users can't log in to SQL using their GP passwords. The article doesn't state a version being used. On some older versions it was possible to chose to allow a user to access SQL with their GP login. This is not possible on any of the supported versions of Dynamics GP. Additionally, the System password referred to has always been a second line of defense. Security has to be given to a particular window in the application before GP even asks for the System password. Relying on the System password alone for security has never been a best practice. There are a number of other areas where the writer confuses different types of passwords and security in Dynamics GP making it clear that he's never actually used the application to understand how differnt passwords and settings interact to provide security. Mark

I'll State This AGAIN: Microsoft Security IS an (0)

Anonymous Coward | more than 3 years ago | (#32294300)

OXYMORON [wikipedia.org] .

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.

Re:I'll State This AGAIN: Microsoft Security IS an (1)

Kilrah_il (1692978) | more than 3 years ago | (#32294486)

actually, nowadays even microsoft is an oxymoron. They should be renamed Bloatsoft (which is easily shortened to BS).

Well they've got work to do before July 1st.... (1)

ducomputergeek (595742) | more than 3 years ago | (#32294466)

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).

Slightly Misleading Article (0)

Anonymous Coward | more than 3 years ago | (#32294494)

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 [msdn.com] , 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.

Better off using xor (0, Redundant)

Chrutil (732561) | more than 3 years ago | (#32294528)

I usually use xor to encrypt my data, and to be really sure I run the encryption twice. ^C

*** Irony, Microsoft did use XOR *** (1)

Cassini2 (956052) | more than 3 years ago | (#32295046)

I usually use xor to encrypt my data

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.

SQL the same? (0)

EkriirkE (1075937) | more than 3 years ago | (#32294586)

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.

Microsoft's latest encryption (4, Funny)

theskunkmonkey (839144) | more than 3 years ago | (#32294622)

Heytay areway oinggay otay useway Igpay Atinlay!

Re:Microsoft's latest encryption (2, Informative)

snowgirl (978879) | more than 3 years ago | (#32295200)

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.

This is the community's fault (1)

Sleepy (4551) | more than 3 years ago | (#32294732)

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.

Deja Vu. (0)

Anonymous Coward | more than 3 years ago | (#32294750)

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.

How bad is bad? (0)

Anonymous Coward | more than 3 years ago | (#32294814)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...