how to one-way encode sensitive data for display?

  • autoexcrement - Monday, August 6, 2018 8:23 AM

    I still just don't fully understand how salts and the like are supposedly so helpful, because it seems like they have to be stored somewhere. Either in code or in an environment variable or somewhere. Why is there an assumption that that's safe when a database isn't?

    "Properly salted" simply makes things like the use of rainbow tables and other brute force decryption techniques a whole lot more difficult.  But, along with "properly salted", you must do proper encryption, which means that if someone manages to get a copy of the database, they not only have to deal with "properly salted" but they also have to deal with the fact that the encryption key(s) don't travel with the database.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • ScottPletcher - Monday, August 6, 2018 8:14 AM

    Jeff Moden - Monday, August 6, 2018 8:00 AM

    ScottPletcher - Monday, August 6, 2018 7:43 AM

    For storing of SSN, you might consider adding a check digit to the value, so that it does become 10 digits (or 11 or whatever).  That way they are trying to hack into the wrong number of digits, which should slow down the process a bit at least.

    If it's stored that way in plain text, a hacker will eat that up in less than a second.  The only right way to protect such things is with properly salted encryption.

    Not talking about plain text, but encrypting a value with extra digit(s) added.  Could even add random digits in fixed locations, just to make it harder for someone to know how many digits they were trying to hack.

    What's the difference between that and using "proper salting"?

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden - Monday, August 6, 2018 8:46 AM

    ScottPletcher - Monday, August 6, 2018 8:14 AM

    Jeff Moden - Monday, August 6, 2018 8:00 AM

    ScottPletcher - Monday, August 6, 2018 7:43 AM

    For storing of SSN, you might consider adding a check digit to the value, so that it does become 10 digits (or 11 or whatever).  That way they are trying to hack into the wrong number of digits, which should slow down the process a bit at least.

    If it's stored that way in plain text, a hacker will eat that up in less than a second.  The only right way to protect such things is with properly salted encryption.

    Not talking about plain text, but encrypting a value with extra digit(s) added.  Could even add random digits in fixed locations, just to make it harder for someone to know how many digits they were trying to hack.

    What's the difference between that and using "proper salting"?

    That's what is called obfuscation, no substitute for security, especially when there are known checksum algorithms to validate the numbers. May add a slight overhead but nothing that comes close to good encryption with a salt / private key.
    😎

    There are many cases where businesses have relied on such measures and utterly failed.

  • Eirikur Eiriksson - Monday, August 6, 2018 8:58 AM

    Jeff Moden - Monday, August 6, 2018 8:46 AM

    ScottPletcher - Monday, August 6, 2018 8:14 AM

    Jeff Moden - Monday, August 6, 2018 8:00 AM

    ScottPletcher - Monday, August 6, 2018 7:43 AM

    For storing of SSN, you might consider adding a check digit to the value, so that it does become 10 digits (or 11 or whatever).  That way they are trying to hack into the wrong number of digits, which should slow down the process a bit at least.

    If it's stored that way in plain text, a hacker will eat that up in less than a second.  The only right way to protect such things is with properly salted encryption.

    Not talking about plain text, but encrypting a value with extra digit(s) added.  Could even add random digits in fixed locations, just to make it harder for someone to know how many digits they were trying to hack.

    What's the difference between that and using "proper salting"?

    That's what is called obfuscation, no substitute for security, especially when there are known checksum algorithms to validate the numbers. May add a slight overhead but nothing that comes close to good encryption with a salt / private key.
    😎

    There are many cases where businesses have relied on such measures and utterly failed.

    Heh... you took the fun out of it.  My question was a "leader" to try to get people to understand that very thing. 😀  That IS, however, the response that I was trying to get folks to come up with though so, as has been the norm since I've known you, spot on Eirikur.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Eirikur Eiriksson - Monday, August 6, 2018 8:58 AM

    Jeff Moden - Monday, August 6, 2018 8:46 AM

    ScottPletcher - Monday, August 6, 2018 8:14 AM

    Jeff Moden - Monday, August 6, 2018 8:00 AM

    ScottPletcher - Monday, August 6, 2018 7:43 AM

    For storing of SSN, you might consider adding a check digit to the value, so that it does become 10 digits (or 11 or whatever).  That way they are trying to hack into the wrong number of digits, which should slow down the process a bit at least.

    If it's stored that way in plain text, a hacker will eat that up in less than a second.  The only right way to protect such things is with properly salted encryption.

    Not talking about plain text, but encrypting a value with extra digit(s) added.  Could even add random digits in fixed locations, just to make it harder for someone to know how many digits they were trying to hack.

    What's the difference between that and using "proper salting"?

    That's what is called obfuscation, no substitute for security, especially when there are known checksum algorithms to validate the numbers. May add a slight overhead but nothing that comes close to good encryption with a salt / private key.
    😎

    There are many cases where businesses have relied on such measures and utterly failed.

    The difference is that it doesn't have to stored like a salt.  I didn't say it was the ultimate way.  Frankly, for something like a SSN, I'd store it in like 3(+) different columns with different names, each encrypted, and then put it back together only when really needed.  Real uses of the actual SSN are so low I think you could easily deal with the overhead of that.  And for all decency's sake, whatever you do, don't name the column "SSN".  This is one time where clear naming is NOT desired.

    SQL DBA,SQL Server MVP(07, 08, 09) Prosecutor James Blackburn, in closing argument in the Fatal Vision murders trial: "If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them."

  • ScottPletcher - Monday, August 6, 2018 10:12 AM

    And for all decency's sake, whatever you do, don't name the column "SSN".  This is one time where clear naming is NOT desired.

    Absolutely agreed on that one!  "TaxID" is the other one to avoid if you're working with businesses.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".
    "Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Jeff Moden - Monday, August 6, 2018 10:47 AM

    ScottPletcher - Monday, August 6, 2018 10:12 AM

    And for all decency's sake, whatever you do, don't name the column "SSN".  This is one time where clear naming is NOT desired.

    Absolutely agreed on that one!  "TaxID" is the other one to avoid if you're working with businesses.

    He he, on that note, one should have few columns like Password, Bank PIN, SSN, Mistress Number etc, the more the better, fill them with encrypted rubbish, keeps the flies away😀
    😎

Viewing 7 posts - 16 through 22 (of 22 total)

You must be logged in to reply to this topic. Login to reply