EPISODE 1701

[INTRO]

[00:00:00] ANNOUNCER: Bitwarden is an open-source password management service that securely stores passwords, passkeys, website credentials, and other sensitive information. Matt Bishop is the principal architect at Bitwarden. He joins the show to talk about the platform and his work there.

Gregor Vand is a security-focused technologist and is the founder and CTO of Mailpass. Previously, Gregor was a CTO across cybersecurity, cyber insurance, and general software engineering companies. He has been based in Asia Pacific for almost a decade, and can be found via his profile at vand.hk.

[EPISODE]

[00:00:48] GV: Hi, Matt. Welcome to Software Engineering Daily.

[00:00:51] MB: Hello. Thanks for having me.

[00:00:52] GV: Yes. So today, we have Matt Bishop, who is the principal architect at Bitwarden, which is exciting. It's a product that I've used a lot and I've used a password vault for a long time. But quite a while ago, I switched over to Bitwarden for various reasons and I've loved that experience ever since. So, this is an exciting episode for me and I hope for listeners as well.

So Matt, I just love to start with your background, and really your story to this point in time now, and how you became the principal architect at Bitwarden?

[00:01:26] MB: Sure. I almost want to take a step back to understand more about your switch story, because it's very relevant to kind of the work that we do. We are very congenial competitors in the space of password management. So, it's always good to hear those stories, perhaps another time, where we get into what makes one product better than the other.

But anyway. Yes, so I have been in the software space for, I guess, 20 or so years. I think it really started with engineering. My father was working within, not as an engineer, but I had an uncle as an engineer. I had a grandfather as an engineer. My father was in sales for an engineering company for motors and pumps outside of the New York City, New Jersey area. As a kid, I'm a six-year-old and there's pictures of me standing inside giant motor housings, playing around in machine shops and yard. So, perhaps not software, because software was a very different thing in the eighties and nineties, when I grew up. But I think it put this bug into me about really becoming an engineer of some sort.

As I grew up, I kind of stayed with that space, electrical engineering, computer engineering, even though it was maybe not that at the time, and I got more and more into software, as I got older. The early nineties were very much that birth of being able to access the Internet and start to use technology in your home in very different ways than you had. So, I really jumped into that and started making websites, becoming a little bit of an entrepreneur myself, and using software on the web to really do different things.

But I would say back then, I was maybe not so much a coder, but getting by. Copy and paste, learning HTML, reading things in books, just doing what I could, and just matured that over the years. So, I thought I was going to really be more of a hands-on engineer, get into maybe aerospace engineering. It was my focus at the time. But I ended up going to Georgia Tech. And before I got there, I said, "Who am I kidding? I know a lot about computers. Let me get into technology, and just blend software and hardware where I could to get those nostalgic elements of my childhood but apply maybe of a software lens to it." 

This is the early 2000s and I focused on computer engineering, which is honestly not a lot different than electrical engineering in a lot of ways. But my focus was embedded systems, is what they call it at the time, or microcontrollers. So, small form factor computing. Now, we take Raspberry Pi's and all these devices we can just buy on the Internet for 20 bucks. So easy. But really thinking about what CPU design and pipelining and all the way down to assembly code and the binary of what it takes to really run a system. I liked that a lot because it was very practical, very hands on, building circuits and understanding what you were really running when you wrote your code.

So, I did a lot with MIPS assembly and technologies of that time that were so abstracted, even back then. But it really fascinated me. As I built up those layers and that experience, I got into Dotnet and I started to learn C# somewhat hobby like. I was a budding photographer at the time of all things and me and a couple of people who were into amateur photography and photojournalism also needed to put our photos on the Internet. So, take a little bit of that past experience, use a modern programming language. Dotnet 1.0 came out when I was in college. I started to build actual programmatic web experiences beyond classic ASP and some of the things at the time into what could be real application development.

I kept going with that. A little bit hobbyist. A little bit entrepreneurial. I ran a little photo startup for a time when I got out of college called PhotoCore, which is now long defunct. But I got out of Georgia Tech and took that embedded systems knowledge and ended up getting into mobile development. The iPhone came out about a year or two after I got out of school. App Store came out shortly thereafter. Android came out around the same time. So, all these App Store presences, the ability to build your own apps. I said, "Well, I have this great skill set to apply mobile software knowledge based on what I've done in the past." That's what I got into.

