Ask HN: I built a Yubikey-based domain controller. Is it sellable?
In my own SMB, I still self-host git, CI, chat, etc. I love the privacy and control, but I also needed to open these services to remote workers without exposing them to the world. So I built an appliance to protect my internal web apps by requiring user/pass+yubikey at multiple layers of the stack: L3 (p2p vpn), L4 (mTLS), and L7 (OIDC). The appliance is self contained (VPN, LDAP, NTP, CA, OIDC), like a classic domain controller, and it keeps servers safe from any users without an authorized hardware key.
I'd love to bundle this with an admin panel and sell it, but I forsee problems connecting with the right market:
* Clients who have meaningful IT budgets will require inter-operation with their legacy domain controllers. This means I won't have an MVP without major changes and lots of testing. It also puts my own product at risk: if Microsoft doesn't want to support my integrations, they can disable my product with a software update.
* Clients who are too small to have lots of legacy IT requirements will have small budgets and require lots of support. Some of these clients will grow larger, but this is a long game. I would love to support these clients but don't want to die for lack of revenue in the short term.
How would you sell what I've built?
101 comments
[ 2.8 ms ] story [ 173 ms ] threadFinding the right market is hard work and consists entirely of rejection until you find it and entirely of rejection if you don't.
> * Clients who have meaningful IT budgets...
> * Clients who are too small...
Selling is hard work and mostly or entirely rejection. Finding reasons not to sell is much easier and avoids the hard work and the psychological tolls of rejection.
> How would you sell what I've built?
One customer at a time. That's how selling is.
On a brighter note. Hardware is a useful abstraction. Customers with big budgets will pay handsomely for annual service contracts and you can fly out in business class, stay in a nice hotel and markup the cost 25% in the materials section of your time-and materials invoice.
Good luck.
What use case + benefit would folks have using this? Why should they trust you?
A classic DC would authenticate windows logins and rely on an external network. My design authenticates just TLS and web-app logins (not windows) but also provides an authenticated layer 3 network. So it's hardware-attested zero trust -- something that's difficult to securely assemble out of existing SaaS.
This would be overkill for a typical call center (large scale, high churn, low trust) but perfect for a team working on sensitive IP (smaller scale, low churn, high trust.) Research and development, administrating expensive systems (regional manufacturing?) or for collaborative work on sensitive documents (legal?)
I think you should not have any issues integrating with legacy AD, but know bigger enterprises have mostly moved to online IdPs. Integrating with legacy AD will make your product also likely less secure. Maybe not the way to go?
> What is an identity provider (IdP)? > > An identity provider (IdP) is a service that stores and verifies user identity. IdPs are typically cloud-hosted services, and they often work with single sign-on (SSO) providers to authenticate users.
Read a full explanation at: https://www.cloudflare.com/learning/access-management/what-i...
I also hope to evangelize the mentality a bit more. Making the technical approach more feasible for non tech companies could be a boon.
So like it or not, you're going to be going door to door and helping smaller clients integrate this into their systems.
I think the right way to approach this would be to better understand the problems your clients would face when trying to integrate this kind of system, and then figure out how to solve them at scale in a way that you make customer acquisition and onboarding easier in the future.
Maybe it's things like creating base docker images for common services or OS pairings that have your stack already integrated. Maybe it's turnkey integrations with existing cloud identity providers or SSO. Maybe it's tailscale integration.
In fact tailscale is probably a good model to look at here - no large organization with an existing VPN solution is moving to tailscale, or at least weren't when they first started. But tailscale made a hard thing easy, and that's exactly what you're doing here.
I am not the market for the OP. Because I want the ability to change MFA vendors or federate, but the strategies of non-software companies is much different IMHO.
Companies fail, projects degrade, like lask week quality can go down.
The better question is why would my organization couple their success to you wagon, do you provide them with a way to get their info out in a portable way?
But there are many reasons to maintain the ability of your IAM to access multiple IDPs.
I do think there is a growing market for products that don't use your private data for their own goals.
But coupling a domain controller to a single 2FA provider just doesn't have any value as you have described it, at least for me.
I am not the entire market, just one potential user, so take this as feedback and not outright dismissal.
Perhaps if you develop the idea more I may be interested in the future.
- certificate management amongst a plethora of hosts, both SSL/web certificates for external use, and management and installation of self-signed "root" certs for validating internal applications and services - keymastering server: an appliance that acts as a genuine root of trust for an organization, using a Yubico HSM for key storage, but providing middleware & admin controls to manage issuance and distribution of intermediate certificates - AD/LDAP/SSO/etc user management, key issuance, etc.
If you have a small team and you don't need global redundancy for these functions across a large fleet, then it makes a lot of sense IMO to shell out $5-10k for a set it and forget it security appliance that makes certificate/key management simple and easy.
I think the biggest challenge is that it's hard to build trust as a startup without open-sourcing your stack, but that makes it a lot harder to get buy-in for an appliance model unless you have some creative dual-licensing ideas.
But "your keys/certs are stored securely on your hardware in the room next door" is a compelling value proposition & probably a much easier pill to swallow for certain companies than a cloud HSM or other solutions which sorta boil down to "trust me bro".
> a compelling value proposition
I completely agree; I'd originally drawn up a design for an offline root CA, then an box with a separate server for an intermediate CA with HSM for intermediate keys, a second, dedicated Secure NTP server (possibly hardware based) so that certificate expiration times could be kept short.
While all that is easy enough to prototype, the complexity of hardware distribution is better left to a later point in the roadmap.
A hardware HSM is not magic or even especially complex. Java cards can do it (slowly). Yubikeys can do it. Other vendors’ devices can do it. Lots of microcontrollers can do it as long as you don’t need resistance to complex physical attack. A startup in this space should seriously consider building its own.
Like, I was looking for an RFID entry system for a customer. Some of these are advertised as using DES/AES security (implied to be some version of DESfire). Most aren't. Try figuring out if they actually use DESfire and if the handshake is tunneled to the door controller (placed in a secure area) or the card reader (placed in the vulnerable, insecure area) has the keys and is just sending the UID to the controller. Nobody will answer this question. (Presumably because these secure systems are all actually UID-only on the backend so trivial to bypass if you learn a valid backend UID).
And even then, you're like "Okay, this sounds interesting. I wanna buy it." - "Oh, you can't. We don't sell these. You need a system integrator / installer." And then you go to one of these and it's super obvious they have essentially no clue how any of the stuff they're system-integrating works, but of course they won't give you admin access to the system they wanna install. "How do I configure this?" - "You don't. Only we do. Using a proprietary software." - "Where's the system manual for this?" - "We have it, we can't and won't give it to you."
I mean a lot of stuff works like this, usually with incompetent middle-men fucking up products which aren't all that bad (another most popular example would be HVAC and heat pumps, especially ASHPs) and manufacturers trying to make a SaaS kind of play with hardware you bought. But for security it feels especially egregious. How do you know the installer doesn't have a master key? Well, they usually do. How do you know the ACLs are set up correctly? Trust me bro. And so on.
None of this was done. It was out in the sun (laminate on control panel fused to the screen), air intake was factory sealed (system failed after a while) and it was left in the rain after an installer came to remove the covers (air intake / exhaust are top facing).
I could have easily solved the issues myself but didn't want to give them the option of pinning liability on the client.
If you do this, make sure you support multiple hardware keys.
Single Yubikey and no backup is not safe, since the key can be lost or damaged easily.
Single Yubikey and SMS backup or "contact customer service to reset" backup is NOT secure, as it reduces your security to that of SMS or the CS rep.
If the active key is lost/destroyed, a self-serve portal allows them to disable their active key at any time. But activating a backup key would require a (different) administrator's approval.
Also, I tend to leave Yubikeys permanently plugged into devices (1 per device) and register all the devices I have (4+) with every service. If any device is lost I would just login with another device disable that key. I also don't usually travel with keys unless I'm travelling with a portable device. When I move between two fixed desktops both in secured locations, the two desktops just have permanently-installed keys, I do not carry a key between them as walking around with a key is a liability.
Sounds like a money quote for the testimonials page!
How would you find some people who might be interested? This is the crux of marketing!
* find communities where such folks might hang out. This includes looking at places where self hosting is big (reddit, here, slacks, discords). Read stuff. If there's commercial channel, post there but respect the community.
* find in-person folks to talk to. local linux group meetups, local security meetups, etc.
* look up anyone on linkedin or in your work network and ask for 15 minutes of their time to get ideas on who might be interested in talking to you about this product. Stick to the 15 minutes, though.
* do some google searches that your potential customers might perform. From your description, I'm not sure I'd use the term "domain controller". Seems more like an app gateway or smart proxy instead. See who else is out there and who their customers are.
* searching might also turn up some communities for you to join.
* build a landing page explaining your product (as it will be). Add a mailing list. See if you can get anyone to sign up.
* You could buy some ads to drive folks to the landing page too. Use the same keywords you wanted to use. Set a limit as Google is happy to take your money.
* if you have more time than money, write up a few articles about building this, publish and share them. This sounds like a great topic for HN. Make sure you link to the landing page.
It's not easy, and this is why there are entire marketing and sales departments.
This post is a good overview too: https://www.kalzumeus.com/2013/04/24/marketing-for-people-wh...
Here's some classic patio11 wordplay.
> The other way I did, was I went home to Chicago, which is where my family is from, and took out $400 from an ATM, and walked around downtown Chicago and looked for salons and other massage therapists, that sort of thing.
> I walked in and said, “Hey, do you take walk‑ins?” “Yeah.” “Are you free right now?” “Yeah.” “Are you the business owner?” “Yeah.” “OK, I’ve got a weird proposition for you,” and no, not that kind of weird.
> “What’s the rate on a 30‑minute shoulder massage?” She would tell me. It’s almost always a she. I would say, “OK, I’m going to pay you the rate for a 30‑minute shoulder massage, but what I’m really interested in, I’m a small businessman, I live in Japan, I’m interested in the business of massage therapy. How about we just skip to that post‑massage cup of tea that you’re going to offer me,” I have learned this over the years. “Skip to the cup of tea, I’m going to pick your brains about how you run your business, and then I’ll go, no massage needed, and you get your money?” Almost everybody took me up on that, and nobody called the police. Yay.
* Put a note in your calendar to follow up this thread in 6 months and let everyone know your progress (or your decision not to progress, either is fine :) )
* If you are moving forward, start a startup accountability email list. Super easy to do, free, but will act as a forcing function for your activities. Wrote more on that here: https://www.mooreds.com/wordpress/archives/3324
I'd seriously started to look into 802.1X but in the "remote work" use case, L2 protection doesn't buy you much because outside your building, an attacker can get L2 access at Starbucks. It seemed like a good feature to leave out of the MVP -- but now I'm wondering if it wouldn't be worth prioritizing.
Can’t really advise what makes a good MVP for your effort. But if I could buy a box that was set and forget for this function, kept itself patched, complained when it couldn’t and wasn’t too expensive, I could acquire one where I work.
Think Tailscale+Let's Encrypt+Okta but all in a single package.
[1] https://learn.microsoft.com/en-us/windows-server/identity/ad... [2] https://learn.microsoft.com/en-us/entra/identity-platform/ms...
It's interesting. You have built something tightly coupled ("like a classic domain controller") but then it is interacting with inspecific, totally decoupled stuff ("(p2p vpn), L4 (mTLS), and L7 (OIDC)").
"Tightly coupled for me, but not for thee" - why would someone who has adopted a decoupled application infrastructure decide that their domain controller should be coupled? I feel like people want one or the other in totality, they are either completely a Windows shop, or they are completely using bits and pieces of everything from everywhere. Everyone in between is ultimately migrating to one end or the other.
I can't speak for how to sell something I've never used. But I know Okta is very popular, and I encounter many IT people in many tech forums basically describe a feature of Okta. That's a huge scope. But that's a company that has tackled the dichotomy of coupled versus decoupled solutions, by simply providing everything. Is there a little bit of a chance that a single person can make something competitive with Okta? Yes!
You'd really only want the current appliance if you don't have the in house staff to assemble/amalgamate an equivalent setup.
My pitch would be that tight coupling enables major security benefits in the implementation:
* rapidly propagate policy updates (eliminate race conditions caused by changes slowly propagating across SaaS vendors.) * simpler modules with fewer features, less attack surface * rich context in logs (even spoofed packets have a cryptographically verified source) * coherent security controls
> something competitive with Okta
I could imagine building the product into "the Okta of on-prem".
OK, now that sounds like a real product with a market, unlike your original post. I don't know if or how you can bootstrap to there (I assume Okta took a bunch of money so that they could blitz out to integrating with everything and didn't need to make sales when they couldn't integrate with everything - maybe building the integrations with a customer's systems as you acquire that customer?) - and I don't know how many people have non-legacy prem systems that they're willing to spend money on. But this is the pitch.
1. The market that needs this will not be capable to use it
2. The market that is capable to use it is also capable to use something like Cloudflare Access.
As for 'domain controller', like others have posted, that is a product or branded product from microsoft that doesn't have much to do with what you described. You could argue that Microsoft Windows Server can host most of those services, and will likely need a Microsoft Active Directory service (which in turn requires at least one Active Directory Domain Controller), it's not really related to what you are doing besides perhaps a user directory.
In a way, your product would address the classic setup that Microsoft (and Apple) have thrown away (many) years ago, companies are very bad at IT, and it gets worse as you focus on smaller companies and companies where IT is rather far removed from their core business. Something that is managed and maintained by someone else, that is where the money is, and in almost all cases that means the services and applications are not co-located in some office somewhere, mostly because the office is pretty much irrelevant these days.
I acknowledge this trend; Microsoft wants everyone in the cloud so their on-prem offerings, while entrenched, are stagnant. This could be an opening that lets me build a quality product for a modest customer base who are unable/unwilling to migrate.
Keep in mind that those brands also have connectivity, filing, user directories, network services (DHCP, NTP, NTP, L2 and L3 VPNs), but in practise they suffer from the same things small businesses have for decades: lack of internal knowledge. And since such systems are never set-and-forget, they would either need physical maintenance contracts (which SMBs can't afford) or remote SaaS-style maintenance which somewhat defeats the point.
The gap between people able to buy an appliance and people who know basic routing, DNAT and subnetting is really really big these days, and that's just to get things up and running. The next step up is still bigger gap than it used to be, but also quickly gets you into too-capable-to-be-a-market territory.
Maybe a better model is the one attempted by the private computing brands, I don't know a successful one of the top of my head but they generally have a NUC-like device with Linux on it with hardware root-of-trust and they present it as a portable-but-desktop computer that comes with a more trustworthy OS and network security. Some are based on heads & tails, others on Qubes OS, others just a fork of PostmarketOS with some Graphene in the mix. The early ones all failed because they just weren't useful to the average user, but the later ones didn't fail immediately while they were news.
This is a major advantage of the mesh VPN layer. If your bare metal hosts/guests hardware have internet access via plain old DHCP, they can connect to the mesh network which is where all the special networking happens at the direction of the controller. On the mesh, every node can have a persistent static IP and dns entry, simplifying the network topology for the layers above.
Even if it's the hardware authenticator your product currently works with.
Don't market it on current specifics; anyone not using a yubikey (personally or organisationally) will dismiss your product and never look at it again if you tie it to one specific third party vendor.
Secure remote access to internal applications
Security is a lemon market so vendor reputation and functional results are more important for winning clients than the implementation ever was.
2. Linked to the above, this is not a competitor to Active Directory. It’s the antithesis. It’s not for a small office of PCs on desktops. It’s to properly secure IoT devices in different locations - sensors, telemetry that niche businesses sell - they sell the service that the device provides, and want a reliable small footprint security solution. Maybe you are it
Edit: I may have misunderstood the use case however - you mention zero trust but I may be missing how it validates at different layers - would love to know more however ! DM me if need be :-)
However, even if I did get that right, your point (1) is excellent.
Smaller ISVs and/or MSPs could quite possibly sell this as part of a bundle, and if you can make it require -less- support than whatever their clients had been using previously that seems like it should make it of significant interest to them.
(I definitely appreciate the 'supporting SMEs is a time suck' concerns in the original post but 'make it less of a time suck for the people already doing it' plus 'turn yourself into 2nd line support only' seems like it could be a way to turn that concern on its head viability wise)
Unlike YubiKey they sell a wider range of products, such as secure hardware. It seems if you make it work with NitroKey they might be able to sell it as a bundle.
Probably won't hurt to reach out to them as a potential partner
Also, the cheap Nitrokey FIDO2 key doesn't support ED25519 for SSH keys, only RSA and ECDSA, and even though they are open source, the promised support for ED25519 is still not delivered even after 4 years, so I doubt it will ever come: https://github.com/Nitrokey/nitrokey-fido2-firmware/issues/3...
Ultimately, while I like the idea of open-source, for a company use case, we had to go with Yubikey.
Almost all of our software is in-house as we're very adept and efficient coders and it keeps the dependencies to a minimum, especially with regards to the licensing. We only have a single non-royalty free dependency and it's a total nightmare, the component is probably responsible for 30% of revenue but 95% of headaches.
So I'm trying to think of a hypothetical where we would buy such a product. Basically if I could have the same flexibility of making such software ourselves I would pay up to what we could expect it would cost to make it. If we were to need it it would be for a ~$1-3M USD project which we could carve off ~$100K for something like this due to the expected dev time savings which could be redirected to other areas while we scale up for the project. But for the second time round pony up bigger chunk say ~$200K to cover the cost of building it ourselves.
We were looking on standardizing on YubiKey, probably for the same reasons you went with them. Honestly I don't think my company should be your target market, we make software and are very good at it so it's a bit hard to sell us software, but if you decide to give out your contact details I'll make a note of it and keep an eye on what you choose to do.
Your target audience is likely companies running old-school, legacy Microsoft installations. These tend to be on-prem for the reasons you list.
The problem, though, is if these companies want a VPN, they already have it. You'll have to convince them that the VPN they've been using for decades is insecure (it's not).
----
Lastly, at a technical level, I'm not entirely sure what you achieve by requiring user/pass+yubikey on multiple layers of the stack. You don't gain any additional technical protection (since L3 would wrap everything else) while still having a single point of failure.
There is strong value in security in layers. While VPN access requires remote users to have a hardware key, internal VMs may need a file based pre-shared key/certificate. If an attacker somehow manages to gain VPN access without a hardware key, they’d still either need a hardware key or they’d have to additionally comprise the TLS PKI be able to complete an mTLS connection to an app. Checking the hardware key on the way up the stack keeps an attacker on the VPN from having a privileged position.
Running the same, breached check in multiple places doesn’t make anything more secure, it simply runs a vulnerable check more.
——
Layers do add to security, but the argument here is that you’re adding more doors to a bank vault while completely ignoring they all open with the same key.
Another way to put it is, that attacker is walking a part of the vault floor, but still doesn’t have keys to the lockboxes.
What I’m focused on is the repeated authentication on multiple layers of the network stack. It just isn’t necessary. Either your authentication mechanisms work at the lowest level, or they’re broken across the entire stack.
In your analogy of the bank robbers, the robbers might exploit a weakness in an exterior wall, and gain entrance to the lobby. The other locked doors will still prevent them from robbing the vault.