Security is core to what we do. This policy describes how we protect the Services and how researchers can report issues to us.
In plain English
A policy has to be precise, which makes it hard to read. Here is the same document answered as the questions people usually arrive with. It is a summary: where the two could be read differently, the numbered sections below govern.
What is protected, and how?
Traffic between you and us is encrypted in transit, and credentials are never stored in a form that can be read back — passwords are salted hashes, so nobody at this company can tell you what your password is, including when you would like us to. Section 1 sets out the encryption we use.
Who at Dual Login can see my profiles and cookies?
Access is limited to the people who need it to run the service and is granted per role rather than handed out generally, which is section 2. Your browser profiles live on your machine in their own data directories; what synchronises to your account is what you choose to sync, so that your logins survive a lost laptop or move to a second PC.
What happens if there is a breach?
Section 6 is the incident response commitment: contain it, work out the scope, and tell the people affected — with what we know, when we know it, including the parts that reflect badly on us. A notification that arrives late and vague is worse than useless, because the one thing it costs you is the time in which you could have changed a password.
I have found a vulnerability. What should I do?
Report it to us before anyone else, under section 5. Send enough detail to reproduce it, give us a reasonable window to fix it, and do not access other people's data while proving your point. We do not threaten researchers who follow that, and we would rather hear about a hole from you than from the people already through it.
Does the product itself make me more secure?
Against account linking, yes — that is what it is for. Against a weak password or a phishing email, no, and no browser can. Isolation limits how far one compromised session spreads; it cannot undo the compromise. Two-factor authentication on the accounts you care about is still the highest-value thing you can do in an afternoon.
Where do my synced profiles actually live?
On our infrastructure, encrypted, and only what you chose to sync. The full profile -- cookies, local storage, cache -- lives in a data directory on your machine. Syncing exists so a login survives a lost laptop or a move to a second PC, which is a real need, and it is opt-in per profile precisely because it is the one place profile data leaves your hardware.
Do you offer two-factor authentication?
Sign-in supports Google and Microsoft as identity providers, which is the practical route to strong second-factor protection today: enable it on that account and it protects this one. This remains the highest-value hour anyone reading a security policy can spend, and it protects far more than your Dual Login account.
What is a salted hash, and why does it matter that passwords are stored that way?
A hash is a one-way transformation: it can be computed from your password but not reversed back into it. The salt is a unique random value mixed in per account, so two people with the same password do not produce the same stored value and a precomputed lookup table is useless against it. The consequence is the one that matters -- nobody here can tell you what your password is, and a copy of our database does not hand an attacker your password either.
How do you handle the browser engine's own security updates?
The engine is Chromium-based, and its security fixes reach you through application updates -- which is the real reason section 3 of the EULA asks you to take them. An out-of-date engine is doubly exposed: it carries known vulnerabilities, and its version string is itself a detection signal that makes profiles easier to distinguish. Staying current serves security and the product's core purpose at the same time.
1. Encryption
We encrypt data in transit using TLS. Sensitive data at rest — including synced browser profiles and secrets — is encrypted. Passwords are never stored in plain text; they are stored as salted hashes.
2. Authentication and access
Accounts are protected by authentication tokens, and team access is governed by roles and permissions so people only see what they need. Internally, we follow least-privilege access, and administrative access to production systems is limited and logged.
3. Infrastructure security
The Services run on reputable cloud infrastructure with network controls, isolation between environments, and regular patching. We keep audit logs, monitor for anomalies, and maintain backups to help us recover from incidents.
4. Data handling
We minimise the data we collect, separate secrets from application data, and restrict who can access customer information. Where you use the local desktop application, your browser profile data stays on your own machine.
5. Responsible disclosure
We welcome reports from security researchers. If you find a vulnerability, please email security@duallogin.com with details and steps to reproduce. Give us a reasonable time to fix the issue before disclosing it publicly, and do not access or modify data that is not yours, degrade the Services, or violate the privacy of others. We will acknowledge your report, keep you updated, and credit you if you wish once the issue is resolved.
6. Incident response
If a security incident affects your data, we will investigate, contain it, and notify affected users and authorities as required by law, along with the steps we are taking.