The Daily WTF: Curious Perversions in Information Technology

2011-10-19 Reply Admin

no laughing matter:
geoffrey:
they wouldn't get near my DBS. It's ring fenced. I don't even call it a database, it's an abstract object constrainer. Uses constraints rather than relationships. There now look what you've made me done, I've reduced the security of my system by a slither of a % just by telling you aspects of how it works.
As long as it stays abstract (iow no concrete implementation) it will still be rather save!

In this case, I am thinking "abstract" meening "generic" which is being releesed in upcoming Java 1.5 relees.

2011-10-19 Reply Admin

If it makes you feel better, I would have given you 7 or 8/10.

2011-10-19 Reply Admin

the beholder:
geoffrey:
You might well laugh, but that same logic explains why elements of the military use their own custom hardware.
It's a matter of cost/benefit analysis. Is the cost of developing our own CPUs worth the extra security it would afford? It might be for the military, but not for an electronic commerce site.

But is the cost of developing our own backend database system for said eCommerce site worth the extra security it would provide? Yes yes and yes again.

Developing NSQL (Not SQL, for lack of a better name): 120 hours dev time

Millions of hackers wasting their time trying to enter snippets of SQL into the edit fields of your website: priceless

What an impressive performance. It's as if he really believes it. I wonder whether he researched how to push people's buttons or does he do it naturally.
I thought there was no way he could get someone with such an obvious trolling, but people never cease to impress me. Negatively, I mean.

geoffrey make good point about security of home-built systim. Not his falt you are being on wrung side of isue.

congnor · 2011-10-19 Reply Admin

Nagesh:
Nagesh:
congnor:
I see what happened here. The developer is from Russia and took his ideas from the Matryoshka doll. Hence this pointless but funny crypt inside hash inside (blah,blah)...

What is matryoshka doll? Is it like Barby?
GIYF, matterhorn

You really have to cut down on coffee!

2011-10-19 Reply Admin

Nagesh:
the beholder:
geoffrey:
You might well laugh, but that same logic explains why elements of the military use their own custom hardware.
It's a matter of cost/benefit analysis. Is the cost of developing our own CPUs worth the extra security it would afford? It might be for the military, but not for an electronic commerce site.

But is the cost of developing our own backend database system for said eCommerce site worth the extra security it would provide? Yes yes and yes again.

Developing NSQL (Not SQL, for lack of a better name): 120 hours dev time

Millions of hackers wasting their time trying to enter snippets of SQL into the edit fields of your website: priceless

What an impressive performance. It's as if he really believes it. I wonder whether he researched how to push people's buttons or does he do it naturally.
I thought there was no way he could get someone with such an obvious trolling, but people never cease to impress me. Negatively, I mean.
geoffrey make good point about security of home-built systim. Not his falt you are being on wrung side of isue.

You guys do realize that geoffrey and his other sock puppets are just waiting for you to bite, right?

Wait, did I just ...

... damnit!

2011-10-19 Reply Admin

sreagsgio:
geoffrey:
C-Octothorpe:
geoffrey:
The real smart developers don't even use SQL, they spin their own custom in-house database system, or use a slightly less obscure 3rd party database system.
The smart hackers will be put off when they realize the backend of the website is not even using SQL and will go off for an easier target.

It's not a popular view I know. But that's because the widespread belief that "industry standard" database systems using SQL should be chosen in development is pure dogma driven by a desire to not have to bother writing a DBS or to bother knowing how to write one.
3/10. Funny, but a little forced. Let's see how many bites you get...

Thanks for proving my point about dogma. You haven't even considered my point, you've just assumed it's false because you've been taught to believe "industry standard" systems are superior to in-house developed systems.

Now there IS obviously benefit in both training and development time in just gluing together well known systems (eg pull MySQL off the shelf instead of rolling out your own alternative). But that comes at a cost of security and, dare I say, a loss of true skilled dev jobs. Nowadays development is just consists of clowns who can glue systems together.

Ask yourself this - who actually quantified the costs vs the benefits to establish the popular idea that in-house systems are inferior? Or is the "popular" idea simply a dogma from beginning to end?

That's why make my own CPUs directly from sand.

You've clearly missed the point. EVERYBODY makes them from sand. You should make your CPUs from wood, or from helium.

2011-10-19 Reply Admin

In Soviet Russia, password hashes YOU!

2011-10-19 Reply Admin

Jay:
sreagsgio:
geoffrey:
C-Octothorpe:
geoffrey:
The real smart developers don't even use SQL, they spin their own custom in-house database system, or use a slightly less obscure 3rd party database system.
The smart hackers will be put off when they realize the backend of the website is not even using SQL and will go off for an easier target.

It's not a popular view I know. But that's because the widespread belief that "industry standard" database systems using SQL should be chosen in development is pure dogma driven by a desire to not have to bother writing a DBS or to bother knowing how to write one.
3/10. Funny, but a little forced. Let's see how many bites you get...

Thanks for proving my point about dogma. You haven't even considered my point, you've just assumed it's false because you've been taught to believe "industry standard" systems are superior to in-house developed systems.

Now there IS obviously benefit in both training and development time in just gluing together well known systems (eg pull MySQL off the shelf instead of rolling out your own alternative). But that comes at a cost of security and, dare I say, a loss of true skilled dev jobs. Nowadays development is just consists of clowns who can glue systems together.

