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:

1. SSH, already fortified by the robust security of 1Password, forms the initial layer of defence against unauthorized access.

2. 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.

3. 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

1. At the Core, Passage!

2. Authentication Device (Desktop / Mobile Browser, Desktop / Mobile App)

3. Server Component to host and verify authentication post receiving passage token

4. 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

1. Passage Connect Server Component

2. Passage Connect Client

   1. Executable (for sshd_config authentication variant)

   2. PAM module (for PAM authentication variant)

3. 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.