Bullet-proof Encryption

« Return to Article
  • Joshua 2011-10-19 09:03
    YAY for SQL Injection.
  • Dani 2011-10-19 09:03
    Could it be frist?
  • Rodnas 2011-10-19 09:11
    I made this bullet-proof vest out of plain cotton, because everyone uses armour-piercing rounds nowadays plus it is easier this way.
  • Steve The Cynic 2011-10-19 09:14
    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.
  • congnor 2011-10-19 09:16
    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 smoke hash with the colleague.


    ftfy
  • congnor 2011-10-19 09:20
    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)...
  • Jerry 2011-10-19 09:21
    I'm so confused! Second or third time now.. a story before noon! Did I get transported to another time zone or did Alex finally get a day job?
  • Fred 2011-10-19 09:24
    As we know, md5 has been broken and it is probably only a matter of time before sha1 and sha2 fall as well. So this code is future proof.

    Now some would argue you shouldn't use md5 if you know it is borken, but that didn't stop us from using plaintext, did it?
  • Spivonious 2011-10-19 09:25
    Jerry:
    I'm so confused! Second or third time now.. a story before noon! Did I get transported to another time zone or did Alex finally get a day job?


    Seriously. I was getting used to not getting an update until the afternoon. Maybe Alex got fired?
  • Nagesh 2011-10-19 09:27
    Not being bad idea to use multipal incription skemes. As haker, I am probable trying sha1 or md5 or base 64 decription skemes. Can it be finding ranebow tables for md5-sha1-sha2 hash?

    I am thinking no.


    Don't be a H8R.

    I undertake project in java, if you need help with
    homework, contact me.
  • Ama 2011-10-19 09:27
    It's a hash within a hash. Hashception.
  • Bobby Tables 2011-10-19 09:30
    Hint: if you didn't get the OR = reference and you call yourself a web developer, step away from the keyboard immediately and go get a job more suited to your knowledge and integrity, like maybe selling used cars.
  • David 2011-10-19 09:35
    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.
  • ObiWayneKenobi 2011-10-19 09:36
    Nagesh:
    Not being bad idea to use multipal incription skemes. As haker, I am probable trying sha1 or md5 or base 64 decription skemes. Can it be finding ranebow tables for md5-sha1-sha2 hash?

    I am thinking no.


    Don't be a H8R.

    I undertake project in java, if you need help with
    homework, contact me.


    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.

    To stay on topic: Developer is an idiot. 'Nuff said.
  • The Great Lobachevsky 2011-10-19 09:46
    Bobby Tables:
    Hint: if you didn't get the OR = reference and you call yourself a web developer, step away from the keyboard immediately and go get a job more suited to your knowledge and integrity, like maybe selling used cars.


    I don't 100% understand it, but I don't call myself a web developer either. But I feel like I only 52% understand it and would like to know more.

    I get that you can do things like change the URL in your browser to tack something like OR 1=1 onto the end of a query to make a DB return all contents of a table (or in this case I guess it lets anyone in if this is entered in a password field?)

    If you know of a good easy to read reference, can you share? Thanks.
  • Nagesh 2011-10-19 09:48
    No one care what you think neither if too lazy to evan read content.


    Don't be a H8R.

    I undertake project in java, if you need help with
    homework, contact me.

    ObiWayneKenobi:
    Nagesh:
    Not being bad idea to use multipal incription skemes. As haker, I am probable trying sha1 or md5 or base 64 decription skemes. Can it be finding ranebow tables for md5-sha1-sha2 hash?

    I am thinking no.


    Don't be a H8R.

    I undertake project in java, if you need help with
    homework, contact me.


    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.

    To stay on topic: Developer is an idiot. 'Nuff said.
  • Machtyn 2011-10-19 09:50
    For people who's browsers didn't wrap the code:
    custom_step(crypt(md5(sha1(sha2(mcrypt_cbc($password))))+
    
    stream_filter_append($rand,$seed,STREAM_FILTER_WRITE, $opts))+"123", $seed);
  • Rupee 2011-10-19 09:58
    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.
  • boog 2011-10-19 09:58
    ...user passwords were stored in plain-text. "But it's easier this way..."
    5 out of 5 hackers agree.
  • someone 2011-10-19 10:00
    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)
  • FreeMarketFan 2011-10-19 10:01
    Ama:
    It's a hash within a hash. Hashception.


    Actually that's a common misconception people have. The concept of hashception is me planting the hash inside your hash without you knowing...

    CAPTCHA: luctus - Dr House argued, "It's not luctus"
  • wernercd 2011-10-19 10:03
    The Great Lobachevsky:

    I don't 100% understand it, but I don't call myself a web developer either. But I feel like I only 52% understand it and would like to know more.


    http://en.wikipedia.org/wiki/SQL_injection

    The basics of it... to my understanding... is that the end product results in a query such as:

    statement = "SELECT * FROM users WHERE name = '" + userName + "';"


    Replace the "userName" with something like 'or 1 = 1' ending up with something like:

    SELECT * FROM users WHERE name = '' OR '1'='1';


    Tack on a "robert'; drop table users; --" and you have http://xkcd.com/327/:

     SELECT * FROM USERS WHERE name = 'robert'; drop table users; --'
  • Alex 2011-10-19 10:09
    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
  • boog 2011-10-19 10:16
    wernercd:
    The Great Lobachevsky:

    I don't 100% understand it, but I don't call myself a web developer either. But I feel like I only 52% understand it and would like to know more.


    http://en.wikipedia.org/wiki/SQL_injection

    The basics of it... to my understanding... is that the end product results in a query such as:

    statement = "SELECT * FROM users WHERE name = '" + userName + "';"


    Replace the "userName" with something like 'or 1 = 1' ending up with something like:

    SELECT * FROM users WHERE name = '' OR '1'='1';


    Tack on a "robert'; drop table users; --" and you have http://xkcd.com/327/:

     SELECT * FROM USERS WHERE name = 'robert'; drop table users; --'
    Also: people who know about SQL injection because they read xkcd will prevent it by sanitizing inputs when they concatenate them into their SQL queries:
     SELECT * FROM USERS WHERE name = 'robert''; drop table users; --'

    Smart developers will just use parameterized queries and go home early.
  • THE Zuy-Guy (You Know You Love Me) 2011-10-19 10:23
    Rupee:
    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.
    Moore's law doesn't concern speed per se, but tranny density. The number of trannys in a club will double every 18 months or until they implement checks at the door.
    Rupee:
    Using different algorithms adds some strength in that if a vulnerability is discovered in one, it won't leave you open to attack.
    Having several layers might prevent penetration, but that just allows me to get multiple "trophies" from the same "occasion".
    Rupee:
    Having a special hashing order like in this example gives you some security through obscurity - but you can't rely on that.
    Like I said, this stops working when the bouncers start lifting skirts.
    Rupee:
    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.
    Well, if it's two chicks, then yeah, it will distract me from this shocking bad example of php (which stands for PHP: Homosexual Penis).
  • C-Octothorpe 2011-10-19 10:24
    boog:
    Smart developers will just use parameterized queries and get all the ladies.
    FTFM

    giggity...
  • Cris 2011-10-19 10:25
    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.
  • Nagesh 2011-10-19 10:27
    wernercd:
    The Great Lobachevsky:

    I don't 100% understand it, but I don't call myself a web developer either. But I feel like I only 52% understand it and would like to know more.


    http://en.wikipedia.org/wiki/SQL_injection

    The basics of it... to my understanding... is that the end product results in a query such as:

    statement = "SELECT * FROM users WHERE name = '" + userName + "';"


    Replace the "userName" with something like 'or 1 = 1' ending up with something like:

    SELECT * FROM users WHERE name = '' OR '1'='1';


    Tack on a "robert'; drop table users; --" and you have http://xkcd.com/327/:

     SELECT * FROM USERS WHERE name = 'robert'; drop table users; --'

    I am not even cliking link and already knew it was some cigarette linking XKCD.

    **** off, your not clever.
  • THE Zuy-Guy (Fraudulent) 2011-10-19 10:28
    boog:
    ...user passwords were stored in plain-text. "But it's easier this way..."
    5 out of 5 hackers agree.
    And 5 out of 6 people enjoy gang rape.

    And now you know!
  • THE Zuy-Guy (You Know You Love Me) 2011-10-19 10:33
    C-Octothorpe:
    boog:
    Smart developers will just use Rohypnol and get all the ladies.
    FTFM

    giggity...

    FTFTFMFY

    I won't keep you long... I'll keep you forever...
  • Martijn 2011-10-19 10:40
    The Great Lobachevsky:
    Bobby Tables:
    Hint: if you didn't get the OR = reference and you call yourself a web developer, step away from the keyboard immediately and go get a job more suited to your knowledge and integrity, like maybe selling used cars.


    I don't 100% understand it, but I don't call myself a web developer either. But I feel like I only 52% understand it and would like to know more.

    I get that you can do things like change the URL in your browser to tack something like OR 1=1 onto the end of a query to make a DB return all contents of a table (or in this case I guess it lets anyone in if this is entered in a password field?)

    If you know of a good easy to read reference, can you share? Thanks.


    According to the article, in this particular case, you don't even have to add the SQL in the URL, you can just type it into the username field.

    I don't know of an easy reference that explains everything you need to know about SQL injection. I do know the silver bullet, however: Never, ever ever use string concatenation to create SQL queries out of user input. Always, always use parameterized queries. And fire anyone who doesn't.
  • THE Zuy-Guy (You Know You Love Me) 2011-10-19 10:40
    THE Zuy-Guy (Fraudulent):
    boog:
    ...user passwords were stored in plain-text. "But it's easier this way..."
    5 out of 5 hackers agree.
    And 5 out of 6 people claim to enjoy gang rape.
    All 6 actually do.

    0,Vx2,Ax2 Now yer talkin'!
  • pjt33 2011-10-19 10:43
    In addition to points already made, that $rand worries me. Is it going to be the same value every time? If so, WTF is it called $rand? If not, a user who gets his password right every time is still going to need luck to log in.
  • Nagesh 2011-10-19 10:44
    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?
  • Andy 2011-10-19 10:47
    Cargo Cult Programming!
  • C-Octothorpe 2011-10-19 10:49
    Martijn:
    The Great Lobachevsky:
    Bobby Tables:
    Hint: if you didn't get the OR = reference and you call yourself a web developer, step away from the keyboard immediately and go get a job more suited to your knowledge and integrity, like maybe selling used cars.


    I don't 100% understand it, but I don't call myself a web developer either. But I feel like I only 52% understand it and would like to know more.

    I get that you can do things like change the URL in your browser to tack something like OR 1=1 onto the end of a query to make a DB return all contents of a table (or in this case I guess it lets anyone in if this is entered in a password field?)

    If you know of a good easy to read reference, can you share? Thanks.


    According to the article, in this particular case, you don't even have to add the SQL in the URL, you can just type it into the username field.

    I don't know of an easy reference that explains everything you need to know about SQL injection. I do know the silver bullet, however: Never, ever ever use string concatenation to create SQL queries out of user input. Always, always use parameterized queries. And fire anyone who doesn't.
    Hmm, this seems familiar... Anybody else sense an impending flamewar?
  • Nagesh 2011-10-19 10:51
    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
  • THE Zuy-Guy (You Know You Love Me) 2011-10-19 10:52
    C-Octothorpe:
    Hmm, this seems familiar... Anybody else sense an impending flamewar?
    No, but I sense an approaching flamer.

    Hey! C-Octo! Good to see ya!

    I WANT TO FUCK YOUR BRAINS OUT!
  • geoffrey 2011-10-19 10:54
    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.


  • Nagesh 2011-10-19 10:55
    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


    :consfued:
  • Zylon 2011-10-19 10:56
    Whoever's running Nagesh is really lonely today, isn't he?
  • Nagesh 2011-10-19 10:56
    Found it.

    http://en.wikipedia.org/wiki/Matryoshka_doll

  • trtrwtf 2011-10-19 10:59
    Zylon:
    Whoever's running Nagesh is really lonely today, isn't he?


    What makes you think it's one person?
  • C-Octothorpe 2011-10-19 11:00
    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...
  • Tom 2011-10-19 11:01
    pjt33:
    In addition to points already made, that $rand worries me. Is it going to be the same value every time? If so, WTF is it called $rand? If not, a user who gets his password right every time is still going to need luck to log in.


    Therein lies the security...
  • Nagesh 2011-10-19 11:01
    Zylon:
    Whoever's running Nagesh is really lonely today, isn't he?

    I am having to study very hard: trying to get getting Java 1.4 certification.
  • Tom 2011-10-19 11:06
    trtrwtf:
    Zylon:
    Whoever's running Nagesh is really lonely today, isn't he?
    What makes you think it's one person?
    Perhaps they're all lonely.

    If only there were some kind of network where they could connect with each other and exchange pictures of their winkies or something.
  • THE Zuy-Guy (You Know You Love Me) 2011-10-19 11:06
    trtrwtf:
    Zylon:
    Whoever's running Nagesh is really lonely today, isn't he?
    What makes you think it's one person?
    I wish I was more than one person - I'm lonely too!

    Love me internet!
  • boog 2011-10-19 11:07
    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.
  • C-Octothorpe 2011-10-19 11:09
    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"...
  • geoffrey 2011-10-19 11:12
    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?

  • Anonymous Coward 2011-10-19 11:13
    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.
  • Rawr 2011-10-19 11:18
    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.
  • boog 2011-10-19 11:18
    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.
  • THE Zuy-Guy (You Know You Love Me) 2011-10-19 11:19
    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.
  • geoffrey 2011-10-19 11:24
    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!
  • sreagsgio 2011-10-19 11:28
    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.
  • Rawr 2011-10-19 11:30
    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.
  • Altourus 2011-10-19 11:32
    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
  • boog 2011-10-19 11:35
    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.
  • geoffrey 2011-10-19 11:35
    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

  • C-Octothorpe 2011-10-19 11:38
    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...
  • Steve The Cynic 2011-10-19 11:46
    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.
  • Danny Moules 2011-10-19 11:47
    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?
  • Nagesh 2011-10-19 11:49
    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.
  • neminem 2011-10-19 11:49
    Yo dawg! I heard you liked hashing passwords, so I put an algorithm in your algorithm, so you can hash while you hash!
  • Bizkit 2011-10-19 11:50
    weak will, could not resist...

  • Coyne 2011-10-19 11:50
    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.
  • geoffrey 2011-10-19 11:50
    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.
  • Nagesh 2011-10-19 11:52
    I see no problem with rolling own db for progect.
  • Bizkit 2011-10-19 11:54
    Damn, ninja'd by neminem. I shouldn't have taken the time to double-check my bbcode.
  • Nagesh 2011-10-19 11:58
    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.
  • boog 2011-10-19 11:59
    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 2011-10-19 12:00
    Nagesh (fake):
    I see no problem with rolling own db for progect.


    Even I not meke mistake of mispel "project". :P
  • Coyne 2011-10-19 12:01
    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.
  • trtrwtf 2011-10-19 12:02
    geoffrey:

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



    Time sheets or it didn't happen.
  • Danny Moules 2011-10-19 12:03
    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...
  • C-Octothorpe 2011-10-19 12:07
    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...
  • geoffrey 2011-10-19 12:09
    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.
  • L. 2011-10-19 12:09
    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.
  • geoffrey 2011-10-19 12:13
    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.
  • TheCPUWizard 2011-10-19 12:14
    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).
  • L. 2011-10-19 12: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 2011-10-19 12:17
    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!
  • L. 2011-10-19 12:18
    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 ;)
  • no laughing matter 2011-10-19 12:24
    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?
  • C-Octothorpe 2011-10-19 12:25
    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...
  • no laughing matter 2011-10-19 12:31
    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!
  • David 2011-10-19 12:36
    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.
  • Dotan Cohen 2011-10-19 12:43
    > 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
  • geoffrey 2011-10-19 12:46
    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.
  • Ayn Rand() 2011-10-19 12:46
    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.
  • C-Octothorpe 2011-10-19 12:53
    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...
  • m 2011-10-19 13:01
    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>
  • geoffrey 2011-10-19 13:01
    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.
  • C-Octothorpe 2011-10-19 13:13
    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.
  • Bronie 2011-10-19 13:27
    Trollfobia much?
  • notromda 2011-10-19 13:32
    C-Octothorpe:
    boog:
    Smart developers will just use parameterized queries and get all the ladies.
    FTFM

    giggity...


    +1
  • trtrwtf 2011-10-19 13:34
    [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.
  • no laughing matter 2011-10-19 13:34
    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
  • the beholder 2011-10-19 13:41
    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.
  • Nagesh 2011-10-19 13:44
    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.
  • Anon 2011-10-19 13:46
    If it makes you feel better, I would have given you 7 or 8/10.
  • Nagesh 2011-10-19 13:48
    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 13:53
    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!
  • Anon 2011-10-19 13:55
    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!
  • Jay 2011-10-19 14:01
    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.
  • LetMeFinclOut 2011-10-19 14:04
    In Soviet Russia, password hashes YOU!
  • trtrwtf 2011-10-19 14:07
    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.

  • Nagesh 2011-10-19 14:10
    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 Zuy-Guy (You Know You Love Me) 2011-10-19 14:12
    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 14:24
    Glass is also good matrial to meke CPU. Samsung company has build several CPU from glass. They will release to market in 2015.
  • THE Zuy-Guy (You Know You Love Me) 2011-10-19 14:25
    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.
  • Nagesh 2011-10-19 14:35
    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 14:40
    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 14:45
    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 14:46
    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 14:48
    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 14:48
    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 14:53
    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 ..."
  • Dazed 2011-10-19 14:53
    Well, thanks everyone for one of the funnier threads here. (Even if I'm not completely certain which of the comments were deliberately funny.)
  • JayC 2011-10-19 14:53
    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 14:59
    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).
  • anonymous_coward 2011-10-19 15:00
    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...
  • big picture thinker 2011-10-19 15:01
    (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.




  • Nabhi Singh 2011-10-19 15:03
    Whatever happened to Top Cod3r I miss him.
  • Matt Westwood 2011-10-19 15:06
    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.
  • P 2011-10-19 15:10
    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.


    1. As of knowing order of hash functions read about Kerckhoffs's principle

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

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

    4. Combining few algorithms make it easier to break as you need to break the easier one. Here you have security on level of md5.

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

    6. 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.
  • Ralph 2011-10-19 15:19
    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!
  • big picture thinker 2011-10-19 15:47
    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 15:47
    geoffrey:
    The real smart developers don't even use SQL, they use an ORM.


    FTFY
  • Nagesh 2011-10-19 15:55
    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 16:02
    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.

  • Bronie 2011-10-19 16:17
    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.
  • THE Zuy-Guy (You Know You Love Me) 2011-10-19 16:19
    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
  • Bronie 2011-10-19 16:19
    What is this story about matterhorn BTW?
    He stole someone's account because his password wasn't triple-hashed right?
  • boog 2011-10-19 16:28
    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 16:29
    Anyway, TRWTF is that the guy who wrote that code forgot the rot13() step.
  • Nagesh 2011-10-19 16:49
    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 16:50
    Nabhi Singh:
    Whatever happened to Top Cod3r I miss him.
    Brainectomy. Now he's Nagesh.
  • The Great Lobachevsky 2011-10-19 16:51
    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 16:54
    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.
  • Joel 2011-10-19 16:55
    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 17:04
    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?
  • Fred 2011-10-19 17:10
    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:
    1) Brute force is stopped by Locking Accounts
    2) 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....)
  • Sugar 2011-10-19 17:28
    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...
  • Jim 2011-10-19 17:32
    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.
  • Hugo 2011-10-19 17:37
    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 17:39
    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.
  • Linus 2011-10-19 17:41
    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.
  • Mickey D 2011-10-19 17:51
    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....
  • Matt Westwood 2011-10-19 17:56
    Mickey D:
    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....


    So don't employ idiots. Du-uh.
  • visualbasucks 2011-10-19 17:56
    Rot26 is sadly missing.
    'Or =' not?
  • boog 2011-10-19 18:15
    Mickey D:
    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...
    Yes, the correct approach is to determine which solution best meets the needs of the project and go with that. Rarely are massive-data-storage needs not fully met by an existing product.

    And I agree it's optimal for people to learn how things work under the hood (how else will you know which products meet your needs?). But honestly, I don't have time to wait for my co-workers to dick around self-teaching things they should have already learned in school (or any time prior to getting hired for this job).
  • trtrwtf 2011-10-19 21:05
    boog:
    Mickey D:
    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...
    Yes, the correct approach is to determine which solution best meets the needs of the project and go with that. Rarely are massive-data-storage needs not fully met by an existing product.

    And I agree it's optimal for people to learn how things work under the hood (how else will you know which products meet your needs?). But honestly, I don't have time to wait for my co-workers to dick around self-teaching things they should have already learned in school (or any time prior to getting hired for this job).


    Anyone worth hiring is going to continue to do a lot of self-teaching. I'm happy to see some of that happen on the job - as long as it doesn't interfere too much with getting the damned work done.

    (If you're learning your primary language on the job, I'd be a little bovvered. )
  • frits 2011-10-19 23:37
    Is this the Bitcoin algorithm finally revealed?
  • Stunning Cute 2011-10-20 02:26
    Mickey D:
    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).

    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.


    Using Java just because we all know how to use it isn't the right approach.
    Your app is slow because you using Java, and not because of object allocation.

    Also, I think they fixed things in C# - its GC optimized for quick allocation of small objects
  • Arvind 2011-10-20 03:19
    The real WTF is you, sir, Mr. Matthew R. You apparently lack the communication skills expected of a team lead. I can imagine very well you must have explained the need for encryption with arrogance, trying to prove them that "I am the lead, and what I say is right".

    If you really had any leadership skills, you would have been able to convince them to do it willingly, and not begrudgingly. Another FAIL for you is you did not notice the obvious sarcasm in the 'bullet proof' remark.

    A team lead needs to be not only technically competent, but needs to have good interpersonal skills too.
  • dkf 2011-10-20 04:57
    Stunning Cute:
    Your app is slow because you using Java, and not because of object allocation.
    There are exactly three ways in which Java is slow.

    1. It's slow to start up.
    2. It's a huge memory hog (which causes problems with both paging and caches).
    3. It's GUI is famously problematic.

    It's also easy to write code that performs badly, but that's true for other languages too. I've never seen any language where it was impossible to write bad code (except for languages where it was practically impossible to write any code, and those were largely just jokes that got out of hand).
  • Tamy 2011-10-20 07:16
    Actually, that's what kevlar vests are made of. Cotton.
  • no laughing matter 2011-10-20 07:45
    Zylon:
    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.

    You couldn't be wronger!

    Recipes are algorithms!

    And Akismet deserves to die!
  • frits 2011-10-20 09:09
    Nagesh:
    A Brahman, a Sikh, and a Muslem walk into a bar. The bartender say: "What is this? Some sort of joking?"
    QFH XD
  • Watson 2011-10-20 09:11
    Meanwhile, the user is logging in with a password of '123456'.
  • ObiWayneKenobi 2011-10-20 10:48
    Watson:
    Meanwhile, the user is logging in with a password of '123456'.


    Hey! That's the same combination I use on my luggage!
  • Dildo Jones 2011-10-20 11:45
    This:

    SELECT * FROM USERS WHERE name = 'robert'; drop table users; --'

    In php wouldnt work.
    One cannot perform ,multiple queries using the default mysql query functions which is what all lesser gods are using.

    However, using 'union all select' might work if the name parameter wasn't properly escaped which is how most lesser god applications trip over and die.

  • Nagesh 2011-10-20 11:47
    ObiWayneKenobi:
    Watson:
    Meanwhile, the user is logging in with a password of '123456'.


    Hey! That's the same combination I use on my luggage!


    My cycle lock is simpel. I use only 1234. :) 2 less digits.
  • Matt Westwood 2011-10-20 11:47
    ObiWayneKenobi:
    Watson:
    Meanwhile, the user is logging in with a password of '123456'.


    Hey! That's the same combination I use on my luggage!


    Yes I know. Wow, is that *really* your *wife*? Ewwwww ...
  • boog 2011-10-20 12:00
    trtrwtf:
    boog:
    Mickey D:
    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...
    Yes, the correct approach is to determine which solution best meets the needs of the project and go with that. Rarely are massive-data-storage needs not fully met by an existing product.

    And I agree it's optimal for people to learn how things work under the hood (how else will you know which products meet your needs?). But honestly, I don't have time to wait for my co-workers to dick around self-teaching things they should have already learned in school (or any time prior to getting hired for this job).


    Anyone worth hiring is going to continue to do a lot of self-teaching. I'm happy to see some of that happen on the job - as long as it doesn't interfere too much with getting the damned work done.

    (If you're learning your primary language on the job, I'd be a little bovvered. )
    I should be clear: I wasn't hating on self-teaching. I was hating on having-to-wait-for-people-who-should-have-already-learned-this-shit-before-starting-on-the-project-to-get-up-to-speed. That counts as "interfering too much with getting the damned work done" in my book.
  • Statute of limitations 2011-10-20 12:14
    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.


    In 10 years these accounts will all be dead. Hell, even some account holders will have died! Encryption only needs to be secure enough while the data is still useful.

    Cell phone encryption is a good example. The audio (voice) must be encrypted and decrypted in real-time to be heard. However, decrypting the conversation 10 days later is useless, since they did whatever they said already.

    This is covered in Applied Cryptography by Bruce Schneier.
  • Nagesh 2011-10-20 12:25
    boog:
    trtrwtf:
    boog:
    Mickey D:
    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...
    Yes, the correct approach is to determine which solution best meets the needs of the project and go with that. Rarely are massive-data-storage needs not fully met by an existing product.

    And I agree it's optimal for people to learn how things work under the hood (how else will you know which products meet your needs?). But honestly, I don't have time to wait for my co-workers to dick around self-teaching things they should have already learned in school (or any time prior to getting hired for this job).


    Anyone worth hiring is going to continue to do a lot of self-teaching. I'm happy to see some of that happen on the job - as long as it doesn't interfere too much with getting the damned work done.

    (If you're learning your primary language on the job, I'd be a little bovvered. )
    I should be clear: I wasn't hating on self-teaching. I was hating on having-to-wait-for-people-who-should-have-already-learned-this-shit-before-starting-on-the-project-to-get-up-to-speed. That counts as "interfering too much with getting the damned work done" in my book.


    Fair enough - I guess we agree. I think this counts as a WTF, these days.
  • trtrwtf 2011-10-20 12:26
    Nagesh:
    boog:
    trtrwtf:
    boog:
    Mickey D:
    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...
    Yes, the correct approach is to determine which solution best meets the needs of the project and go with that. Rarely are massive-data-storage needs not fully met by an existing product.

    And I agree it's optimal for people to learn how things work under the hood (how else will you know which products meet your needs?). But honestly, I don't have time to wait for my co-workers to dick around self-teaching things they should have already learned in school (or any time prior to getting hired for this job).


    Anyone worth hiring is going to continue to do a lot of self-teaching. I'm happy to see some of that happen on the job - as long as it doesn't interfere too much with getting the damned work done.

    (If you're learning your primary language on the job, I'd be a little bovvered. )
    I should be clear: I wasn't hating on self-teaching. I was hating on having-to-wait-for-people-who-should-have-already-learned-this-shit-before-starting-on-the-project-to-get-up-to-speed. That counts as "interfering too much with getting the damned work done" in my book.


    Fair enough - I guess we agree. I think this counts as a WTF, these days.


    (oops - caught myself Nageshing...)
  • frits 2011-10-20 12:29
    trtrwtf:
    Nagesh:
    boog:
    trtrwtf:
    boog:
    Mickey D:
    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...
    Yes, the correct approach is to determine which solution best meets the needs of the project and go with that. Rarely are massive-data-storage needs not fully met by an existing product.

    And I agree it's optimal for people to learn how things work under the hood (how else will you know which products meet your needs?). But honestly, I don't have time to wait for my co-workers to dick around self-teaching things they should have already learned in school (or any time prior to getting hired for this job).


    Anyone worth hiring is going to continue to do a lot of self-teaching. I'm happy to see some of that happen on the job - as long as it doesn't interfere too much with getting the damned work done.

    (If you're learning your primary language on the job, I'd be a little bovvered. )
    I should be clear: I wasn't hating on self-teaching. I was hating on having-to-wait-for-people-who-should-have-already-learned-this-shit-before-starting-on-the-project-to-get-up-to-speed. That counts as "interfering too much with getting the damned work done" in my book.


    Fair enough - I guess we agree. I think this counts as a WTF, these days.


    (oops - caught myself Nageshing...)

    I think it would have been funny to see Nagesh ranting about the verbing of "hate". You're usually a grammar nazi type, right?
  • trtrwtf 2011-10-20 12:37
    frits:
    trtrwtf:
    Nagesh:
    boog:
    trtrwtf:
    boog:
    Mickey D:
    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...
    Yes, the correct approach is to determine which solution best meets the needs of the project and go with that. Rarely are massive-data-storage needs not fully met by an existing product.

    And I agree it's optimal for people to learn how things work under the hood (how else will you know which products meet your needs?). But honestly, I don't have time to wait for my co-workers to dick around self-teaching things they should have already learned in school (or any time prior to getting hired for this job).


    Anyone worth hiring is going to continue to do a lot of self-teaching. I'm happy to see some of that happen on the job - as long as it doesn't interfere too much with getting the damned work done.

    (If you're learning your primary language on the job, I'd be a little bovvered. )
    I should be clear: I wasn't hating on self-teaching. I was hating on having-to-wait-for-people-who-should-have-already-learned-this-shit-before-starting-on-the-project-to-get-up-to-speed. That counts as "interfering too much with getting the damned work done" in my book.


    Fair enough - I guess we agree. I think this counts as a WTF, these days.


    (oops - caught myself Nageshing...)

    I think it would have been funny to see Nagesh ranting about the verbing of "hate". You're usually a grammar nazi type, right?


    I prefer to think of myself as "ReMastered".... they're so much more effective and cool and fictional and stuff. But my ranting services are being not needed in this instance. I am thinking that you will find "h8" is alreddy verb. U cannot verb a verb, matterpaneer! </Nagesh>
  • boog 2011-10-20 13:36
    trtrwtf:
    Nagesh (trtrwtf):
    Fair enough - I guess we agree. I think this counts as a WTF, these days.

    (oops - caught myself Nageshing...)
    How disappointing. I'd expect you to just play along with the sock puppet, responding to him even if he inadvertently speaks out of turn.

    But instead you went and took off the sock, revealing it to be a puppet all along. To everyone's surprise, no doubt.
  • trtrwtf 2011-10-20 13:41
    boog:
    trtrwtf:
    Nagesh (trtrwtf):
    Fair enough - I guess we agree. I think this counts as a WTF, these days.

    (oops - caught myself Nageshing...)
    How disappointing. I'd expect you to just play along with the sock puppet, responding to him even if he inadvertently speaks out of turn.

    But instead you went and took off the sock, revealing it to be a puppet all along. To everyone's surprise, no doubt.


    If that's a revelation, I have some bad news for you regarding Santa Claus.
  • boog 2011-10-20 14:02
    trtrwtf:
    boog:
    trtrwtf:
    Nagesh (trtrwtf):
    Fair enough - I guess we agree. I think this counts as a WTF, these days.

    (oops - caught myself Nageshing...)
    How disappointing. I'd expect you to just play along with the sock puppet, responding to him even if he inadvertently speaks out of turn.

    But instead you went and took off the sock, revealing it to be a puppet all along. To everyone's surprise, no doubt.

    If that's a revelation, I have some bad news for you regarding Santa Claus.
    Sorry, my comment was intended to sound as deadpan as possible, particularly the last bit.

    <deadpan>I'll be sure to use proper markup in future.</deadpan>
  • frits 2011-10-20 14:09
    trtrwtf:
    boog:
    trtrwtf:
    Nagesh (trtrwtf):
    Fair enough - I guess we agree. I think this counts as a WTF, these days.

    (oops - caught myself Nageshing...)
    How disappointing. I'd expect you to just play along with the sock puppet, responding to him even if he inadvertently speaks out of turn.

    But instead you went and took off the sock, revealing it to be a puppet all along. To everyone's surprise, no doubt.


    If that's a revelation, I have some bad news for you regarding Santa Claus.

    I was actually surprised it was you.
  • trtrwtf 2011-10-20 14:12
    boog:
    trtrwtf:
    boog:
    trtrwtf:
    Nagesh (trtrwtf):
    Fair enough - I guess we agree. I think this counts as a WTF, these days.

    (oops - caught myself Nageshing...)
    How disappointing. I'd expect you to just play along with the sock puppet, responding to him even if he inadvertently speaks out of turn.

    But instead you went and took off the sock, revealing it to be a puppet all along. To everyone's surprise, no doubt.

    If that's a revelation, I have some bad news for you regarding Santa Claus.
    Sorry, my comment was intended to sound as deadpan as possible, particularly the last bit.

    <deadpan>I'll be sure to use proper markup in future.</deadpan>


    Sorry, hard to tell the deadpan from the serious some days. Markup would be helpful. <wide-eyed naivete>Do you think it would defeat the purpose, though? </wide-eyed naivete>
  • trtrwtf 2011-10-20 14:14
    frits:
    trtrwtf:
    boog:
    trtrwtf:
    Nagesh (trtrwtf):
    Fair enough - I guess we agree. I think this counts as a WTF, these days.

    (oops - caught myself Nageshing...)
    How disappointing. I'd expect you to just play along with the sock puppet, responding to him even if he inadvertently speaks out of turn.

    But instead you went and took off the sock, revealing it to be a puppet all along. To everyone's surprise, no doubt.


    If that's a revelation, I have some bad news for you regarding Santa Claus.

    I was actually surprised it was you.


    Only once in a while. Not mine to begin with, I assure you.

    Isn't it your hand in the sock some days? Now I'm the one surprised.
  • frits 2011-10-20 14:24
    trtrwtf:
    frits:
    trtrwtf:
    boog:
    trtrwtf:
    Nagesh (trtrwtf):
    Fair enough - I guess we agree. I think this counts as a WTF, these days.

    (oops - caught myself Nageshing...)
    How disappointing. I'd expect you to just play along with the sock puppet, responding to him even if he inadvertently speaks out of turn.

    But instead you went and took off the sock, revealing it to be a puppet all along. To everyone's surprise, no doubt.


    If that's a revelation, I have some bad news for you regarding Santa Claus.

    I was actually surprised it was you.


    Only once in a while. Not mine to begin with, I assure you.

    Isn't it your hand in the sock some days? Now I'm the one surprised.

    Only the unicode Иagɘsнen...

    I think you have to be some kind of insider to have controlled the "real" Nagesh. However, I postulate someone changed the password and usurped the sock for themselves only these days.
  • Nagesh 2011-10-20 14:26
    frits:
    trtrwtf:
    frits:
    trtrwtf:
    boog:
    trtrwtf:
    Nagesh (trtrwtf):
    Fair enough - I guess we agree. I think this counts as a WTF, these days.

    (oops - caught myself Nageshing...)
    How disappointing. I'd expect you to just play along with the sock puppet, responding to him even if he inadvertently speaks out of turn.

    But instead you went and took off the sock, revealing it to be a puppet all along. To everyone's surprise, no doubt.


    If that's a revelation, I have some bad news for you regarding Santa Claus.

    I was actually surprised it was you.


    Only once in a while. Not mine to begin with, I assure you.

    Isn't it your hand in the sock some days? Now I'm the one surprised.

    Only the unicode Иagɘsнen...


    I don't find that highly unlikely.
  • PedanticCurmudgeon 2011-10-20 15:02
    trtrwtf:
    Nagesh:


    Fair enough - I guess we agree. I think this counts as a WTF, these days.


    (oops - caught myself Nageshing...)
    And what else will you admit to? You'll be telling us zunesis is a virgin next...
  • trtrwtf 2011-10-20 15:08
    PedanticCurmudgeon:
    trtrwtf:
    Nagesh:


    Fair enough - I guess we agree. I think this counts as a WTF, these days.


    (oops - caught myself Nageshing...)
    And what else will you admit to? You'll be telling us zunesis is a virgin next...


    Oh, no, that could never be.
  • C-Octothorpe 2011-10-20 15:10
    trtrwtf:
    PedanticCurmudgeon:
    trtrwtf:
    Nagesh:


    Fair enough - I guess we agree. I think this counts as a WTF, these days.


    (oops - caught myself Nageshing...)
    And what else will you admit to? You'll be telling us zunesis is a virgin next...


    Oh, no, that could never be.
    It can if you don't count the vacuum and the family dog...
  • Ipods will go down! 2011-10-20 15:31
    trtrwtf:
    Isn't it your hand in the sock some days? Now I'm the one surprised.
    My hand is on the sock fairly frequently - it's not my hand that I put in it.

    Unless you're talking about something else, which which case, yes, my hand is in the "sock" - I stretch my fingers to turn it inside out. Psssst... Hint: distended rectum. Can you imagine it coming inside out, say after a huge, rock-hard shit (need to eat them greens) and then running around, begging your wife/roommate/teenage child's friends - "shove it back in!"
  • Ipods will go down! 2011-10-20 15:33
    PedanticCurmudgeon:
    trtrwtf:
    (oops - caught myself Nageshing...)
    And what else will you admit to? You'll be telling us zunesis is a virgin next...
    I think trtrwtf knows very well that's not true. WHY WON'T YOU CALL ME!!!!!!!
    Doesn't he?
  • The Great Lobachevsky 2011-10-20 15:36
    Zylon:
    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.


    I think you overestimate my mom. :)

    I am trying to find a way to relate it to reality TV, QVC, or the Food Network to get it in a context she'll understand. And I don't really want to try to flowchart the outcomes at Tribal Council. :)
  • Ipods will go down! 2011-10-20 15:39
    C-Octothorpe:
    PedanticCurmudgeon:
    And what else will you admit to? You'll be telling us zunesis is a virgin next...
    It can if you don't count the vacuum and the family dog...
    I've never misused a vacuum cleaner is such a way! Who do you think I am!?

    As an aside, just speaking hypothetically, using my imagination, I really wouldn't recommend it. If I had to guess, I'd say it causes unsettling numbness and discoloration following, and you care about Junior like any normal guy, seeing him like this isn't the happiest of pictures. If I had to guess. HIDDEN MESsAGE!@!!!!!!
  • Ipods will go down! 2011-10-20 15:43
    The Great Lobachevsky:
    Zylon:
    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.
    I think you overestimate my mom. :)

    I am trying to find a way to relate it to reality TV, QVC, or the Food Network to get it in a context she'll understand. And I don't really want to try to flowchart the outcomes at Tribal Council. :)
    I think I can help. I'll need her phone number (of course) and a picture. Beach photos, preferably. That will help me to relations to her. oh, and some used panties of hers if you can get them.
    You can get in on the call if you want - what numbers do you press to make it a three-way?
  • boog 2011-10-20 17:14
    C-Octothorpe:
    trtrwtf:
    PedanticCurmudgeon:
    You'll be telling us zunesis is a virgin next...

    Oh, no, that could never be.
    It can if you don't count the vacuum and the family dog...
    I expect you'd have to omit every inanimate object in Zunelander's house if you really wanted to make such a claim.
  • rtmroger 2011-10-20 23:03
    Welcome to RTM, that started from manufacturing commercial and domestic cooling tools and refrigeration spare parts 10 years ago. Today, our product lines have expanded to include not just top-quality HVAC/R products , but also unparalleled automotive A/C tools. Most of our products approved “CE “, “ROHS” and ”UL” certification.
    NINGBO SPARK INC. is a manufacturing and exporting supplier for clients all around with one-stop solution of the HVAC/R products, covering Refrigerants,Refrigeration spare parts,Air-Conditioning Accessories, and Ventilation products, etc.
  • Brian White 2011-10-21 00:53
    Mickey D:
    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....


    Building a new DBMS is never the right approach. Whether you want sql, object, or noSql, it's all out there already. Now eventually you may end up writing your own domain specific programming language, but please don't write a DBMS
  • ᴺᵃᵍᵉsh 2011-10-21 09:21
    Brian White:
    Building a new DBMS is never the right approach. Whether you want sql, object, or noSql, it's all out there already. Now eventually you may end up writing your own domain specific programming language, but please don't write a DBMS

    Let him be go ahead and write it. Jaffrey-troll is needing something productive to do. You wouldn't want to let him close to any real work, would ja?
  • Watson 2011-10-23 04:40
    mcrypt_cbc($password)
    That doesn't even make sense. CBC-mode encryption, but most of the parameters are missing - it doesn't even specify the encryption algorithm to use. Anonymisation artefact?
  • Watson 2011-10-23 04:43
    Brian White:
    Building a new DBMS is never the right approach. Whether you want sql, object, or noSql, it's all out there already. Now eventually you may end up writing your own domain specific programming language, but please don't write a DBMS

    (To a first approximation): Because it doesn't matter how the internals are implemented if an attacker can't even make it past the interface.
  • The poop of DOOM 2011-10-24 06:37
    trtrwtf:
    boog:
    Mickey D:
    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...
    Yes, the correct approach is to determine which solution best meets the needs of the project and go with that. Rarely are massive-data-storage needs not fully met by an existing product.

    And I agree it's optimal for people to learn how things work under the hood (how else will you know which products meet your needs?). But honestly, I don't have time to wait for my co-workers to dick around self-teaching things they should have already learned in school (or any time prior to getting hired for this job).


    Anyone worth hiring is going to continue to do a lot of self-teaching. I'm happy to see some of that happen on the job - as long as it doesn't interfere too much with getting the damned work done.

    (If you're learning your primary language on the job, I'd be a little bovvered. )

    In my previous job, the boss hired a PHP developer... who didn't know PHP at all. He claimed he knew .NET (which he didn't either), so had to learn his primary language on the job... and refused to do so! He kept claiming he, as a programmer, should just be able to download any and all code he needed from the internet. He even just plain refused to make the simplest exercises.

    When he walked in one morning and had his coffee, I gave him an exercise of making a contact form. Just a plain "name, e-mail address, textarea" form and returning the input on-screen.

    At noon, none was done yet, so I opened the manual's pages explaining the functions he required up in his browser and gave him an example (meaning he actually just had to alter a 10-line or so piece of code!).

    By the evening, it still didn't work. Guy told me it didn't return the input. He didn't even bother reading the function page in the manual, or he'd have known he should assign the return value of that function to a variable...
  • trtrwtf 2011-10-24 08:16
    The worst part is, that guy probably comes on this site to gloat about all the terrible programmers out there.
  • GL 2011-10-26 21:08
    I thought someone just hooked in Emacs to this site and started ELIZA.

    CAPTCHA: Ludus - apparently a "playful lover"
  • Jules 2011-10-28 10:49
    Somebody should tell this guy that if you hash the results of a hash with a different algorithm, it can be broken by a collision in either scheme, so it's actually *less* secure than just hashing once...
  • Jules 2011-10-28 10:52
    Building a new DBMS is never the right approach. Whether you want sql, object, or noSql, it's all out there already. Now eventually you may end up writing your own domain specific programming language, but please don't write a DBMS


    I almost agree with you. But I also think saying something is *never* right is too extreme. There are applications where writing your own DBMS is likely to be the best thing to do. I'll grant that they are *extremely* rare, but they are out there, which is why every now and then we see a new design of database crop up which is better than existing ones for some narrow task.
  • zozz 2012-03-13 09:39
    I agree with that, it is superfluous talking about that anymore! http://www.porntubest.com/sites