• (cs) in reply to umalut
    umalut:
    I store passwords in a database using strong encryption algorithm called tripleROT13: ROT13(ROT13(ROT13(password)))

    I think it's a good idea to increase the security of my database, therefore I think I shold consider switching to tripleROT13(tripleROT13(password)) encoding.

    You can't do that; the net effect is to end up with ROT13'd text a total of six times. 6 is the only composite number that is a result of multiplying the lowest 2 different prime numbers (discounting 1 for historical reasons), and it has been shown that using an involution cypher with that magic number of rounds is vulnerable to an attack base on a simple lookup table. This reduces to an O(1) operation for an attacker with sufficient ram to store the necessary lookup table. A Rainbow Table may help reduce memory requirements, possibly at the cost of increasing the time required to perform the lookup.

    Now a lookup table of sufficient size, or a processor necessary to run through the Rainbow Table may be out of reach (financially speaking) of your typical attacker, but I wouldn't bet my bacon on it.

    I won't argue that protecting passwords against lookup-table based attacks is important, especially since IP packets can leak out onto the network in some broken IP stacks that honor IP source routing, even if the database lives on the magical host "localhost".

    A scheme that does not fall victim to a simple lookup table is SXOR (Self-referential eXclusive OR). Example pseudo-code code is as follows:

    $encpasswd = xor($passwd, $passwd);

    Empirical evidence suggests that a password encrypted in this manner is indistinguishable from the random distribution of "bit noise" on a typical ethernet link, making the password unrecoverable by would-be attackers. A user creation routine such as

    exec_sql(
    "insert into USERS(NAME, ENCPASSWD) values(:name, :encpasswd);",
    { 'name' => $name, 'encpasswd' => $encpasswd });

    would be authenticated as follows:

    $authenticated = select_single_record(
    "select 1 from USERS where NAME = :name and ENCPASSWD = :encpasswd",
    { 'name' => $name, 'encpasswd' => $encpasswd })
  • (cs) in reply to beltorak
    beltorak:
    umalut:
    I store passwords in a database using strong encryption algorithm called tripleROT13: ROT13(ROT13(ROT13(password)))

    I think it's a good idea to increase the security of my database, therefore I think I shold consider switching to tripleROT13(tripleROT13(password)) encoding.

    You can't do that; the net effect is to end up with ROT13'd text a total of six times. 6 is the only composite number that is a result of multiplying the lowest 2 different prime numbers (discounting 1 for historical reasons), and it has been shown that using an involution cypher with that magic number of rounds is vulnerable to an attack base on a simple lookup table. This reduces to an O(1) operation for an attacker with sufficient ram to store the necessary lookup table. A Rainbow Table may help reduce memory requirements, possibly at the cost of increasing the time required to perform the lookup.

    Now a lookup table of sufficient size, or a processor necessary to run through the Rainbow Table may be out of reach (financially speaking) of your typical attacker, but I wouldn't bet my bacon on it.

    I won't argue that protecting passwords against lookup-table based attacks is important, especially since IP packets can leak out onto the network in some broken IP stacks that honor IP source routing, even if the database lives on the magical host "localhost".

    A scheme that does not fall victim to a simple lookup table is SXOR (Self-referential eXclusive OR). Example pseudo-code code is as follows:

    $encpasswd = xor($passwd, $passwd);

    Empirical evidence suggests that a password encrypted in this manner is indistinguishable from the random distribution of "bit noise" on a typical ethernet link, making the password unrecoverable by would-be attackers. A user creation routine such as

    exec_sql(
    "insert into USERS(NAME, ENCPASSWD) values(:name, :encpasswd);",
    { 'name' => $name, 'encpasswd' => $encpasswd });

    would be authenticated as follows:

    $authenticated = select_single_record(
    "select 1 from USERS where NAME = :name and ENCPASSWD = :encpasswd",
    { 'name' => $name, 'encpasswd' => $encpasswd })

    Han Solo: I think we're in trouble. C-3PO: If I may say so, sir, I noticed earlier the sarcasmdrive motivator has been damaged. It's impossible to go to WTFspeed. Han Solo: We're in trouble.

  • Tom (unregistered) in reply to JR

    He probably meant something like: "SELECT * FROM users WHERE username=base64_decode('".base64_encode($user)."') AND ..." Too bad computers can't read your mind and write whatever you mean in stead of what you actually type on your keyboard.

  • Tom (unregistered) in reply to Global Warmer

    I would go through 1000 screen shots for 1000 dollars.

    CAPTCHA: dignissim

  • King Kong (unregistered)

    a few people have given examples like

    http://..url?vector=';drop table users;

    and

    http://..url?vector=';select user, passwd from users

    but hang on a second.. a hacker doesn't typically want to drop or delete your data, they want to see it. and in the second case, if your database stores users and passwords unencrypted in a table called users, I suspect you may need outside help to cover one attack vector of SQL injection.

  • Bob (unregistered) in reply to KattMan
    KattMan:
    Global Warmer:
    I am not a hacker or a security guru so could someone please explain to me why banning SQL keywords as part of your strategy is a bad thing? I realize it should not be your only defense but what is wrong with it being part of it?

    As others have shown, you will be banning valid words. Ban "drop" and when asking for someones favorite song they can't enter a true statement "Drop it like it's hot". Or perhaps if you aren't look for just the single word but any string containing it, then Mr. Andropolis can't get an account with you.

    This just in: the RIAA has published new guidance, advising that artists avoid the words DELETE, DROP, SELECT, ALTER, TRUNCATE and the symbols = and ; and = when naming new songs. Failure to do so may result in some websites being unable to host the artist's song for technical reasons.

  • Mike (unregistered)

    But it would work great if you have a base64_decode function in mysql!

    $sql = "select * from customers where " . "email_address = base64_decode('" . base64_encode($email_address)
    . "') and password = base64_decode('" . base64_encode($password) . "')";

    I think this was probably an idea handed to a WTF coder in a hallway from a reasonable coder. "Encode to Base64 before you pass it in, and then decode once you're in the database" ... and the WTF person didn't understand.

  • Andrew O'Reilly (unregistered)

    Having a last name that includes an apostrophe is a disaster these days. Any time I go to type my name into a website from a, lets say second tier, provider it's a total crap shoot whether it will (a) work, (b) give me an error telling me that I can't use my own name or (c) crash and burn with an internal error.

  • Bruce (unregistered) in reply to ThePants999

    And the even worse: "EXEC" keyword.

  • Why god, why (unregistered)

    http://www.mcun.org/MFA/faq.asp?CreditUnion='

  • Tim Ellison (unregistered) in reply to Aaron

    Um, you mean 538.

  • Evil Fruit (unregistered) in reply to halcyon1234
    halcyon1234:
    Let's say their favorite fruit is ';--DROP DATABASE, and you've made sure that your user-entering fields are properly parametarized. So when he updates his profile with the Evil Fruit, it's saved OK and doesn't trigger anything. Then he hits the button that says "Find all users with the same fruit preference as me", which submits ';--DROP DATABASE to a second stored procedure written by the junior developer, that isn't paramaterized...
    Evil Fruit... LOL. I will re-use that phrase in the future!
  • (cs) in reply to ThePants999

    hehe, and ya don't tell me I can't use DROP lol.

    check it ;]

    declare @sql char(256) set @sql = cast(0x64726F70207461626C65206F7264657273 as char(256)) select @sql

    just don't change that last select to exec

  • Montoya (unregistered) in reply to Matt S
    Matt S:
    I guess paramaterized queries are just TOO HARD to implement.

    HEAR, HEAR!

  • Alucard (unregistered) in reply to ThePants999

    Truncate is harmless, right...??? :D

  • Anonymous (unregistered)

    TRUNCATE users;

Leave a comment on “SQL Injection Protection * 3”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article