Passage Connect: Eligible for an innovation?
Participating in the hackathon organized by 1Password provided me with an invaluable opportunity to delve into the world of WebAuthn and its Passkey Authentication feature. The integration of Passkey authentication through Passage, a solution offered by 1Password, proved to be an incredibly smooth and user-friendly experience. Over several days, I thoroughly explored the capabilities and benefits of this integration, allowing me to gain a comprehensive understanding of its potential in various applications.
If you are interested to know, how my thoughts began and ended up building Passage Connect, please keep reading
How thoughts articulated to build Passage Connect
For interested readers, who wonder what ran behind the scenes (my brains :p) that caused sleepless nights since the time (15th June 2023), I came across this Hackathon.
Creating this mindmap in a diagrammatic form was even more difficult than the real process. ๐ฌ
Motivation
SSH keys are the first entry point to any of our beloved and treasured servers. but are they really secure
Point to highlight from the below article: "Keys/passwords bought on the dark web (including SSH keys)"
1Password goes above and beyond in protecting your keys from being compromised. However, when it comes to the security between SSH authentication and 2FA, is there room for additional measures?
The typical flow involves SSH authentication with a password, followed by 2FA verification, resulting in a successful authentication(SSH->PASSWORD->2FA->Auth Success). While this offers a solid layer of security, there's still potential for further enhancement. We need something that is not easily guessable or manually stored like a password. This is where biometrics can come to the rescue, but traditionally they have been tied to specific desktop hardware or external devices.
Fortunately, with the advent of WebAuthn, biometrics authentication can now be supported over the web. This is where Passage, with its exceptional integration capabilities, comes into play. Imagine marrying server authentication with the power of biometrics using Passage.
The marriage of server authentication and biometrics authentication through Passage opens up exciting possibilities for strengthening the security of SSH and 2FA. It provides an extra safeguard against unauthorized access while offering a user-friendly and seamless experience.
With Passage's innovative approach to integrating biometrics authentication, we can take the security of our server authentication to the next level. By leveraging the power of WebAuthn and the convenience of biometrics, we can create a robust and future-proof authentication solution that brings together the best of both worlds.
Introducing Passage Connect
A seamless passwordless authentication for Servers!!! Yes, that is the reason for removing the or and adding Beyond in my cover image.
SSH(secured by 1Password)->Connect(Passage)->2FA(Google Authenticator)
OR
SSH(secured by 1Password)->2FA(Google Authenticator)->Connect(Passage)
Experience the convenience and security of a seamless passwordless authentication solution for servers! Say goodbye to the hassle of managing weak or guessable passwords when it comes to server access.
Here's how the enhanced server authentication route unfolds:
SSH, already fortified by the robust security of 1Password, forms the initial layer of defence against unauthorized access.
Enter Passkeys, powered by Passage, the ultimate passwordless authentication solution. Passkeys revolutionize the way you authenticate yourself to servers. No more remembering or storing passwords manually. Instead, Passkeys use your official computer, phone, or other trusted devices as the medium for authentication.
The power of 2FA (Two-Factor Authentication) further strengthens the server authentication process. With Google Authenticator, you can enjoy an additional layer of security that verifies your identity using a time-based OTP (One-Time Password) generated on your trusted device.
By combining SSH, Passkeys, and 2FA, the entire server authentication journey becomes exceptionally robust. And the best part? You no longer need to carry separate devices or tokens to unlock access. Your existing computer or phone becomes the key to seamless and passwordless server authentication.
A short video for the Demonstration
Components of Passage Connect
At the Core, Passage!
Authentication Device (Desktop / Mobile Browser, Desktop / Mobile App)
Server Component to host and verify authentication post receiving passage token
Server Component: A client (as an executable configured in sshd_config at startup / PAM module file) installed on your servers that you want to authenticate
How does it work?
A typical successful authentication flow is described below using a sequence diagram using Mermaid โค๏ธ
The code does cover failure cases also :). Just don't want to overwhelm my readers
FCM is not implemented in the source code developed at github. Because thats the easiest challenge of all in the passage connect.
What did it take to build Passage Connect?
Passage Go SDK
Golang
sync.Mutex
sync.Cond
sync.Map
Developers' Favourite (Go Routines)
C
SSH (Secure Shell)
Docker
React + Typescript (Example React App)
Web Push, FireBase push notifications, Desktop Notifications
Bash
Virtual Box
AWS ec2
SSL (Let's Encrypt) and some domain setup basics
Linux
Ubuntu Server
And the most important PAM (Pluggable Authentication Module) of Linux
Some restless nights since a few things were new to me here too.
Patience to understand PAM documentation, they are not as friendly for devs coming from JAVA, Golang and other such languages
The thrill against the clocking ticking at the Hackathon
Locking myself out of test VMs in the trial runs ๐
Passage Connect is just a working and tested Prototype!!!
Tested on a single instance for a single user. Can it be configured for multiple users on the same/different machine? Yes. Would I recommend running it in production? No!
Why is the Prototype, not production ready?
Production-ready means ready to market or at least have a beta version. The reason for not being production ready is Resources!!!
Technical Reasons
Re-architecture: The connect application works well on a single server node and when it comes to the authentication system high availability is a must. This means involving cache, pub-sub systems, messaging
Linux architectures: The build has to be compatible with various Linux architectures (example: arm64be || armbe || mips || mips64 || mips64p32 || ppc64 || s390 || s390x || sparc || sparc64) + Tested on various flavours of Linux images and cloud providers
User applications: The demo is a web application, however, the offerings could be a desktop app, a browser extension and a mobile.
Notifications: Web Push and Mobile push notifications engines integration
Infrastructure: Testing on various providers like GCP, AWS, Azure to name a few
Functional Reasons
I believe in User First experience. From installation by tech teams to the end users
We are touching server security, which means that specialists are involved
The Passage Connect is a major extension product (not a plugin) in itself providing organizations and individuals who wish to run servers with biometric security
Adminstration panel is a must!
How will access to servers be configured and managed (Grant / Revoked)
User roles for which Passage Connect will be a must and optional
Block authentication
Device and server mappings, etc
Allowing/disallowing logins during a timeframe
Additional authorization mechanisms to ensure the application is secure
Client App Configurations
Attempts numbers, duration of each attempt, actions on failures, etc
Notifications on login/invalid logins
Each of these needs a thorough and deep discussion
Team Reasons
Product
Linux & Cloud Security Expertise
Architects
UX & UI
Developers
Testers
And all this needs time and finances to ideate, build and test
Like they say "Rome was not built in a day" :) Happy to collaborate and work with 1Password if they would find this interesting. ๐
From my past architectural estimation, it looks like around 9-12 months.
Hope my reasons are justified to the reader, as this is a prototype submitted for Hackathon. โค๏ธ
Finally the code, you all want to see
The code is uploaded to the repository, https://github.com/godwinpinto/passage-connect.
Part of code
Passage Connect Server Component
Passage Connect Client
Executable (for sshd_config authentication variant)
PAM module (for PAM authentication variant)
Passage Connect device(web) module
Attention to developers!!! This code deals with Authentication modules
Would love to hear from you
If you enjoyed the article then please feel free to press the like button. Your upvote makes a difference. Would love to hear your views in the comments below.
30 mins left to go for the date of final submission!!!
Now time to rest, rejuvenate and trek to the next mountain.
Once again thanking 1Password and Hashnode for organizing this event, to all participants whose submissions I loved and enjoyed reading and being of the contributing community.
Thank you all for your love and support.
Subscribe to my newsletter
Read articles from Godwin Pinto directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Godwin Pinto
Godwin Pinto
Although being in various roles of a software development company by talent, a software architect and development enthusiast by hobby. I love creating business ideas that come to life with the touch of technology. Always evaluating an impactful problem to solve. One Idea can change your life!