Comment On Bullet-proof Encryption

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?

C-Octothorpe:

boog:

trtrwtf:

Zylon:

Whoever's running Nagesh is really lonely today, isn't he?

What makes you think it's one person?

Indeed, I'd wager it's at the very least three high-schoolers crowded around the same school computer. Possibly four or five.

High school? Me thinks you're giving too much credit to this "hive mind"...

Believe it or not, the original teaches at my college. The copycats are most likely Americans (or even Indians) who found the English funny.

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.

C-Octothorpe:

boog:

trtrwtf:

Zylon:

Whoever's running Nagesh is really lonely today, isn't he?

What makes you think it's one person?

Indeed, I'd wager it's at the very least three high-schoolers crowded around the same school computer. Possibly four or five.

High school? Me thinks you're giving too much credit to this "hive mind"...

Probably so.

Either way, I'm sure we all missed Nagesh over the summer break, and it's great he(they) was(were) able to return, right on time for the fall semester.

boog:

trtrwtf:

Zylon:

Whoever's running Nagesh is really lonely today, isn't he?

What makes you think it's one person?

Indeed, I'd wager it's at the very least three high-schoolers crowded around the same school computer. Possibly four or five.

But then they wouldn't be on this website and wouldn't have to resort to touching themselves.

Here, guys. You're welcome.

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!

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.

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!

You know what, you're starting to convince me you're serious. I'll hear you out.

Tell me why rolling a custom database would be more efficient, less costly and more secure than using a product that a large dedicated team has been working on for years.

And then I'm going to use your same arguments to try and convince you that you're way better off just rolling your own OS. You've been warned, so tailor your points accordingly.

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

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.

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 blah blah shameless-troll blah...

My, so stubborn. Or maybe he's hungry.

Won't somebody just feed him a little? Not too much, just enough so his tiny troll tummy stops grumbling?

Addendum (2011-10-19 11:43):
Oh good: 363593, 363597
I'll stop worrying now.

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

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

geoffrey:

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?

Building your own causes problems as well. There is no guarantee of more security (except for what amounts to "by obscurity") in a home-grown database system. Indeed, it's possible to argue that developing your own database system increases the risks, as you are diluting your expertise. In effect, you have to employ all your normal *application* developers, and all your administrators, as well as someone (or a team) to develop and maintain the database system. If that costs more money and/or time than just using an off-the-shelf DBMS product, then you had better get something good for it.

In addition, any home-built system will have limitations not found in NIH products. Normally, at any given stage in your overall product's lifespan, you won't experience these limitations (because they represent the restricted boundaries of the application's use of databases - you don't try to anticipate unplanned future usage scenarios, thanks), but you will eventually trip over these limitations as you travel into those scenarios.

NIH DBMS products will have more liberal capability boundaries, as they must anticipate the union of all (for suitable definitions of "all") client user scenarios.

