A date of birth is a verification detail used in email account recovery, not a credential that opens an inbox. Sign-in still requires the password, plus a second factor where one is set. A birth date alone therefore opens nothing. Its value to an attacker comes from combination. Paired with a name and an email address, it can support a recovery claim and make a phishing message or a phone call more convincing. This article sets out where providers use a birth date as proof, how attackers obtain one, and the measures that stop it being useful.
What a birth date does and does not do#
A birth date is not a secret in the way a password is a secret. People share it on social media, on forms and with services that ask for it at sign-up. It is also short. Only 366 days exist in a year, and the year narrows further once an attacker knows roughly how old a person is. On its own, it is a weak piece of information.
Sign-in is unaffected by it. The sign-in page asks for the password, and it asks for a second factor too when two-factor authentication is turned on. Knowing a birth date changes none of that. The guide on hacking an email account without a password sets out the methods that do work, such as stolen passwords and session theft. A birth date is not among them.
Recovery is where a birth date has force. Recovery exists for people who have lost both the password and the second factor, so it has to rely on details the owner can supply from memory. A birth date is one of those details. It is also a detail an attacker can often find. The gap between what recovery accepts and what an attacker can find is the whole problem.
| Use of a date of birth | Result |
|---|---|
| Sign-in | Nothing changes. A password and a second factor are still required at sign-in, and knowing a birth date changes neither of those two requirements. |
| Account recovery | It counts as one verification detail among several. |
| Phishing | It lends a message or a call credibility. |
| Password reset at a bank | Regulators state it is not valid proof on its own for a password reset. |
A password can be reset after a breach. A birth date stays valid for life, and it stays useful to an attacker for as long as any service accepts it as a verification detail.
How a birth date reaches attackers#
Breaches are the largest source. Have I Been Pwned lists dates of birth among the exposed data in many large breaches, and the scale is large. The Facebook data set dated August 2019 covers 509,458,528 accounts, as HIBP lists, summarised by serus.ai. Names, phone numbers, email addresses, dates of birth, locations, employers, genders and relationship statuses are listed as exposed. The Facebook breach summary records that the data was added to the HIBP database on 4 April 2021 and that no passwords are in the data. The absence of passwords does not make the set harmless. Each email address in it sits beside the name and birth date that recovery checks ask for.
The Luxottica leak is another case at the same scale. HIBP lists, as summarised by serus.ai, 77,093,812 accounts. Names, emails, phone numbers, addresses, dates of birth and genders are listed. The Luxottica breach summary notes that the data was taken in March 2021 and leaked in 2023. Because a birth date cannot be changed, the exposure does not fade with time.
Public posts are the second source. People post birthday messages, photos of celebrations and age milestones, and friends and family add to that. A birth date found in a breach can also be checked against a public post, which confirms it. Data brokers are the third source. They collect public records and sell them, and a name plus a rough location is often enough to pull a full birth date from a broker listing. The guide on how email leads to identity theft explains how these pieces join up: one leaked detail leads to another, and the email address is the thread that ties them together.
The guide on checking whether an email address was leaked explains how to find out if an address appears in a known breach. That check covers the address, not the birth date directly. The two travel together in the same breach records, so a leaked address is a fair warning that the birth date went with it.
Account recovery at the main providers#
Microsoft is the clearest example. Its recovery form uses a birth date as a verification credential. The guidance notes for the Microsoft account recovery form list Birthdate as a field on the form. They tell the user to enter the date of birth in USA format, MM/DD/YYYY. The same page states that the more information a person provides, the better the chances of validating ownership of the account. The form also asks for the full name, the country or region where the account was created, previous passwords and other details. A birth date is one item in that set. It is not the whole test.
Google takes a similar approach with questions rather than a single field. Its tips to complete account recovery steps tell users to answer as many questions as possible and to take a best guess rather than skipping a question. The page also states that Google never asks for a password or a verification code over email, phone call or message, and that passwords and codes should only be entered at accounts.google.com. Google's own page does not list a date of birth among the questions, so this article does not claim that Google asks for one. What the page does show is that recovery is a test of how many correct details a person can supply.
Apple's current recovery page lists no birth date among its recovery factors. Its support page for a forgotten Apple Account password lists trusted phone numbers, codes from a recovery contact, the account email address, a credit card CVV, and a recovery key or security keys. A birth date is not listed among them.
The pattern across the three providers is consistent. A birth date is useful to a provider only when nothing stronger is available. Where a stronger factor exists, the provider uses that instead. No provider publishes how much weight a birth date carries in a recovery decision, so this article cannot say how far a birth date alone gets an attacker in a real recovery attempt.
The view of banks and regulators#
Banks treat a date of birth with more caution than email providers do. Regulators have said so in plain terms. The European Banking Authority answered a question about whether a payer's date of birth and place of birth can count as a knowledge element for strong customer authentication under PSD2. Its final answer in Q and A 2021_5821, published on 30 July 2021, states that date and place of birth cannot constitute a knowledge element under PSD2 and the Delegated Regulation, since these may be accessible by third parties other than the payment service user or the payment service provider. The reasoning is direct: knowledge has to be something only the user knows, and a birth date is not that.
The same reasoning applies beyond banking. A birth date describes a person. It does not belong to them as a secret. Identity documents carry it, records carry it, and data that has already leaked carries it. A system that accepts it as proof is therefore accepting a detail an attacker can obtain through ordinary research. The EBA answer concerns payment authentication, not email recovery, and it should not be read as a rule for email recovery. The logic is the same logic, and email providers are moving the same way.
Phishing and impersonation#
A birth date makes phishing more convincing, and that is where it does the most damage in practice. A phishing message that opens with a name and a correct birth date looks like it comes from a company that knows the recipient. A phone call that quotes a birth date sounds like a support agent who has already verified the caller. The birth date is not the attack. The attack is the message or the call, and the birth date is what makes the target trust it.
The mechanism is simple: a company that holds a birth date is expected to know it. A message that includes it therefore passes a quick check in the reader's mind, and the reader then follows the link or answers the questions that follow. The guide on how phishing uses a leaked email sets out how a leaked address is used to target a person. A birth date adds one more correct detail to that targeting. The guide on checking whether an email is phishing gives the checks that still work when a message looks right. The checks that still work are the sender address, the link destination, and whether the message asks for a password or a code.
Impersonation at a help desk is another use. A caller who gives the correct name, email address and birth date can sound like the account owner, and a support agent who relies on those three details may accept the claim. This is the same weakness as in the recovery form, applied over the phone. The defence is the same in both cases: a second factor that cannot be recited from a breach record.
Birth dates as passwords and PINs#
Some people use their birth date as a password or a PIN, and that is a separate problem from recovery. A birth date used as a PIN is easy to guess once the birth date is known, and the research on this is old and clear. Bonneau, Preibusch and Anderson studied customer-chosen banking PINs and found that guessing PINs based on the victim's birthday lets a competent thief gain use of a stolen bank card once for every 11 to 18 stolen wallets. The finding is reported in Bruce Schneier's write-up of the research. The research dates from 2012, so it should not be read as a current rate. The mechanism has not changed: a PIN built from a birth date falls as soon as the birth date is known.
The same warning applies to passwords. A password that contains a birth date, or that is a birth date with a few extra characters, is weak against anyone who knows the date. Credential stuffing is the attack that turns a weak password into a taken account: a password exposed in one breach is tried against other services, and a birth-date password is also easy to guess directly. A birth date should never appear in a password or a PIN, in any form.
A spam email on its own does not give an attacker access either, and the guide on whether opening a spam email can hack an account explains why. The risk in both cases is what the person does next: clicking a link, entering a password, or giving details to a caller.
Protection measures#
The strongest protection is a second factor that does not depend on personal details. An authenticator app generates a code on a device the owner holds. A passkey proves possession of the device itself. Google states that passkeys provide the strongest protection against phishing. A passkey cannot be shared, copied, written down, or given away by mistake. It also bypasses the second step where two-step verification is set, because it already proves possession of the device.
The UK National Cyber Security Centre recommends setting up 2-Step Verification on important accounts, starting with email, because criminals with access to an inbox can use it to reset passwords on other accounts. The same guidance is repeated in the NCSC advice on securing user accounts, which states that turning on two-step verification instantly makes it much harder for an attacker to access an account, even if they know the password. The guide to setting up two-factor authentication on Gmail gives the steps for the most widely used email service.
Security questions should be removed where the service allows it. NIST's digital identity guidelines, SP 800-63B-4, prohibit password hints and knowledge-based questions as authenticators, and the full text of SP 800-63B-4 is published by the US National Institute of Standards and Technology. Where a service still forces a security question, the answer should not be a real personal detail. A random string stored in a password manager works as an answer, because the question is then answered by something the attacker cannot look up.
CISA's advice on safeguarding personal data covers the same ground from the data side: use strong passwords, keep software updated, and limit the personal information shared online. Every detail posted is a detail an attacker no longer has to steal.
AliasFleet and email aliases#
A separate alias for each site reduces what a birth date can be combined with. One email address used everywhere means a breach at any one service exposes the identifier every other service uses, and the birth date from that breach pairs with it. A different alias per site breaks that pairing. A leaked address is used nowhere else. AliasFleet provides managed aliases that forward to one inbox. Each alias can be paused or removed on its own if it starts receiving spam or appears in a breach.
An alias does not stop a birth date from being used in recovery at a provider that asks for it. That is a limit worth stating plainly. The alias changes the address an attacker holds, not the birth date the provider asks for. The protection comes from the combination: the alias breaks the link between services, and two-factor authentication or a passkey stops the recovery attempt from succeeding. The guide on using an email alias for account recovery explains how recovery works when the address on the account is an alias, including which services accept one. Pricing sets out the plans, including the free tier of 10 aliases.
After a birth date is exposed#
A birth date cannot be changed. The response is to make it useless, not to hide it. The check is whether the email address appears in a known breach, using Have I Been Pwned. The next step is to turn on app-based two-factor authentication or a passkey on the email account, and the same step is repeated on every account using the address. Then any password or PIN that contains the birth date is changed. Security questions that use personal details are removed too.
If identity theft has already happened, the US Federal Trade Commission runs IdentityTheft.gov, which produces an Identity Theft Report and a personal recovery plan. A credit freeze at the main bureaus stops new accounts being opened in the person's name. A name, an email address and a birth date are the standard starting set for opening an account, which is why a freeze matters. The guide on whether a home address can be found from an email address covers a related exposure. The same breach records that carry a birth date often carry an address too. The same protections apply.
A birth date alone opens nothing. A birth date combined with a name and an email address is a verification credential that attackers can use. The fix is not to keep the birth date secret, because that is no longer possible for most people. The fix is to make the birth date worthless as proof, with a second factor the attacker does not hold and an address that does not link every account together.
