Comment On The Super Secure Web Service

Now this is the best wtf in ages..... Has everything on it. Incapable manager, hardcoded values, pointless technology used, etc.....

Love it ;)

First? 

Alex Papadimoulis:

"This way, if the Accounts Payable system ever needed to know who
checked in some code to the Source Control system, it'd be a simple Web
Service call."

I love it. What AP module is complete without a code checkout report?

 
:-)

--doc0tis 

Wait, wait , wait!!

Do they have webservices to destroy companies ? 

I have to point out the obvious. They invented REST.

Alex Papadimoulis:

This way, if the Accounts Payable system ever needed to know who checked in some code to the Source Control system, it'd be a simple Web Service call.

Anonymous:

I have to point out the obvious. They invented REST.

Restricted Environmental Stimulation Technique?  Yeah, that would explain a lot.

Alex Papadimoulis:

...Integrated Widows Authentication to determine who was making the request. The big problem with Integrated Widows Authentication...

 Although the authentication scheme is flimsy at best, threatening to make widows out of attacker's wives kept all but the bravest / loneliest hackers at bay...

[Note from Alex - fixed typo =-)]

Alex Papadimoulis:

He'd send off warning emails to everyone, saying the testing was not
conclusive, the deployment plan was incomplete, and the code was
riddled with bugs. Then he'd call for a "weekend crunch" to make things
right and slave away as the project's sole martyr when no one else
would come in. Granted, he would never actually check-in code or make
any other changes, but he'd always take credit for the project.

 That's genius!
 

Anonymous:

Alex Papadimoulis:

He'd send off warning emails to everyone, saying the testing was not
conclusive, the deployment plan was incomplete, and the code was
riddled with bugs. Then he'd call for a "weekend crunch" to make things
right and slave away as the project's sole martyr when no one else
would come in. Granted, he would never actually check-in code or make
any other changes, but he'd always take credit for the project.

 That's genius!
 

Anonymous:

Quite a few typos the last few days.  Wonder what's up?

Given what Alex posts, can you imagine what he reads that we never see? It's a miracle he can sit up straight...

Anonymous:

Alex Papadimoulis:

"This way, if the Accounts Payable system ever needed to know who
checked in some code to the Source Control system, it'd be a simple Web
Service call."

 

I love it. What AP module is complete without a code checkout report?

 
:-)

 

--doc0tis 

Well,
how else would the developers get the per-bug-fix bonus they were
promised in the interview?  Come to think of it, I'm still waiting
on my check...

Alex Papadimoulis:

public string WebRequest(string requestXml, string username, string passkey)
{
    if (passkey == "32foi$^")
    {
        return InternalWebRequest(requestXml, username);
    }
    else
    {
        return null;
    }
}

Hey I have an idea.  Maybe he should just hard code everyone’s usernames and passwords in to this if statement.

Alex Papadimoulis:

 [WebMethod]
public string WebRequest(string requestXml, string username, string passkey)
{
    if (passkey == "32foi$^")
    {
        return InternalWebRequest(requestXml, username);
    }
    else
    {
        return null;
    }
}

 Oh I get it, the WTF is that there aren't any capital letters in the secure passkey, right?

Alex Papadimoulis:

 [WebMethod]
public string WebRequest(string requestXml, string username, string passkey)
{
    if (passkey == "32foi$^")
    {
        return InternalWebRequest(requestXml, username);
    }
    else
    {
        return null;
    }
}

 Oh I get it, the WTF is that there aren't any capital letters in the secure passkey, right?

Fonzy:

Hey I have an idea.  Maybe he should just hard code everyone’s usernames and passwords in to this if statement.

I have a better idea - hard code them into the Javascript!  Rely on the browser to tell you if the person has authenticated or not.  With the added bonus that you're exposing your userids and passwords to anybody who looks at the page source. 

Alex Papadimoulis:

This way, if the Accounts Payable system ever needed to know who checked in some code to the Source Control system, it'd be a simple Web Service call.

