FileDeskSecurity
How should a tax agency store client FBR portal passwords?
Almost every practice I have looked at keeps client portal logins in one of three places: a hardbound register in a drawer, a WhatsApp thread with a staff member, or a shared spreadsheet that has been copied to four laptops. All three fail in the same way, and it is worth being precise about how.
What actually goes wrong
The register in the drawer
It works until someone needs a password while the drawer is locked, or the person who knows the handwriting is on leave. Then the practice starts photographing pages and sending them on WhatsApp, and you now have the second problem as well.
The WhatsApp thread
A password sent on WhatsApp lives on every device that ever received it, in cloud backups you do not control, and in the chat history of a staff member after they resign. You cannot revoke it. You often cannot even enumerate where it went.
The shared spreadsheet
This is the most dangerous, because it feels organised. One file contains every client's identity and every password in plain text. Anyone who can open it can copy all of it in five seconds. Nothing records that they did. When a junior leaves with a USB stick, the practice usually finds out months later — or never.
The test is simple: if a staff member resigned this afternoon, could you say precisely which client credentials they still hold? If the answer is no, the arrangement has already failed.
Start with consent, not technology
Before any of the technical questions, there is a professional one. You are holding the keys to your clients' tax affairs. That requires their permission, and the permission should be explicit rather than assumed because they handed you a password once in 2021.
Get it in writing, and make the scope clear:
- that you will store their portal credentials to act on their behalf;
- that the credentials will be held in encrypted form in a digital wallet;
- that they can ask you to remove them at any time.
This is not bureaucracy. It is the difference between a professional arrangement and an informal habit that becomes indefensible the moment something goes wrong.
What a safe arrangement looks like
1. Encrypted at rest, not merely "password protected"
A spreadsheet with a file password is not encryption in any meaningful sense. Credentials should be encrypted with a modern authenticated cipher — AES-256-GCM is the sensible default — before they are ever written to storage, so that someone who obtains the raw data file obtains ciphertext and nothing else.
One refinement matters: derive a separate key per field rather than encrypting the username, password and PIN under one key with one initialisation vector. Reusing an IV under the same key is a genuine cryptographic weakness, not a theoretical one.
2. The key lives somewhere the data does not
If the encryption key sits next to the encrypted data in the same backup, you have encrypted nothing. The key should live in a root-owned file on the server, outside the database and outside version control.
And it must be backed up separately and deliberately — lose it and every stored credential becomes permanently unreadable. That is a feature, but it is an unforgiving one.
3. Staff use credentials without seeing them
This is the part most practices never consider, and it is the most valuable. If a staff member must read a password to type it, they can memorise it, photograph it or write it down. If instead the credential is filled into the login form directly, the practical exposure drops to almost nothing.
The credential is decrypted at the instant the form is filled, used, and discarded. Nobody reads it. Nobody carries it home.
4. Access is revocable and enumerable
You should be able to answer, at any moment:
- which staff accounts exist and what each is permitted to do;
- which devices are enrolled to use credentials;
- how to cut off one person, on one device, right now.
A register in a drawer answers none of these. A per-account login with registered devices answers all three.
5. Never fill a CAPTCHA
Any tool that offers to solve the portal's CAPTCHA or OTP for you is offering to help you defeat an anti-automation control. Do not use it. A legitimate tool fills the identifier and the password and stops — the human completes the challenge, which is exactly what the challenge is for.
A practical migration
If you are moving off a spreadsheet, do it in this order:
- Write to clients and obtain explicit consent for encrypted storage.
- Import identities first — names, CNIC, NTN — and confirm them.
- Enter credentials for the clients you actually file for, not all of them.
- Give each staff member their own login. Stop sharing one account immediately.
- Destroy the spreadsheet, including the copies on personal laptops.
Step five is the one practices skip. An encrypted system alongside a surviving spreadsheet is no safer than the spreadsheet alone.
What FileDesk does
FileDesk stores one portal credential per client, encrypted with AES-256-GCM using a separate key per field, with the master key held only on your own server. Staff search for a client and press Fill; the browser extension completes the login form on supported portals without displaying the password. Each device is registered and revocable, and the extension will not touch a CAPTCHA field.
If you would like to see how that works on a real agency, send me a message — I will walk you through it and tell you honestly whether it suits your size of practice.