how to one-way encode sensitive data for display?

Question

how to one-way encode sensitive data for display?

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

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

Jeff Moden SSC Guru Points: 1003853 More actions · Answer 1

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.

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

Jeff Moden SSC Guru Points: 1003853 More actions · Answer 2

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.

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

Eirikur Eiriksson SSC Guru Points: 182881 More actions · Answer 3

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.

Jeff Moden SSC Guru Points: 1003853 More actions · Answer 4

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.

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

ScottPletcher SSC Guru Points: 100942 More actions · Answer 5

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) A socialist is someone who will give you the shirt off *someone else's* back.

Jeff Moden SSC Guru Points: 1003853 More actions · Answer 6

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.

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

Eirikur Eiriksson SSC Guru Points: 182881 More actions · Answer 7

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