I can't quite decide if I would wish that that monstrosity was hosted on SSL, or if it wasn't.  If it wasn't, at least it would be blatantly obvious to the first network sniff what a stupendous WTF this is... but then there's the danger that the first person to do a network sniff *ahem* doesn't tell anyone.

 Argh!  Damn this thing - it tempts me to try to take it seriously!

people either look good or *are* good.

this doofus is the former

how secure is that and his *promotion* to management was deserved 'eh

Alex Papadimoulis:

He believed in "leading by example" and wanted to show everyone that he knew what he was going.

Apparently, he didn't know whether he was coming or doing. 

Fixed it! 

[WebMethod]
public string WebRequest(string requestXml, string username, string passkey)
{
    if (passkey == "32foi$^")
    {
        return InternalWebRequest(requestXml, username);
    }
    else
    {
        return "Hey dumbass...the password is \"32foi$^\".";

    }
}

By the way, the second best solution is to write a wsdl that contains the password. (I had to write a client for such a webservice once.)

I work with someone who used to be a developer, but "failed upward". Not only did his solutions hardly ever work consistently, but his design practices were, well, terrible. His code was generally a uncommented mess of hard-coded global variables with a total lack of any sort of object oriented design, or any distinguishable design pattern for that matter, with no traces of any sort of error handling. So he has his new position and decides to start exercising some of his new found authority. Our reporting department had been complaining that some of their reports take too long to generate. Although this is to be expected with multi-hundred-thousand row reports consisting of sometimes a decade's worth of production data, we did what we could to optimize our reporting tools.

Ultimately, what it boiled down to was the memory limits for ISS worker processes on 32-bit platforms. The obvious solution was to upgrade our aging reporting server to a more robust 64-bit platform. So when the aforementioned individual called a meeting with the reporting department to discuss possible solutions we brought that suggestion to the table. Person X's response to our suggestion was classic. Mind you that this person was promoted all the way to the top of the development chain.

developer y: "We did some research and believe that upgrading to a 64-bit platform will solve our problems by extending the memory limitations for ISS worker processes"

manager x: "What are you talking about?! 64-bit? That doesn't even exist! Come back with something realistic."

developer y: "Isn't your lab top 64-bit?"

manager x: "No, and I think I would know."

developer y: "See that sticker right there next to your keyboard? Doesn't that say 64-bit?"

manager x: "Well so what, I don't see how improved graphics could help our reporting problems"
 

To be fair, it seems like this system is only for internal use. If that is the case, they shouldn't have to worry about someone packet sniffing the password; if someone who shouldn't be inside the network is inside the network, they have other problems. Of course, having a password in the first place would then be rather pointless.

Okay, I'll stop trying to apologize for this sorry excuse for an engineer.

So what? the password is hardcoded, stored in code, and passed in the clear. It provides no real security either - the only reason to have it at all is to force developers to talk to you before using your service.

/knowhutimean 

Dragnslcr:

To be fair, it seems like this system is only for internal use. If that is the case, they shouldn't have to worry about someone packet sniffing the password; if someone who shouldn't be inside the network is inside the network, they have other problems.

Because the system is for internal use, they *should* worry about packet sniffing.  I'm willing to bet that most successful security hacks happen on the inside.  How many times have you played with Ethreal/Wireshark at your house?  It's much more fun at work. 

The larger the company, the more likely you are to get a disgrunteld employee who acts on their malicious impulses.  I used to work in Loss Prevention at a major retail store, and our estimates were that 80% of all our "loss" was internal.  My job was to watch the employees first and the customers second.

stimmell:

I work with someone who used to be a developer, but "failed upward". Not only did his solutions hardly ever work consistently, but his design practices were, well, terrible. His code was generally a uncommented mess of hard-coded global variables with a total lack of any sort of object oriented design, or any distinguishable design pattern for that matter, with no traces of any sort of error handling. So he has his new position and decides to start exercising some of his new found authority. Our reporting department had been complaining that some of their reports take too long to generate. Although this is to be expected with multi-hundred-thousand row reports consisting of sometimes a decade's worth of production data, we did what we could to optimize our reporting tools.