Ask yourself this - who actually quantified the costs vs the benefits to establish the popular idea that in-house systems are inferior? Or is the "popular" idea simply a dogma from beginning to end?

That's why make my own CPUs directly from sand.

You've clearly missed the point. EVERYBODY makes them from sand. You should make your CPUs from wood, or from helium.

I can't recommend helium. Anchoring the machine to the desk has been a real nuisance, and it's really hard to get the speech synthesizers to output at the correct pitch.

Wood might work, but you have to manage project discipline...

...

... you wouldn't want to have to deal with a splinter group.

2011-10-19 Reply Admin

trtrwtf:
Jay:
sreagsgio:
geoffrey:
C-Octothorpe:
geoffrey:
The real smart developers don't even use SQL, they spin their own custom in-house database system, or use a slightly less obscure 3rd party database system.
The smart hackers will be put off when they realize the backend of the website is not even using SQL and will go off for an easier target.

It's not a popular view I know. But that's because the widespread belief that "industry standard" database systems using SQL should be chosen in development is pure dogma driven by a desire to not have to bother writing a DBS or to bother knowing how to write one.
3/10. Funny, but a little forced. Let's see how many bites you get...

Thanks for proving my point about dogma. You haven't even considered my point, you've just assumed it's false because you've been taught to believe "industry standard" systems are superior to in-house developed systems.

Now there IS obviously benefit in both training and development time in just gluing together well known systems (eg pull MySQL off the shelf instead of rolling out your own alternative). But that comes at a cost of security and, dare I say, a loss of true skilled dev jobs. Nowadays development is just consists of clowns who can glue systems together.

Ask yourself this - who actually quantified the costs vs the benefits to establish the popular idea that in-house systems are inferior? Or is the "popular" idea simply a dogma from beginning to end?

That's why make my own CPUs directly from sand.

You've clearly missed the point. EVERYBODY makes them from sand. You should make your CPUs from wood, or from helium.

I can't recommend helium. Anchoring the machine to the desk has been a real nuisance, and it's really hard to get the speech synthesizers to output at the correct pitch.

Wood might work, but you have to manage project discipline...

...

... you wouldn't want to have to deal with a splinter group.

A Brahman, a Sikh, and a Muslem walk into a bar. The bartender say: "What is this? Some sort of joking?"

2011-10-19 Reply Admin

trtrwtf:
Jay:
sreagsgio:
That's why make my own CPUs directly from sand.
You've clearly missed the point. EVERYBODY makes them from sand. You should make your CPUs from wood, or from helium.
Wood might work, but you have to manage project discipline... I like where this is going ...you wouldn't want to have to deal with a disobedient slave.

Wood is always the best fit. Rubber will do in a pinch.

Nagesh · 2011-10-19 Reply Admin

Glass is also good matrial to meke CPU. Samsung company has build several CPU from glass. They will release to market in 2015.

2011-10-19 Reply Admin

Nagesh:
A Brahman, a Sikh, and a Muslim walk into a bar. The bartender say: "Can't you read the sign? No darkies!"

What's the difference? They're all turban-wearing pederasts. My kinda guys!

Seems like a good place to hide your stash.

2011-10-19 Reply Admin

Nagesh:
trtrwtf:
Jay:
sreagsgio:
geoffrey:
C-Octothorpe:
geoffrey:
The real smart developers don't even use SQL, they spin their own custom in-house database system, or use a slightly less obscure 3rd party database system.
The smart hackers will be put off when they realize the backend of the website is not even using SQL and will go off for an easier target.

It's not a popular view I know. But that's because the widespread belief that "industry standard" database systems using SQL should be chosen in development is pure dogma driven by a desire to not have to bother writing a DBS or to bother knowing how to write one.
3/10. Funny, but a little forced. Let's see how many bites you get...

Thanks for proving my point about dogma. You haven't even considered my point, you've just assumed it's false because you've been taught to believe "industry standard" systems are superior to in-house developed systems.

Now there IS obviously benefit in both training and development time in just gluing together well known systems (eg pull MySQL off the shelf instead of rolling out your own alternative). But that comes at a cost of security and, dare I say, a loss of true skilled dev jobs. Nowadays development is just consists of clowns who can glue systems together.

Ask yourself this - who actually quantified the costs vs the benefits to establish the popular idea that in-house systems are inferior? Or is the "popular" idea simply a dogma from beginning to end?

That's why make my own CPUs directly from sand.

You've clearly missed the point. EVERYBODY makes them from sand. You should make your CPUs from wood, or from helium.

I can't recommend helium. Anchoring the machine to the desk has been a real nuisance, and it's really hard to get the speech synthesizers to output at the correct pitch.

Wood might work, but you have to manage project discipline...

...

... you wouldn't want to have to deal with a splinter group.

A Brahman, a Sikh, and a Muslem walk into a bar. The bartender say: "What is this? Some sort of joking?"

The muslem then explode with laughter.

Matt Westwood · 2011-10-19 Reply Admin

geoffrey:
Rawr:
geoffrey:
C-Octothorpe:
geoffrey:
The real smart developers don't even use SQL, they spin their own custom in-house database system, or use a slightly less obscure 3rd party database system.
The smart hackers will be put off when they realize the backend of the website is not even using SQL and will go off for an easier target.

