The Daily WTF: Curious Perversions in Information Technology

snoofle · 2006-09-05 Reply Admin

ole gustie:
Anonymous:

Having worked for several fortune-50 companies over the past 25 years, I am sad to report that this sort of thing is more norm than abberation.

Among the fortune 50 from 2005 are:
Citigroup
Fannie Mae
Bank of America Corp
J.P. Morgan Chase & Co
Morgan Stanley
State Farm Insurance Cos

So... what you are saying is that my bank and credit card statements, mortage info, investment portfolio, and insurance records could be just a few stupid simple hacks away from being public knowledge? Holy scary shit batman.

Um, you are quite right.

Not long ago, a nameless company on your list took all sorts of security precautions to protect data, then put it on a tape, unencrypted, and handed it to some minimum wage messenger, who proceeded to misplace it. Oops :(

Carnildo · 2006-09-05 Reply Admin

drdamour:
Anonymous:
Security through obscurity is still quite common in web applications.

Well no duh, the entire session based web page uses this concept. Across all the backend languages, the idea is to give the app engine a security token (usually some guid) to identify the appropriate session. There's nothing stopping you from spoofing that token, except for the sheer volume of available tokens.

No, session-based web systems will usually hand the client a session ID (I use a combination of the username, user IP address, and current time), then store a copy in the local database. You can't generate a valid token out of thin air because you can't get the database to store it, you can't move a token from one computer to another because the IP address of the original computer is stored in the database, and you can't re-use a token at a later date because the time the token was generated is stored in the database.

2006-09-05 Reply Admin

Carnildo:
drdamour:
Anonymous:
Security through obscurity is still quite common in web applications.

Well no duh, the entire session based web page uses this concept. Across all the backend languages, the idea is to give the app engine a security token (usually some guid) to identify the appropriate session. There's nothing stopping you from spoofing that token, except for the sheer volume of available tokens.
No, session-based web systems will usually hand the client a session ID (I use a combination of the username, user IP address, and current time), then store a copy in the local database. You can't generate a valid token out of thin air because you can't get the database to store it, you can't move a token from one computer to another because the IP address of the original computer is stored in the database, and you can't re-use a token at a later date because the time the token was generated is stored in the database.

Have you ever heard of proxies????

nobody · 2006-09-05 Reply Admin

The real WTF is that they used VB.NET.

No, wait... scratch that.

The real WTF is that they used VBScript and old-school ASP. o.O

triso · 2006-09-05 Reply Admin

Brendan Kidwell:
So, uhm, bone-headed storage of trusted data in cookies, and infinite loops aside, let me get this straight: Nate was required to write code that included a module, SecurityInclude.asp, but was not given the source code nor any spec about how his code was SUPPOSED TO BEHAVE with respect to the "secret" code? How can anyone expect this sort of arrangement to work?

They can't tell you--It's a secret.

triso · 2006-09-05 Reply Admin

ammoQ:
Har har, now we know ho to break into this company's extranet. Well, we don't know which company it is, but I've heard there are less than one-hundred Fortune 50 companies, probably a number between 40 and 60. Can't be too hard to check them all.

I suspect that they have fallen out of the Fortune 50. Any simple IT audit would have flagged that one. If they are skimping on IT audits then they are skimping on other audits. Did Enron ever make it into the Fortune 50?

2006-09-05 Reply Admin

Any given fortune 50 company has myriad extranets in production, sometimes at duplicate or even cross-purposes.

2006-09-05 Reply Admin

ole gustie:
Anonymous:

Having worked for several fortune-50 companies over the past 25 years, I am sad to report that this sort of thing is more norm than abberation.

Among the fortune 50 from 2005 are:
Citigroup
Fannie Mae
Bank of America Corp
J.P. Morgan Chase & Co
Morgan Stanley
State Farm Insurance Cos

So... what you are saying is that my bank and credit card statements, mortage info, investment portfolio, and insurance records could be just a few stupid simple hacks away from being public knowledge? Holy scary shit batman.

Nah, State Farm's WAY too advanced for that. Browsing my cookies, I can see that they use W0082393.userID

Maurits · 2006-09-05 Reply Admin

Anonymous:
Pink Duck:
    Compelled to optimise....
    If (Len(userID) = 0 or Trim(userID) = "") Then
    If Len(Trim(userID)) = 0 Then

That looks like an optimisation, but it will actually perform worse in some cases: namely, when Len(userid) = 0, the first part of the first 'if' expression will be true, and the second part will be skipped.

Why not just:
    if Trim(userid) = ""

In VBScript, Or doesn't short-circuit.

2006-09-05 Reply Admin

biziclop:
drdamour:
Anonymous:
Security through obscurity is still quite common in web applications.

Well no duh, the entire session based web page uses this concept. Across all the backend languages, the idea is to give the app engine a security token (usually some guid) to identify the appropriate session. There's nothing stopping you from spoofing that token, except for the sheer volume of available tokens.

One could argue that the entire username password idea is really security through obscurity, considering you could (and places like the NSA do) iterate through all possible combinations.

I think you misunderstood security through obscurity. Obviously all security is about having something others don't have. The level of safety is equal to the number of guesses you have to make in a worst case scenario. Security in obscurity refers to a subset of these, where knowing the exact algorithm of security is enough to break it. Session ids stored in cookies or passphrase checks are another thing, no matter how much you know about the method, you have to make lots of guesses to spoof a valid one.

This man is correct. "Security through obscurity" means that your method of security is only secure if nobody knows how you are doing it. In this case it's hardly even obscure, since the cookie freakin says "userId" right on it.

2006-09-05 Reply Admin

Well, I for one can understand what's so secret about that code. I too would by every mean try not to let anybody have a look at it. I'd be ashamed to...

BTW, how did Nate manage not to laugh out loud, right there, on the spot? I don't think I could.

Magic Duck · 2006-09-06 Reply Admin

Alex Papadimoulis:
Nate was excited. He landed his first "Fortune 500" contract at, not just a Fortune 500 company, but a Fortune 50 one. It was a fairly small project and a great foot in the door. Today an interactive brochure website, tomorrow a global content management system that leverages collective synergy to drive "outside of the box" thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line.

And *Ding!* *Ding* *Ding* *Ding* Omg, my bullshit-o-meter just exploded! That really has to be great job :D

xrT · 2006-09-06 Reply Admin

Alex Papadimoulis:
Today an interactive brochure website, tomorrow a global content management system that leverages collective synergy to drive "outside of the box" thinking and formulate key objectives into a win-win game plan with a quality-driven approach that focuses on empowering key players to drive-up their core competencies and increase expectations with an all-around initiative to drive up the bottom-line.

Wow, that's 58 words in a sentence and I still haven't got a single clue on what it means, it must really be from one of the Fortune 50s...

Alex Papadimoulis:
And finally, Nate had a chance to see this secret security code file ...

And the next day Nate was reported missing...

xrT · 2006-09-06 Reply Admin

Anonymous:
Pink Duck:
    Compelled to optimise....
    If (Len(userID) = 0 or Trim(userID) = "") Then
    If Len(Trim(userID)) = 0 Then

That looks like an optimisation, but it will actually perform worse in some cases: namely, when Len(userid) = 0, the first part of the first 'if' expression will be true, and the second part will be skipped.

Why not just:
    if Trim(userid) = ""

I prefer to just base it on the length of the string in determining if it's empty or not, if it's zero then there's no way it won't be an empty string ("")...

2006-09-06 Reply Admin

Brendan Kidwell:
GizmoC:
Excuse my ignorance, but, where is the WTF in the code?

The code reads the "userid" back from the client and probably assumes it hasn't been tampered with; if the value is set, then the user is logged in. This is a completely invalid assumption.

Further, if you include this code on the home page, 'default.asp,' without any additions, you'll get an infinite redirecting loop when you hit that page. Maybe that doesn't happen in the real code and Alex snipped out or oversimplified that part of it.

A la Shania Twain. . . "I'm outta here"

lomaxx · 2006-09-06 Reply Admin

it's still more secure than the WTF a while back that had loggedin=true in the url query string

Ion9 · 2006-09-06 Reply Admin

Anonymous:
Or maybe the company just got fed up with all the begging and pleading and decided to show the guy a file that has nothing to do with the "real" SecurityInclude.asp ... :)

