Not useful for tracking unless used in ECB mode, and if they're encrypting anything larger than 120 bits (AES block size) then AES in ECB mode would itself leak information about the encrypted information.

The real thing to do if they wanted pseudonymous values (none of this is anonymous in any way) is either just associate a fresh random value with every account, or if you don't want to have to store any additional information, HMAC the account number with a reasonably long secret key.

It's sad to see so many applications use SHA1/SHA256 when they really need to be using HMAC-SHA1/HMAC-SHA256.

> HMAC the account number with a reasonably long secret key

By "reasonably long" you mean "of the correct length"? That is to say, equal to the block size of the underlying hash (e.g. 64 bytes for HMAC-SHA256). Any longer that that does not increase strength. Shorter keys will be zero-padded out to the block size and are therefore weaker.

I assume they want the pseudonymous values, since they probably want to do analytics on the backend. Thanks for the reply about HMAC. I've got some new learning to look into tonight. :)

Even just using {b,s}crypt and a larger salt, even without regenning on every request, would be massively more difficult in terms of memory and CPU to reverse.