>>Hi,
>>
>>This is a follow up my thread on the same subject. Just to refresh:
>>I store (un-encrypted) a string that consists of "Y" and "N" in a 250 char field GRP_ACCESS (in SQL Server). Each position corresponds to a feature in the application. When a user logs in, based on his credentials, he may or may not have access to a feature (based on the value in the GRP_ACCESS field).
>>
>>I tried to encrypt the values in this field using the function cipher() (created by S. Berezniker). This function creates an encrypted string (based on the "YYYYNNNNYN..." But if one were to look at the encrypted field you can clearly see a pattern. For example, the users who have/had all "Y"s in the un-encrypted field get the same encrypted string. It is just the encrypted string has many non-ascii characters; so it looks unreadable. But if someone wants to, they can simply store the field value into a variable and then execute the UPDATE table and set this value in all records. I doubt my customer would do it. But, I would like to explore other ways to encrypt the field.
>>
>>If you have any suggestions, please let me know.
>
>No matter which specific approach you take, I think you'll need to include something distinct for each user. Otherwise, as you point out, replay attacks are possible.
>
>Off the top of my head, you could add a GUID or UUID for each user (or maybe you have one already?) You have the database enforce uniqueness on this column. Then you use the GUID as a key for whatever encryption you'd like to use; the result should look different for every user, even if they all have all "Y"s.
>

I was set to write a short "salt on a record basis", but again you have already described much better ;-))

>A replay attack would require UPDATEing both the GUID and the encrypted string, which should be stopped by the database because of uniqueness violation on the GUID column.

A good kink to have in place against attacker with access to the backend, will slow down a bit, but I'd also try to guard against atackers
working on single records - if they also have access to the cipher function code and the salt field value, they could just run the function to decipher.

Having rules in place forbidding serving up specially marked fields in many layers (think like Python concept "_Varname" and "__Varname" for hiding fields) is a step further, involving PK (as *immutable* unique field value) will be beneficial most of the times.

Drawback: on export/re-import often a discrete run to generate unciphered field should be always planned, as PK might change ;-))