Also, are you a DBMS development shop or an application shop? Can you hire people who have immediate expertise in your home-grown system? (This isn't immensely critical, but also impacts your ability to hire people who want to gain RoR by working for you. Sure, they learn something about databases as a concept, but most people with any ambition want to learn transportable specific skills as well as general-concept skills. And who wants to hire ambition-free lumps, anyway?)

Even [redacted], a large information supplier that I worked for in [redacted], which *had* developed its own database system (and lots of other things as well), used a variety of "standard" SQL-based systems because the home-grown system was not even close to being designed for relational manipulation.

Moving back to the question of security: are you saying that just because the skiddies will leave you alone, you're OK? Some will find that SQL trickery doesn't work and go away, but others will stay and have fun with your front end. Worse, you have to be on guard against complacency. No, Bobby Tables can't kill you, but his PHP-groping buddy will still take down your front end.

Bah, tl;dr. Summary: NIH applied to tools like DBMSes *will* hurt you even as it protects you against certain sorts of pain.

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

That's what salts are for.

As the poster 'Cris' correctly stated, the chained hashes are only as good as their weakest point. The related concept is called 'entropy': http://en.wikipedia.org/wiki/Entropy_%28information_theory%29

CAPTCHA: praesent - I have to prae this comment will be sent?

geoffrey:

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

I undertake coding project of database and have NSQL (Nagesh SQL) also.

Yo dawg! I heard you liked hashing passwords, so I put an algorithm in your algorithm, so you can hash while you hash!

weak will, could not resist...

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

LOL

I was thinking it was the "Swiss Army Knife of password encryption" but I like your metaphor better.

[quote user="C-Octothorpe"][quote user="geoffrey"][quote user="C-Octothorpe"][quote user="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.[/quote]3/10. Funny, but a little forced. Let's see how many bites you get...[/quote]

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?

[/quote]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.[/QUOTE]

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

[QUOTE]"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.?"[/QUOTE]

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

[QUOTE]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.[/QUOTE]

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.

I see no problem with rolling own db for progect.

Damn, ninja'd by neminem. I shouldn't have taken the time to double-check my bbcode.

C-Octothorpe:

boog:

trtrwtf:

Zylon:

Whoever's running Nagesh is really lonely today, isn't he?

What makes you think it's one person?

Indeed, I'd wager it's at the very least three high-schoolers crowded around the same school computer. Possibly four or five.

High school? Me thinks you're giving too much credit to this "hive mind"...

All feke Nageshes have not seen front side of schol.

geoffrey:

C-Octothorpe:

geoffrey:

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

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

They could if you left the backhoe behind a faulty fence, and next to the house, with the keys in the ignition.
</just-keeping-with-the-analogy>

Hey, keep on trollin'!

Nagesh (fake):

I see no problem with rolling own db for progect.

Even I not meke mistake of mispel "project". :P

geoffrey:

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

"Use parameterized SQL? No way: We're building our own [better] database engine!!!"

Sigh. The lengths we go, to avoid doing things the right way. No wonder NIH syndrome is so common.

geoffrey:

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

Time sheets or it didn't happen.

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

geoffrey:

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.

Way to quote fail, but I digress...

I like how you pretend to know where hackers are going to attack any given system. The fact is they'll attack where there are potential entry points, and if you or I knew where these weak points are/were, there wouldn't be any because we would engineer them all out, right?

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

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

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.

I'd definitely start with this :
Hash is NOT encryption.

Using Hash when you need encryption is a BAD idea.

Use encryption stuff instead (like AES256).

The fact that it's been brute forced once doesn't matter much as mostly every encryption available has already been.

And lastly, encrypting the same thing a thousand times doesn't make it safer than encrypting it once. (i.e. the product of many algorithms is an algorithm, which can be about as strong as the weakest of the many depending on the order)

Else we would have had a tunnel within a tunnel within a tunnel for SSL since the start.
I think this looks smart when under the effect of a very powerful sedative.

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.

For those people who still want a "for dummies"...

I have a super secure method for hashing (umteen levels) your password. We will then compare hashes to see if you know the password.

The only thing I will tell you is that the resultant hash is a 4 bit number...

It will take you years to "break my scheme", but less than a second to igure out a valid value (just try all 16).

geoffrey:

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

Nice troll.
For the poor people who actually got poisoned by your funny joke, I'll just point out the following fact :

Developing/adapting a cleansqlinput function : 120 minutes of dev time (if you're really slacking)

Millions of retards thinking SQL is unsafe by nature spending 60* the same time to create something useless and worthless by nature : priceless

Always interesting to see how noob DBA's think they can do better, either with NoSQL or whatever they thought was such a good idea at the time... go back to xml db, it's safer and you can template-check it !! constraints ftw !

Nagesh:

Nagesh (fake):

I see no problem with rolling own db for progect.

Even I not meke mistake of mispel "project". :P

That is Enlgish speling, matterhorn!

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.

Again, awesome trolling.

MySQL innodb is still 5 years behind any real rdbms and you can write a good dbms in two weeks ? please save us all oh almighty troll ;)

geoffrey:

You might well laugh, but that same logic explains why elements of the military use their own custom hardware.

Which then gets infected by malware targeted at facebook users.

Or is the use of custom hardware not so common as you suggest?

geoffrey:

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.

This is one point we can agree on. A vast majority of developers know only to open their IDE, drag and drop this and that, and they're done. But there is this marvelous thing called *training*, which can *teach* people *new* things who previously didn't know those things, such as parameterized queries to prevent sqli.

geoffrey:

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.

If their job entailed two weeks of training, then you teach someone to fish. What you're suggesting is to teach the dev to dig a deep hole, fill it with water, wait until fish appear, then drain the lake and eat the fish. It's just a ham fisted solution to a problem that doesn't exist...

geoffrey:

I don't do interviews

It's pretty clear you don't do IT or security either...

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!

C-Octothorpe:

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

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

> Fail troll is fail, and your spelling is too atrocious
> even for Hinglish.. Also the amusing (or sad?) part is
> that this Nagesh is copy/pasting that signature every
> time it posts.

And he forgets to put this valuable contact information.

To stay on topic: Developer is an example of why articles like this get posted:
http://www.goodphptutorials.com/out/Why_PHP_Was_a_Ghetto

[quote user="C-Octothorpe"][quote user="geoffrey"]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. [/quote]This is one point we can agree on.[/QUOTE]

Lets agree to disagree then. I can see I am not getting through, a bit tired at the moment so I'll leave the discussion there.

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?

You know, at first I thought this guy was an idiot... but now I'm starting to believe in what he is saying. 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 still have some doubts though, but if you could use the word 'Sheeple' a few times, I think I would then be obligated to agree with you.

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

sreagsgio:

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

Surely you draw the photomasks with a pen. All the commecially available EDA toolchains are known to install backdoors in their output.</paranoid>

David:

C-Octothorpe:

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

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

I think you are confused. If you mean neointimal hyperplasia, first that is not a 'syndrome'. Second he isn't referring to a medical condition at all. If you scroll up a few comments he defines what NIH is.

geoffrey:

C-Octothorpe:

geoffrey:

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.

This is one point we can agree on.

Lets agree to disagree then. I can see I am not getting through, a bit tired at the moment so I'll leave the discussion there.

Fair enough.

But for my own sanity, I'm going to go ahead a assume you're much smarter than that and you just trolled the entire forum really hard.

Trollfobia much?

C-Octothorpe:

boog:

Smart developers will just use parameterized queries and get all the ladies.

FTFM

giggity...

+1

[quote user="geoffrey"][quote user="C-Octothorpe"][quote user="geoffrey"]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. [/quote]This is one point we can agree on.[/quote

Lets agree to disagree then. I can see I am not getting through, a bit tired at the moment so I'll leave the discussion there.[/quote]

You're getting through just fine. I think the problem is you're not right.

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.

There is a real problem with assuming that other people make mistakes that you won't make. Instead, you should assume that if someone else makes a mistake that means that you're likely to make the same mistake or a similar one.
And then you should assume that the product that's been in development for a long time with lots of developers has had more eyes on it to catch more of the mistakes than you will.

There are real vulnerabilities in off-the-shelf tools, it's true, and it can be difficult to get those fixed. There can also be real inconveniences, if the tool does not allow you to do something you want to do, and this can cause great frustration. However, on the whole I think it's safe to assume that the more widely a product is used and the longer it's in operation, the safer it becomes, if only because the vulnerabilities become more widely known. If you know that FooSQL has a particular hole, you can either guard that hole or avoid the product. If your local SQL has a hole, you might not learn about it until it's used against you, and you're not likely to discontinue using it because of the ordinary human sensitivity to sunk costs: you've put in the 120 hours to develop it (ha!), so it's hard to justify throwing that away, especially since you had to rubbish every existing off-the-shelf tool it replaces in order to get the local one slotted for development.

I think your best bet, if you really want to take your logic seriously, would be to do your 120 hours of development on the project, then release it as an open-source tool and really push to have it used widely and developed by lots of people.
If there's no uptake, this should tell you that you haven't got an attractive option. If there is uptake, the usual open-source benefits and risks apply.

C-Octothorpe:

But for my own sanity, I'm going to go ahead a buttume your much smarter than that and you just trolled the entire forum really hard.

FTFY