Has Your Bank, Government Agency or Insurer Compromised Your Privacy? The Dangerous Practice of Using Your Date of Birth to Protect Confidential Documents

Your date of birth is not a password. So why are organisations entrusted with protecting your personal information still using it as one?

Imagine receiving an email from your bank containing confidential financial documents.

Perhaps it includes loan information, financial statements, personal identification documents, insurance assessments or details about your financial circumstances.

The email tells you that the attached PDF is password-protected and that you should use your date of birth to open it.

You might think this is a reasonable security measure.

It isn’t.

In fact, it raises some serious questions about the security practices of organisations entrusted with our most sensitive personal and financial information.

The problem is two fold

Putting aside the fact that a date of birth is often information that can be discovered through public records, social media, historical documents and other sources the first problem is the date is from a finite set of numbers, less than 30,000 combinations in practice especially if you exclude dates of people deceased, future dates and dates of people younger than can hold an account with the bank.

Using it as the password to protect confidential documents creates a predictable and dangerous weakness. A PDF or ZIP file may technically be encrypted, but that doesn’t automatically make it secure because once you have the file you have as much time as you need to break the protection on it.

If the password is based on information that someone can reasonably discover or a program can determine in real time, the protection may be substantially weaker than intended, we will show just how weak later in the article.

Now the second point which is what makes this so much worse. A date of birth is personality identifical data, not just sensitive. Its a key piece of information for identity thief. When you decode he password you’ve got two vital bits of data, the identity data (date of birth) and the confidential information, e.g. loan material, full name, address a lots of goodies in the document that was suppose to be protected. This now enables identity thief.

ANZ: A particularly uncomfortable contradiction

Let’s look at ANZ.

ANZ publishes security requirements in its Business Banking Conditions of Use.

Its May 2025 documentation explicitly warns customers against using their birth date as a password, PIN or Telecode.

The document states that users must not select a numeric password, PIN or Telecode representing their birth date.

That’s a sensible security requirement.

But it raises an important question:

If a bank recognises that dates of birth are unsuitable passwords for protecting banking access, why should customers accept dates of birth being used to protect confidential documents?

There is an important distinction here. ANZ’s published banking security clause concerns passwords and security codes used for banking services. It does not expressly establish a prohibition on using DOBs for PDF attachments or ZIP attachments. (Note most banks like NAB, have mandatory compliance courses that advise staff not to use date of birth but this has done little to stop this practice in real terms)

Lets see some proof… here is one of many examples I have collected, I use this one as its from a member of the non-financial risk management team at ANZ.

How bad is that a non financial risk person not understanding this risk?

Nevertheless, the underlying security principle is exactly the issue we are challenging.

A date of birth does not become a strong secret simply because it is being used to unlock a document rather than access an account. (note this email exchange is after AFCA directed ANZ not to use DOB in correspondance exchange)

Have you seem examples like this? I’ve got examples of correspondance from not just ANZ but here is a few more

Unisuper

Coles Master Card

NAB – Premier Banking Team

Yarra Valley Water

Computershare

Also from OAIC, TIO, EWOV and OVIC itself (yes the companies that manage privacy don’t themselves use strong privacy controls nor do the agencies that are pathways to those organisations like TIO or EWOV)

Email is not a secure

The Office of the Australian Information Commissioner (OAIC) provides guidance on securing personal information.

Its guidance makes an important statement:

Email is not a secure form of communication.

The OAIC recommends that organisations consider:

• Avoiding the transmission of sensitive information through unsecured email.
• Using secure websites or online mailboxes.
• Using secure messaging where appropriate.
• Validating recipient email addresses.
• Sending sensitive information as encrypted or password-protected attachments.

This is particularly relevant when organisations handle financial, identity or other sensitive personal information.

There is also an important technical distinction between an encrypted PDF or ZIP protected attachments and an encrypted email connection.

An encrypted attachment protects the document itself. Transport encryption, such as TLS, protects an email connection while it travels between participating mail servers.

