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

Bartol Benjak — Wed, 10 Dec 2025 17:31:13 +0000

Introduction
Why SeguraPass Exists
SeguraPass: The Best of Both Worlds
Architecture Overview
Tech Stack
Application Screenshots
Challenges Encountered
Security Considerations
Installation and Integrity Checks
Final Thoughts

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)

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)

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)

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

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

Login screen

Dashboard

Adding new credentials

Dashboard after new credentials have been added

Updating 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!

Forem: Bartol Benjak