DEV Community

Cover image for SeguraPass: A Zero-Knowledge, End-to-End Encrypted Password Manager Built in Java
Bartol Benjak
Bartol Benjak

Posted on

SeguraPass: A Zero-Knowledge, End-to-End Encrypted Password Manager Built in Java

#java #showdev #security #saas

Table of Contents

 

 

Introduction

Password managers are some of the most sensitive applications we use. They hold the keys to everything: banking accounts, emails, private documents and the entire digital footprint of a person. With such a high level of trust, the traditional architecture of password managers raises an uncomfortable question:

Why should any company hold your vault, your keys, your password hashes or even metadata about your accounts?

This question defined the foundation of SeguraPass, a free, zero-knowledge, end-to-end encrypted online password manager designed so that your passwords belong only to you. Not the server, not the cloud and not the application developer.

SeguraPass is a full desktop application built with Java, JavaFX, Spring Boot and PostgreSQL, with cryptographic foundations based on SRP-6a, AES-256-GCM and Argon2id. Its primary objective is simple:

Even in the worst-case scenarios, such as server compromise, credential leaks and insider attacks, no attacker or administrator should be able to derive a single byte of your secrets.

Below is a breakdown of why SeguraPass exists, the problems it solves and the architecture behind it.

 

 

Why SeguraPass exists

The current ecosystem of password managers largely falls into two camps:

1. Cloud-First Password Managers

These are the most mainstream options, as they are convenient, cross-platform and full of syncing features.

But they come with major security drawbacks:

  • They often receive your vault unencrypted and encrypt it on the server.
  • They frequently send telemetry or usage analytics.
  • They rely on storing hashes of master passwords for login.
  • Many still use outdated KDFs.
  • Security mostly depends on policy ("We promise we won’t access your data") rather than design.

Even when implemented well, these systems require extensive trust:

  • Trust in the company’s servers
  • Trust in their cryptographic implementation
  • Trust they won’t add a backdoor
  • Trust they won’t leak telemetry
  • Trust their hashes won’t eventually be cracked

History has shown that trust-based systems inevitably fail.

2. Local-Only Password Managers

These avoid cloud risk altogether, but introduce a different set of problems:

  • No automatic syncing
  • Manual data transfer between devices
  • No redundancy
  • High risk of losing or corrupting local vaults
  • No multi-device access
  • Poor portable backups

Users are thus forced to choose between:
Convenience and insecurity
or
Security and inconvenience

SeguraPass was built to combine the best of both worlds and break out of this compromise.

 

 

SeguraPass: The Best of Both Worlds

SeguraPass is built on two fundamental principles:

1. Zero-Knowledge Authentication

The master password never leaves the device.
The server only stores a verifier generated through SRP-6a, from which attackers cannot reverse-engineer the master password.

2. Client-Side End-to-End Encryption

Credentials are encrypted before leaving the device using AES-256-GCM and are only ever decrypted locally.
The server never sees plaintext credentials, master passwords, encrypted key material or key derivatives.

This means that even if the entire database becomes public, your passwords remain unreadable.

 

 

Architecture Overview

SeguraPass executes four critical workflows that must remain secure:

  • Registering a new user
  • Logging in
  • Writing credentials
  • Reading credentials

Underlying everything are two SRP parameters (N and g) defined by the RFC5054 3072-bit group.

1. Registration Flow (SRP-6a)

Registration flow

When a new user registers:

  • 1. The user enters their email and master password.
  • 2. The client generates:
    • A random authorization salt (for SRP)
    • A random key salt (for AES key derivation)
    • A verifier v = g^x mod N, where x = H(saltAuth | masterPassword)
    • A random device ID
  • 3. The client sends only:
    • The randomly generated authorization salt
    • The randomly generated key salt
    • The verifier v
    • The device ID
  • 4. The master password never touches the server

To activate the newly created account, the user verifies their email address through a link received via email.

2. Login Flow (SRP-6a Mutual Authentication)

Login flow

SRP is used again during login:

  • 1. Client sends their email, device ID and A = g^a mod N, where a is a randomly generated client secret which cannot be reverse-engineered from A
  • 2. Server responds with B = (k*v + g^b) mod N, where b is a randomly generated server secret which cannot be reverse-engineered from B, k = H(pad(N) || pad(g)) and v is the stored SRP verifier. It also sends the stored authorization salt back to the client
  • 3. Client computes a proof M1, which is calculated like this:
    • First, the premaster secret S = (B - (k*g)^x)^(a+u*x) mod N is calculated, where u is an ephemeral value calculated using N, A and B, meaning both client and server can calculate it independently
    • Afterwards, the proof M1 = H(pad(A) || pad(B) || pad(S)) is calculated and sent to the server
  • 4. Server independently computes M1, calculated like this:
    • Server calculates its own premaster secret S = (A * v^u)^b mod N
    • The server calculates M1 in the same way as the client
  • 5. If both M1 proofs match, server sends:
    • A short-lived JWT
    • A refresh token that is hashed and stored connected to the client's session
    • Its own proof M2 = H(pad(A) || pad(M1) || pad(S)), proving to the client that it independently calculated the same S
  • 6. Client calculates own M2 in the same way and verifies server's M2 to ensure the server is legitimate before accessing the service using the supplied tokens