It's not a popular view I know. But that's because the widespread belief that "industry standard" database systems using SQL should be chosen in development is pure dogma driven by a desire to not have to bother writing a DBS or to bother knowing how to write one.
3/10. Funny, but a little forced. Let's see how many bites you get...

Thanks for proving my point about dogma. You haven't even considered my point, you've just assumed it's false because you've been taught to believe "industry standard" systems are superior to in-house developed systems.

Now there IS obviously benefit in both training and development time in just gluing together well known systems (eg pull MySQL off the shelf instead of rolling out your own alternative). But that comes at a cost of security and, dare I say, a loss of true skilled dev jobs. Nowadays development is just consists of clowns who can glue systems together.

Ask yourself this - who actually quantified the costs vs the benefits to establish the popular idea that in-house systems are inferior? Or is the "popular" idea simply a dogma from beginning to end?

Meh, it's going downhill. I think if you left only the first argument you would have trolled more people.

Oh no I might accidentally educate them instead!

Tell you what, you can even write it in COBOL if you want.

Matt Westwood · 2011-10-19 Reply Admin

geoffrey:
C-Octothorpe:
geoffrey:
C-Octothorpe:
geoffrey:
The real smart developers don't even use SQL, they spin their own custom in-house database system, or use a slightly less obscure 3rd party database system.
The smart hackers will be put off when they realize the backend of the website is not even using SQL and will go off for an easier target.

It's not a popular view I know. But that's because the widespread belief that "industry standard" database systems using SQL should be chosen in development is pure dogma driven by a desire to not have to bother writing a DBS or to bother knowing how to write one.
3/10. Funny, but a little forced. Let's see how many bites you get...

Thanks for proving my point about dogma. You haven't even considered my point, you've just assumed it's false because you've been taught to believe "industry standard" systems are superior to in-house developed systems.

Now there IS obviously benefit in both training and development time in just gluing together well known systems (eg pull MySQL off the shelf instead of rolling out your own alternative). But that comes at a cost of security and, dare I say, a loss of true skilled dev jobs. Nowadays development is just consists of clowns who can glue systems together.

Ask yourself this - who actually quantified the costs vs the benefits to establish the popular idea that in-house systems are inferior? Or is the "popular" idea simply a dogma from beginning to end?

Ha! Ok, I'll bite...
Tell me, if I'm a contractor coming to your house to build an addition (say a sunroom), would you think it a good option for me to build all my tools (including the backhoe) from scratch before starting any real construction.

If people could exploit your use of a backhoe to tear down my house, yeah Id rather you use something custom.

"Or if I'm installing some doors, would you rather me install my "very own designed and built" locks vs., oh, I don't know, any tried-and-tested product for a fraction of the cost (i.e. Stanley), which backs their products, etc.?"

No because the issue isn't locks. The issue is glass. Thieves tend to go through the window.

It's a form of delusion whenein the sufferer (you) truly believes their small team of "crack" devs could outsmart teams of hundreds domain experts who have developed and QAed a product for years.

You are forgetting that there are two teams in this. The devs and the hackers. Your team of hundreds of domain experts is balanced against an even larger team of hackers in the wild attracted by all the attention.

None of this is as clear cut as the dogma would like.

HAAAA-ha! You have fucked up the quote integrity! By the rules of TDWTF argumentation, that means YOU HAVE LOST! FOAD!

Kuba · 2011-10-19 Reply Admin

geoffrey:
Developing NSQL (Not SQL, for lack of a better name): 120 hours dev time

Maybe for a very small value of "developing". 120 hours isn't enough to write even the most rudimentary test harness. Just look at what process they employ to test sqlite. The latter is pretty much tested to be certifiable for use in certain kinds of safety critical equipment.

As of version 3.7.8 (all statistics in the report are against that release of SQLite), the SQLite library consists of approximately 77.6 KSLOC of C code. (KSLOC means thousands of "Source Lines Of Code" or, in other words, lines of code excluding blank lines and comments.) By comparison, the project has 1177 times as much test code and test scripts - 91392.4 KSLOC.

Matt Westwood · 2011-10-19 Reply Admin

geoffrey:
they wouldn't get near my DBS. It's ring fenced. I don't even call it a database, it's an abstract object constrainer. Uses constraints rather than relationships. There now look what you've made me done, I've reduced the security of my system by a slither of a % just by telling you aspects of how it works.

