Invented by Jenkins; George Maurice, Galloway; Gregory L.
Let’s look closely at a new way to make passwordless logins safe from phishing attacks. This article explains, in simple words, how this patent application improves device authentication, how it works, and why it matters. We’ll start with why this is needed, examine older solutions, and then show how the new invention brings better security for everyone.
Background and Market Context
Passwords are everywhere, but they have been a problem for a long time. People forget them, reuse them, or pick weak ones. Hackers can steal passwords using fake websites, called phishing, or by tricking users in other ways. Companies and experts have been trying to get rid of passwords by using other ways to prove you are you. This is called passwordless authentication.
Passwordless authentication tries to make logging in both easier and safer. With passwordless methods, you might tap an app on your phone, use a fingerprint, or press a button on a special device. These ways often use codes called cryptography. Cryptography can prove you are the real user without showing your password to anyone.
The biggest challenge is making sure only the real user and their device can complete the login. If someone else can trick the system, they can still break in. This is called phishing. Even with passwordless systems, some older systems can be tricked. For example, a hacker might get a special link from a login attempt and use it to steal access from the real user. This is especially risky on devices and apps that don’t have the latest security features.
Companies building login systems want to be sure their users are safe, but they also want their systems to work everywhere. Some devices and apps are old or use special browsers, so they can’t use the latest tricks. This means that to support everyone, developers sometimes have to use weaker security, which opens the door to phishing again.
The market for passwordless login tools is growing fast. Big companies like Microsoft, Apple, and Google have their own systems, but there are also smaller companies making special tools, called authenticators, that work on many devices. These third-party authenticators need to work everywhere and be easy to use, but also must stop all common attacks.
The key problem is how to pass secret messages, called authentication grants, from a server to a user’s device in a way that only the real device can use them. In real life, this often means using a “rendezvous channel.” This is a special link or code that is unique for each login attempt. If someone else gets this code, they can steal the login, so the channel must be safe.
Until now, many of these rendezvous channels were not strong enough. If a hacker could trick a user into clicking a link, or grab the code, they could steal the session. The new invention tackles this exact problem, aiming to make sure that only the device that started the login can finish it and get access.
Scientific Rationale and Prior Art
To understand why the new system is better, let’s look at how older systems tried to stop phishing in passwordless logins.
First, some systems use push notifications to phones or devices. When you try to log in, your phone shows a message, and you tap to approve. This is easy for the user, but not always safe. Hackers can trick people into saying yes to fake requests.
Some passwordless systems rely on special links or app schemes. For example, when you log in on your computer, you get a link that opens your phone app. This works, but if someone grabs the link, they can use it too. There is no strong way to check if the device using the link is the real one.
Another trick is called “loopback.” Here, the login system checks if the request is coming from a trusted app or browser on the device. It checks for special headers and certificates. This helps, but only works on some web browsers and not on all devices or apps, especially older ones or special webviews inside apps.
There’s also FIDO2 and WebAuthn, a standard that uses cryptography to prove you are you. This is strong, but not all browsers and devices support it perfectly yet, especially for software-based authenticators made by third parties. Some apps and browsers just don’t work with these standards.
Some systems use “mutual TLS.” This is where both the server and the device show each other special certificates to prove who they are. This is very safe, but setting it up is hard, and it doesn’t work everywhere. Some operating systems make it very hard to use, especially with apps that embed their own browsers.
Other solutions are built into the operating system, like Apple’s SSO extensions. These only work in certain browsers (like Safari) and don’t help if you use a different browser.
The main weakness in all these older solutions is how they pass the secret authentication grant. If the channel isn’t bound to the real device, a hacker can steal the session just by getting the right link or code. This is called a “rendezvous channel,” and it is often the weakest link.
In the typical attack, a hacker starts a login from their own machine and gets the special link or code. They then trick the real user into finishing the login, so the server sends the session to the hacker, not the real user. This is a huge problem because the system cannot tell that the login started on one device and was finished on another.
Some systems try to check the “origin” of the request, but not all browsers and apps send this information, or they send it in ways that can be faked. Other methods, like using special keys or certificates, don’t work everywhere or are too hard to set up.
So, the challenge is to make a system that works on any device, with any app or browser, is easy to use, and is safe from phishing. It must make sure that only the device that starts the login can finish it, even if the system has to use a rendezvous channel.
Invention Description and Key Innovations
This new patent proposes a clever way to make sure that when you log in without a password, only your device can finish the process. It does this by tying the special channel (the rendezvous channel) to your device in a way that is almost impossible to trick.
Here’s how it works, step by step, in simple words:
When you try to log in from your device, your app or browser (called the “user agent”) sends a message to a special server (the “coordinator”). The coordinator sets up a secure connection using a standard called TLS, which is like a locked tunnel between your device and the server.
The coordinator then creates a unique code, called a “subdomain,” for your login attempt. This code is different every time. The coordinator sends this code back to your device, telling your app or browser to use it in the next step.
Now, your device contacts another server (the “gateway”) using this unique subdomain. When it does this, your device starts another secure tunnel, and this action creates a special message called “ClientHello” that includes the subdomain in a field called SNI (Server Name Indication). This SNI is sent in the open, so other software on your device can see it.
A special app or helper on your device (the “authenticator”) watches for this ClientHello message using something called packet capture. Packet capture means the authenticator can see certain kinds of network traffic on your device. All major operating systems allow this in one way or another, so this trick works nearly everywhere.
When the authenticator sees the ClientHello with your unique subdomain, it knows your device is really opening the connection. It grabs the subdomain, adds a timestamp, signs it with a secret key that only your device has, and sends this proof back to the coordinator.
The coordinator checks this proof. If it is valid, it tells the gateway to finish opening the secure tunnel with your device. Now, only your device can finish this connection—no one else can use this subdomain or code, not even if they somehow get it from the internet.
The authenticator also watches for the final message (“ServerHello”) from the gateway. This shows that the connection is complete and safe. Only then will the authenticator let you finish logging in.
This method means even if a hacker tries to trick you or steal the subdomain, they cannot finish the connection. The server will refuse to talk to anyone else using that code, and the authenticator will only sign off if it sees that the connection really happened on your device.
The system is smart about performance and privacy. It only watches for the right kind of network messages, and it can filter things to avoid looking at things it shouldn’t. The server only lets one device use each code, and codes expire quickly, so hackers can’t reuse them.
The channels are set up using standard internet protocols (TLS and SNI), so no special hardware or new technology is needed. This means the system works everywhere, even on older devices or inside special app browsers.
The system also does not require your operating system or browser to have special features. It uses standard parts that have been around for years. The only thing it needs is the ability to see network packets and the support for SNI, which almost all devices have had for a long time.
If a hacker tries common tricks, like intercepting the network, replaying old messages, or guessing codes, the system blocks them in several ways. Only the real device’s authenticator can see and sign the right message at the right time. Codes are short-lived and unique, and the server will not accept more than one device per code.
The invention also adds a double check: the authenticator only gives final approval if it sees both the start and finish of the secure connection, all on your device. This stops a special kind of attack where a hacker tries to get you to confirm their own login session.
From a technical point of view, the invention is a new way to make rendezvous channels device-bound, using packet capture and standard network fields. It works on all major operating systems and does not depend on browser quirks or special hardware. It is easy to deploy and does not require changes to the way TLS or SNI works.
Performance tests show that the system is fast and works well even when many people are logging in at the same time. Security checks found and fixed a tricky bug, but now the system only approves logins after the secure channel is fully set up, making it extra safe.
This invention is a practical, real-world solution that makes passwordless logins much safer, even in places where older tricks don’t work. It means users can log in without passwords, on any device or app, without being afraid of phishing attacks. For companies and developers, it offers a way to support all users without lowering security.
Conclusion
Passwordless authentication is the future, but only if it is safe from phishing. The invention described here solves a key problem: how to make sure only the real device can finish a login, even when using a rendezvous channel. By tying each login attempt to a unique code and having the device prove it opened the connection, this system blocks common attacks and works everywhere.
For businesses, this means less risk and fewer headaches from stolen accounts. For users, it means they can log in easily, on any device, and know they are safe. The invention is simple, clever, and based on well-known internet standards, making it a big step forward in secure passwordless logins.
If you are building or using passwordless login systems, this approach offers a strong, practical way to prevent phishing and protect users everywhere.
Click here https://ppubs.uspto.gov/pubwebapp/ and search 20250220044.