I am going with this thoery, there is NO -ing way that so much hype could be put over something as gimpy as this.

obediah · 2006-09-06 Reply Admin

Anonymous:
DigitalLogic:
The real WTF is blaming the security library which has obviously been used in other applications instead of debugging your own code.

Nice quote, but you're assuming he didn't bother to test his own code. Nor is it mentioned that Nate was "blaming" the security library. Was it unreasonable of him to expect he might be given even basic details about the interface to the security library, and what effect it might have on the global namespace?

He's assuming Nate didn't test his own code well enough. Maybe it's Alex's embellishment, but it comes off that our intrepid contractor became fixated on the security black box that he had no control over to early in the debugging process.

Debugging is about balancing likelihood and effort. You test a component that is 1% likely to be the cause of a bug, but only takes 1 minute to check before you test a component that is 99% likely to be the cause but takes 6 hours to check. In the example, the black box was highly probable, but once it became clear that getting access to it was going to require a lot of effort from multiple people, and require his contacts in the company to stick their necks out for him, he should have made damn sure the bug had something to do with that black box.

2006-09-06 Reply Admin

Anonymous:
until a couple of car thieves in Manila did it for real so it's not fiction anymore)).

Except that never happened, at least not in Manila.

obediah · 2006-09-06 Reply Admin

