search

contao / core

Contao 3 → see contao/contao for Contao 4
GNU Lesser General Public License v3.0
490 stars 213 forks source link

ModuleRegistration ignores unique when DCA encrypt #8144

Closed t-me closed 5 years ago

t-me commented 8 years ago

Hello,

On issues #8110 you solved the DCA Encrypt on ModuleRegistration,

Only the value will not be compared now when it must be unique. People registration can set same input as other people.

leofeyer commented 8 years ago

No idea how to solve this without decrypting every single row and comparing the unencrypted values, which will notably affect the performance.

@contao/developers /cc

aschempp commented 8 years ago

How about DB level uniqueness? The same encryption should result in the same value…

ausi commented 8 years ago

The same encryption should result in the same value…

I don’t think so: Encryption::encrypt('foo') !== Encryption::encrypt('foo')

aschempp commented 8 years ago

Not? If you use the same encryption key?

leofeyer commented 8 years ago

Definitely not.

discordier commented 8 years ago

This is the benefit of block ciphers in favor over substitution. You can not guess the plaintext from ciphered text. There is nothing to do here aside from checking against the whole DB. However, when you encrypt everything you are aware of the fact that it costs time. That's the tradeoff of security by encryption. Therefore I think it is ok to scan the DB in that case.

aschempp commented 8 years ago

I would actually say this is an edge case we don't need to handle in the care. It can be simply added using a save_callback.

leofeyer commented 8 years ago

Therefore I think it is ok to scan the DB in that case.

Well, I don't. Imagine a customer database with 1,000,000 entries and encrypted credit card numbers. To check the uniqueness of a credit card number, we would have to select all entries, decrypt them on PHP level and then compare them. How much RAM is the application supposed to consume?

discordier commented 8 years ago

Bad example as CC numbers never must get stored and many ppl pay with company CC for all accounts but anyway, what do you want it to be? There is nothing(!) we can do here without loosening the encryption. Imagine a new column which holds a hash of the original value, thus allows yet again to take a guess on the original value. Salting that hash will increase security again but raise the original issue. Therefore, if you want to have unique encrypted values, you will have to check via rowscan. This however will have to be in bulk sets, to not let the memory explode.

leofeyer commented 8 years ago

Or we simply add a known issue that encrypted columns cannot be unique.

leofeyer commented 8 years ago

As discussed in Mumble on April 21st, we are going to make this a known limitation.

leofeyer commented 5 years ago

Added in contao/contao@bb2c8c90ee991062a8b7f20582ab1f9a735cb1c7.