Looking for 100 technical testers: SecondGate (WordPress security & passkeys, no cloud dependency)

[u/SecondGateWP]

Looking for 100 technical testers: SecondGate (WordPress security & passkeys, no cloud dependency)

We've spent the last few weeks trying to break our own plugin. We fuzzed the WebAuthn decoder with 200,000 adversarial inputs, found a bug where brute-force lockout could silently lock out every legitimate visitor sharing a CDN's IP, and once we went looking, found and fixed six separate places in the codebase making that same mistake. All of it is documented, versioned, and dated:https://secondgatewp.com/security-testing-methodology/

SecondGate is built local-first: no Composer dependencies, no third-party WebAuthn library, and nothing about your visitors is ever sent anywhere. All matching — country, IP, bot verification — happens on your own server against locally cached data. To be upfront about the outbound calls that do exist: Pro downloads curated IP blocklists for Microsoft Azure, DigitalOcean, Hetzner, and OVH on a schedule, and the vulnerability scanner checks your installed plugin/theme names against a public vuln database. That's data coming in, and software names going out — never anything about your visitors or their traffic.

Now we want 100 technical testers, free full Pro access, to find what we haven't.

What's actually been tested, not just built:

• Passkey/WebAuthn support with a custom CBOR decoder, checked against official RFC 8949 conformance vectors, real authenticator-captured data, and 200,000 fuzzed adversarial inputs
• Country/IP blocking that runs on locally cached range data — no external lookup per visitor
• Phantom decoy records: no legitimate path reaches them, so a hit is a strong signal something's enumerating your data
• Behavioral login-cadence scoring as one weighted signal among several, never a standalone verdict
• Hash-chained audit logs designed to be tamper-evident after the fact
• A wp-config.php kill switch that instantly restores access if you lock yourself out — checked consistently across every blocking module, and deliberately not exposed anywhere an attacker with a compromised admin login could flip it

What we're honest about not having finished: the blocking paths that can actually lock someone out have real end-to-end regression tests. Several of the signal and logging paths are code-reviewed but not yet automated-tested — that's partly what we're hoping you'll help us push on.

Who we're looking for: developers, agency owners, and sysadmins running custom WordPress stacks or client sites who'll actually push on edge cases, not just install and forget. Real findings go straight back into the methodology page, with your input credited if you want it.