A sign-in page can copy a bank's colors, logo, wording, and help links almost perfectly. The hostname is harder to copy. That difference gives password autofill a useful security role: a manager can compare the site asking for a password with the site recorded alongside that password before it offers the secret.
Quick answer
Password autofill can interrupt many phishing attempts, but it cannot certify a website as safe. When a credential stored for accounts.example.com is requested by accounts-example.com, strict hostname matching should refuse the match. Krypt uses exact normalized host matching and no parent-domain fallback. The user still chooses whether to fill. Autofill can be misleading when the saved hostname is wrong, the operating system cannot identify the web origin reliably, or the real origin itself is compromised.
The safest interpretation is narrow: a correct autofill suggestion is evidence of a hostname match, not proof of brand identity, trustworthy page content, or a clean device. A missing suggestion is a reason to pause. It is not an invitation to copy the password manually.
What an autofill system actually decides
Autofill is a multi-party workflow. The webpage or native app exposes fields. The operating system or browser describes those fields and the requesting context. A credential provider receives enough information to find candidates. The user selects a candidate, and the platform places values into the identified fields. Security depends on what context reaches the provider and how cautiously the provider matches it.
Four questions should remain separate:
- Field question: are these inputs actually username, password, or one-time-code fields?
- Origin question: which hostname or app is requesting the credential?
- Match question: which stored records are authorized for that exact context?
- Release question: did the user intentionally select and, when required, authenticate for the credential?
Correct field recognition without correct origin matching can put a real password into an impostor form. Correct matching without an intentional release can expose credentials through an unexpected automatic action. Conversely, a cautious refusal can be inconvenient on a legitimate page whose fields or origin were not described properly. A secure design should prefer an understandable refusal over guessing.
| Signal | Useful conclusion | Unsafe conclusion |
|---|---|---|
| No saved login appears | Stop and verify the full hostname and context | The manager is broken, so manual paste is safe |
| Expected login appears | The provider found a matching saved context | The page and device are unquestionably trustworthy |
| A related subdomain is refused | Exact matching is separating two hosts | Every subdomain operated by the brand should inherit the password |
| The password was filled | A credential was released into identified fields | The resulting session cannot be stolen or abused |
Hostnames matter more than page appearance
Read a web address from right to left around the dots, while remembering that public suffixes can span labels—for example, co.uk. In login.example.com, com is the top-level domain, example is the registered name, and login is a subdomain. An attacker who owns example-login.com has a different hostname. So does example.security-check.com: its controlling domain is security-check.com, regardless of the trustworthy word placed to its left.
Lookalike attacks exploit what people skim. A hyphen, substituted character, different top-level domain, or internationalized character can make two addresses look similar. Exact matching is indifferent to the logo and prose; different normalized host strings do not match. That is valuable, but it is not a visual-brand detector. If a user saves the real password against the lookalike address, the stored association itself is now wrong and future autofill may consistently repeat that mistake.
Why exact host matching is stricter than parent-domain matching
Some services use several legitimate hosts: www.example.com, login.example.com, and support.example.com. A convenience-oriented matcher might treat them as members of the same parent domain. That can reduce repeated setup, but it also expands the set of pages allowed to request one credential. A vulnerable or abandoned subdomain then matters more.
Krypt takes the narrower route. A password record stored for example.com is not returned for login.example.com; a record for login.example.com is not returned for evil.login.example.com. Case and a final trailing dot are normalized where appropriate, but the resulting hostname must be equal. When a service genuinely signs in on another host, verify that address independently and record it deliberately instead of relying on inherited access.
Ports are a separate detail. An HTTPS URL such as https://example.com:8443/ still has the hostname example.com. Krypt's matching is host-based, not a promise that different services on different ports are separate credential boundaries. The URL scheme, certificate validation, and platform's representation of the requesting page still matter.
Apple Password AutoFill and associated domains
Apple's Password AutoFill documentation says the system recommends credentials for an app's associated domain and supports third-party password managers through credential provider extensions. Association is bidirectional configuration: the app declares domains and the website publishes an Apple App Site Association file. Apple's workflow documentation explains that the system checks that file and then supplies relevant options when the user selects a supported field.
In Krypt's Apple credential provider, the operating system supplies service identifiers. Krypt converts HTTP or HTTPS identifiers to canonical hosts, rejects malformed values, user-info disguises, wildcard domains, domain strings containing paths or ports, and unsupported schemes, then compares the requested host with the stored host for equality. The iOS extension does not release a password without interaction: it asks for fresh device-owner authentication and rechecks the credential context before completion.
That design does not make every app screen equivalent to a website. A native app needs the platform association and correctly marked fields. Safari, embedded web content, and native views can reach the credential provider through different platform paths. If Apple supplies no usable web service identifier, Krypt's exact-host authorization cannot create one by inference.
Android Autofill and web-domain context
On Android, a user must explicitly enable an autofill service in system settings. Apps and browsers provide an assist structure containing fields and, for web content, a web domain. Android's autofill-service guide describes the provider and dataset flow. Krypt inspects the most recent structure, looks for username, password, and one-time-code fields, and stops if it cannot find a nonblank web domain. It passes that host to an exact normalized database query; no parent hostname is substituted.
Android's more detailed AutofillService security guidance warns providers to authenticate native app packages and to verify web-domain relationships using Digital Asset Links. It also explains that WebView content in an iframe can generate a separate autofill context whose web domain comes from the frame's source. These are platform-level trust problems, not details that a recognizable page design can solve.
Krypt's current Android implementation uses the web domain exposed in the assist structure and returns only exact-host records. It does not invent an origin when that value is missing. The implementation should not be described as independently proving every requesting app's signing identity or Digital Asset Links relationship. Treat Android's platform integration, supported browser behavior, and accurate domain reporting as part of the trust boundary.
Subdomains, iframes, and embedded sign-in pages
An iframe is a webpage nested inside another page. The address bar may show the outer page while the login fields belong to the frame's origin. A legitimate payment or identity service can use this structure; so can a deceptive page. Android documents a frame-specific web-domain context for supported WebViews. Other combinations of browser, operating system, and embedded content may behave differently or decline to offer credentials.
Exact matching still answers only the hostname Krypt receives. It does not tell you who controls the outer page, whether scripts on the legitimate origin were altered, or whether a post-login redirect is safe. When an embedded flow is surprising, open the service through its known app or address instead of solving the ambiguity by pasting a password.
Krypt's answer: exact-host matching and deliberate release
Krypt is a zero-knowledge password manager whose shipped OS-level autofill uses the hostname stored with each password record. On Android, Krypt normalizes the requested hostname, performs an equality query against stored hosts, and offers matching datasets for user selection. If the vault is locked or its live engine is unavailable, Android directs the user to unlock Krypt rather than returning decrypted credentials from that path.
On Apple platforms, Krypt exports credentials from the currently unlocked real vault into a platform-accessible encrypted cache tied to that vault session. The credential extension validates the cache, filters records with exact-host authorization, requires device-owner authentication, and confirms the cache is still current before completing the request. A vault switch, lock, stale session, malformed identifier, or unmatched host prevents the normal release.
This approach makes silence meaningful. If a record for bank.example is absent on bank-example.help, do not search the vault and force the password into the page. Inspect the full address, leave the page, and open the bank from a trusted bookmark or its installed app. If the genuine provider has changed its sign-in domain, confirm that change through a separate official channel before editing the saved host.
Krypt's OS-level autofill should also be distinguished from its pending Chromium connector work. This article does not claim that a separately distributed browser extension is generally shipped. The behavior described here is the current Android Autofill Service and Apple Password AutoFill credential-provider path.
Why manual copy and paste removes the phishing signal
A password manager can withhold a suggestion because the host does not match. Once you open the vault, copy the password, and paste it yourself, the destination receives the secret regardless of that mismatch. The protective comparison did its job; manual paste overrides the outcome.
The UK National Cyber Security Centre makes the same practical distinction in its guidance on phishing links: password-manager autocompletion can help because an incorrect site should not receive the password, but a person can still be persuaded to enter it manually. This is why “autofill did not appear” should become a stop condition in your personal workflow.
What autofill cannot protect
A real hostname can serve malicious content after a site compromise, DNS or hosting incident, or unsafe third-party script change. Exact matching will see the same host it saw before. Likewise, a malicious process on an already compromised device may capture keystrokes, screen content, clipboard data, or an authenticated session. Autofill is not malware detection.
Autofill also does not make a reusable password phishing-resistant. NIST's current authenticator guidance explains that passwords are not replay-resistant and defines phishing as tricking a claimant into presenting an authenticator to an impostor. Use a unique password so disclosure does not spread, and enable a phishing-resistant authenticator such as a passkey or security key where the service offers one.
Finally, autofill does not validate what happens after sign-in. An attacker can steal an existing session, trick you into approving an OAuth permission, or place a fraudulent payment instruction on a legitimate account. Continue to verify sensitive actions, review provider activity, and protect recovery methods. Host matching is one control in a layered account-security plan.
A safer autofill checklist
- Save the credential only after reaching the service through a trusted address or installed app.
- Store the exact sign-in hostname rather than a brand name or assumed parent domain.
- When the expected suggestion is missing, stop and inspect the entire hostname, including its registrable-domain and public-suffix boundary.
- Do not bypass a mismatch by copying and pasting the password into the same page.
- Treat a related subdomain as a separate host until the service confirms it.
- Be especially cautious with embedded frames or app WebViews whose origin is unclear.
- Use unique generated passwords and phishing-resistant MFA where available.
- Keep the device and browser updated, and investigate unexpected account activity separately.
The key question is not “did autofill appear?” in isolation. Ask, “which hostname did the platform identify, which exact record matched it, and did I intend to release that credential here?” Krypt answers the match narrowly. Your verification of the site, device, and action completes the decision.
FAQ
Does an autofill suggestion mean the website is legitimate?
No. A matching suggestion means the requested hostname matched a saved credential under the platform and provider's rules. It does not prove that the site's server, page content, or your device is trustworthy. Verify the domain and use phishing-resistant MFA where available.
Why will Krypt not offer a credential on a related subdomain?
Krypt uses exact-host matching with no parent-domain fallback. A credential stored for example.com is not offered to login.example.com or support.example.com. After independently verifying the service's real sign-in address, save that exact hostname as a deliberate credential record.
Is copying a password safer when autofill does not appear?
No. Copying and pasting bypasses the hostname check that caused autofill to stay silent. Treat the missing suggestion as a reason to stop, inspect the full address, and open the service from a known bookmark or trusted app instead of forcing the credential into the page.
Can Krypt autofill passwords in every app, browser, and frame?
No. Availability depends on the operating system, browser or app integration, correctly identified fields, and usable domain context. Krypt's Android service requires a nonblank web domain, while Apple supplies service identifiers to its credential provider. Ambiguous or unsupported contexts may produce no suggestion.
Technical references
Apple's Password AutoFill overview and workflow describe associated-domain credential suggestions, supported fields, and credential-provider extensions. Android's implementation and API references document the autofill service, user enablement, web-domain context, app verification, Digital Asset Links, and iframe handling. The NCSC explains the phishing value of refusing an incorrect site, while NIST defines the limits of reusable passwords and phishing-resistant authentication.
Use Krypt to keep unique credentials in an encrypted vault and release them through exact-host OS autofill when the requesting context matches.
