Comment On The Encryption Initiative

Alex Papadimoulis:

...each application could (and often did) have its own encryption algorithms, the service would need to account for that. ...

Sounds like that should've been the first thing to go.

Nice one!

Classic.

Whoops.. I mean.. brillant!

Captcha: Doom.  Nice.

And this is why God invented semaphores.

Sounds very "Web 2.0" and quite "Enterprisey" to me.
Where is the XML?

WTF, when did the Web become stateless?

Duh.

classic.

let me guess, the webservice it self was all un-encrypted ! and setPrivateKeyId() was plain text

I don't get it.

--- Shitty Quote ---
... until one considers that, as a web service used by several applications, it takes a lot of luck that one individual thread will be lucky enough to have three consecutive requests to set the encryption type, set the key, and encrypt that data. Whoops.
--- End Shitty Quote ---

I'm confused. Are you saying that the application would have had to performed 3 requests in a row? If so, why?

Here I am, thinking that the wtf is that they have one key for everything.

Another example of a race condition and a coder that doesn't understand how to handle it.  Gee, that's a new one.

Alex Papadimoulis:

Once everything went into production, some same strange things started happening: ...

This should have been a clue.  The strange things were the same (as other "strange things"?)

Anonymous:

And this is why God invented semaphores.

...or you can pass them as parameters to the webservice. That is why God invented SOAP packets

And by 3 requests, I mean three seperate requests, from someone else, to this.

Did you mean "it will be lucky enough to run long enough that this all stays correct" ?

Volmarias:

--- Shitty Quote ---
... until one considers that, as a web service used by several
applications, it takes a lot of luck that one individual thread will be
lucky enough to have three consecutive requests to set the encryption
type, set the key, and encrypt that data. Whoops.
--- End Shitty Quote ---
I'm confused. Are you saying that the application would have had to
performed 3 requests in a row? If so, why?
Here I am, thinking that the wtf is that they have one key for
everything.

I presumed the code snippet is on the client end and each function call
is a request to the server, thus giving rise to clients racing each
other.

Anonymous:

Anonymous:

And this is why God invented semaphores.

...or you can pass them as parameters to the webservice. That is why God invented SOAP packets

This one could benefit from some serious SOAP.  It smells pretty bad.[|-)]

Sadly, we had a similar situation at my company.

Programmer downloads a C++ encryption class, but needs it in C. Programmer writes C wrappers using a static implementation of the class. Everything works fine in their single-threaded application, but when the same routines are moved into a multi-threaded application......

Well if that was the work of their "best" developers, they should shoot the person who came up with the measurement criteria.  BTW where the hell was the testing?  Did they just deploy to production without trying to do encryption for multiple applications at once?  WTF????

So, the webservice wasn't thread-safe (not sure if this is correct term for this situation)?



This "crack" team of developers have been making code for this company
for a while now, I would guess.  Makes me wonder how "thread-safe"
the rest of the applications are.

