Devlog 25

I need new extenstion (old one is really crappy), and there are only 7 days to finish it (not doable right)?

So I’ve used AI to generate base code for extension, now I’ll review this whole thing (I’ve partly already did, it was a hassle :d ). It’s much easier to work on it tho, we are using WXT, webext libs and code is really clean (working without them was bad decision, stack is one of the reasons I’m not trying to refactor old extension)

Here is list of extension features (it’s intentionally short):

• Capturing passwords
• Coping username / password for each entry
• Filling passwords
• Logging in (not registering tho)
• Generating passwords (I’ll work on it soon!)

I wanna put my extension on chrome webstore, It will take like 2 days to be accepted probably (that what it took when I tried to do that for flavortown (and it was accepted too late :c)

See you around

Devlog 24

After reading and analizing this flow today, I’ve realized that it’s better to keep each vault with it’s own passkey (one leak won’t expose your all keys). Also right now if you have already registered passkey for that vault you can choose to use exising passkey (so it’ll look it up on your device), or create new one (it might overwrite your old one (for same vault)).

After reviewing this PR by myself and finding nothing that would make this insecure, I’ve used GPT Astra 6 as well to review it, so now I’m pretty sure that this branch is ready to go on main.

See ya!

Devlog 23

I added one really important thing. Before, Mossy used a 4-digit PIN to unlock the vault (it was used as a wrapping key (after going through HKDF and Argon2)). It was 10,000 combinations. Argon2 made it take longer, but after some time (a few hours), it could be cracked (if someone had your encrypted encryption key (sounds funny :d)).

After this change:

• We use PRF from WebAuthn (really secure stuff) that uses Touch ID, Windows Hello, or Yubico Security Keys (and others) to give deterministic random bytes. Think of it like a random function that remembers what it returned for which argument. Assuming that an attacker would try to brute-force this encryption key, even with 10^18 tries per second, it’d take 1.8 x 10^51 years to crack it (kinda looooong time).

• Oh, and for those who can’t or don’t wanna use PRF, I’ve added regular passwords. They’re not as good as PRF, but it still takes a really long time to crack those.

Those changes are still in an open PR, but it’s 10 PM, and I need to take a closer look at it tomorrow (already did a code review myself, but I’m kinda sleepy, and I’d like to keep y’all secure <3).

See ya!

Devlog 22

Frontend:

• Added light, dark, and auto themes support (with settings tab!)
• Settings tab with themes options and links to request new features
• Added dashboard onboarding to help users setup their vault and add their first password
• Reworked key synchronization (now users will provide 6-character code instead of 6-digits code (Also it lacks of ambiguous characters like “l” and “I”)

Backend:

• Complete rework of key-sync microservice (HTTP + SSE instead of WebSockets) (so user can access synchronized passwords up to 5 minutes after they are sent)
• Improved scallability by completely rethinking key-sync flow (that was kinda tricky)

Devlog 21

Changelogs
Frontend:

• Standarized colors, boders, shadows, and button styles using globals.css system
• Updated typography: Syne for body text and Geologica for headings
• Centered headers navigation links
• Redesigned home page hero
• Fixed the footer so it stays at the bottom of the page
• Added leaf decorations on home page
• Based on feedback (from flavortown) I’ve decided to add some links to docs and instructions on how to set something up.

Backend:

• Added SSE endpoint for live device enrollment updates

I am working on delivering some more things before end of stardance. Stay tuned!

Devlog 20

Here is what happend after last devlog (lots of improvements :D)

On frontend:

• Improved secured passwords chart, so it does only show integer values, centered chart’s line
• Added total count of passwords chart (as default mode)
• Added email verification interface
• Improved recent actions section
• Removed website icon from recent action card (API was broken, and it didn’t looked good anyway)

On backend:

• Finished and integrated email verification system (verification link and code expires after 15 minutes)
• Added limits for incorrect codes, resend cooldowns, and hourly email deliveries
• Added rate limiting to public verification endpoint
• Emails are sent asynchronously through RabbitMQ

That’s all for now. I’ll focus on design consistency & responsiveness for now.

Devlog 19

It’s been a long time from last devlog.
Here is changelog:
On frontend:

• Vault loading, refreshing, selection, etc are now centralized in zustand store
• Removed redundant useVault hook
• Now user can select vault from dashboard view
• Added clearer selected-vault indicators and improved keyboard accessibility
• Made dashboard vault cards presentational and reusable
  On backend:
• Fixed critical bug in resource server logic (refresh token could be used as auth token (very bad :c))
• Improved and refactored jwt validation & generation
• Added correct typ claim in JWT tokens
• Simplified refresh token claims (some were unused or not necessary)
• Updated Authentication.md documentation
• Expanded JWT generation, management, and decoder tests

Work in progress:
Currently I’m working on new feature, central microservice that will handle sending emails to users
This is what I got so far:

• Batched async communication through RabbitMQ
• Integration with resend and some templates
• Retry queue with 30 secounds delay
• Service requeue mail only if something went wrong with sending (429 or 5XX response), if recipient doesn’t exist, there is no requeue
• Added tests for duplicates, pending commands, successful sends, permanent failures, and retryable failures.

See ya!

Devlog 18

Mock API is finished, now I’m working on frontend design & consistency

Changelog

• Finished Mock API
• Renamed RippleButton to Button as it’s generic right now
• Made Button component generic (support for icon, ghost buttons etc)
• Replaced all buttons with generic Button component

Also I adjusted some colors so design is more consistent.

See ya!

Devlog 17

Device manager is now up and running on production!
in code review I noticed:

• some edge cases (mostly related with multi-threading)
• user could not change accounts (persisted device id was the issue)
• probably more, but stardance was down so I couldn’t write this devlog

Now I’m working on creating Mock API so frontend development will no longer require running real backend.
Stay tuned!

Devlog 16

Finally device manager is ready to go.

• Refactored frontend side logic for key-sync to work with new API
• Fixed bugs, improved error handling (so error message is not misleading)
• Removed .idea folder from repo
• Introduced mossy-reactor (way to test micro-services with their dependencies without deploying them to main before tests)

Now it’s time to work on frontend features + design (typography, colors, globals <– boring stuff ://)

Devlog 15

• I’ve integrated API with frontend, created new tab for managing devices.
• Fixed some bugs related to interation of cross-microservice communication (maybe I’ll write some integration tests? who knows)
• I’ve added detection of OS and device type via user agent (using Yauaa library). Now I’ll have to think about how to create good risk-engine when at same time not storing too much user informations (to keep it privacy-first) If you guys have some idea how to do that let me know!
• To merge this feature to develop branch I need to fix some really minor bugs.

see ya!

Devlog 14

Soo…

• Recently I saw that there was no way to add new devices (** facepalm **). From last devlog I created nice enrollment system that will require already verified device to accept new one before trusting it.
• I’ve utilized JWT scopes for that, so client authenticated with enrollment token can only access specific endpoints.
  All of that probably sounds pretty easy but e g. I didn’t wanted to duplicate existing code, enrollment token is issued by same /login endpoint etc etc. basically it was quite a hustle.
  Hopefully, next devlog will be about how I integrated API with frontend (cross your fingers!)

BTW: test count jumped from 31 to 72 from last devlog so you can see how big is the difference!

Devlog 13

Device manager is pretty much ready to go to production from API pov (there are some things that I still need to code tho), from last devlog I integrated it with Auth microservice, with each login / session refreshment it’s checked if given device is blocked, if so, Mossy will refuse to provide user new tokens.

PS: look at those green tests (so cool)!

Hello there!

From last devlog I’ve managed to add some features for this new Device Trust Microservice.

• Right now device can be blocked by another device (it will stop this device from access to account)
• Nonce challenge is working and has really good test coverage (this whole microservice does too) thanks to TDD
• I’ve finished implementing controllers & their tests

It might look like TDD is slowing me down, but my code is getting really mature (each scenario is prepared). For whole process of developing this MS I didn’t opened insomnia even once - and that’s cool, because running tests without running whole MS (and it’s dependencies) is much faster.

See ya!

Hello everyone,

For last 10 hours I’ve made major progress on Mossy development.

• First of all my custom JWKS system got replaced by Spring Boot OAuth2 Resource Server Starter (looong name isn’t it?), it’ll make future maintance & coding much easier. In futher I’m going to migrate it to use Authorization Server Starter to achive full OAuth2 compatibility.
• Also I’ve been learning how TDD works, and for last 4 hours I’ve been using it during coding, it makes life so much easier!
• I’m currently working on new feature - Device Manager, it’s really huge feature (I need to refactor existing Device MS), but it’s really exciting, it’ll show you what devices are added to your account & analyze risk of each login (based on your common IP & MAC & OS & some more) it requires me to change old Device Microservice domain to just key-sync. Also I’ll create 2 new microservices - one called Device Trust (I’m working on it currently), it’ll tell my Authentication system to allow login or not (before cryptography was just for key-sync) by using challenge - client’ll receive randomly generated nonce and it’ll have to sign it with it’s key. Then if everything is alright it’ll ask Risk Engine if it should send user an alert or not (in future it might require MFA from client detected as higher risk)

This is my biggest project ever
Stay tuned!

Mossy now supports ssh public keys as well

• Refactored actions in frontend code to achive cleaner code
• Added validation of ssh keys

Mossy now supports SSH keys!

• Old Add Password form got removed, and replaced by new, cleaner one.
• Also I’m on my way to refactor code, and make lifting of Mossy’s extension UI.
• Support for public keys, and other SSH specific features will be introduce later, right now, only private key is supported

Notes system is ready and works like a charm, I had minor problem with JPA while implementing it (Cascade.ALL) fixed issue. Notes are encrypted with vault encryption key, so it’s suitable for sensitive data. Next up I’ll implement usage history!

Now, I’m working on implementing notes for passwords, backend is already ready, and frontend logic is half-way there, probably I’ll finish everything tommorow. Also I’ve made major refactor in vault request handlers logic by creating AbstractVaultRequestHandler to keep boilerplate-code in one place.

Mossy’s search engine works like a charm!

Currently, I’m working on a search engine for Mossy using Fuse.js. There are still a few things to implement, such as the UI for query search, and some bugs in the tag search logic to fix.

I’ve finaly finished system of managing tags! I really like how it turned out. Next up I’ll work on searching and filtering passwords!

Whole tag system is ready on backend, currently I’m working on integrating frontend with API in nice way. stay tuned !!!

I’ve created vault <—> backend communication for adding, assigning, and getting tags. Also adding logic is ready on frontend. Whole system ’ll be ready by tommorow 😱

Currently, I’m writing tag management system, that will include CRUD on tags, searching for passwords with tags. Adding tags already works! Also I’ve made really nice roadmap of Mossy Development!