Me and a couple of friends, we met at work. We were doing basically Dotnet software development during the day and said, "Let's go build some apps." The joke back then in a sense was you'll build a 99-cent app, you'll sell a million of them, you'll retire early, the dream. But for every successful app you read about in the news, there were about 10,000 of them that didn't do that at all. So, we quickly learned that the App Store environment was a way to actually get into a better environment of consultative style development for everybody else that wanted to get into that space that weren't necessarily looking for the in-app purchase, or the pay to play, and built a company around it.

It was called iMobile3. We went from smaller to bigger clients and turned what we thought would be kind of a simple moonlighting gig into a full-time job, and went from what we thought would be a couple of years of an interest into a decade, and had 125 people by the time we were acquired by one of our clients at the time. I mention all this because this is actually what introduced me to what Bitwarden became. The founder of Bitwarden came on board to our company. We were doing more than development. We needed full-service technology. So, that meant building server side, creative and design teams, everything to really be a holistic software division.

Kyle, the founder of Bitwarden was a Dotnet engineer that came on board and helped build a lot of things with me in Dotnet, for loyalty point of sale, payment processing products. We kind of specialized in the payment space. So, I have lots of fun stories about working with Apple or Google on various things over the years and worked side by side with Kyle on building a number of things. He started this small idea of what Bitwarden was back then. Then, it was about eight years ago, he said, "Hey, this is become such a thing that I'm going to take it full time and I got to quit on you guys." It was a totally understandable exit and look where we are now. It's come all around, where now I'm working at Bitwarden.

[00:08:12] GV: Very interesting. Yes. It sounds like you and I don't have two dissimilar backgrounds, actually, just in how we probably moved from our school days to whatever we ended up doing in that next phase and then sort of, here I am talking to you from one side. But yes, very interesting.

So, Bitwarden has a very interesting context there of how it vaguely started. But why was Bitwarden conceived in the first place? I'm really curious. What did the password manager vault and maybe you can even correct me like what the better term is there? What did that landscape look like back when Bitwarden was sort of conceived?

[00:08:51] MB: Vault is almost, I always think about it in the Bitwarden sense. Not everybody calls it a vault. But that collection of stuff that you want to keep secure, which is much more than passwords today. But was really passwords at the beginning was a not too crowded space and there were some players that started getting into it. I like to think that most, everybody was starting out with the personal user in mind, because that's where it all starts. The individuals have to use it and there were a few players in the space when Kyle started to vet out this idea, but he saw it and said, "I can differentiate what we're building by being, first and foremost, an open-source platform and showcasing a different approach to not being perhaps as productized or building a walled garden, or a closed-in experience, like maybe some of the competition was doing at the time but something that is truly open." Open encryption standards, open source so you can truly see what is actually happening and being zero knowledge.

It started to create some differentiators about being, yes, another opportunity in the space. But being something that mostly the engineering minded individual, I think at first, could really grab hold of, and that naturally manifested itself into being more than just the personal vault, the personal manager, and getting into those business relationships that felt the same values. Honestly, a lot of the earliest business customers were from evangelism and advocacy inside those businesses where someone used it personally, and felt like it was a good fit for the business.

Self-hosting and other ways that we now exist today have matured, but I think it really started with just being an open-source product and something that someone could see and felt comfortable and trusted would be what they needed it to do.

[00:10:52] GV: Yes. I guess, a side question to that is when Bitwarden was conceived, is this when the average person, I say, the average person, more a probably technical person to begin with, was starting to understand the importance of unique passwords or just I have 10 passwords I need to store? Where did that kind of evolve from?

[00:11:16] MB: The big players that offered other things were much more simplistic as well, at the same time, in my opinion, that the synchronization of your Chrome profile or the iCloud Keychain that is so ubiquitous across the Apple ecosystem. These were many years away. So, the people and the technology that was there wasn't necessarily offering it. It was something that filled a space, I think, primarily just to be a place to hold something. Cloud connectivity is a big part of it. Bitwarden differentiated itself with a big self-host model so that someone could be sort of in between, depending on how you want to take that, run it locally in your network, or what have you. But you still had some of that connectivity, so that you could at least store something somewhere and it would be in a means that you could access it easily. 

Then, I think the product, and all password management products started to mature outside of that to be not just the container, but how do we make better what the actual thing is beyond passwords. But it really did start with a way. I need a place to hold on to some things. Not just passwords to be fair. The identity type management where you're not just holding on to these magic strings that may mean something or not. But knowing later on, whether those were good or not, like a health check, making sure they were different, et cetera. But maybe you want to put your driver's license in there or a credit card number. I think little bits here and there were easy extensions for someone to understand their vault, as we call it today, being more than just password management.