Just because a bank mail system turns on TLS that doesn’t mean everyone else uses it, so it cannot stop interception, and TLS is not mandatory end to end, so if TLS is not available at the recievers end it falls back to plain text!!

Also there is no way to verify the email address used is the customers email, this is where most of the issues occur. I had case where Vonex compromised my privacy where they were sending to another person with the same general name but different email domain, any mistake on the email will compromise the transmission.

Also the infrastructure between the bank and the customer is subject to any number of attacks, these are owned and adminsitrator by other people not the bank or you as the customer. also remember most customers use free email services such as google mail, hotmail etc, so they are not in control either.

The question is not simply whether a PDF has a password but where the document or attachment was picked up other people along the way or could be discovered later on mail servers all all the infrastructure neither you or the bank own between the start and end of the process.

The question is whether the entire document-sharing process provides appropriate protection against unauthorised access and disclosure and the answer is it does not.

ANZ already has a better alternative it does not use

Interestingly, ANZ claims to provide its own Document Exchange service.

ANZ describes this service as more secure than email.

It allows customers to:

1. Sign in using their registered email address and mobile number.**
2. Receive a verification code by SMS.**
3. Access requested documents through the secure service.
4. Upload, download and manage documents.

ANZ also operates Secure Information Exchange for sharing sensitive information with approved external parties.

These services demonstrate that secure alternatives to ordinary email-based document exchange are available but its just marketing hype unfortunately first two reasons, firstly its not available to consumers when interacting with ANZ either on complaints or any general correspondance including on AFCA lead investigations, secondly it (see the **) ANZ mandates mobile phone use which means its inaccessible to so many australians that suffer from disability or otherwise are unable to use mobile phones such as those in the older generation.

So the reality is ANZ will send you information encrypted with your date or birth whether you like it or not, or no protection at all.