Ultimately, what it boiled down to was the memory limits for ISS worker processes on 32-bit platforms. The obvious solution was to upgrade our aging reporting server to a more robust 64-bit platform. So when the aforementioned individual called a meeting with the reporting department to discuss possible solutions we brought that suggestion to the table. Person X's response to our suggestion was classic. Mind you that this person was promoted all the way to the top of the development chain.

developer y: "We did some research and believe that upgrading to a 64-bit platform will solve our problems by extending the memory limitations for ISS worker processes"

manager x: "What are you talking about?! 64-bit? That doesn't even exist! Come back with something realistic."

developer y: "Isn't your lab top 64-bit?"

manager x: "No, and I think I would know."

developer y: "See that sticker right there next to your keyboard? Doesn't that say 64-bit?"

manager x: "Well so what, I don't see how improved graphics could help our reporting problems"
 

I didn't know there was a 64 bit Etch-a-sketch. 

stimmell:

I work with someone who used to be a developer, but "failed upward". Not only did his solutions hardly ever work consistently, but his design practices were, well, terrible. His code was generally a uncommented mess of hard-coded global variables with a total lack of any sort of object oriented design, or any distinguishable design pattern for that matter, with no traces of any sort of error handling. So he has his new position and decides to start exercising some of his new found authority. Our reporting department had been complaining that some of their reports take too long to generate. Although this is to be expected with multi-hundred-thousand row reports consisting of sometimes a decade's worth of production data, we did what we could to optimize our reporting tools.

Ultimately, what it boiled down to was the memory limits for ISS worker processes on 32-bit platforms. The obvious solution was to upgrade our aging reporting server to a more robust 64-bit platform. So when the aforementioned individual called a meeting with the reporting department to discuss possible solutions we brought that suggestion to the table. Person X's response to our suggestion was classic. Mind you that this person was promoted all the way to the top of the development chain.

developer y: "We did some research and believe that upgrading to a 64-bit platform will solve our problems by extending the memory limitations for ISS worker processes"

manager x: "What are you talking about?! 64-bit? That doesn't even exist! Come back with something realistic."

developer y: "Isn't your lab top 64-bit?"

manager x: "No, and I think I would know."

developer y: "See that sticker right there next to your keyboard? Doesn't that say 64-bit?"

manager x: "Well so what, I don't see how improved graphics could help our reporting problems"
 

The real WTF is:  Steve can now deny responsibility because it was secure until the submitter leak the company's secret authentication scheme.  Now if only he/she tell us the actual identity of the company. ;)

Billant! 

CAPTCHA = paula

We can learn something significant from this, guys. Steve, despite his incompetence, managed to rise all the way to the top.

He must be doing something right. Me, if I have a guy like that as a colleague I'll watch closely what he'll do. So the next time it's my turn, I can do the same tactics, with clear conscience, because I know that my technical skill will actually back me up.

 

>No one bought it, and that's why it was so funny. Well, funny until he was promoted to management.

I don't buy it... if no one believed his charades, then who promoted him to management? I'm guessing he was rewarded for his dedication, ability to rally the troops to fix critical issues, etc.

webzter:

>No one bought it, and that's why it was so funny. Well, funny until he was promoted to management.

I don't buy it... if no one believed his charades, then who promoted him to management? I'm guessing he was rewarded for his dedication, ability to rally the troops to fix critical issues, etc.

Either it was an exaggeration, or Steve was actually _that_ good in making the right impression to the right people.
 

ptomblin:

Fonzy:

Hey I have an idea.  Maybe he should just hard code everyone’s usernames and passwords in to this if statement.

I have a better idea - hard code them into the Javascript!  Rely on the browser to tell you if the person has authenticated or not. 

 Good thinking batman! We all know that http isn't really secure so do the password validation on the client side and you never have to send passwords over http.

Anonymous:

ptomblin:

Fonzy:

Hey I have an idea.  Maybe he should just hard code everyone’s usernames and passwords in to this if statement.

I have a better idea - hard code them into the Javascript!  Rely on the browser to tell you if the person has authenticated or not. 

 Good thinking batman! We all know that http isn't really secure so do the password validation on the client side and you never have to send passwords over http.

 