[00:13:05] GV: Yes. That makes sense. Certainly, I use the credit card vault bit just as much as the as the password piece. So, that makes a lot of sense. And yes, Bitwarden was from day one, was an open-source project, and what has been the importance of the community to the evolution of Bitwarden alongside, right now, Bitwarden has full-time staff on the development side. But yes, what has been the importance of the community back then? And then what is it sort of today as well?

[00:13:34] MB: The product really was open source, in a sense out of necessity products or software as a service offerings like GitHub were very much, if you want to use this thing for free, you're going to need to have a public open source type model, and that created many other great examples of open source beyond Bitwarden. But that truly is what it started.

So, it was always there, whether someone noticed it or not. I think it was via our placement of what the source was in a variety of different places that made it create some traction, meaning App Store presences, binaries that you could easily download and install, continuing to snowball that and we frankly offer a huge number of clients across a lot of different platforms that today is even a challenge to maintain, because we have so many great ways to use the product, is really how it started. And when you threw in the community element to that, GitHub is, in a sense, a very engineering minded place to go. The layman may not go there, but they would go to social sites like Reddit, or Reddit has been a strong source for us. We've stood up a community forum that is Mastodon base that someone can go visit and connect with that.

So, seeing the inklings of where this happens, and saying, "Okay. Well, what is this product? Let me learn more about it." And then depending on your acumen, being able to engage with the community that is going to fit that mold. The community resolves itself to a degree. I mean, there's great intercommunication that isn't necessarily coming from Bitwarden about how to do things, how to resolve things, how to use additional features, and so on, and so forth. Again, we just continue to build up that content library to better serve our users as it went on. But yes, it really did start with open source and as we matured that model, we created more. There was kind of a core Bitwarden repository, that is where it all began, and then it made sense to break things off and separate a mobile application and our clients, from our server, and so on, and so forth.

We have a pretty good collection now today, and we still follow the same model, though. We've done that for scale, for reliability, for maintainability, but it's all still out there. The thing that the individual user installs on their devices coming from an open-source repository where they can browse exactly where it's happening. But it was very grassroots in a lot of ways, where the community - we outsourced some of these things. The product roadmap was outsourced. When Kyle was running this solo, the community shared what the next big thing should be, or how to do something, and that is cyclical as well, where because it is GitHub based, in our case, we accept pull requests and issue filings.

Bring up a bug, propose how to fix that bug, add a whole new feature. We've had so many great contributions over the years from people that we just found, and we've actually hired a good number of them to join full time as a result. But a great number of them have come just from being original open-source contributors, and adding great features. 

[00:17:03] GV: Yes, that's a nice little anecdote at the end there, where it maybe isn't always obvious to maybe developers getting their start in their career, whether it's out of school, or just self-taught. How do you get noticed? And how do you look for that sort of dream role, and maybe see if where you're trying to work does have open source, and that's a great place to start.

[00:17:24] MB: Open source is a great recruiting mechanism in one sense, and it attracts different audiences as well. It's not just about building a product. It's about securing a product. We have public code review. You can see exactly what we're building while we're building it. We get contributions on an auditing type lens of, "Hey, I'd like to make this thing more secure, or add the security feature, or point out that there may be some kind of critical issue that it needs to be resolved." We get a lot more than just product features from it, too. The security presence is always very important to us. We're zero-knowledge encryption solution, but we want to make sure that everybody can see how it's done, how it's made, what the algorithms are. If something comes up a better way to do it, if you still propose that.

[00:18:10] GV: Yes. That is hugely important. It's almost interesting that sometimes, someone actually says, "Oh, Bitwarden, or let's just say a similar security angle product is open source." For some reason, they take the other view, and they think that makes it less secure somehow, and I have to kind of help them along and say, "No. Actually, it's quite the opposite." I won't name names here, but there is another password vault that is famously closed source and has had its fair share of security problems and I don't think that's unrelated to being closed source.

Let's dive into some of the kind of evolutions of Bitwarden, and the listeners will know, I'm a passkey guy. I love passkeys. So, we're going to talk about passkeys. But I mean, we're doing it also, because this is a huge step Bitwarden has had to take really, as other vaults have, as well. So, passkeys, they've been a big change in the way that users potentially get to register, login. I say register, that's on the bleeding edge right now. But certainly, as a multifactor option passkey have started to gain a fair bit of traction. How did Bitwarden sort of decide on its approach for how it integrated passkeys?