I’ve tested this a number of times and see this trend also appearing with organisations such as NAB (more recently since the offshoring of IT), Unisuper (who don’t even require protection in most cases, and numerous governance agencies such as Yarra Valley Water who regularly compromise their customer data. Its amazing the response I get when raising the concern back to these companies which is usually its “standard” practice I don’t see the problem.

So why should customers have to accept weaker practices when dealing with confidential information?

That is a reasonable question for customers to ask.

I decided to test just how weak DOB passwords can be

Rather than simply making claims about password security, I decided to demonstrate the problem over a single “coffee” session with help of my good friend chatgpt free tier.

I developed a small Python cybersecurity laboratory using two libraries:

• Python’s pypdf library to create and validate password-protected PDF documents.
• reportlab to generate sample PDF documents.

We created a sample PDF containing a simple message:

PDF has been unlocked

The document was protected using a randomly generated fictional date of birth in DDMMYYYY format.

We then developed a separate Python program to generate possible dates of birth and test candidates against our laboratory PDF.

The experiment used a fictional date, not anybody’s real personal information.

Our actual results

The test successfully opened the protected PDF.

Measurement	Result
Password format	DDMMYYYY
Password attempts	16,391
Time taken	75.54 seconds
Average validation speed	Approximately 216 attempts/second
PDF successfully opened	Yes

The recovered password represented a fictional date of birth.

In other words, our laboratory computer took approximately one minute to discover the password in this particular experiment on a weak G6 HP mini pc already loaded doing other work.

And use I tested it with my ANZ actual documents (adjusting for the format as showing in the email) and it works too. But I won’t share those for obvious reasons.

Note this is not a universal password-cracking benchmark. Actual performance depends on PDF encryption, password derivation settings and hardware but on a proper setup seconds is pratical as I have no special hardware and its just python code.

The test demonstrates the fundamental problem: predictable personal information should not be used as an authentication secret.

Why this matters

The issue isn’t limited to the number of attempts or the speed of a computer.

The problem is that dates of birth have a constrained, predictable structure.

A password that looks like eight digits can have a dramatically smaller search space when those digits represent a calendar date.

And unlike a randomly generated password, a person’s date of birth may already be known publically so a code generator may not even be required.

Why this really maters! is that a date of birth identifyings who you are, it is necessary to access personal information and in fact its often the only control that is used in additional to your name to access and change data by so many companies these days including government agencies. As such if an attacker gets your date of birth they can start to compromise your identity straight away!

Balance this criminal opportunity with the easy in which the password can be reversed and you’ve got a threat vector than is both profitable to criminals and easy to execute by the most novice criminal because of how banks, like ANZ, are handling your private information.

I’ve spoken to people that have had their privacy breached like this, having to deal with ongoing court actions for acts by the person that stole their identity. Identity thief is horrible one of the worst forms of digital crime that can happen especially given how weak our government processes are such as handling of proof of infringement notices.

My position: This is not good enough

I believe organisations entrusted with confidential customer information have a responsibility to use appropriate security controls.

That includes banks, insurance companies, government departments, financial advisers and other organisations handling sensitive personal information.

I do not believe customers should be expected to accept weak document-protection practices simply because they are convenient for the organisation sending the email.

My position is straightforward:

1. Dates of birth should never be used as passwords for confidential documents.
2. Sensitive documents should be distributed through appropriately secured document-sharing systems.
3. Where encrypted attachments are used, passwords should be strong, random and communicated through a separate, appropriately secured and accessible channel.
4. Organisations should review their document transmission procedures against their own security policies and applicable privacy obligations.
5. Customers should be given a safe and practical way to receive confidential information without relying on publicly discoverable personal details.
6. And last but not least, channels should not discriminate customers with accessibility needs. Mandating mobile phones, multifactor authentication that requires those devices is a breach of the Discrimation Act 1992 and just not good enough.
   
   I’ve got so many examples now of agencies saying things like, call us on the phone and speak to us to prove your voice disiability (an unnamed road related agency), or met us in person and speak to us so we can understand your concern (computershare when asked to enable non voice based authentication for a customer that required a non mobile solution to account login)

A password-protected file is not automatically a secure document.

And a security procedure that relies on a customer’s date of birth should be challenged every time.

A discriminatory work around is not the answer.

Have you experienced this?

I would like to see discussion from customers who have received confidential documents from:

• Banks such as ANZ, CBA, NAB.
• Government departments and agencies such as Yarra Valley Water.
• Insurance companies or health providers like HCF
• Superannuation providers, like Unisuper.
• Mortgage brokers and financial services organisations, (I’ve seen some interesting ones like illion that requires customers to actually give them their login passwords to the banks to do a loan application)

Have you been sent a confidential PDF and instructed to use your date of birth to open it?

Were you comfortable with that process?

Did the organisation offer a secure document portal as an alternative?

I am particularly interested in documented examples of organisations using DOB-based passwords despite publishing security requirements that discourage predictable personal information as passwords.

Please do not publish your date of birth, account details, unredacted documents or other sensitive personal information in any discussions.

A final question for the organisations involved

If your organisation already knows that a customer’s date of birth is not an appropriate password for protecting banking access, why would it consider that same information suitable for protecting confidential customer documents?

Customers deserve better.

Privacy is not just about collecting personal information responsibly. It is about protecting that information throughout its entire lifecycle, including when it is sent to the customer.

I believe it is time for organisations to stop treating a date of birth as a security control and start treating customer privacy with the seriousness it deserves.

---

References and further reading

1. ANZ – Business Banking Conditions of Use (May 2025)
2. ANZ – Privacy Policy
3. ANZ – Document Exchange
4. ANZ – Secure Information Exchange
5. OAIC – Guide to Securing Personal Information

This article represents my position on responsible information security and consumer privacy. References to individual organisations are based on publicly available documentation. Any allegations about specific document-handling practices should be supported by the relevant correspondence or other evidence. This article is not a finding that any organisation has breached privacy law.