From Wikipedia, the free encyclopedia

Irony is a literary or rhetorical device in which there is a gap
or incongruity between what a speaker or a writer says, and what is
generally understood (either at the time, or in the later context of
history). Irony may also arise from a discordance between acts and
results, especially if it is striking, and known to a later audience. A
certain kind of irony may result from the act of pursuing a desired
outcome, resulting in the opposite effect, but again, only if this is
known to a third party. In this case the aesthetic arises from the
realization that an effort is sharply at odds with an outcome, and that
in fact the very effort has been its own undoing.

WTF! They are not using the correct casing rules!
 

public string WebRequest(string requestXml, string username, string passkey)

 should be

public string WebRequest(string requestXml, string userName, string passKey)

;)

I am web developper, and I have no idea the right way to implement that.

But I think can something about that:

• Client ask for service XYZ.
• Server give unique string "challenge",
  
• Client concatenate "challenge" and "password" and create a md5 hash of that.
• Client send that hash withing service call.
  
• Server concatenate "challenge" and "password", create md5 hash and compare with the one the client send. If match, able to run the service, else detailless error (ERROR 501 and nothing else more informative).

I think this idea is weak because you need to store the user passwords at clientside and at serverside. Is better to forget passwords and only store a hash of the original password serverside :I. Other problem: you need to do 2 calls to get the data, and the server need some sort of session, and the result can be man in the midle weak.

How to enhance that? 

Got this ad at the end of the article : 

Enterprise security software that gets theats before get to you

 Symantec
 

haha !

Still waiting symantec to kick incapable manager out.

This is a little off topic, but the problem is sending unencrypted passwords in the clear over a TCP/IP connection. Simple hash protocols are not really encryption and are not normally considered secure enough for that job.

 If you are interested in encryption technology that can be used on the client side of an internet connection, you might want to check out the JavaScript crypto functions in a package such as Dojo, freely available at the Dojo website.
 

Anonymous:

Any fool knows you can't run 64-bit worker processes in a zero-gravity environment, sheesh.

Are you saying that this system should be operated from outer space? So the whole universe can sniff that password-packet?  :-)

>>This is a little off topic, but...

 Sorry, this was directed to Anonymous who asked the question about password hashing. Quote function didn't work.
 

Anonymous:

Dragnslcr:

To be fair, it seems like this system is only for internal use. If that is the case, they shouldn't have to worry about someone packet sniffing the password; if someone who shouldn't be inside the network is inside the network, they have other problems.

Because the system is for internal use, they *should* worry about packet sniffing.  I'm willing to bet that most successful security hacks happen on the inside.  How many times have you played with Ethreal/Wireshark at your house?  It's much more fun at work. 

The larger the company, the more likely you are to get a disgrunteld employee who acts on their malicious impulses.  I used to work in Loss Prevention at a major retail store, and our estimates were that 80% of all our "loss" was internal.  My job was to watch the employees first and the customers second.

 Ever heard of switches?

Switch your adaptor to promiscuous and two things happen at our company,

1) You find out you cant actually sniff anything not going to or from your local box

2) You find my boot up your arse, and a P45 in the post for breaking computer use policy

And the answer to 'clear text authentication issues' arent javascript crpyto libraries, hash functions or anything similar. Its called SSL/TLS, its a standard and its trivial to layer over HTTP.

CAPTCHA: giggity giggity giggity ITS QUAQMIRE
 

Fonzy:

Alex Papadimoulis:

public string WebRequest(string requestXml, string username, string passkey)
{
    if (passkey == "32foi$^")
    {
        return InternalWebRequest(requestXml, username);
    }
    else
    {
        return null;
    }
}

Hey I have an idea.  Maybe he should just hard code everyone’s usernames and passwords in to this if statement.

Yes.

And hard-coding each password to be a ROT-13 of the username would make it completely secure because you would not be relying on one global password! </sarcasm>

Ghost Ware Wizard:

people either look good or *are* good.

this doofus is the former

how secure is that and his *promotion* to management was deserved 'eh

A classic example of The Peter Principle !