>>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.
>
>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.

Interesting approach. Let me think of how this would be implemented.
Thank you.