What you describe here is masking which was what was asked about. It just replaces the data shown in fields on the screen with * but does not hide the data.
Of course, you should have permissions set up so that users don't get access to data they shouldn't. You can do this at the field level so you can just not give users who shouldn't see the data access and there is no masking or anything else that is needed. Now, you have the users who are allowed to see the data the only ones who get it in any form. Now, what is the requirement? To let them get it but not see it? Is there anyone who should be able to see it and in what way? Can I search on it? Can I search on it if I can't see it? Remember, that means I can guess at it by just searching different combinations and if I find it, I know the value. Once we have all permission issues cut out. Once we have decided that there is someone who needs to be able to see it. Once we have decided on whether it is searchable or not, then we can see if there is something else you can do. If it must be searchable, you are really not protecting it in any way other than permissions. Masking is just a trick/side effect but it doesn't protect the data as I can search on it. If you have to protect it from people who can see it so you cannot search it, it doesn't show on the screen (just a mask), but there is a condition under which the user can get it (within permissions), you could use the ENCRYPT() and DECRYPT() functions to protect the data. You can call encrypt whenever a new value is supplied. You can call decrypt only when needed (or if decrypt doesn't work on the client (which I don't think it does), you can use a Get filter to decrypt only when the client type is the mid-tier or windows client and use a masked field. The wire is encrypted by default and can have higher encryption added if needed. Going this direction means it is encrypted in the database, on the wire, if it was needed for workflow, decrypt, use, encrypt again. It decrypts it only for use by the client tools and only for users who can see it. The key is to really define what the requirement is and then be very clear about using the right techniques to protect the data. Stage 1 is permission to not allow access to the field if the user shouldn't be able to see it (note with "Allow anyone to submit" option you can allow someone to submit a value but then not see it if they don't have permission otherwise). Now, only people who can potentially see it are left and that may be enough or you may want to go the encrypt/decrypt route if you need it further protected and you control things via workflow. I hope this helps, Doug Mueller -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of LJ LongWing Sent: Friday, July 30, 2010 1:06 PM To: [email protected] Subject: Re: Mask information Guillermo, There is an option of a character field to display it as type 'mask'...but be warned...it's nothing more than a visual mask...the data is still transferred across the line as its text and still stored in the db as its text and can be reported out as real text...the only thing it does is not display it on the screen...there is no way to mask anything else that I'm aware of. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Guillermo Alfredo Torres Barron Sent: Friday, July 30, 2010 1:52 PM To: [email protected] Subject: Mask information Hi dear lister In our organization we have some users that need to capture privileged information, p.e. id cards, therefore we need mask this information in the character or diary fields, how can we do it? For example, the user capture id card but when search and display ticket the id card apper mask with other character, can be "*" Any idea is appreciate Thanks in advance Greetings ............................................................................ ............... Este correo electronico es confidencial y/o puede contener informacion privilegiada. Si usted no es su destinatario o no es alguna persona autorizada por este para recibir sus correos electronicos, NO debera usted utilizar, copiar, revelar, o tomar ninguna accion basada en este correo electronico o cualquier otra informacion incluida en el, favor de notificar al remitente de inmediato mediante el reenvio de este correo electronico y borrar a continuacion totalmente este correo electronico y sus anexos. Nota: Los acentos y caracteres especiales fueron omitidos para su correcta lectura en cualquier medio electronico. This e-mail is confidential and/or may contain privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any other information herein, please advise the sender immediately by reply this e-mail and delete this e-mail and its attachments. ............................................................................ ............... ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
