Timeline for Security flaws of storing strings and some of its substrings using Microsoft SQL Server Transparent Data Encryption?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 11, 2020 at 4:29 | vote | accept | Shreyash Sharma | ||
| Dec 7, 2019 at 20:43 | comment | added | Kenny Evitt | @ShreyashSharma The problem with CryptDB, or anything like that, is that's impossible to protect secrets from a system's administrators if those secrets ever need to or even can be decrypted. That's why passwords are protected with hash algorithms instead of encryption algorithms. But note that, even for hashed passwords, a suitably privileged system administrator could simply change the code of the system to log the plaintext passwords entered by the users when they login! The only way for a user to protect a secret, like a password, from others is to never share it in the first place. | |
| Dec 7, 2019 at 20:35 | comment | added | Kenny Evitt | @ShreyashSharma [continued] If you think about hashing passwords in a database, that's intended to protect against anyone accessing or knowing the password except the original user. In that case, you don't want to know the password, ever. You only want to be able to confirm whether a password being entered, after being hashed, matches the hash of the original password. In the case of data that's intended to be decrypted, you want to carefully consider who should have access to that decrypted data. Obviously something or someone is going to need to access any data that's decrypted. | |
| Dec 7, 2019 at 20:31 | comment | added | Kenny Evitt | @ShreyashSharma TDE is perfectly fine, and might be entirely appropriate, but it's a separate or independent form of security from encrypting a specific subset of your data in the database. As always, with any kind of security analysis, you need to carefully consider your 'threat model', i.e. what kinds of 'attacks' do you want to defend against or mitigate? TDE protects against unauthorized database users accessing any data in the database, e.g. from stolen copies of your database files. | |
| Dec 7, 2019 at 10:29 | comment | added | Shreyash Sharma | I was focused on TDE as I am trying to accomplish all this to save the data to be seen in plain text from the privileged user, and there will only be one user, that is because I need at least one user to fire queries on the database. | |
| Dec 7, 2019 at 10:28 | comment | added | Shreyash Sharma | Thank you for the replies and updating your answer. I was going through the paper on CryptDB (people.eecs.berkeley.edu/~raluca/CryptDB-sosp11.pdf) & they have a similar approach in the paper which is detailed on page 5 under "Word Search". They are providing an extra layer of security with the proxy and the database will only give a "yes" or "no" for the LIKE queries. So what if I was to keep the indexes of the complete name strings ("John" "Johnny") on a separate database with its own encryption and TDE and this one database only revealed the indexes(hashed) for that second db? | |
| Dec 6, 2019 at 16:38 | history | edited | Kenny Evitt | CC BY-SA 4.0 |
Clarify even more, add some section headers, and *two* TLDR sections
|
| Dec 6, 2019 at 16:22 | comment | added | Kenny Evitt | @ShreyashSharma I think I understand your comment now. If you decided that you do want to create indexes of encrypted values for searching, for either 'whole' strings or substrings – despite the weakened security – then you should probably use an HMAC algorithm to generate the values to be used in those indexes. But yes, overall, you probably shouldn't create indexes of encrypted values at all. | |
| Dec 6, 2019 at 16:20 | history | edited | Kenny Evitt | CC BY-SA 4.0 |
Clarify, move one paragraph, and add some quotes
|
| Dec 6, 2019 at 15:51 | comment | added | Kenny Evitt | @ShreyashSharma Would you quote what exactly you think claims that HMAC will leak information as well? (There are seven links in my answer and two that I think you're probably referring to.) Maybe you meant these sentences from the "encryption" link?: "At best, what you could do is to implement deterministic encryption, such that encryption of a given record value always yields the same encrypted result. This leaks a modicus of information (if two records have the same contents then this will show, despite the encryption layer); ...". | |
| Dec 6, 2019 at 2:36 | comment | added | Shreyash Sharma | The answers on your link, suggests using HMAC but says that will leak information as well. So that would not work as well, correct? I see no substantial increase in security using HMAC. | |
| Dec 3, 2019 at 5:15 | review | First posts | |||
| Dec 3, 2019 at 6:36 | |||||
| Dec 3, 2019 at 5:11 | history | answered | Kenny Evitt | CC BY-SA 4.0 |