Making progress toward launch 🔏

The TrustedLogin service works beautifully—it has for months. But before launching a platform that deals with sharing encrypted logins with support, it is vital to make sure all angles are covered.

Dotting all the security “i”s

Naturally, the biggest concern when it comes to TrustedLogin is security. We had two rounds of security audits during development and have implemented additional checks to address possible security scenarios.

After the latest audit, we implemented multiple changes suggested by the security professionals. Here are just a few of the modifications we made:

• Made it possible to revoke all existing logins from the TrustedLogin site.
• Added a verification step for each login that shares the support user IP.
• Added brute force detection that notifies the TrustedLogin site when a client’s site has multiple failed login attemps.
• Implemented a Pause Mode after a brute force has been detected. Pause Mode allows users to grant new access to websites, but no existing logins will be permitted until the brute force alert has been reviewed by an administrator.

A founding principle of TrustedLogin is that using TrustedLogin should always be more secure than sharing a username and password, sharing login credentials using a one-time secret site, or sharing a temporary login generated by another plugin. After multiple rounds of security audits, my confidence is higher than ever in our service.

The audits have been beneficial in another way: the security features we added are now differentiators. There’s nothing else like TrustedLogin in the WordPress space.

Mitigating potential downtime

When I launch a new product or service, I pay attention to my concerns. What am I nervous about? Are those concerns justified?

When designing the original structure of TL, we set out to create a MVP (“minimum viable product”) that we could iterate on. This led to us hosting our secure secrets manager on a single server—we would migrate to a distributed solution later.

That was two years ago, and TrustedLogin is far past the “MVP” stage! A single source of failure—that single server—was not good enough. I decided to pause the TrustedLogin launch in order to migrate our secure secret storage to a multi-node Kubernetes cluster. The encrypted secrets are constantly synced between nodes, and even if multiple nodes crash, another node will be live and ready.

By making these changes now, before going live, it means that we’re ready to scale immediately. This has delayed launch by a few weeks, but it’s worth it: my biggest remaining concern has been addressed.

It has been a long process to make sure TrustedLogin is secure and reliable. Now, more than ever, I’m thrilled with our setup.

My next blog post should be a release announcement, and that is truly exciting.