[00:19:28] MB: We like to be open and standards compliant whenever possible. So, that has matured over the years. I think we've gone from a hardware to a software space in a lot of ways, and we've supported not necessarily - we've gotten to the WebAuthn type world where we're really interacting and it's taken a while for browsers to really catch up to it. At the end of the day, browser technology or piece of OS technology that you hook into, has to be available there. So, the time needed to go on until we got to a place where that worked, and it's still catching up maybe in some ways. There's certainly a user adoption curve and getting comfortable with that, in that same vein. But we've supported hardware options like YubiKeys being a great example, for many years now, just as that way TOTP, and starting from a two-factor sense, perhaps a little bit of the edge of the most savvy users to being more and more mainstream to, frankly, enterprises and businesses in the day to day prompting more experience for the end user to know what those things are, such as using a fingerprint reader on their laptop to log in, or asking them to carry around a key that may generate a number, like a YubiKey, where it's a tap, or the variety of different devices that are out there.

It's becoming more and more software based. Friends, I like to say, with the FIDO Alliance, and getting into how we can participate in open standards as much as possible, and competition does as well. We do have common goals and making sure that we get a great user experience and we want to be that, again, open source showcasing of how to do that. The Passwordless.dev acquisition, about a year ago, year and a half ago, I suppose. Well, about a year ago, was a big part of that. How do we become that technical player that allows in today's world, a passkey-oriented option to get into that?

But that's just part of passwordless.dev. We can get more into that. But the software world of passkeys has been something that we've really been doing just for a few months, and it's building more and more traction. We have hundreds of thousands of passkeys registered on the platform. Thousands every single day, still register. So, we're seeing the grip. But it takes an army and it takes everybody kind of playing together to do that. We see Safari and Chrome and other browser technology starting to present that with their own experiences. The big tech players are presenting it in other experiences. That is a big part of it. When a login and a vault item, essentially, that you want for them to present that experience to you. Then, we're ready to go. We're opt in. You may not even notice that you ask for something to happen on the web and it just starts to present a Bitwarden experience for you.

So, we're prepared. I think we're continuing to push for even more depth and maturation, you might say, in what FIDO is putting out and how we go beyond some, call them V1 or even prior to V1 approaches to some of this. But it's getting there. I like it personally, but I'm a big technologist. The point is that we want to convince everybody to really get into it to get us to a proper passwordless world. Because as many I've seen that have used the product, unless you're single sign on in an enterprise or some of the more advanced use cases we have, you're still setting a master password. The master password is that key and there's advanced ways to defer that, or to be able to offload that key, and that's the big focus, I think, is getting to a full end to end passwordless state, which is remarkably technical when you deal with encryption keys and exchange.

We've done a lot of work in the last few months as well on what we call trusted device encryption, which touches on some of the same concepts where we're allowing devices to interoperate to handoff the key material necessary securely, so that one device can opt into a user's account without information a master password necessarily being entered.

So, strides here and there, continuing to push the hardware, continuing to push the ecosystems and the operating systems and everything lower level that we need to be successful there. But not done yet. 

[00:24:11] GV: Yes. I'm very familiar with what will happen when I approach a site that asks, do I want to register a passkey? And sort of what happens with Bitwarden. But maybe, could you just describe what does that flow look like to a user? Because I think there's actually quite a lot of people out there whose experience of passkeys is very, let's say hardware device specific right now. They assume it's going to be the Apple Touch ID that shows up. So, maybe you could just walk through what happens when Bitwarden is let's just say the Chrome extension is installed, what kind of happens?

[00:24:45] MB: It depends a little bit on your user setup and how deep you want to go into the Bitwarden world per se. But the typical experiences, let's say, you log into a Facebook or an eBay or and we're trying to maintain an index, actually, of all the websites that are out there that support passkeys, and there's other players contributing to that same kind of world where someone can just go and say, "Hey, where can I just start to add passkeys." This will be a part of our experience, I imagine, the future where we can say, "Hey, there's an option for you to take your current password-based login and add a passkey to it."

So, flipping that the other way, once you know that you're at a site, and you want to log in, there's usually some kind of offering. Would you like to add this? Sometimes it comes a second factor. I'd say more often than not, I see it as a two-factor option versus a direct login than others. There's certainly, some sites that are pushing it as a truly password as login. But it's often coming as a tow in to let's add a passkey to your site. Would you like to use a different method, and via whatever means they present that, and what ends up happening is, and this is where I say, it depends on how you've configured your extension, or what have you, a little bit, is you'll be prompted with a Bitwarden extension pop up in our ideal state that says, "Would you like to save this passkey to your account?"

