Techlore Talks brings you in-depth conversations with the experts at the forefront of privacy, security, and digital rights. Hosted by Henry Fisher, founder of Techlore and long-time digital rights educator, each episode features meaningful discussions with the people building, researching, and advocating for digital freedom.
From cybersecurity researchers and privacy tool developers to open-source advocates and digital rights activists—if they're shaping how we protect ourselves online, they're on this show.
Topics include: privacy tools and technologies, cybersecurity threats and defenses, open-source software, surveillance and digital rights, encryption, tech policy, and digital sovereignty.
New episodes released regularly. Subscribe and join the community at techlore.tech.
If you're a bank, you want to know what's happening.
When you're on the end user side,
you want to have a guarantee that your password manager
doesn't know what you're doing.
So you can see already that.
Hello, everybody, and welcome to Techlore Talks.
Today, I have the privilege of having Remy on from Passbolt.
That is an open source password manager
that has a quite similar philosophy to KeePass in many ways.
And we talk a lot about unsophisticated phishing attacks
that target individuals through deceptive emails.
We also touch on the implications of credential theft.
We talk pretty much everything about password managers,
What makes them more secure for most people than regular things?
And also very commonly asked questions like, should you use TOTP or 2FA along with your
password manager and many other things?
So now let's dive into the interview.
Thanks for coming on Techlore Talks, Remy.
Do you want to start by just introducing yourself and what you work on?
Sure.
Thanks for having me today.
I'm Remy Berto.
I'm co-founder of Passbolt.
So I'm a software engineer by trade and training.
And I've been working on basically Passbolt, which is an open source password manager designed for collaboration for about 10 years.
So this is actually all 10 years in 2016 since launch.
Very nice. And when I first learned about Passbolt, first off, it's really cool you guys are open source.
What's kind of the target demo historically? And is that still the target demo you're chasing today with Passbolt?
Like what are kind of the unique things about Passport for someone who hasn't heard of it before?
So when we started a long time back, there were no like web-based password manager.
And like actually there was this infamous article like JavaScript cryptography considered harmful and, you know, all these things.
It was very nascent, like the idea of having a password manager in the browser.
And what was available at that time was really solutions like KeePass that was already around.
So it was like client is basically one file that you have and you decrypt locally.
And it's very safe that way.
What was missing for us, because we were basically making software, we were a software house.
And we were having these needs of sharing credentials and being able to track and audit credentials.
So that, for example, when somebody is leaving the company, we can see who had access to what and rotate the credentials.
So it started from that need that we had.
And my co-founder, Kevin, created a very early version that we use internally.
And then from them, we started onboarding some clients.
And then eventually, we were convinced that this solution was interesting.
So we didn't want to build another personal password manager.
We skipped that step.
we went directly into like, okay, let's build a password manager for businesses
that would meet our requirements.
So there are some security requirements that were important for us.
And there were also some functionalities that were important for us
that basically became the DNA of Fastbolt.
So things like sharing items on the 101 basis.
So as opposed to KeePass, for example, you have all your credentials in one file
or like some other personal password manager
where you have like collections of credentials.
So every time you share,
you basically share a collection.
So you share all the credentials
that are in that collection.
There is no granular, fine-grained,
okay, this person can read this password
but cannot change it.
Or the same goes for audit log.
Every time you basically access credentials,
you download the entire collection
and then there's no fine-grained tracking
of who has access to what.
So you can report back,
the client can say,
hey, you know, I have access to that credential and that's fine for most usage.
But you don't really know if that credential was actually leaked from the client.
And the way we did it for PassVault is that we only download the secret when you use it.
So this way, even if a secret, let's say, is shared with you, if you don't use it,
meaning like you never fill it in the form, we have the proof that you never actually downloaded it.
So yeah, that's so easy.
There are some collaboration.
There are some security requirements that were important for us.
Another one is a lot of credentials managers,
they use a user-generated passphrase or password
as the main encryption key.
And we know that letting people select the basis
for their cryptographic keys is generally not a good idea.
What you want is something that is truly random
and something that people cannot remember.
And so that's why we introduced that concept of having like a private key
that is used to basically decrypt secret.
So other password managers would generate that key by doing iteration,
like a private key derivation function.
And they will apply some rounds so that it's hard to brute force.
But it's still something that is user generated.
So it can still be phished.
It can still be brute force, for example, on the login form.
And that's what we wanted to avoid.
So obviously, it creates some friction with usability.
So it's not ideal that people have to have this private key.
And if they lose this private key, then if they remember the passphrase to unlock the private key,
basically they cannot access the solution unless they have shared that private key with a trusted
party. There are different types of security requirements. So yeah, that's really like the
DNA of the solution. I don't know if I'm talking like, like if it's clear or not.
Yeah. So, I mean, there's definitely a lot there and I've been taking notes so we can
kind of deep dive into some of these things. So I want to start by just maybe covering the basics
of a password manager. And it's so to this day, would you say you're still more enterprise focused
than end users?
Yes, definitely.
Because of these security requirements,
it's like when you're on the end user side,
like for personal usage,
you want less friction
and it's okay to have trade-off
when it comes to security.
You would want to have like maybe more privacy
than say if you're in an enterprise space.
Because if you're a bank,
you want to know what's happening
with the credential.
When you're like a credential manager
and you're serving like individuals,
you want to have a guarantee as an individual
that your password manager
doesn't know what you're doing.
So you can see already that
even though it's password manager,
there are very conflicting requirements,
whether you're coming from business
or whether you're coming from the personal space.
And so we choose to go that side
instead of trying to do everything,
you know, because it's really hard to do everything.
And so what are the kind of the,
you know, what's a typical customer
before we deep dive into some more of this stuff?
Is it small businesses, big businesses, governments?
Who do you see getting the most value out of something like this?
It applies to a lot of businesses, but the sweet spot for us is people that are, I would say, interested in the security posture that we are proposing, as well as things like the ability to self-host or that have a need to organize credential at a very granular level with fine-grained permissions.
And so this tends to be organizations that are small or large, but that are privacy conscious or like that have certain appetite for fixing some of this risk or fixing some of the issues that I talked about.
Yeah. And so, you know, let's say I'm a business owner, right?
Like I have various options to choose from.
There's just not using a password manager and kind of just hoping for the best in the world.
I think most of our audience might know the issues with that, but maybe we can still touch on that a little bit.
Then there's maybe going with a more mainstream enterprise solution.
I'm thinking, I believe like Nord, who has NordVPN, is run by NordSec, who has been moving into more enterprise direction, and they have more of those tools now.
Then we have like probably 1Password, Bitwarden, et cetera.
And then we have kind of you guys who also allow the ability to self-host and all these things.
So what are kind of the general pros and cons of these different approaches?
If you were to kind of break down why someone might go for a specific one and how you guys position yourself in kind of that space.
Yes.
So it's and also we are not the end all of, you know, so if your organization is super mature and very advanced, we might not be a right fit for you.
So I was not trying to present us as, OK, we are the most, you know, secure, most mature.
It's just like to explain like a little bit where we position ourselves.
Like you have personal credential manager, like typically the one built in in your OS or your browser.
And if you're a small business owner, this is perfectly acceptable way of handling your credential.
It's better than nothing.
And it's actually way better than nothing.
It's a proper solution.
And then you have like, if you want to start having like a little bit of collaboration, but your team is small and you don't have like very complex requirements.
And you also want to be more on the, I want a low friction, low barrier of entry, and I'm okay to accept this risk that come with that low friction.
Then you can go for solutions that have came from that personal space and that have developed business solutions.
And then if you evolve and you want to use it as a beginning of doing access privilege management,
and you want to have like more fine-grained tuning
of who can access what,
make sure that there's a least privilege enforced
at your organization,
then you can start like going for a solution like PassBolt.
And then after that, you will, you know,
go into more complex spam solutions and all that,
that if you like really large enterprise
with a lot of use cases.
- And why, you know, 'cause I feel like
if someone's starting a business, you know,
you get like a how to start a business book, you go to business school. Business school is
interesting because I feel like part of the point of business is to be, is to, you know, insert
something new into the market. And it's kind of hard to get that from something like school. It's
a whole side tangent. And it's weird. But my point is, there's no like right way to do business. And
if you try to go through traditional resources, password management and security isn't really a
part of that discussion for a company. So what are kind of the attacks that you guys see and how
might, yes, a password manager help in these attacks, but why should someone even care in the
first place if they're just trying to get their business done? They want to get a product out
there. Why should they put any attention to the security stuff? Most of the attacks and like the
scenarios that are covered by a password manager are like unsophisticated attacks. So typically it
would be like things like phishing.
Like, so basically you receive a link
that looks like a legitimate email.
You go to an app that looks like the login app
and you just log in in that because you're tired
and you're like you have 10,000 things to do.
You don't really check the emails, the URL,
the URL lookalike, but you don't pay attention
and boom, basically like you got phished
and that person have access to the credential for that site.
So let's say you don't have to have a in place
that service then it starts becoming complicated and you'll have to to deal with that breach that's
one issue another issue is that if people don't use anything they will tend to reuse predictable
passwords or like reuse the same everywhere so typically uh you know the name of the service at
the the year but they sign up for the service or like come up with this like what they think are
like very clever combinations but that you know i've been analyzed for years by by attackers
using like breached uh breached data what you want is to protect yourself from these basic
sort of attack you know like it's it's it's it's just normal hygiene the same way like you
clean your hand you know so that you don't get disease this is kind of like
automated thing that you should be doing at that stage because if you don't do it it's it's gonna
to you for sure. And so password managers, they really help you with this. So for example, you go
on a site, it will suggest, hey, do you want to feel that credential for that site? With Passable,
for example, if that URL do not match the entry that you have in the Passable database,
it will not suggest it. So you will already feel that there's something fishy because like you'll
be like, how come Passable is not suggesting the credential for that site? And they will give you
like some hints and then it will generate passwords for you. So it will generate like
truly random and strong passwords that you don't even have to type anymore. If you are a business
owner, like you should definitely do this. And like, for example, even you're in your family,
if you have maybe like people that are a little bit older, they are not doing that yet. It's very
easy now to like hold them out, even just like if they are using an iPhone, then, you know,
just set them up with the basic password manager on an iPhone. It's really important that people
get up to speed with this because it just makes their life easier as well, you know?
Yeah. I want to ask about your guys' business model because you're open source. And always
important to ask how open source projects make money. My understanding is that you offer to,
like if I'm an organization and I want to get going on a password manager that's got good
security, has good permissioning, gives me the stuff. I can roll that over in-house and I can
self-host it. And then you guys theoretically get nothing from that, from what I understand,
but maybe I'm wrong because that's just my idea. And then you probably offer a managed solution.
So do you want to kind of break this down for me?
Yeah.
So we have three versions of Passbolt.
We have the community edition, which is free as in freedom and free beer.
So basically you can get started.
We have packages for all major Linux distribution and you self-host.
And then you have Passbolt Pro edition, which is the same similar code base than Passbolt
Community Edition with some additional plugins.
And that requires a subscription.
like so you will be prompted to enter a subscription key when you use it so the software is free as in
freedom but not as in free beer so it's it's uh it's an important distinction so there is a price
attached to it and then we finally we have the the latest uh which option which is uh cloud so it's
we host it for you so it's basically passable pro but hosted by us and we have some other options
so for example if you are a bank and you work in like regulated environment we also work with
with other partners to provide you with a fully managed solution that match your legal requirements.
So for example, if you want like bank approved hosting environment of Passport Managed with like 24-7 support,
then we do that through partners.
So what's someone missing if they just download the free community edition and they just start using that?
So they will have access to most of the functionality, so sharing groups.
So what would be missing is the productivity features such as policies, like I want to enforce certain policy on the application, like my password needs to be like this, or users are required to sign up for MFA, or I want to have them place their private key in escrow with me so that I can decrypt their content in case they leave the organization or they lose access to their stuff.
So, for example, these kind of requirements, they come from more larger organizations that have requirements that come from their local law or the way they operate.
And so, they will have access to things like LDAP sync or these kind of features that if you're like 20 users, it's okay to invite everybody manually.
But if you have like 500 users, you're not going to want to do that manually.
So these are the functionalities like productivity for the administrator that are part of the paid version.
So this is pretty much how we make the distinction between what goes into the community edition and the pro edition.
Got it. And so this is obviously for larger companies.
And, you know, for us internally, we're just going to use something simple, like you were saying earlier, because we're very small.
But what kind of organizations are going to be self-hosting this on their own versus just paying you guys to host it for them?
Do you find that like really big companies want to self-host it or do the really big companies want to outsource it?
Or is it the inverse or is it kind of just depending on the company?
This is where it gets interesting is like 75% of our customers are using the self-hosted version,
which is not what you would see in other businesses.
And I know that there have been a big move for people to go to the cloud,
but we, like, basically someone else's computer,
and we are seeing now this reverse trend.
Do you think it's because of global politics and digital sovereignty?
Partly because of that, but even before world leaders
starting being a little bit more erratic,
there was already some concern around trusting cloud providers with the crown jewels.
So let's say you're a government.
Do you trust an American company?
Or do you trust even a Luxembourg company to host your most important secret?
And so for a solution like Passport,
it makes sense that this is one of the few things you want to self-host.
like your encryption key, your passwords, like they become like really like something people value.
And now this trend we've seen have accelerated. So we see like even like medium sized company are also interested in this.
And we have a lot of small businesses that start with self-hosted and then they realize that it's too much work for them.
And then they want to move to Passbook Cloud, for example. So this we've seen like all sorts of trends there.
And governments, for sure, they want to self-host, but also like large organization industries that work in, you know, sensitive things like energy sector also is like, you know, they use solutions that are not connected to the Internet because it's critical infrastructure.
They have their own network.
Their network is not connected to the Internet.
So then it makes sense that, you know, a solution like PassBolt is something that you want to use.
We also have like small businesses.
I don't know, like it becomes like a cultural thing.
Like in, for example, in Germany, people are more privacy conscious than, say, other places.
And so they would prefer if they have the choice, if they have the option and the option is good, they will choose that option.
Got it. And a pattern I've noticed, and maybe this is changing and maybe it's a generalization that's not accurate,
but I hear a lot about how the execs in the boardrooms,
They're more likely almost a lot of times to go for a technology that is being sold to them as some proprietary, flashy, black box technology.
Only we have the ability to do this and we keep it, you know, we offer you this exclusive service, proprietary.
I feel like proprietary technology for end users is seen as almost a negative thing.
But for some businesses, it's seen as a positive thing or at least more neutral.
So how do you kind of approach that as an open source organization?
Do you think that's a positive?
Do you think some businesses see it as a negative almost?
Are they like, well, does that mean it's less secure?
Does that mean that this isn't as good as it could be?
Is this kind of a friction point?
Because I could see it potentially being a friction point,
or maybe I'm just making things up.
I think there's a cultural component to it.
So some organizations may not have this culture and it's complicated,
and we have a fit with organizations
that believe that openness is required for security.
So if they believe the opposite,
I don't see them because they don't come to us.
So I see people that are enthusiastic
about the thing being open.
And I think on the long term,
people see the advantages of it.
For example, when we do audits
and we do audits several times per year,
then people can see the fixes.
They can see if we do the fixes or not
or how much time it takes to do the fixes.
And we published our audits and our reports unchanged,
so people can actually see what we are prioritizing.
And this transparency goes beyond the code itself.
Because if I give you the code and the code is just mangled
in a way that it's not human digestible,
or if nobody's looking at it, then what's the point of it being open?
you know so there is also the the component of making it this accessible to people so that they
can make the right choices and understand okay this security risk is covered this security is
risk is not covered and they don't have so much this option with with closed source software
because they don't know like okay what were the arbitration done you know like uh did they choose
to place the cursor more on usability or more on security?
Or did they manage to find a new technique that solve it for both?
And you don't see that.
So you just have to take their word for it.
Now I can see more and more people doing their homework and they want to see,
like, okay, explain to me how it works and tell me about the risk.
And tell me about the risk that you are not covering.
All right.
So I'm going to pivot now a bit more into kind of features and overall the usability
and what that looks like.
And then we can do a quick security deep dive.
and I have a few personal questions for you.
I wanted to start by asking,
because you guys seem to be like a very dedicated solution.
You are offering password management
to predominantly organizations,
but also to the community as well.
There's this trend that I see a lot,
especially with more proprietary-oriented companies.
I don't mind using it,
because there's not necessarily a negative aspect
to this necessarily.
I think NordSec is a good example of this,
where they're trying to build a whole suite.
Like there's the password manager, there's the VPN,
there's, I think they have data removal at this point.
This is for their end user,
but then their enterprise product,
I think also has a lot in it.
Do you see this as a disadvantage for you guys?
Like, are you looking to expand, you know,
Passbuilt to be a bit more than just a password manager?
Or do you think that just a narrow focus
to just do that one thing
is kind of the right approach for you guys?
I think it depends on how much resources you have.
So like, I'll be, I'll be frank, like we are like 50 people.
So, and we have not raised like in hundreds of millions in capital.
So obviously we cannot compete everywhere.
So we have to choose like where we want to be good at.
And it's a very competitive landscape.
So like you, if you want to stay competitive, you cannot just do 20 things poorly.
You need to be good at something.
So that's the way we are approaching it.
So we are still working on like improving the product to the point where like we,
are satisfied with like where we are and but we still plan to support like more use cases that are
like related to credential management and there's there's quite a bit so like our goal is to keep
doing what the users are requesting and um i don't think they will stop asking for things
at any point but we try to have this feedback loop of like building what people are asking for
and since we are not you know building extremely fast then we we we get to to see on the long term
what are the trends and like what's you know what's important for people what is recurring
what is coming from the customer what is coming from the the community what is coming internally
on what people want to work on and like yeah and so what are some of like the requested features
that you guys get that are the most frequent?
A lot of the things that we just delivered.
So recently, we did a major revamp of the architecture with Passable v5,
and now we are able to add some new resource types.
So our goal is for people to be able to create multiple resource types
and be able to compose different types of credentials.
So, for example, a password with a TOTP or a secure note with a list of custom fields.
And so we try to continue going in that direction, like having secure notes, having all sorts of properties that people can add to credential and compose them.
And so we will continue going in that direction for some time.
People are asking a lot, for example, about file attachment.
But, you know, you don't want to become like a drive.
So it's kind of like a fine line.
They are like...
That's a whole other ballgame.
Yes, it's a very different storage of credentials
and storage of files,
like totally different beast.
So we have to be careful
on how we approach these things
so that they have the right expectations
and so on.
Like, okay, you want to attach a certificate?
Yeah, that's fine.
You want to attach a movie?
Maybe not.
So do you guys support integrations?
I know this is more of...
it's funny this is definitely more of an end user regular consumer feature but i actually think it's
very useful for business and maybe i think it's going to catch up to the business world eventually
but aliasing services for emails um so that way yeah is that something you guys support or so
typically this is this is something like which i believe falls in the realm of personal password
management it's what i was saying at the beginning like you want full privacy and you you don't want
the service to know about what is your username.
In the enterprise world, you want to know which username people are using.
I don't want to see the logs in my security operation center of random emails and not being
able to link them to actual users.
So it doesn't like these two things are like maybe there are some scenario in enterprise
where you would want that, but like most of the time, not so much.
Like people are more interested in like having integration with CM, for example.
Can you send me alerts in real time so that I can analyze behaviors and link them to other behaviors that are happening on other services?
They are more interested in these kind of scenarios than, okay, can you make my users anonymous?
It's more like the other way around.
They want to praise them to understand behavior and see if there are patterns that don't make sense.
Got it. And how have you seen adoption for things like passkeys in the enterprise world?
Are they embraced? Are they seen as not good?
So the passkey is pretty vast subject.
And it's one credential that I believe like have a lot of like this is basically the future and like this will happen.
The speed at which it will happen is like it will be like IPv6 or I don't know.
They might take a while.
But I can see people are intrigued.
And this is one of the top things that people have requested for Passport.
And this is one of the things we are committed on working on.
We are actually part of the feed-o-a-land.
So we are seeing how is the RFC evolving and how does it integrate in the browser, for example.
How can we exchange passkeys between credential managers.
And our strategy had been to wait a little bit until the dust settled when it comes to specification, because there is the specification and there is the implementation by Google, Microsoft and all that.
And that becomes the standard.
So it's like you want to see like, OK, of the whole standard, like which part is actually the standard.
So we are kind of like waiting a little bit to see like, OK, what's where are we like on that front?
And now we are like, for example, the mobile experience, I think is pretty much there.
The browser experience is still a bit like, depends on the browser and depend on the OS.
And so for me, it's not ideal that you have like an experience that shifts so much that if you use Edge or Chrome, then you're going to have a different experience.
I don't think that's good for the end user, especially with new technology.
But I think it's going to go there at some point that, you know, there would be like a more unified perception.
Is that because of Manifest V3 by any chance?
Manifest V3, no, it's a separate topic.
Manifest V3 is more like the underlying format for Chrome extensions.
Got it.
So that doesn't influence your ability to develop.
Okay, cool.
So the way the browser works at the moment when you do like passkeys,
it uses some API like the credential API.
And that then talks to your browser.
And so if your browser extension, you can basically replace that JavaScript API with your own stuff that will talk to the extension.
But if there are several providers and they are all doing that, then it becomes not clear who's adjacking the most the credential API.
And you would want to have some form of agreement that if several people want to do that, then this is how you do it so that for the user it's clear.
Let's say I'm using Dashlane and Passbolt.
So Dashlane for personal use and Passbolt in my company.
And I have passkeys for Gmail, like my personal one in Dashlane,
my professional one in Passbolt.
You want us to play nice with each other.
Basically, we're like, okay, do you want to use which one?
And not like, okay, I nuke Dashlane out of existence and you only use mine.
And the OS level, sometimes they are a bit brutal like that.
They're like, okay, we're Google.
It's a Chrome browser, so you want to use our stuff.
I think there needs to inevitably be some way to select and disable passkey options on devices.
Because right now it happens with me.
I figured out some workarounds, but if I'm going into a website, I use ProtonPass as the extension, right?
And then it's like, oh, login.
I accidentally, I don't use passkeys too often, actually.
I normally use passwords and I use my YubiKey.
but I don't use proper passkeys
and it'll be like, oh, log in
but I'll accidentally click the passkey button
this time around and then ProtonPass
comes out and it's like, oh, no passkey
found and I say, oh, ignore.
And then the Brave browser automatically comes up
next and it says, oh,
no passkey found and I click, ah, shoot
and I click cancel and then like the OS
comes up and it goes, oh, no passkey
found and I click cancel. So there's like three
people who get pinged
to see if they have a passkey
and I think that that's kind of like demonstrating exactly so it's it's frustrating um and I think
that'll be figured out over time so it's good you guys thinking about that like in field alliance
this is I think it's a big topic and like um like the thing is like people would have different views
on that so you need to find consensus and all that but I think it would get it would definitely
get better it's already getting better since like last three years you know like at the beginning
there was like the the ux was uh changing also a lot because they were learning and so it's it's
also complicated for users like if every time you log in with a passkey the the experience changes
because you're fixing it at the same time it's also like uh you know confusing so and so with the
passkeys do you think that's a good microcosm for just your overall approach because most you know
ProtonPass, Bitwarden, all these mainstream password managers aimed at consumers.
Passkeys is like a priority one thing.
Like this is a new technology.
People expect it from us and they rush it out.
And it's well received by the community.
You guys are like, okay, this is way too early.
Like we need to wait.
We need to see, we need to make sure we do it right.
So do you think that there is a speed difference in terms of features because of the different clientele that you're serving?
Yes.
and also like resources you know it's like to be completely transparent like it's what i was saying
you know like you have like like companies in the us that raise like in several hundreds of millions
obviously they kind of get it out of the door uh faster than us and that's all right that's you
know that's part of the of like being the first mover or not and uh well we are like you know
we're still participating we're still looking at what's happening and and our goal is is just like
our advantage is basically being the last to do it. We can like take the good part, see how people
have done it and see like which, which part works well, you know? So we have this, this, uh, this
advantage of not having to maintain, uh, things that, you know, like have not worked. So it's,
there's like a disadvantage, but also there are some, some advantages to that.
Got it. And then do you guys support TOTP natively in your password?
Yes.
And what are kind of, you know, if an organization, you know, starts using you guys, they might inevitably ask, oh, should we be using TOTP within your app?
Is that safe enough or should we be using a dedicated solution?
Do you guys offer a dedicated solution or do you have something else you can recommend them if they want even more security with that separation?
So the good answer is it depends.
I would say, like, I've answered that question, like, pretty extensively, like, on the community forum, because it comes back every now and again.
It really depends on what is your posture, like, your risk scenarios and, like, what is important for you or not.
As opposed to not doing any MFA, storing them in Passport, is it better?
Yes.
Like, so it really depends where you're coming from and where you're going and, like, what's your threat model.
So I would say it's probably not ideal if you're in a high-risk scenario.
What I would recommend typically is that you have your second factor authenticator in a separate device.
So it's the same if your password manager is on the same device, but on another app.
Is this still better?
I don't know.
If you can compromise the OS, for example, you can compromise both.
Is that like a scenario that you care about?
Or are you like, okay, no, I only care if one of the app gets compromised and then that's basically my scenario.
But if you care, for example, OS level stuff, then you would need a completely separate device.
So I'm trying to give you a clear answer.
You see, it really depends what you want to do.
Yeah, I was just curious if maybe the way of looking at it from an organization's perspective is different.
If you have, for example, a shared second factor authentication, then it makes sense.
Because then you, like, it's the same if I give you a QR code, you know, we both scan the same QR code and we both have it on the TOTP app.
Let's say you leave the organization.
I need to remember to change that code because I shared it with you.
But if you use Passbolt, then Passbolt will tell you, okay, that person left and you need to replace that code.
It will directly be built in the interface.
And how do you ensure, because what's stopping someone from still recovering the seed encryption key for the,
I don't know if it's technically encryption, but what's stopping them from recovering the seed and just importing it to their own 2FA app?
They can do that.
So that's why you need to rotate it.
So you still need to rotate it even if you kept TOTP in Passable.
Yes, yes.
Does Passable automatically notify you as someone who's managing that?
"Oh, they left, hey, you need to reset the TOT for this?"
Yes, exactly.
That's pretty cool.
So do you kind of like handhold a little bit for organizations that they can pick up on
those habits if they don't know to do them?
Yeah, the way it would be, it would be signaling in the interface would be like a little warning
and it would be like, ideally you would not have like 50 warnings.
So if there is a new warning, they will see it, they will click, they will be like, "Okay,
you need to change."
So it's pretty straightforward.
forward. And do you guys integrate with things like have I been pwned? Like do you scan? Yes,
we do that as well. Yeah. Cool. So when you create a credential, it's like, basically the goal for us
is like you don't enter credentials. It's like you only have a random generated key and you have like
a passphrase to encrypt this locally on your machine and that's it. And then the rest is just
like credentials that are completely random. But if by some changes you need to have like something
that is manually generated,
then we would also check
whether it was part of breach or not.
All right, perfect segue
because my next more technical question
was going to be this two different keys
essentially to get in.
So this might be different.
So I'm saying this to kind of open it up
for you to correct my understanding of this.
Totally fine.
With like ProtonMail,
by default, when you use ProtonMail,
it's just a username and password,
kind of like any other account out there.
And they essentially,
because it's end-to-end encrypted and they're not supposed to get access to the data,
they derive an encryption key based on the password you choose.
So it's really important to use a strong password
because that's the password to get into your account
and it's the password that's encrypting your data.
It's two different things.
You're saying you guys are essentially offering Proton's like 2Password mode
because with Proton you can enable something called 2Password mode
where you have an account login,
but then you still need to type in a second password
to essentially decrypt your data.
is that essentially what you guys are doing as well or is it different i'm not 100 sure how proton
works but my understanding is that when you uh type your password it's actually the password that is
used to decrypt the private key so they basically they derive it two times they derive one for login
and one to decrypt the private key that they download once you manage to log in so there are
actually two separate uh credential one that is used for login and one that is used to download
private key and decrypt it.
And so from what you're saying, I'm thinking maybe they split and you would have one for
authentication and one to decrypt your private key so that it's not the same one that is
used for authentication.
So this way, it cannot be phished.
The way Passable Block is a little bit different.
So your key is not stored server side.
It stays only on your machine.
So we don't store a copy on the server and you log in and you get that key.
Basically, it's there on your device and you type your passphrase.
It basically decrypts the private key.
So it's like local database encryption, essentially.
And then we use that key to produce cryptographic signature.
And that cryptographic signature is used to authenticate.
So it's not like a password that we send to the server and the server check whether it matches.
It's very similar to passkeys.
It's not the same protocol.
So it's not Fido Alliance protocol.
It's something that is specific to Passport, but it's still based on like cryptographic challenges and signatures.
So it's more strong.
So each authentication attempt is unique and you cannot fish this.
Wow, that's really cool.
Do any other password managers do this that you know of?
I know that one password is using like a private key.
So they have like this, like the collector recovery code, but it's basically like they use this to create the final key that is used for authentication.
and for decryption.
And so it adds quite a bit of entropy
as opposed to just like, you know,
like for example,
Bitwarden is using like just a key derivation function
from the password that is user generated.
So LastPass was doing this as well.
And the issue with LastPass is that
because they were like very old account,
the key derivation function uses a cost parameter.
And that cost was for 10 years back.
So the cost didn't catch up with what modern computer could do.
So we didn't want to have these sets of problems,
to have to recreate that key and change the parameters
and re-encrypt everything because that key is changing
because we are increasing the strength.
We wanted to have something completely random, like 1Password.
The way we're doing it compared to 1Password
is a little bit different.
Because ours is based on OpenPGP, which is an open standard, and they have developed their own thing.
But in practice, I think we are the only two password managers that use a random private key.
Definitely the only one that's doing it transparently, because 1Password isn't open source.
You guys are open source.
And it sounds like you're also using OpenPGP.
But I think there are some other credential managers that use, for example, passkeys,
and they store like an encryption key as part of the passkey.
So for example, I know at least two password managers that do this.
So they use like something that is called a PRF extension.
They basically store cryptographic materials inside the passkey.
So when you successfully log in, it gives you like basically this private key that can be like truly random.
And then they build on that.
Yeah, it's a different techniques, but like same kind of goals.
Got it.
And kind of the final way I wanted to finish out this interview was just kind of talking about yourself.
I wanted to ask kind of what your favorite password manager is for yourself and kind of the people in your life.
If you're not going to recommend Passport to them.
So like how is Passport's community version for just regular people?
And then how does that compare to maybe other options that people have?
Yeah. So I would say like if I recommend the competition, it's going to be complicated.
So like, I would say PassBolt, like I really like it.
Like I use it on a daily basis and it's really nice.
And I've seen like people like staff or like install it for their family and it works really well.
Because it's like, you know, it's available on mobile phones and like it works pretty seamlessly.
My other option would be I really like the Apple solution.
like i think it's like pretty privacy uh respectful and i like the fact that you know it's like
hardware baked and you know like so that that that part i i actually enjoy to be fair with
other password managers like there's a lot of them like i'm in contact with a lot of their staff and
we talk often about like threats and like what can we do as an industry to improve and i would say
like everybody like is is um pretty dedicated and so there's no like uh you know bad uh bad actor
that is so like if you use one of the major password manager and you like it then you know
why not you know say got it and is there um like overall advice do you see like a common mistake
people make with their password manager uh or for most of these services you think just getting on
service and starting to use it is pretty much the main thing to be okay yes i would say like you
know pick one you like and stick with it it's like uh this is one of the thing in the industry is
like when people choose a password manager they generally like you know it becomes part of their
daily life because every day you log in into something so it's like then it becomes an habit
and you know and they are pretty emotional about it sometimes when it changes and so it's like
yeah yeah i i do like to use and this is generally advice i give only use a password manager that
makes it easy to leave because you never know what's going to happen and i i like password
managers that allow easy exports um and all that kind of stuff and i i actually wanted to ask you
know maybe there's something i'm missing but um without naming names there's a few password
managers that have TOTP built in, but they never let you view the seeds of it. And that's even in
their dedicated TOTP apps. And I view this as a consumer, as anti-consumer, because that means I
never actually own the seed to the TOTP code and I can't ever take it to another service and they
don't let you see it again and you have to reset it for every service. Devil's advocate, is there a
reason they might do that that actually is advantageous to the user.
It's more like obfuscation than like really hiding it.
So they are not providing you the features to see it.
But like in practice, you can't like if they have a web-based interface, you just open
the code and you will find the actual seed, you know, because they use it for generating
these numbers.
So it's definitely there.
Okay.
But why hide it?
Why hide it?
I don't know.
I don't know which one you're talking about.
Yeah, I know.
I'm not like, I'm just, I'm asking mainly to see if there is like something I'm missing here.
And maybe there's like a valid security reason.
Because I think you're the, I recorded an interview already with someone who's developing a password manager for that's very consumer oriented.
But like, these are kind of my first password manager interviews.
And so I'm trying to, I also have just like these lingering questions I've had over the years that I'm kind of asking.
Yeah, that's cool.
I can't think of any security reason why you would do this.
For example, people sometimes ask us,
can we insert in a page a password
and make sure that there is no way for the user to see it?
And I'm like, see it where?
There is an HTTP request.
The server on the other side is going to see that thing in clear text.
There is no way for me to hide it from everybody
but the destination server is not possible.
Like you can do this with a proxy
that replaces it with something else,
but then it's not like end to end.
It's like, it's different kind of service.
Interesting.
Yeah, okay.
So is there, are there any kind of final things
you wanted to mention to people listening,
whether they're an organization or a regular person
before we kind of log off?
No, no specific, specific things.
I'm just like, yeah,
if you're interested about how Password Manager works,
one of the things I invite you to do
is have a look at their white papers.
So for example, you have some of these questions
and some white papers are pretty well written
and they will give you how it works under the hood.
And it's often an interesting read.
So I would say if you're interested in Password Manager,
definitely go into that.
Great. And how can people find you and find Password?
You can just go online, like vvv.passball.com.
And we're also on social media as well.
We're on MasterDome and Blue Sky, I think.
Great.
I'll leave links down in the description.
And I want to thank you for your time, Remy.
Thank you very much.
And I know I learned quite a few things today.
I'm glad I could clarify some things.
It was great.
Cool.
Thank you.
Thank you very much.
And that is the interview.
I want to thank Remy for coming on Techlore Talks.
And I want to thank all of you for learning a little bit more about how to protect yourself
out in this crazy world that is always, always seems like it's trying to get you.
If you enjoy these podcasts and you want to see more of them and you want this podcast
to keep growing with time, consider leaving a rating if you're on a platform that allows
that.
You can also support Techlore directly for free by just using one of our affiliate links.
We have a support page down below that details how to do this.
Or we also have paid support methods if you just want to directly contribute to the mission.
I want to thank you all for listening, and I'll see you all next time on Techlore Talks.