Gotcha. There is only one way that could have been designed with the parameters you have supplied (including the fact that it took 120 hours of dev time. I have taken that into account and have written a program that cracks your DB wide open.

I pwn you.

Kuba · 2011-10-19 Reply Admin

trtrwtf:
Jay:
You've clearly missed the point. EVERYBODY makes them from sand. You should make your CPUs from wood, or from helium.

I can't recommend helium. Anchoring the machine to the desk has been a real nuisance, and it's really hard to get the speech synthesizers to output at the correct pitch.

I'd call this response punting. As in putting different pun into OP's mouth.

I believe Jay meant it so: Start with helium. Fuse it to obtain necessary elements (Si, O, P, ..). Then build a CPU.

Matt Westwood · 2011-10-19 Reply Admin

C-Octothorpe:
Ayn Rand():
I think its because he used the word 'Dogma' enough, to describe my beliefs. It really made me see how I have been living the life of an uninformed, conformist, fool all these years.
I think he just learned that word today...

Hey, didn't Melanie do a song about that?

"Look what they've done to my dogma, Look what they've done to my dogma, Turned it round, inside out, gave it quite a snog, ma Look what they've done to my dogma ..."

2011-10-19 Reply Admin

Well, thanks everyone for one of the funnier threads here. (Even if I'm not completely certain which of the comments were deliberately funny.)

2011-10-19 Reply Admin

Cris:
Alex:
The concatenation operator in PHP is ".", not "+" (addition). Because of how the addition operator performs typecasting, that line is essentially equivalent to:
custom_step(123, $seed);

...except in cases where crypt returns a string that begins with "valid numeric data". Then it's the sum of the "valid numeric data" and 123 as the first argument. What counts as "valid numeric data"? Read this: http://sg.php.net/manual/en/language.types.string.php#language.types.string.conversion
Even without this error, when you stack layers of encryption on "the real password" all the hacker has to do is brute force any input value that passes the test -- which may or may not equal the original password. So your algo becomes as strong as its weakest link. For example:

check = super_crypt (weak_crypt (user_input)) if check = super_crypted_password_in_database ...

Say weak_crypt only returns two bits, or a total of four possible values. Then it doesn't matter if super_crypt makes 16 passes and returns a 2048 byte string... there will still be only four possible values, and thus the hacker can pass the equals test in about 2 tries.

It's also conceivable that strong_crypt1(strong_crypt2(x)) is actually weaker than either strong_crypt2 or strong_crypt2 for similar reasons: you may make from two functions that are (maybe not everywhere, but generally) one-password-to-one-crypt-value into one function that is (generally) many-passwords-to-one-crypt-value. I wouldn't know if that could happen with the given functions, but as I recall, it's a well known possible scenario with encryption of any sort.

Matt Westwood · 2011-10-19 Reply Admin

trtrwtf:
Seriously. I'm all for reinventing wheels - you learn a lot about wheels that way. I'm big on knowing about how things work under the hood. I usually find it difficult and annoying to learn someone else's interface, and I'd often prefer to just write it myself.
But.

... tl;dr

Reinventing wheels is essential for the purposes of education. Part of any comprehensive education system in learning how to get computers to do stuff should include bits where you get the noobs to create standard building blocks.

When I trained, they got us first writing a variety of sort routines, then a calendar, then an emulator / disassembler of a simple CPU (they were simple enough in those days for this to be feasible), and then they let us loose on real stuff (with the caveat to always use the library routines because they were better than the shit we wrote).

2011-10-19 Reply Admin

the beholder:
geoffrey:
You might well laugh, but that same logic explains why elements of the military use their own custom hardware.
It's a matter of cost/benefit analysis. Is the cost of developing our own CPUs worth the extra security it would afford? It might be for the military, but not for an electronic commerce site.

But is the cost of developing our own backend database system for said eCommerce site worth the extra security it would provide? Yes yes and yes again.

Developing NSQL (Not SQL, for lack of a better name): 120 hours dev time

Millions of hackers wasting their time trying to enter snippets of SQL into the edit fields of your website: priceless

What an impressive performance. It's as if he really believes it. I wonder whether he researched how to push people's buttons or does he do it naturally.
I thought there was no way he could get someone with such an obvious trolling, but people never cease to impress me. Negatively, I mean.

I am sad this is a troll. I thought, just maybe, there is still an OS370 gray hair still bent on ISAM as the One True Way(tm). The bit about using SQL is somewhat reasonable (I really hate XPATH) but then bashing RDBMS in general. No big iron machine accountant would cross IBM that way...

2011-10-19 Reply Admin

(md5(sha1(sha2(mcrypt_cbc($password)))))

It's not uncommon to hash multiple times, but usually you would be appending a salt in between each hash:

$hashed_salted_pass = sha1(sha1($password).$salt);

You wouldn't just hash the digest of the previous hash directly. That's kind of pointless.

Also, why would anyone hash a more secure digest (sha1) with a smaller, and less secure digest (md5)? The addition of the md5 function actually makes it less secure, than if they would just have left it out.

It's also arguable whether it's worth encrypting the password itself before hashing it... Since this encryption involves a key that must be stored somewhere (example: in a config), so if someone compromised the host machine and had access to the database, then they would likely also have the key.

2011-10-19 Reply Admin

Whatever happened to Top Cod3r I miss him.

Matt Westwood · 2011-10-19 Reply Admin

Kuba:
trtrwtf:
Jay:
You've clearly missed the point. EVERYBODY makes them from sand. You should make your CPUs from wood, or from helium.

I can't recommend helium. Anchoring the machine to the desk has been a real nuisance, and it's really hard to get the speech synthesizers to output at the correct pitch.
I'd call this response punting. As in putting different pun into OP's mouth.

I believe Jay meant it so: Start with helium. Fuse it to obtain necessary elements (Si, O, P, ..). Then build a CPU.

Iron several others are fluorine you with our puns. You wouldn't lead us go on boron you so it's back to chlorine your way back up the greasy pol-onium about to gold down with flu-orine your case I'd just say: 'tin right.

2011-10-19 Reply Admin

David:
Steve The Cynic:
So the idiot colleague thinks that an encrypted hashed hashed hashed encrypted password is more secure than one that is merely hashed. Wonderful.

I've heard people say this before. Can someone explain why this isn't more secure? I'm not arguing that it actually is. Security is not really my field, so I'd just like someone to give me the "For Dummies" overview of why this doesn't help.

My thought process (and clearly the guy who wrote it like this) would be that you'd have to brute force it multiple times AND know the exact order that the encryptions were applied.

I can't be the only one in the dark, so someone help the rest of us learn something new today.

As of knowing order of hash functions read about Kerckhoffs's principle
Function h = H(m) (hash function) generates b-bit length "pseudorandom" noise if it is secure (yes - I know it strange but the function is both constant and "random"). Applying it twice lowers the security further due as if probability of 2 hashes (one chosen and one random) having the same hash is 1:2^b but the probability of hashes of hashes to be the same is (1/2^b + (1 - 1/2^b)*1/2^b) i.e. approximately 1/2^(b-1) assuming 0 ≪ b. In general, if I haven't made any stupid error, you get approximately 1/2^(b-n) chance of succeeding after n tries (assuming n ⋘ b and 0 ≪ b). That's not a big problem for small n but still it exists.
You reduces the search space for offline attacks. To simplify I will use 2 hashes H(H'(m)) where m ∈ S - space of all possible passwords (a, b, ... aa, ... Aa, ... &UH..&, ...). Unless the dictionary attack is successful you need to traverse all of the searchspace in case of H(m) which is unbounded. In case of H(H'(m)) where H' is b-bit hash you have only 2^b options which is much smaller then infinity ;). In practice the users make have S' ⊆ S (S' is space that users choose - say password etc.) where |S'| ≪ 2^b.
Combining few algorithms make it easier to break as you need to break the easier one. Here you have security on level of md5.
It does increase security as it have non-standard rainbow table and therefore you cannot just go and buy one, However there are much more sound methods of dealing with it (for example salt).
It does increase security as it adds some time to computation. However it is probably better to use sound method such as bcrypt.

PS. It is not encryption but hash. While multiple levels of encryption do increase security it is not necessary the case with hash.

2011-10-19 Reply Admin

Ha! I have outsmarted you all! I eliminated the database vulnerability entirely. I just do:

RESULT=grep $USER_INPUT mydatafile

There's no way that could fall to SQL injection. No SQL: no problem!

2011-10-19 Reply Admin

Nagesh:
the beholder:
geoffrey:
You might well laugh, but that same logic explains why elements of the military use their own custom hardware.
It's a matter of cost/benefit analysis. Is the cost of developing our own CPUs worth the extra security it would afford? It might be for the military, but not for an electronic commerce site.

But is the cost of developing our own backend database system for said eCommerce site worth the extra security it would provide? Yes yes and yes again.

Developing NSQL (Not SQL, for lack of a better name): 120 hours dev time

Millions of hackers wasting their time trying to enter snippets of SQL into the edit fields of your website: priceless

What an impressive performance. It's as if he really believes it. I wonder whether he researched how to push people's buttons or does he do it naturally.
I thought there was no way he could get someone with such an obvious trolling, but people never cease to impress me. Negatively, I mean.
geoffrey make good point about security of home-built systim. Not his falt you are being on wrung side of isue.

Option 1: Developing your own obscure in-house system that is guaranteed to be flawed, poorly maintained, and probably worse-performing than a real RDBMS with a fraction of the functionality, knowing full well that it will have vulnerabilities of it's own and "security-through-obscurity" doesn't work forever.

Option 2: Learn how to sanitize your inputs properly.

Hmm... tough choice.

On a side note, how did this TDWTF become about SQL?

ObiWayneKenobi · 2011-10-19 Reply Admin

geoffrey:
The real smart developers don't even use SQL, they use an ORM.

FTFY

Nagesh · 2011-10-19 Reply Admin

ObiWayneKenobi:
geoffrey:
The real smart developers don't even use SQL, they use an ORM.

FTFY

Finaly, someone who thinking like me. +1111111

no laughing matter · 2011-10-19 Reply Admin

David:
...

Nah, that's just WRONG!

In the future, please enter your correct forename.

Let me fix that for you (and slightly increase the meme density):

Bob:
My son had NIH Syndrome and I assure you it is no laughing matterhorn. In the future, please try to show more sensitivity.

2011-10-19 Reply Admin

big picture thinker:
Option 1: Developing your own obscure in-house system that is guaranteed to be flawed, poorly maintained, and probably worse-performing than a real RDBMS with a fraction of the functionality, knowing full well that it will have vulnerabilities of it's own and "security-through-obscurity" doesn't work forever.
Option 2: Learn how to sanitize your inputs properly.

Hmm... tough choice.

Option 1 no-brainer. That way you secure lifetime job for yourself.

2011-10-19 Reply Admin

no laughing matter:
David:
...
Nah, that's just WRONG!
In the future, please enter your correct forename.

Let me fix that for you (and slightly increase the meme density):

Bob:
My son had NIH Syndrome and I assure you there is no laughing matterhorn up my ass. In the future, realize that your not too bright, but who cares? anyway, you're too immature and too stupid to be attempting matterhorn insertions.
Sincerely, Burp Glandzune

ZTFY >;P

2011-10-19 Reply Admin

What is this story about matterhorn BTW? He stole someone's account because his password wasn't triple-hashed right?

boog · 2011-10-19 Reply Admin

Bronie:
big picture thinker:
Option 1: Developing your own obscure in-house system that is guaranteed to be flawed, poorly maintained, and probably worse-performing than a real RDBMS with a fraction of the functionality, knowing full well that it will have vulnerabilities of it's own and "security-through-obscurity" doesn't work forever.
Option 2: Learn how to sanitize your inputs properly.

Hmm... tough choice.

Option 1 no-brainer. That way you secure lifetime job for yourself.

A lifetime stuck in the same boring job, supporting the same broken system until retirement. Sounds like quite the dream.

Zylon · 2011-10-19 Reply Admin

Anyway, TRWTF is that the guy who wrote that code forgot the rot13() step.

2011-10-19 Reply Admin

Zylon:
Anyway, TRWTF is that the guy who wrote that code forgot the rot13() step.

ROT13 is not valid hash Algorerhythm.

D-Coder · 2011-10-19 Reply Admin

Nabhi Singh:
Whatever happened to Top Cod3r I miss him.

Brainectomy. Now he's Nagesh.

The Great Lobachevsky · 2011-10-19 Reply Admin

WOOSH! I love that cool-mountain air feeling of a meme blowing by.

PS: My very non-technical mom has asked me on several occasions what the word "algorithm" means. I keep trying to give her definitions on her level but it isn't working very well... I'm tempted to pull out a cookbook and point to a recipe and tell her it is an algorithm for pot roast. :)

Matt Westwood · 2011-10-19 Reply Admin

boog:
Bronie:
big picture thinker:
Option 1: Developing your own obscure in-house system that is guaranteed to be flawed, poorly maintained, and probably worse-performing than a real RDBMS with a fraction of the functionality, knowing full well that it will have vulnerabilities of it's own and "security-through-obscurity" doesn't work forever.
Option 2: Learn how to sanitize your inputs properly.

Hmm... tough choice.

Option 1 no-brainer. That way you secure lifetime job for yourself.
A lifetime stuck in the same boring job, supporting the same broken system until retirement. Sounds like quite the dream.

Even more perfect if you live in the basement of the business for which you work. Just think: never late for work because of the traffic. And you won't ever need to exercise either your brain *or* your body. As I say, utterly fucking perfect.

2011-10-19 Reply Admin

Rupee:
David:

Steve The Cynic:
So the idiot colleague thinks that an encrypted hashed hashed hashed encrypted password is more secure than one that is merely hashed. Wonderful.
I've heard people say this before. Can someone explain why this isn't more secure? I'm not arguing that it actually is. Security is not really my field, so I'd just like someone to give me the "For Dummies" overview of why this doesn't help.
My thought process (and clearly the guy who wrote it like this) would be that you'd have to brute force it multiple times AND know the exact order that the encryptions were applied.

I can't be the only one in the dark, so someone help the rest of us learn something new today.

Performing multiple hashes can make it harder to brute force a password - because it adds a few milliseconds to your authentication process, but could add years to a brute force attack. Checkout Key Stretching. Checkout bcrypt as it has a built in mechanism to avoid the need for key stretching.

It's interesting because Moore's Law about computer speed doubling every so often means that an algorithm that is secure today may be brute forced in 10 years time when computers are faster.

Using different algorithms adds some strength in that if a vulnerability is discovered in one, it won't leave you open to attack.

Having a special hashing order like in this example gives you some security through obscurity - but you can't rely on that.

My PHP ain't great, but it looks like this guy has gone a little over the top. I reckon I'd "WTF" if I came across that - but it's not as shocking as people are making out.

This was my thoughts too. Multiple hashing would be less prone to Rainbow Table lookups - of course, adding a good salt should be able to provide the same effect, if I'm not mistaken.

The bigger issue (based on comments) seems to be that of the SQL injection - that's based on the final comment, rather than the actual code excerpt posted. The article seemed to suggest the approach to Hashing was the issue....

congnor · 2011-10-19 Reply Admin

Bronie:
What is this story about matterhorn BTW? He stole someone's account because his password wasn't triple-hashed right?

First rule in Hyderabad is you don't talk about Matterhorning your relatives.

Naljnl, pbssrr?

2011-10-19 Reply Admin

someone:
Using several hashs is actually way more secure, but using crypt as final step can be an real problem, since it only considers the first 8 characters. If the md5 is hex-encoded, we just have to find a collision of the first 4 md5 bytes to login. (on the other hand the exact password can never be found)

How is multiple hashing more secure? 1) Single Hash - vulnerable to Rainbow table 2) Double Hash - Rainbow Table needs to be site-specific (assuming noone else hashes in the same order as you) 3) Multiple Hash - as secure as 2 4) Single Hash with a good salt (eg based on a constant and a variable) - as good if not better than 2 (depending on whether 2 uses any salt).