It is essentially an invisible thing. It is a piece of cryptographic material. It doesn't have much to it other than creation date and a little bit of basic information. So, it's not going to wow you with its visuals in any way. But it gets attached to that vault item that you have that you just used. It's very germane to the two-factor process, because you'll have an existing, in our case, login item for your site. And then a passkey will be embedded into it. We maintain one passkey inside that vault item so that you can use that experience.

There's a little bit of that interplay, if you use your native browser support or an operating system support. So, you do want to say, "Hey, I'd like to use the Bitwarden extension for this case." We, of course, will fairly differ and we give a little button that says, "I'd like to use my operating system instead." Because we don't want the user to have saved it in one place and not another. But yes, it's pretty simple. It's just a couple clicks. And then you say, "Save passkey." You're good to go. Then, when do you want to use that thing, the prompt, and the experience is totally streamlined, where you start to log through. Let's say that website knows that you have a passkey registered, because it's holding on to the other half of the key material, essentially, for the passkey experience. We react to certain OS or browser events that ask for that. Then we say, "Well, we can provide this key material, this passkey." Then you just click a button, and then you're logged in, and it just magically works. So, your day to day is seconds of a password as login experience.

[00:27:49] GV: Yes, nice. Again, if it is not clear to those listening and haven't perhaps use this that the passkey is effectively then synced within your Bitwarden account, which is different to say storing a passkey via your Touch ID on Mac. If you don't use iCloud and that's a whole rabbit hole to go into. If you don't use iCloud, then it is effectively just stored on your, let's just say, your MacBook and it doesn't go with you anywhere.

Whereas with something like Bitwarden, it does go with you, wherever you have Bitwarden. One potential caveat to that is that, am I right in saying at the moment the native mobile experience doesn't support passkey? So, how does that look at the moment?

[00:28:32] MB: Correct. As of this recording, it is on the brink and we are eagerly at work on a totally refreshed mobile experience, actually, native iOS and Android applications. We've given some teasers out to our various community spaces about exactly what it even looks like. I think the community has responded quite positively to that. So, it'll be there.

We're releasing it on to the existing application as well. Just making sure that everything is working. This is actually a great example of how we have matured as a software product that any end engineer can just watch in real time. You can go to our mobile GitHub repository and see how it has changed over time. It was Xamarin based. Microsoft made it end of life with Xamarin and said, "You need to move over to MAUI." We've switched over to MAUI and we're kind of finishing up the MAUI transition with hot on its heels, the native application experiences as well.

So, we really want to cover all our bases and make sure that we have continuity features in everything to work well. It is a seamless upgrade experience and everybody will enjoy it and it'll have some of that native mobile capabilities. Passkeys on mobile, I think, is a place where the software parties that want the login also need to mature in a lot of ways too. Web-based experiences are by far the leader, and when you come to your favorite app and want to do a passkey log in on that thing, I think, there's definitely some work to still be done there some maturity in OS, Android or what have you, on how to make that a great experience and we'll be ready when they are.

[00:30:08] GV: Yes, I think that's a great call out and this is it. It's not to sort of zone in on one product, like Bitwarden and say, "Well, hang on, why haven't you done this bit of the of the puzzle yet?" It's a group effort. It's a very trivial way of putting it that passkeys can be fantastic. But it does require kind of every party of the Internet to kind of get on board with it, in the way that relates to their piece of the puzzle. So yes, great to see Bitwarden really pushing that.

You mentioned Passwordless.dev and that's a very interesting acquisition. So, this is more of the developer side, as opposed to the end user side. And I believe it's sort of helping developers faster integrate passkeys on their side, on the platform side. I believe it's also got quite a heavy magic link focus as well. But yes, could you maybe just speak a bit to the motivations behind that position? And what is Passwordless.dev today and what does it provide?

[00:31:05] MB: Yes. It is very much that technology platform, and we were able to kind of bring it in, and we have dogfooding aspirations to make it really a part of the platform where Bitwarden Passwordless.dev are seen as truly one platform. One of my goals is to, as I focus a lot on technical strategy, is how we think about everything working well together.

But out of the gate today, yes, it's I think, first and foremost, the most developer focused piece of technology or product that we really have. There are plenty of APIs for our password manager. We have a Secrets Manager product that was also all about developer experiences, and being able to use what we actually call internally ciphers. A cipher is really each individual component that is stored inside a user's vault, that are touching on a variety of these things. But Passwordless.dev really is that developer experience on plug the API in and support passkeys, and frankly, a few lines of code.