If anything has been tampered with, the authentication will fail.

This creates a fully authenticated session without ever revealing the master password.

3. Writing Credentials (Client-Side Encryption)

Writing credentials

Before any credentials are stored:

  • 1. The client derives a 256-bit AES key using:
    • Argon2id
    • The user's master password
    • The user's key salt
    • Argon2id parameters: 64 MB memory, 3 iterations, 1 lane
  • 2. For each credential field (namely website, username and password), a new random 12-byte IV is generated
  • 3. The client encrypts each field using AES-256-GCM and sends the encrypted fields and their IVs to the server
  • 4. The server thus only stores field ciphertexts and their IVs, from which field plaintexts cannot be reverse-engineered

Neither the AES key nor any of its derivatives ever leave the client.

4. Reading Credentials

Read credentials

To read credentials:

  • 1. The client fetches encrypted data and IVs
  • 2. The same Argon2 key is recomputed locally
  • 3. Credentials are decrypted locally on the device

At no point does the server have the decryption key or any means to derive it and decrypt the ciphertexts remotely.

 

 

Tech Stack

Client

  • Java 17
  • JavaFX 21
  • ControlsFX, ValidatorFX
  • BootstrapFX + Ikonli

Server

  • Java + Spring Boot
  • PostgreSQL
  • Cloudflare Tunnel for secure HTTPS access

Crypto

  • SRP-6a (via BouncyCastle)
  • AES-256-GCM
  • Argon2id

Packaging & Deployment

  • jlink + jpackage
  • Inno Setup installer

 

 

Application Screenshots

Registration screen

Registration screen

Login screen

Login screen

Dashboard

Dashboard

Adding new credentials

Adding new credentials

Dashboard after new credentials have been added

Dashboard after new credentials have been added

Updating existing credentials

Updating existing credentials

Deleting existing credentials

Deleting existing credentials

 

 

Challenges Encountered

1. Implementing SRP-6a Correctly

A custom RSA-based scheme was initially considered, with encrypted private keys and challenge signatures. However, it was rejected due to the possibility of offline attacks.

SRP-6a eliminated this risk and provided a proven, secure, mutual-authentication mechanism.

Implementing SRP securely required careful handling of:

  • Big integers
  • Hashing
  • Handling ephemeral values

Storing ephemeral values very briefly (<1 minute) in the DB solved multi-step request flows safely.

2. Achieving True End-to-End Encryption

Ensuring the server never saw plaintext required:

  • Per-user salts
  • On-device Argon2 key derivation
  • Random IVs for each field
  • Local AES-256-GCM encryption

After implementing this, no plaintext credential data leaves the client.

3. Packaging & Distribution

Creating a self-contained Windows installer required:

  • Using jlink to produce a custom runtime
  • Packaging with jpackage
  • Wrapping the output with Inno Setup
  • Fixing module issues and JavaFX rendering errors

4. Update Handling

A simple, robust update system was implemented:

  • Client checks a version endpoint at startup
  • Endpoint returns version, release date and download URL
  • If client app is outdated, user must update it to continue

5. Secure Client–Server Communication

Even though SRP combined with end-to-end encryption already protects against MITM attacks, HTTPS was still mandatory.

Cloudflare Tunnel was selected because it:

  • Provides automatic TLS
  • Hides the server’s IP
  • Blocks direct inbound traffic
  • Reduces malicious traffic

 

 

Security Considerations

SeguraPass follows a defense-in-depth model:

Authentication Security

  • SRP prevents offline attacks and password disclosure
  • No password hashes are stored
  • All SRP values are strictly validated
  • Only BouncyCastle primitives are used

End-to-End Encryption

  • AES-256-GCM with per-field IVs
  • Argon2id with large memory usage
  • Zero-knowledge server storage

Transport Security

  • TLS enforced via Cloudflare
  • Server identity validated through SRP M2
  • JWTs validated and short-lived

Update Security

  • Version endpoint served over HTTPS
  • Installer auto-removes old versions

Design Principles

  • Secure-by-design, not secure-by-policy
  • Strict separation of concerns

 

 

Installation and Integrity Checks

Users can simply download the installer EXE or ZIP by going to the following link. Before installation, they can verify integrity via SHA-256 also present at the supplied location.

 

 

Final Thoughts

SeguraPass was built with one goal in mind:
Maximum security with zero trust

By combining modern cryptography, a zero-knowledge design, strong key derivation and secure mutual authentication, SeguraPass eliminates the historical weaknesses of both cloud and local password managers.

Whether attackers gain full database access, intercept traffic or compromise the infrastructure, they gain nothing but encrypted blobs.

Your secrets stay yours.

 

 

If you have any questions or suggestions, feel free to leave them in the comments below!

Top comments (0)