Re: Encrypted bank account info

[Luke <..hidden..>]

On Fri, 5 Mar 2010, Chris Travers wrote:

> Similar but slightly different.  Both allow storage of an banking
> institution code and an account number.
>
> 1.3 allows multiple bank accounts per customer/vendor record.

Presumably with some kind of nickname or account note functionality?

For one thing, for record keeping, I was thinking that if the encrypted 
number had an unencrypted handle--a sequence--you could use that in 
transactional records.  The only thing would be that you could not allow 
changing of bank account numbers associated with a particular sequence, so 
that the same pointer always pointed to the same thing, even if it wasn't 
used any more.

Realistically, though, encrypting them could cause all kinds of headaches 
which may not be worth the effort for reasons already stated.

I would say that users with the "view full bank info" permission should be 
able to view and edit bank info, whereas users without such a permission 
should only be able to reference it (I.E. "****4755" for "17732694755"). 
That's a UI info, but it would keep the full number from being thrown back 
and forth to browsers unnecessarily.
Of course, it too would probably require unique sequence IDs for bank 
account numbers or rows containing them.

No, this isn't really an answer to your direct question.

To encrypt or not to encrypt: I don't think it makes a difference, as long 
as a mechanism exists to decrypt with the right access level.  Cracking 
below that should be prevented by the UI from gaining access to the full 
info; and above that the point is moot because they'll get it anyway.

Luke