It's remarkably easy. It allows Passwordless.dev to be able to manage the key material for you, if you so desire, so that you don't really have to do more than that, and there's more advanced use cases of it as well. But it's meant to give you that passwordless login experience, even if you're not trying to build an entire infrastructure out to really support it. That naturally extends the password experience into other areas where you're not necessarily exchanging passkeys, but you want to provide a simple login, which is in the converse of what we were speaking about previously, much more a mobile first experience to me than a web-based one, where you can ask for, in this case, what we call a magic link to be created. You've entered the requisite information that we need to really feel that we're going to ask the real email address on file to click said magic link. Then, you turn the two keys, as I like to think of it, where you've got the other side of the scenario, you've got the email account, you've got the access, this is critical in verification and other scenarios, is to really ensure that someone has the access to the thing that they're trying to get into. Then, boom, you're in. You're done. You really never have to touch password material, key material or anything like that. It's a seamless experience. It's great for onboarding and account creation, obviously, login. Then, scenarios like account recovery are a lot easier too.

One of the most heart wrenching things that we have in Bitwarden is when someone forgets their master password. The harsh truth is, even if we could, we can't help you to answer that problem, because we're at zero knowledge. We have no ability to get around this thing for you. So, when you can utilize something like your ownership of a piece of technology, like an email account, a magic link can be really helpful to get you back into play. Because when you get stuck, sometimes it's a technical solution that you want to get back in. But if you don't have at least one piece of key information to get us a little bit further, then you get stuck. So, magic links is really helpful for those recovery type environments.

[00:34:24] GV: Yes. Magic links, I guess, a lot of people exactly are more used to using them properly is if you're a user consumer of a product. From the developer side, it's maybe not always as clear why they're going to go that way. It does remove passwords or it can remove passwords. There are various products out there that are password lists using magic links own linear, the great product management product that I use and I think a lot of listeners probably do. That is a purely register and login with magic links product. Could you be just elaborate a little bit, just what you have in what you were just talking about.

But in my view, it moves the security really into the inbox of the user. So, the users, the way that they then authenticate into their email client is then what effectively becomes their way to authenticate to this other service. Is that a good solution? I mean, this is just a sort of completely open question. Is that a good solution? Or is this just maybe a step to something else? I'm curious what your thoughts are on that.

[00:35:27] MB: If I were building a greenfield piece of technology, like a web-based software service today, this would be an incredible way for me to not eliminate, you never eliminate risk, but to incredibly diminish risk, meet compliance, if you're starting to get into the enterprise world of password management, because of the many lessons we've learned and we share technical and blog articles about is that, and these are everywhere, is users often reuse passwords. It's not even so much about a simple password. It's about password reuse.

So, we get attacked all the time where people attempt to do account enumeration attacks, or the kind of the converse of one of those where we test this password, or tested this user as an account. There's all these different attack vectors for it, because whether the user remembers or not, or they think, "Well, these things have nothing to do with each other." When you get into a data dump, or some kind of breach scenario, your two very disparate password reuses could really become a problem for you personally. So, if I was building a software product that had me not storing that, in any sense, and it literally was not stored anywhere, because it does not need to exist. It was a secure way to hand off using totally open standards that are incredibly secure.

We worry about the end state many years from now where you get to quantum level cracking and that sort of thing. That's a separate animal. But when you can rely on globally available cryptography technology that can be interchanged seamlessly, if a developer integrates something like Passwordless.dev, and simply not have to maintain a password anywhere, but just to hold on to an identifier. It not only diminishes the risk for us as the provider of that, since we don't have the other half of the critical key. But the end platform, it's an amazing way to build something where you're not holding on to personally identifiable information in a sense.

So, I would always go for that if I were to try to build something, and the effort today is to push out SDKs and interfaces in as many languages as possible to make that as easy as possible. Dotnet, PHP, Python, Go, whatever it may be in all of our products, really, so that it can be embedded, it can be made simple, and you can defer that risk and be a more secure platform by default, and never hold on to this information.

[00:37:56] GV: Yes. I think that's a good summary, especially anybody, as you say, Greenfield project. I mean, it really isn't that complicated now to integrate, if you're an existing product, and but certainly Greenfield products, there isn't really a good reason if you're starting off with email plus password. Then, let's just say you learn an MFA after that. That's not really a sensible way to go now. You should be thinking, what is the passwordless way that we can kick this off.