first? :D (I'm pathetic, i know)

Wait, so applications have to send unecrypted data over wires to encrypt it? Who wants to bet that they didn't use SSL?

(PS: hey, it's the same problem that this forum software has with validation! har har)

first post at 3:37pm

at 3:49pm...

Anonymous:

first? :D (I'm pathetic, i know)

Time to upgrade to broadband there numbnuts

Volmarias:

And by 3 requests, I mean three seperate requests, from someone else, to this. Did you mean "it will be lucky enough to run long enough that this all stays correct" ?

OMG The WTF is that it is a race condition. With multiple applications using this web service each application needs to make 3 requests of the web service to complete an encryption.

If application A sends its first two requests and before it gets a chance to send the third request application B sends its first request then application A is screwed because application B just changed the encryption type or some other piece of the information.

Brillant!!! See, I've always thought the best developers are the ones that second guess themselves the most.

Anonymous:

first post at 3:37pm

at 3:49pm...

Anonymous:

first? :D (I'm pathetic, i know)

Time to upgrade to broadband there numbnuts

or glasses...  I know there's a Reply button here somewhere....

hahaa - ws transaction anyone

Alex Papadimoulis:

Quite a many secure electronic transactions take place at Oliver Klozoff's company and, in order to make sure the remain secure, his company undertook an Encryption Initiative. The idea was that, because encryption is such a vital part of security, all encryption should be done in one place, with once web service, instead of within each application. All applications -- new and existing -- would need to be immediately changed to utilize the new web service, and a crack team of only the best developers would be formed to lead up the Encryption Initiative.

The web service required to support the Encryption Initiative needed to be pretty robust. Because each application could (and often did) have its own encryption algorithms, the service would need to account for that. In addition, applications could (and often did) use several different keys that plugged into their application. Thankfully, the Encryption Initiative team had already thought of all that.

Once everything went into production, some same strange things started happening: quite a bit of data in various applications couldn't be decrypted. The Encryption Initiative team blamed it on the applications, saying that their code was elegant and simple, and couldn't possibly fail. A few days and several thousand un-decryptable transactions later, Oliver was brought in to help. At first glance, the application code doesn't seem that bad...

encWebSrvc = new EncryptionWebService(SERVICE_URL);

encWebSrvc.setEncryptionType("CFB64");

encWebSrvc.setPrivateKeyId("42B9657F-0E9A-44EC-BCC2-F1E38770B0C2");

return encWebSrvc.Encrypt(transactionLog);

... until one considers that each line requires a separate request and, as the web service is used by several applications, it takes a lot of luck that one individual thread will be lucky enough to have three consecutive requests to set the encryption type, set the key, and encrypt that data. Whoops.

.net webservices allow for sessions. Not terribly hard to implement it; it's just missing from the code.

That is nothing. I just had to write a queer piece of code myself:

BOOL SomeClass::TestSomething()
{
if(this == NULL)
return FALSE;
TestSomethingAndReturnResult;
}

The reason was the earlier piece of code:

return (pSomeObject == NULL)?FALSE:pSomeObject->TestSomething();

was crashing occasionally because some other thread would come and change pSomeObject to NULL in between the first part and second part of that line.

Any kind of synchronization object was out of question because that line was being called for a few thousand objects every few milliseconds by THIS thread, not to mention the OTHER thread where pSomeObject was being modified.

--- I said ---
And by 3 requests, I mean three seperate requests, from someone else, to this. Did you mean "it will be lucky enough to run long enough that this all stays correct" ?
-------------
--- Hattrick said ---
OMG The WTF is that it is a race condition. With multiple applications using this web service each application needs to make 3 requests of the web service to complete an encryption.
If application A sends its first two requests and before it gets a chance to send the third request application B sends its first request then application A is screwed because application B just changed the encryption type or some other piece of the information.
----------

Ok, calm down porkchop. I was wondering if this was serverside code or clientside code, the writeup wasn't very good.

OMG, that is just priceless! I do so love it when application developers think they get the whole web thing and then so obvioulsy fail to grasp the most funcamental aspect of the web thing, the HTT request-response cycle!

Ironically this MAY actually be a case where XML might actaully play a useful role! Create on XML request to the service and get one response back from the service, one request-response cycle, hence one thread hence actually getting YOUR data back!

I don't know how WTF worthy this is.  sure it's pretty bad that they didn't realize that applications could encryt (and decrypt) at the same time as other applications...  but it's a pretty simple bug to fix by adding session information and making sure the web service can handle multiple sessions at once.  then again, they were REALLY stupid to implement this with all their applications (and encrypting I'm assuming valuable information) before doing more thourough testing.  I wouldn't want to be the one given the task of going back and trying to retreive the lost data (that could be a disaster).

There are some WTFs in the OP:

1) Encrypting with the PRIVATE KEY? Is that anonymization problem? You should never send you private key thru plain text... Alex, is this an anonymization (sp?) typo?

2) Encryption as webservice is a WTF in itself, even if done "correctly": in order to encrypt your transaction, you need to send it plain-text; in order to decrypt, you need to send your PRIVATE KEY in plain text and receive your transaction in plain-text again. This begs for interception. Encryption should ALWAYS be done locally.

3) The thread-safety problem: that's really silly. Those parameters should be pushed in constructor and the constructor should be built in a thread-safe manner (hoo-ray for encapsulation... the client of a webservice shouldn't be responsible with semaphores himself). This 'pattern' is called "Monitor".

(this forum software is a WTF... I'm having problems to type my post on a Firefox 1.6... hopefully, it won't chew my post)

(it chewed my post. let's try again)

There are some WTFs in the OP:

1. Encrypting with the PRIVATE KEY? Is that anonymization problem? You should never send you private key thru plain text... Alex, is this an anonymization (sp?) typo?
   


2. Encryption as webservice is a WTF in itself, even if done "correctly": in order to encrypt your transaction, you need to send it plain-text; in order to decrypt, you need to send your PRIVATE KEY in plain text and receive your transaction in plain-text again. This begs for interception. Encryption should ALWAYS be done locally.
   


3. The thread-safety problem: that's really silly. Those parameters should be pushed in constructor and the constructor should be built in a thread-safe manner (hoo-ray for encapsulation... the client of a webservice shouldn't be responsible with semaphores himself). This 'pattern' is called "Monitor".
   

(this forum software is a WTF... I'm having problems to type my post on a Firefox 1.6... hopefully, it won't chew my post)

Anonymous:

Anonymous:

And this is why God invented semaphores.

...or you can pass them as parameters to the webservice. That is why God invented SOAP packets

No, God invented SOAP packets so people could clean themselves.

OLIVER KLOZOFF?  C'mon!  Nice fake name. :)

 

 

Anonymous:

That is nothing. I just had to write a queer piece of code myself: BOOL SomeClass::TestSomething() { if(this == NULL) return FALSE; TestSomethingAndReturnResult; } The reason was the earlier piece of code: return (pSomeObject == NULL)?FALSE:pSomeObject->TestSomething(); was crashing occasionally because some other thread would come and change pSomeObject to NULL in between the first part and second part of that line. Any kind of synchronization object was out of question because that line was being called for a few thousand objects every few milliseconds by THIS thread, not to mention the OTHER thread where pSomeObject was being modified.

most people would just handle the null pointer exception rather then making a hack.

Anonymous:

the earlier piece of code:

return (pSomeObject == NULL)?FALSE:pSomeObject->TestSomething();

was crashing occasionally because some other thread would come and change pSomeObject to NULL in between the first part and second part of that line.

... you mean that a variable X in two threads of one program refers to the same memory space?

What's the point of multi-threading, then? Why don't these simultaneous/parallel executions have their own sandbox to play in? That's like hiring two people, but they've got to use one desk and one computer and one document.

fmobus:

I'm having problems to type my post on a Firefox 1.6

I also have trouble posting in browsers that don't exist.

Anonymous:

I don't get it.

The web service object is not a persistent object; it is like a handle to a DLL.

The mutators are setting properties global to the whole WebService, not to the instance handle.

If client A sets a property value to 1, then client B set the same property value to 2, then client A calls Execute, the Web Service with property value 2 because it is one instance no matter how many clients use it SIMULTAINIOUSY.

The fix is to have the Web Service present a single method that takes all the parameters at once.

Cheers

HatTrick:

Volmarias:

And by 3 requests, I mean three seperate requests, from someone else, to this. Did you mean "it will be lucky enough to run long enough that this all stays correct" ?

OMG The WTF is that it is a race condition. With multiple applications using this web service each application needs to make 3 requests of the web service to complete an encryption.

If application A sends its first two requests and before it gets a chance to send the third request application B sends its first request then application A is screwed because application B just changed the encryption type or some other piece of the information.

I'm probably wrong, but I would have figured that the WebService class stored those properties as local variable and then simply used them in the Encrypt function as the parameters to the server. You know, something like this:

public string Encrypt(log);
{
  return WebServiceExecute(SERVICE_URL, this.EncriptionType, this.PrivateKeyId, log);
}

So no calls to the server until that method was hit, and the "set" methods just store as local/client variables (rather than posting them up to the server). But I guess that's not the case?

-shnar

Anonymous:

first? :D (I'm pathetic, i know)

And a slow reader.

Absolutely brilliant, another impractical use of
web applications

Anonymous:

Wait, so applications have to send unecrypted data over wires to encrypt it? Who wants to bet that they didn't use SSL?

(PS: hey, it's the same problem that this forum software has with validation! har har)

Damn, my thoughts exactly. I was just wondering how far down the thread I would have to go before someone picked it up.

Mike5

This would be a pretty common kind of mistake when moving from an
object oriented programming mindset to a service oriented
architecture.   Going stateless takes either some training or
time away from the keyboard thinking about what you're doing

All of the above parameters should have been made either properties of the web service proxy or parameters of the Encrypt method. They ceratinly do not warrant making web service stateful

dhromed:

fmobus:

I'm having problems to type my post on a Firefox 1.6

I also have trouble posting in browsers that don't exist.

It exists.  I even have it installed.
Download it here:

http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/deerpark/alpha2/win32/

and a crack team of only the best developers

You are what you eat.

Anonymous:

That is nothing. I just had to write a queer piece of code myself: BOOL SomeClass::TestSomething() { if(this == NULL) return FALSE; TestSomethingAndReturnResult; } The reason was the earlier piece of code: return (pSomeObject == NULL)?FALSE:pSomeObject->TestSomething(); was crashing occasionally because some other thread would come and change pSomeObject to NULL in between the first part and second part of that line. Any kind of synchronization object was out of question because that line was being called for a few thousand objects every few milliseconds by THIS thread, not to mention the OTHER thread where pSomeObject was being modified.

You do realize, of course, that you are going to be the subject of tomorrows WTF?  If a thread is getting in between

return (pSomeObject == NULL)?FALSE:pSomeObject->TestSomething();

and deleting the object, why is it that you believe that the exact same thing can't happen right after your check for (this == NULL)?

 

 

I have a theory about this and the general state of humanity.

You see, the amount of intelligence in the Universe is a Constant.

The problem is, there are more and more people...

so since it is all centralized then what happens when the service goes down?

Alright then they fucked it up and - as any good programmer should do - tried to blame someone else.
But WHY?
Isn't this

encWebSrvc = new EncryptionWebService(SERVICE_URL);

object tied to a session or something like that?
It's 11 pm now and I'm struck with hayfever so maybe someone who can still think clearly is willing to explain this to me.