Perhaps the resistance to a Brute Force attack mentioned by someone else might be a factor, but just lock the account after 5 bad entries and brute force becomes rather difficult (even if a hacker assumes a person will log on once a day, and that they can safely have 2 attempts at the password every day, there is still a massive risk that they'll lock the account (if someone takes holidays, for example, or sick leave) - not to mention, rather than adding a couple of milliseconds to each Authentication attempt, the hacker is forced to wait 24 hrs between attempts, and probably can't reliably make an attempt on weekends - adding centuries to any attempt.

Agree (I think) on the crypt thing, though (if it really does only use 8 char).

People are over obsessed with Security. You need to look at what you are trying to protect against. Passwords on accounts that can never lock (such as SysAdmin passwords - presumably you don't want to through out an entire system just because the SysAdmin forgot the password) need to be very secure. Other passwords (even the one you use for banking) can be less secure. Justification:

Brute force is stopped by Locking Accounts
Rainbow Table would require hacker to have access to password hash - in which case he's probably breached the system already, and the system has a major issue - he would presumably be able to see any scheme that is used to obfuscate passwords....

Just don't use stupidly easy passwords (username (or derivative of), pet's name, "Blink182", "qwe123", "password1", "4got10", "abc123", "summer99", etc....)

2011-10-19 Reply Admin

geoffrey:
C-Octothorpe:
geoffrey:
The real smart developers don't even use SQL, they spin their own custom in-house database system, or use a slightly less obscure 3rd party database system.
The smart hackers will be put off when they realize the backend of the website is not even using SQL and will go off for an easier target.

It's not a popular view I know. But that's because the widespread belief that "industry standard" database systems using SQL should be chosen in development is pure dogma driven by a desire to not have to bother writing a DBS or to bother knowing how to write one.
3/10. Funny, but a little forced. Let's see how many bites you get...

Thanks for proving my point about dogma. You haven't even considered my point, you've just assumed it's false because you've been taught to believe "industry standard" systems are superior to in-house developed systems.

Now there IS obviously benefit in both training and development time in just gluing together well known systems (eg pull MySQL off the shelf instead of rolling out your own alternative). But that comes at a cost of security and, dare I say, a loss of true skilled dev jobs. Nowadays development is just consists of clowns who can glue systems together.

Ask yourself this - who actually quantified the costs vs the benefits to establish the popular idea that in-house systems are inferior? Or is the "popular" idea simply a dogma from beginning to end?

It's like everything, the bottom line is money, and less money now seems to appeal more than more money now, less in the future. There's also a severe distrust in Developers, which is quite a catch 22 because it means that people don't listen to developer's concerns, and then complain that the developers are unable to get the results expected - despite the fact that their opinions earlier would have helped.

Some years ago, we were updating some identity resolution software, and the company who makes the software recommended that rather than use their libraries (which we would have to (quite cumbersomely) meld into our application, we should consider their 'out of the box' system which could integrate simply with the database we use, and simplify the calls to the library so that it would be as simple as offering it some personal details and their system would magically find results. The cost differential for licensing the libraries vs the 'out of the box' was significant (somewhere near 10 fold more for the 'out of the box'), so the powers that be, in their infinite wisdom dictated that we should instead use the raw libraries. I don't really know how much the total project cost (especially including some unexpected hiccups when we deployed), nor how much we are still paying for the poor decision now, but suffice it to say if people had had the guts to spend more upfront, we'd be ahead now...

I don't mean to look as though I'm arguing against your point - quite the opposite. The point is that the long term cost needs to be considered when making these sort of decisions. Unfortunately, the decision makers are often not technical (and rarely trust their teams technical talent either way) and consider upfront cost and support (but not support cost). Sometimes people probably are better off creating their own systems from scratch, rather than hacking an existing product into a state that is close to what they want...

2011-10-19 Reply Admin

Altourus:
Steve The Cynic:
So the idiot colleague thinks that an encrypted hashed hashed hashed encrypted password is more secure than one that is merely hashed. Wonderful.
Maybe someone should hash the colleague.

Yes because single hashed passwords are extremely secure, there is no way someone can take a hashed password and find out what the original password was... http://lmgtfy.com/?q=ae2b1fca515949e5d54fb22b8ed95575

The same applies for multiply hashed passwords - provided you know how they've been hashed...

Actually, you can never definitively find out what the original was, merely what would have created the same hash. In most systems, there are far more passwords available than the total number of hashes possible (that is, it's not a 1-1 relationship), so it might be possible to find a string that makes the same hash, but this is not necessarily the same password.

2011-10-19 Reply Admin

C-Octothorpe:
geoffrey:
C-Octothorpe:
geoffrey:
The real smart developers don't even use SQL, they spin their own custom in-house database system, or use a slightly less obscure 3rd party database system.
The smart hackers will be put off when they realize the backend of the website is not even using SQL and will go off for an easier target.

It's not a popular view I know. But that's because the widespread belief that "industry standard" database systems using SQL should be chosen in development is pure dogma driven by a desire to not have to bother writing a DBS or to bother knowing how to write one.
3/10. Funny, but a little forced. Let's see how many bites you get...

Thanks for proving my point about dogma. You haven't even considered my point, you've just assumed it's false because you've been taught to believe "industry standard" systems are superior to in-house developed systems.

Now there IS obviously benefit in both training and development time in just gluing together well known systems (eg pull MySQL off the shelf instead of rolling out your own alternative). But that comes at a cost of security and, dare I say, a loss of true skilled dev jobs. Nowadays development is just consists of clowns who can glue systems together.

Ask yourself this - who actually quantified the costs vs the benefits to establish the popular idea that in-house systems are inferior? Or is the "popular" idea simply a dogma from beginning to end?

Ha! Ok, I'll bite...
Tell me, if I'm a contractor coming to your house to build an addition (say a sunroom), would you think it a good option for me to build all my tools (including the backhoe) from scratch before starting any real construction. Or if I'm installing some doors, would you rather me install my "very own designed and built" locks vs., oh, I don't know, any tried-and-tested product for a fraction of the cost (i.e. Stanley), which backs their products, etc.?

There's actually a term for what you're describing: Not Invented Here Syndrome.

It's a form of delusion whenein the sufferer (you) truly believes their small team of "crack" devs could outsmart teams of hundreds domain experts who have developed and QAed a product for years.

Wait, you're not Joel Spolsky, are you? Christ, if you are, then there's no helping you...

No, No, no....

The sunroom example is like building your own IDE. Rather we are talking about a contractor who is willing to help you design the room, instead of insisting that it should be a pre-defined plan with some limited adjustments we can make to get it closer to what you want.

The same is true with DB's. By using an existing DB we are forced to create a solution close to what we want around the limitations of the DB. By building our own solution, we can guarantee it works EXACTLY as we want. Of course, in most cases the effort involved might outweigh the benefit, but we should accept the idea of creating our own system as a valid option.

Zylon · 2011-10-19 Reply Admin

The Great Lobachevsky:
PS: My very non-technical mom has asked me on several occasions what the word "algorithm" means. I keep trying to give her definitions on her level but it isn't working very well... I'm tempted to pull out a cookbook and point to a recipe and tell her it is an algorithm for pot roast. :)

Recipes aren't algorithms. Flowcharts, however, are. Just Google up a flowchart, point at it, and say "This is an algorithm!" Everyone understands flow charts.

2011-10-19 Reply Admin

Danny Moules:
geoffrey:
You might well laugh, but that same logic explains why elements of the military use their own custom hardware.
It's a matter of cost/benefit analysis. Is the cost of developing our own CPUs worth the extra security it would afford? It might be for the military, but not for an electronic commerce site.

But is the cost of developing our own backend database system for said eCommerce site worth the extra security it would provide? Yes yes and yes again.

Developing NSQL (Not SQL, for lack of a better name): 120 hours dev time

Millions of hackers wasting their time trying to enter snippets of SQL into the edit fields of your website: priceless

One hacker who runs a fuzzer against your database: Um, how much does our insurance cover again?

Unless your team of developers + testers can be confident of being collectively smarter in all areas of security than all the hackers who will ever look at your system, don't bother.

When the military use custom hardware they carefully analyse existing specifications and then very carefully tailor them, test them, double-test them, triple-test them, destroy them then test them again. Then get a third-party to repeat. Then it gets 'experimental' status and can only be used in an extremely limited context. Then funding disappears and it gets canned until another department comes along and resurrect it, which gets canned again until ten years later a company decides to fund it during an industry bubble. Then there's a one in five chance the business takes off and their product becomes mainstream (also, 94% of statistics are made up on the spot).

CAPTCHA: sagaciter - What I would have been if I'd cited the entire saga of posts we seem to be collecting...

I agree, we'd rather something we didn;'t have to test that much!

This is reminding me of Linux vs MS...Linux is more secure because fewer hackers are attacking it. This is why I wrote it.

2011-10-19 Reply Admin

geoffrey:
C-Octothorpe:
Back in *reality*, the weak points are usually caused by human error (lack of training, knowledge, poor implementation, etc.), and not because MS Sql Server failed in some way or because SHA256 was broken. No, it was because fucking moron developers who like do things like concat SQL strings with user input, don't encode output, don't sanitize input, etc., etc., because they don't know how or even that they *should*.

And why is that? It's because all devs have to do to survive these days is glue a website to SQL Server, even if they have no idea how it all works.

If their job entailed tasks such as coding a DBS in two weeks, well that would soon sort the wheat from the chaff. If there were no jobs for morons there would be no morons in jobs.

Sorry, but you're argument is simply a grossly misinformed red-herring. Fortunately, if I ever have to work with you or interview you, I would be able to spot you from a mile away...

I don't do interviews, but hey, swings and roundabouts.

This I agree with to some degree. Without promoting C too much, I recently had to work with someone who grew up on Java (and knew it well), but because they didn't really understand what the memory was doing under the hood they had little issue with spawning objects unnecessarily (which had the double whammy of increasing memory usage and increasing work done by the Garbage Collector). Although I have no objection to the likes of Java and C# (and many others) I think developers still have to understand not just the language, but what the system is actually doing.

I think this is where geoffery is coming from. Good developers believe they can do anything. They might not need to, but they believe themselves capable of it. Bad developers want to use only the technologies they know (although they may be quite good at them). Using Oracle (for example) just because we all know how to use it isn't the right approach. Building a new DBMS for the hell of it, isn't necessarily the right appraoch either, but as someone has pointed out, the weakest link is usually the (local) developer. The simpler a system is to use, then the lower quality the developer that will appear adequate in it, and the higher the risk of hiring a turkey who doesn't really know what he's doing - and will end up stuffing things up irrespective of the technology you choose to use.

Creating systems for idiots merely encourages idiots. It won't be long before systems are so 'clever' that there will be no-one who actually understands what is going on to properly fix things when the shit hits the fan....

Bullet-proof Encryption

Leave a comment on “Bullet-proof Encryption”