So, let's switch gears just a little bit, the Bitwarden business product. I'm curious. So, a lot of probably what we've been talking about almost 100% relates to a single user. It can also relate to a business user. But I'm also curious, what have been some of the challenges that had to be solved to make Bitwarden a successful business product as much as a consumer product?

[00:38:50] GV: As I alluded to a little bit earlier, there was a growth into the business space in a very grassroots way, or an advocacy kind of way. Now, of course, we spend a lot of time ensuring that business solutions work just as great as the individual. Solving those challenges leads to the benefits. So, we want to make those things strength. Any challenge, we want to turn into a strength to try to be very optimistic about that, and whether it's the community or specific business customer, or our own ideas about where we really want to take their roadmap, we're always trying to turn everything into a strength.

The competition these days, I like to think is in most dimensions at a feature parity. So, we're really pushing for recently focused on quality and user satisfaction. As I mentioned, native app development so that we get a really great experience and really dive into what the platform is that the person is using, which applies to the individual. Sure. But when the business has user satisfaction, it's sticky. It's valuable to the business. It's easier to maintain and so on and so forth. It's not just user satisfaction, it's the performance and reliability of the system as well. Bitwarden has many millions of users now in our cloud platform, and you can self-host it yourself and scale that out to however you want it too, as well. 

So, performance and reliability, I have this effort internally that I just call reliability at scale is paramount. Making sure that the bigger and bigger usually a business customer with 100,000 users is going to be able to utilize the platform, the same way that a five-user family would, or an individual user, and balancing those things. Not focusing on one versus the other, but how in our case, a cloud focused platform is able to perform at scale, and that touches on other parts of the typical cloud-based problems. How do we observe this if privacy is at the forefront for us?

We want to be able to observe how our platform is doing. But without anything identifiable, this is just not what we do, and we want to ensure that this API call takes a certain amount of time and interoperability of our other services, and so on and so forth, is doing great, and works for multiple use cases, and hosting solutions, and all that. Some of our bigger customers host internally. So, we want to make sure that we provide some flexibility, whether it's a piece of database technology. We support a lot of different data platforms. Beyond our typical Microsoft SQL Server, in our case. We support different hosting solutions. We have a lot of opportunities where we just almost natively offer digital ocean images. Everything is Docker containerized.

So, you can do all these things in lots of different ways and we want to make sure it all works well. Automation, testing, performance testing, reliability, chaos testing, all these things are on my mind all the time to do all of that and make sure our big business customers or small business customers are all thinking about that. Sometimes it turns into just the complexities of what a business need. Sometimes its governance and compliance. Getting into how we can work well with ISO 27001, or FedRAMP, or other governmental entities.

Some of it touches on that, too. That's sometimes the boring part of software engineering, but there's a lot to that and I like to think of it practically as securing our platform and providing continuity and resiliency in ways that make everybody happy. The individual user is going to benefit from that resiliency just as much as the business customer in the cloud. Really, great customer support is one of our huge things that came perhaps out of our community mentality. But we have a huge what we just call CS team today that is highly engaged with the community and has a huge matrix or set of permutations about all the unique ways that our platform runs today. Great examples and our CS people code sometimes to provide Docker image customizations, or how to adjust certain cloud scaling environments.

So, we're an Azure shop. But there's no reason you can't go run us in Amazon, or Google, or Oracle, or whatever you choose at the time. We built up that experience, because we're so hands on. So, business solutions are all over the place. But I think it comes down to our core about making a great resilient platform for everybody.

[00:43:27] GV: That's a really interesting kind of peek behind the curtain a little bit. I hadn't maybe appreciated just the level that you have to go to, to support the business case, especially on the CS side. I didn't know why didn't think that would have to be a large part of it. But of course, it does. Actually, going just back to your original question right at the start of the episode of why did I switch from another provider way back when, is performance and reliability. That was the two things that stood out to me and the product and have never really changed for me. It is a fast product, especially the Chrome extension. Chrome extensions are not trivial to make good ones. I've used a lot of very bad extensions, and particularly one of a competitor that was so bad. That was enough to - I said, I have to find something else. Then actually, it was a news outlet in Hong Kong, where privacy is a huge bit to their business because of various laws there now. They said, "We use Bitwarden and we trust it and we think the performance and reliability is fantastic." That's part of the reason I moved over.

So, that is interesting to hear, that being such a kind of key tenet of Bitwarden, especially when looking at the business case. One other part of the product, which I've only recently become aware of, the Secrets Manager. That's more of a sort of business case, in a sense, but business on the developer side, I guess. But yes, what was the thinking there and that sort of does start to feel that Bitwarden is now becoming a bit of a sweet to both products. What was the thinking to go there as well?