Anonymous:
Anonymous:
until a couple of car thieves in Manila did it for real so it's not fiction anymore)).

Except that never happened, at least not in Manila.

If it's feasible, it will happen. Car jacking didn't become a problem until automakers abandoned the master keys. Now your car is less likely overall to be stolen, but it's more likely you'll have gun stuck in your face in the process of it. I'm not sure that's progress.

It boggles my mind why anyone would protect something valuable with something even more valuable. You wouldn't spend $60k on a security system for a $20k car, why would you protect a $5k credit limit with your thumb? or an eye? Biometrics is about convenience, not security. The people putting this stuff together should ask MS about how well that tends to work out. :)

drdamour · 2006-09-06 Reply Admin

Anonymous:
or someone can just chop off the appropriate bits (that used to be from a movie, until a couple of car thieves in Manila did it for real so it's not fiction anymore)).

Unless he (Simon Phoenix) rips someones hand off, let's hope he doesn't figure that one out. ~ John Spartan

Excellent movie!!!

drdamour · 2006-09-06 Reply Admin

savar:

So I disagree that all security is fundamentally based on obscurity, unless you count the fact that secrets worth securing exist in the first place.

biziclop:

I think you misunderstood security through obscurity. Obviously all security is about having something others don't have. The level of safety is equal to the number of guesses you have to make in a worst case scenario. Security in obscurity refers to a subset of these, where knowing the exact algorithm of security is enough to break it. Session ids stored in cookies or passphrase checks are another thing, no matter how much you know about the method, you have to make lots of guesses to spoof a valid one.

Not all security is based on obscurity, but session id is.

Anonymous:
That's why you also create a hash with a secret salt value and send that to the client too. If the hashes don't match, then the identifier is forged. Granted, you could still brute force it, but you can easily get past the volume of combinations that even a supercomputer can forge quickly.

Thank you for making my point half way, this is a great tactic to keep session id's just one key, but again your tactic is still just a very obscure implementation of obscurity (2 keys instead of 1).

For a real example of good security that doesn't rely on obscurity, you have to think back to the early telnet servers. When they were given in invalid password the first time, they waited 1 second to tell you. When they were given another bad password, they would wait like 5 seconds. A third bad password would cause a 20 second delay. A 4th disconnected you, often with a timed ban (say a minute). This was an ingenius way to increase security, without simply increasing obscurity (bigger keys, like your 512 bit example, which IS true).

A lot of security tries to just make things more complicated, which is what most of your arguements have been. Some security just needs to make things more difficult to access when being accessed inappropriately. This is one of the features of Vista, and all the "Are you really sure you want to do this" dialogs.

The trick is keeping the difficult access away from things that are being accessed appropriately, and having the heuristics to differentiate between appropriate and inappropriate.

drdamour · 2006-09-06 Reply Admin

Carnildo:
No, session-based web systems will usually hand the client a session ID (I use a combination of the username, user IP address, and current time), then store a copy in the local database. You can't generate a valid token out of thin air because you can't get the database to store it, you can't move a token from one computer to another because the IP address of the original computer is stored in the database, and you can't re-use a token at a later date because the time the token was generated is stored in the database.

Ok first, the IP that you are using is coming from an HTTP request, not form the packet level, so spoofing that is a joke. But even if you were getting it from layer 3, again spoofing that is not hard. second, the idea is not to create phoney sessions, it's to hijack existing sessions that ahve already been authenticated. This kills both yoru DB based/created adn timestamp arguements.

Also, storing yoru session info in a DB immediately makes session info available to all SQL injection attacks, and i really doubt most programmers on the script side, have appropriately set up security on the DB tables themselves to have them blocked off. (meaning, a special account shoudl be used to access the session data table, and other accounts to access the DB based on user requests, thus limiting SQL injection access)

2006-09-06 Reply Admin

yo, my apologies for not looking into this more, but is this a true story? wtf is right, heh.

2006-09-06 Reply Admin

The real WTF here is that no-one has made the obvious fixes that would make it 100% extra uber secure:

''' BEGIN SecurityInclude.asp

''' Check for user id
Dim userID
userID = Request.Cookies("diresu").Value

If (Len(userID) = 0 or Trim(userID) = "") Then 
  Response.Redirect ("/default.asp")
End If

''' Check user id validity
Dim isValidUser
isValidUser = Request.Cookies("resUdilaVsi").Value

If (isValidUser <> "sey" and isValidUser <> "eurt") Then 
  Response.Redirect ("/default.asp")
End If
''' END SecurityInclude.asp

Problem solved.

*Sits down to enjoy a nice relaxing mug of ale*

Raafschild · 2006-09-06 Reply Admin

drdamour:
Carnildo:
No, session-based web systems will usually hand the client a session ID (I use a combination of the username, user IP address, and current time), then store a copy in the local database. You can't generate a valid token out of thin air because you can't get the database to store it, you can't move a token from one computer to another because the IP address of the original computer is stored in the database, and you can't re-use a token at a later date because the time the token was generated is stored in the database.

Ok first, the IP that you are using is coming from an HTTP request, not form the packet level, so spoofing that is a joke. But even if you were getting it from layer 3, again spoofing that is not hard. second, the idea is not to create phoney sessions, it's to hijack existing sessions that ahve already been authenticated. This kills both yoru DB based/created adn timestamp arguements.

Also, storing yoru session info in a DB immediately makes session info available to all SQL injection attacks, and i really doubt most programmers on the script side, have appropriately set up security on the DB tables themselves to have them blocked off. (meaning, a special account shoudl be used to access the session data table, and other accounts to access the DB based on user requests, thus limiting SQL injection access)

Drdamour is right in saying that an existing session can be hijacked. If you know that Mr. Smit the CFO has logged in from his PC at around 10:30, it should be possible test all combinations, one with timestamp 10:25:00, one with timestamp 10:25:01, etc. The solution is simple: add some randomly generated number to the session ID.

I don't see why storing the session information in a database would be problem. You should prevent unauthorized access to the database but you have to do that anyway.

2006-09-06 Reply Admin

GoatCheez:

Today seems to be great programmer quote day.... so......

Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
Alan Kay

Well kind og off topic, but i do recall that the Pyramids were in fact not build by slaves but by hired workers (as the whole of the egyptian population had almost nothing to do the three months each year when the Nile valley was flodded. The egyptians used slaves for mining operations in the eastern desert, but that is another story.

Yours yazeran

Plan: To go to Mars one day with a hammer

Talchas · 2006-09-06 Reply Admin

drdamour:
savar:

So I disagree that all security is fundamentally based on obscurity, unless you count the fact that secrets worth securing exist in the first place.

biziclop:

I think you misunderstood security through obscurity. Obviously all security is about having something others don't have. The level of safety is equal to the number of guesses you have to make in a worst case scenario. Security in obscurity refers to a subset of these, where knowing the exact algorithm of security is enough to break it. Session ids stored in cookies or passphrase checks are another thing, no matter how much you know about the method, you have to make lots of guesses to spoof a valid one.

Not all security is based on obscurity, but session id is.

Anonymous:
That's why you also create a hash with a secret salt value and send that to the client too. If the hashes don't match, then the identifier is forged. Granted, you could still brute force it, but you can easily get past the volume of combinations that even a supercomputer can forge quickly.

Thank you for making my point half way, this is a great tactic to keep session id's just one key, but again your tactic is still just a very obscure implementation of obscurity (2 keys instead of 1).

For a real example of good security that doesn't rely on obscurity, you have to think back to the early telnet servers. When they were given in invalid password the first time, they waited 1 second to tell you. When they were given another bad password, they would wait like 5 seconds. A third bad password would cause a 20 second delay. A 4th disconnected you, often with a timed ban (say a minute). This was an ingenius way to increase security, without simply increasing obscurity (bigger keys, like your 512 bit example, which IS true).

A lot of security tries to just make things more complicated, which is what most of your arguements have been. Some security just needs to make things more difficult to access when being accessed inappropriately. This is one of the features of Vista, and all the "Are you really sure you want to do this" dialogs.

The trick is keeping the difficult access away from things that are being accessed appropriately, and having the heuristics to differentiate between appropriate and inappropriate.

That is not the standard definition of security through obscurity. You are saying that anything is security through obscurity if there is some hidden information. The standard definition is if the algorithm is hidden - because then you have no way of testing how secure the algorithm is. Almost any security/cryptography system requires a key to be kept secret to function, that is the whole point. A good system only requires the key to be secret to be secure.

2006-09-06 Reply Admin

Raafschild:
drdamour:
Carnildo:
No, session-based web systems will usually hand the client a session ID (I use a combination of the username, user IP address, and current time), then store a copy in the local database. You can't generate a valid token out of thin air because you can't get the database to store it, you can't move a token from one computer to another because the IP address of the original computer is stored in the database, and you can't re-use a token at a later date because the time the token was generated is stored in the database.

Ok first, the IP that you are using is coming from an HTTP request, not form the packet level, so spoofing that is a joke.

Are you sure? I would expect that the client ip address header is generated by the server when it calls the cgi, and is not accepted nor passed through if supplied by the client in the http request.

drdamour:
But even if you were getting it from layer 3, again spoofing that is not hard. second, the idea is not to create phoney sessions, it's to hijack existing sessions that ahve already been authenticated. This kills both yoru DB based/created adn timestamp arguements.

Huh? IP spoofing a TCP connection is very very hard indeed. Easy enough across a LAN, even a switched one, since you can sniff the replies from the victim even though they aren't being sent to your IP, but next to impossible to do blind across the internet at large these days; modern TCP stacks have much more random ISN generation than the old ones and are very very hard to predict.

drdamour:
Also, storing yoru session info in a DB immediately makes session info available to all SQL injection attacks, and i really doubt most programmers on the script side, have appropriately set up security on the DB tables themselves to have them blocked off. (meaning, a special account shoudl be used to access the session data table, and other accounts to access the DB based on user requests, thus limiting SQL injection access)

Drdamour is right in saying that an existing session can be hijacked. If you know that Mr. Smit the CFO has logged in from his PC at around 10:30, it should be possible test all combinations, one with timestamp 10:25:00, one with timestamp 10:25:01, etc. The solution is simple: add some randomly generated number to the session ID.

To be fair, Carnildo said he "used a combination of" that data, and if the method of combining includes a random nonce and a hash, there's no way on earth you're going to guess it. This also mitigates any attempt to inject SQL, if it's a non-user-controllable hash of the id.

snoofle · 2006-09-06 Reply Admin

Anonymous:

The real WTF here is that no-one has made the obvious fixes that would make it 100% extra uber secure:

''' BEGIN SecurityInclude.asp

''' Check for user id
Dim userID
userID = Request.Cookies("diresu").Value

If (Len(userID) = 0 or Trim(userID) = "") Then 
  Response.Redirect ("/default.asp")
End If

''' Check user id validity
Dim isValidUser
isValidUser = Request.Cookies("resUdilaVsi").Value

If (isValidUser <> "sey" and isValidUser <> "eurt") Then 
  Response.Redirect ("/default.asp")
End If
''' END SecurityInclude.asp

Problem solved.

*Sits down to enjoy a nice relaxing mug of ale*

Erm, wouldn't that more correctly be:

''' BEGIN SecurityInclude.asp

''' Check for user id
Dim userID
userID = Request.Cookies("diresu").Value

If (Len(userID) = 0 or Trim(userID) = "") Then 
  Response.Redirect ("/default.asp")
End If

''' Check user id validity
Dim isValidUser
isValidUser = Request.Cookies("resUdilaVsi").Value

If (isValidUser <> "sey" and isValidUser <> "DNUOF_TON_ELIF") Then 
  Response.Redirect ("/default.asp")
End If
''' END SecurityInclude.asp</QUOTE>

2006-09-06 Reply Admin

Anonymous:
Any given fortune 50 company has myriad extranets in production, sometimes at duplicate or even cross-purposes.

That's a fact. Reading this, I'm guessing Nate was doing something for some "shadow IT" group.

2006-09-06 Reply Admin

drdamour:
biziclop:

I think you misunderstood security through obscurity. Obviously all security is about having something others don't have. The level of safety is equal to the number of guesses you have to make in a worst case scenario. Security in obscurity refers to a subset of these, where knowing the exact algorithm of security is enough to break it. Session ids stored in cookies or passphrase checks are another thing, no matter how much you know about the method, you have to make lots of guesses to spoof a valid one.

Not all security is based on obscurity, but session id is.

A number of people have tried to correct your misunderstanding on this point, but you just repeat it. Do you not think it would be a good idea to do some serious reading on the subject before arguing with people like biziclop who clearly understand the subject better than you?

2006-09-06 Reply Admin

If Len(Trim(userID)) Then

...is even more optimised, since it avoids string concatination with what's already a variant string. Traditionally Len checks are faster than string comparison. From a quick test I found almost twice as efficient when checking for empty string, over 5 million comparisons. Equivalent number of characters too.

quack!

2006-09-06 Reply Admin

drdamour:
For a real example of good security that doesn't rely on obscurity, you have to think back to the early telnet servers. When they were given in invalid password the first time, they waited 1 second to tell you. When they were given another bad password, they would wait like 5 seconds. A third bad password would cause a 20 second delay. A 4th disconnected you, often with a timed ban (say a minute). This was an ingenius way to increase security, without simply increasing obscurity (bigger keys, like your 512 bit example, which IS true).

My iPaq still does this, except that it keeps incrementing the time even if you get the right password. It's a great way to keep my 10 year old from guessing my 4 digit password. It's "secure enough", and that's what counts.

The trick is to determine, for each situation, what "secure enough" means.

The *real* WTF is the CAPTCHA: wtf

... har ...

DigitalLogic · 2006-09-06 Reply Admin

Anonymous:
Pink Duck:
    Compelled to optimise....
    If (Len(userID) = 0 or Trim(userID) = "") Then
    If Len(Trim(userID)) = 0 Then

That looks like an optimisation, but it will actually perform worse in some cases: namely, when Len(userid) = 0, the first part of the first 'if' expression will be true, and the second part will be skipped.

Why not just:
    if Trim(userid) = ""

I think we just stumbled upon the REAL wtf. VBScript evaluates all operations even if the boolean logic has been satisfied.

x = "test" if isnumeric(x) and abs(x) = x then msgbox "Truth" else msgbox "Falsehood" end if

VBScripts evaluates both sides of the 'and' even though isnumeric() returns false. The result of this statement is an error for calling abs() on a string.

To implement this logic you would need: x = "test" if isnumeric(x) then if abs(x) = x then msgbox "Truth" else msgbox "Falsehood" end if else msgbox "Falsehood" end if

Now THAT is a WTF.

ammoQ · 2006-09-06 Reply Admin

DigitalLogic:
I think we just stumbled upon the REAL wtf. VBScript evaluates all operations even if the boolean logic has been satisfied.

AFAIK this is the normal behaviour of Visual Basic, it's only natural for VBScript to do the same.

2006-09-06 Reply Admin

Anonymous:

Also, I try to avoid string concatenation (string & "") as much as I possibly can.

Well, string & "" is a no-op anyway (unless string was a real null or something other than an empty string, and you want the operation to do an implicit conversion). Why would you concatenate an empty string to a string?

drdamour · 2006-09-06 Reply Admin

Anonymous:
A number of people have tried to correct your misunderstanding on this point, but you just repeat it. Do you not think it would be a good idea to do some serious reading on the subject before arguing with people like biziclop who clearly understand the subject better than you?

No, a number of people have tried to argue a couterpoint to mine. In fact i have done serious reading on this subject. I have degrees in computer science and computer engineering. Just because you agree with their points, and they agree with each others doesn't make it the correct point.

More importantly, i was throwing out a hypothesis, and when people made their arguement i made counter arguements to support mine.

I will agree that the common definition of security through obscurity is what you guys have been refering to, and was very well stated:

Talchas:
The standard definition is if the algorithm is hidden - because then you have no way of testing how secure the algorithm is. Almost any security/cryptography system requires a key to be kept secret to function, that is the whole point. A good system only requires the key to be secret to be secure.

I was simply stating that given the definition of obscurity http://dictionary.reference.com/search?q=obscurity, maybe it should be thought of a little broder. There are other forms of security that absolutely cannot be confused with obscurity.

But thanks for completely missing my point

2006-09-06 Reply Admin

Alex Papadimoulis:

And finally, Nate had a chance to see this secret security code file ...

''' BEGIN SecurityInclude.asp
Dim userID
userID = Request.Cookies("userid").Value
If (Len(userID) = 0 or Trim(userID) = "") Then
Response.Redirect ("/default.asp")
End If
''' END SecurityInclude.asp

I get it now. If my userID consists of spaces only I can't log in. What an oversight.

2006-09-06 Reply Admin

drdamour:
I have degrees in computer science and computer engineering.

Oh well then, I guess you have to be right then. And all the other people here with CS and CE degrees are wrong.

ole gustie · 2006-09-06 Reply Admin

DigitalLogic:
Anonymous:
Pink Duck:
    Compelled to optimise....
    If (Len(userID) = 0 or Trim(userID) = "") Then
    If Len(Trim(userID)) = 0 Then

That looks like an optimisation, but it will actually perform worse in some cases: namely, when Len(userid) = 0, the first part of the first 'if' expression will be true, and the second part will be skipped.

Why not just:
    if Trim(userid) = ""

I think we just stumbled upon the REAL wtf. VBScript evaluates all operations even if the boolean logic has been satisfied.

x = "test" if isnumeric(x) and abs(x) = x then msgbox "Truth" else msgbox "Falsehood" end if

VBScripts evaluates both sides of the 'and' even though isnumeric() returns false. The result of this statement is an error for calling abs() on a string.

To implement this logic you would need: x = "test" if isnumeric(x) then if abs(x) = x then msgbox "Truth" else msgbox "Falsehood" end if else msgbox "Falsehood" end if

Now THAT is a WTF.

I know vb.net provides "AndAlso" and "OrElse" operators that will do the optimized boolean comparisons. Not positive, but I think that earlier versions of VB provide those operators as well. That said, I don't understand why VB gives the programmer the option to use "And" vs. "AndAlso". Can anyone think of a reason where evaluting all expressions, even after the boolean logic has been satisifed, is desired behavior?

ole gustie · 2006-09-06 Reply Admin

ole gustie:
DigitalLogic:
Anonymous:
Pink Duck:
    Compelled to optimise....
    If (Len(userID) = 0 or Trim(userID) = "") Then
    If Len(Trim(userID)) = 0 Then

That looks like an optimisation, but it will actually perform worse in some cases: namely, when Len(userid) = 0, the first part of the first 'if' expression will be true, and the second part will be skipped.

Why not just:
    if Trim(userid) = ""

I think we just stumbled upon the REAL wtf. VBScript evaluates all operations even if the boolean logic has been satisfied.

x = "test" if isnumeric(x) and abs(x) = x then msgbox "Truth" else msgbox "Falsehood" end if

VBScripts evaluates both sides of the 'and' even though isnumeric() returns false. The result of this statement is an error for calling abs() on a string.

To implement this logic you would need: x = "test" if isnumeric(x) then if abs(x) = x then msgbox "Truth" else msgbox "Falsehood" end if else msgbox "Falsehood" end if

Now THAT is a WTF.

I know vb.net provides "AndAlso" and "OrElse" operators that will do the optimized boolean comparisons. Not positive, but I think that earlier versions of VB provide those operators as well. That said, I don't understand why VB gives the programmer the option to use "And" vs. "AndAlso". Can anyone think of a reason where evaluting all expressions, even after the boolean logic has been satisifed, is desired behavior?

maybe:
IF X AND Y
where Y is a function that does some work and returns a boolean. And the work in done in Y needs to happen regardless of the value of X. Although that would be pretty WTF all by itself.

2006-09-06 Reply Admin

drdamour:

More importantly, i was throwing out a hypothesis, and when people made their arguement i made counter arguements to support mine.

I will agree that the common definition of security through obscurity is what you guys have been refering to, and was very well stated:

Definitions are nice. They let people talk about the same thing and know that each other is talking about the same thing.
"Security through obscurity" is a fairly well defined concept. If you would like to define a new phrase for the conecpt of security that requires *anything* to be secret, such as "security through secret keys", maybe that would let us have actual conversations about concepts and not definitions.

drdamour:
There are other forms of security that absolutely cannot be confused with obscurity.

However, you haven't given us an example of this. While your telnet example may be more secure, at the root it still requires secret data, namely a password. I can imagine scenarios where the delaying tactic could be subverted, such as through a distributed attack.

2006-09-06 Reply Admin

mmm if this was only a snippit of the SecurityInclude.asp i wouldn't even judge it as a WTF.
It's just common sense to first check if there even is a userid to do stuff with.

but it's pretty non-enterprise to not atleast have this encapsulated in a dozen objects.

Then you can make it look impressive like

$site_config = new site_config($_SESSION,$_REQUEST);
$security = new Security();

if ($security->user_loggedin()) {
//bla
}

where user_loggedin offcourse only contains

if (is_array($_SESSION['user'])) {
return true;
}
return false;

:P
but heck it's good enough for the things i make.
And i could argue that reading from session is secure, but i believe that's already been done.

2006-09-06 Reply Admin

ole gustie:
Anonymous:

Having worked for several fortune-50 companies over the past 25 years, I am sad to report that this sort of thing is more norm than abberation.

Among the fortune 50 from 2005 are:
Citigroup
Fannie Mae
Bank of America Corp
J.P. Morgan Chase & Co
Morgan Stanley
State Farm Insurance Cos

So... what you are saying is that my bank and credit card statements, mortage info, investment portfolio, and insurance records could be just a few stupid simple hacks away from being public knowledge? Holy scary shit batman.

"It was a fairly small project and a great foot in the door. Today an interactive brochure website..."

So I think the vault is probably still safe. Hacking an interactive brochure is unlikely to
bring down the company. More likely, newbies are allowed to work on this stuff while
the people who actually know something work on the critical apps.

RyuO · 2006-09-06 Reply Admin

Anonymous:
ole gustie:
Anonymous:

Having worked for several fortune-50 companies over the past 25 years, I am sad to report that this sort of thing is more norm than abberation.

Among the fortune 50 from 2005 are:
Citigroup
Fannie Mae
Bank of America Corp
J.P. Morgan Chase & Co
Morgan Stanley
State Farm Insurance Cos

So... what you are saying is that my bank and credit card statements, mortage info, investment portfolio, and insurance records could be just a few stupid simple hacks away from being public knowledge? Holy scary shit batman.

"It was a fairly small project and a great foot in the door. Today an interactive brochure website..."

So I think the vault is probably still safe. Hacking an interactive brochure is unlikely to
bring down the company. More likely, newbies are allowed to work on this stuff while
the people who actually know something work on the critical apps.

Well, sometimes. The most critical apps, the ones that handle money, are controlled by the few corporate people who know the value of a dollar (sorry for the Americanism). Therefore they'll tend to be lean and to have stood the test of time. This type of app is not likely to cause security issues; it is more likely to be secure from the ones who are supposed to use it.

Corporations take financial systems for granted, but what they think are critical apps are the status symbols: corporate portals, CRM, and the like. Those projects attract the "suits", and they fill up with all sorts of techies who can use business buzzwords and fast-talking consultants - the depth of WTFedness they achieve is beyond anything written up here (although the stories are longer). I've worked at two of the companies on that list of 6 above, not to mention another dozen or so in the top 50, and I can tell you that this type of project is, in fact, the norm.

Hector McCarthy · 2006-09-07 Reply Admin

Anonymous:
The essence of using session ids and encryption keys (and passwords if used properly) is that one can calculate how much time and effort is likely to be needed to break them. One can then increase the level of difficulty to whatever is necessary.

Exactly. The calculation is easy: complexity = min(complexity_of_attacks_I_know_about, complexity_of_attacks_I_dont_know_about)

Now all you need is the value of the second parameter...

drdamour · 2006-09-07 Reply Admin

Anonymous:
drdamour:
I have degrees in computer science and computer engineering.
Oh well then, I guess you have to be right then. And all the other people here with CS and CE degrees are wrong.

that is not what i said, and i'd appreciate it if you did not put words in my mouth.

this was simply a retort to the statement that "i needed to study-up" on the concepts. at no point did i say that my credentials made my case any more valid.

drdamour · 2006-09-07 Reply Admin

Anonymous:

However, you haven't given us an example of this. While your telnet example may be more secure, at the root it still requires secret data, namely a password. I can imagine scenarios where the delaying tactic could be subverted, such as through a distributed attack.

You are correct, i did NOT give you a good example of this.

Take the same system, but instead of there being a password for access, instead there was simply a command called "off". "off" is completely secure, noone should be able to invoke it. Every time someone does, "off" will warn you and make you timeout for (n)*5 seconds, where n is the number of times you've invoked the "off" command. now no password, but there is security.

sure it's a crappier example, but it does prove that punishment and passkeys are seperate concepts of security. We see this every day in banks. Yes you should have an account and passphrase or key to transfer out money of a bank's lockbox, but you can brute force your way in (maybe with a gun & crowbar) and get the money. What is the security for that? mostly the deterent of the punishment of getting caught, or the possibility of being injured in the attempt. the punishment, a form of security that certainly is not obscure.

2006-09-07 Reply Admin

Anonymous:

Compelled to optimise....

If (Len(userID) = 0 or Trim(userID) = "") Then

If Len(Trim(userID)) = 0 Then

Not really an optimisation, as you will ALWAYS execute Trim regardless of whether there's data there or not. The first one will detect an empty string and stop without even executing the Trim statement.

Secret Enterprise Security

Leave a comment on “Secret Enterprise Security”