[00:45:03] MB: Secrets Manager was very much to me the product number two for us. Password Manager was the thing for so many years. At its common core, though, it is a secure end to end vault storage mechanism. There's a lot of ways to take that capability. While Password Manager is super user focused as of its beginning, we swing all the way to the other side of things like Passwordless.dev that are really all about a developer focused technology, and then there's a little bit of an in between, to me, of what Secrets Manager is, where you take a lot of the collateral, you might say. The admin console, as we call it. The experience of managing an organization or users, which in many ways applies to the password management space, but can also bolt on something that is developer, or CI/CD, or infrastructure, however you think about it. But being about running a business on the technical side.

So, developers use it, but it's about the same kind of cipher as we call it, storage, except it's for a different audience. The user isn't pulling this up. They need to administer it. We have a rather robust and complex set of access policies and other controls that we allow organizations to manage with. Then, we put that lens on of, "Okay, well, what does it take if I'm a DevOps engineer, and want to ask for a secret that I need to deploy to a cloud environment or something like that?"

There's service accounts. We're really calling the machine accounts these days. That is the connection of, I configure my machine account to be this thing that is doing these jobs for me, and I surround it with access policies and projects, and I manage the experience in a robust way, and give the engineer the ability to ask for that thing using - we have a CLI. We've had a CLI for many years. But we're just like Passwordless.dev and other products, we have an SDK as well, CLI, SDK, however, you want to slice it, offering that for as many platforms as possible. Go, Python, Dotnet, et cetera, to allow these capabilities to be plugged into your world of choice. We are launching a Kubernetes operator for Secrets Manager any day now. We have plugins into TerraForm and Ansible. And the CI/CD and infrastructure managed world, we felt like that was a great spot to land the technology into so that we could provide a similar experience and that same aggressive user base that really love the product, giving the engineering minded workloads and ability to be successful with it as well.

[00:47:54] GV: Yes. Very interesting. So, as we wrap up, we've heard a little bit about, obviously, on the horizon, and this is obviously we're recording in - this is April, and I imagine that it will probably come out sometime in May. So, for those listening, we've heard a little bit about the native apps getting a whole rewrite, and they're going to be sort of coming out soon. Anything else you can share about anything else on the horizon with Bitwarden from a product size or anything else?

[00:48:21] MB: You mentioned the browser extension and how you enjoyed how it worked and its performance. There's been a big push for a largely Google driven effort called Manifests v3. So, we have rewritten the browser extension, essentially, for a number of extension platforms to work very differently. Big undertaking. Perhaps not the most user facing piece of functionality. We actually rewrote our autofill mechanism just a few months ago and that's working incredibly. But Manifest v3 was a big item for us to refactor how we communicate to our platform in a lot of ways.

So, we're adopting a number of technological changes to really facilitate that. Better adoption of other protocols to synchronize the vault, such as web push, and just lifting a lot of boats with the move to Manifest v3. The native apps was certainly a thing that I'm excited about. It's a lot of integrations. I think we're just continuing to push out the breadth. But at the same time, I'm really thinking a lot about the depth. While it may not always be user visible, lots of work around security posture improvements and making sure that people continue to trust us with what is so important to them. Certainly, no way for us to get to those things. But how do we just continue to make all the layers better and better and better? Better edge networks and CDNs and security protocols in place. I don't know that's the nerd in me that's answering this question, but it's that reliability at scale again. All the different things that we can do. Stay tuned. But I think the engineer will thoroughly enjoy the changes to the code base if they're watching.

[00:50:05] GV: Great insight. I think, it's wise also, we don't always have someone in your role, a principal architect getting to speak to us and I think it's always interesting to hear how you're thinking about the product in development versus even a CTO or CEO. I think that has some great insight there. So yes, for anyone who hasn't, say, done anything with Bitwarden, where's the best place for them to go just to take a look around? Where can they go?

[00:50:32] MB: Bitwarden.com is the easiest way to get there. It'll shoot out links to all the various spots. Github.com/bitwarden is where everything and everything happens from an engineering perspective. But a simple Google search will point you to our community forums or Reddit, other social properties. You can read all about us before you even use us, but I'm certain you'll enjoy it.

[00:50:54] GV: Fantastic. Matt, it's been great to have you on. I've learned a lot. Always great to hear what's on the horizon with the product as well. So, thanks so much for making the time.

[00:51:04] MB: Thank you. Pleasure to be here.

[END]