[mdaniel]

Congratulations on the launch

> Passwordless access to apps and infrastructure

...

> Next, we added a password vault.

Isn't this just moving the passwords out of something known-and-trusted like 1P and into your cloud, versus "passwordless"?

Also, I see a lot of these entrants into this space talk about SSH, but we don't use SSH for _anything_ here, and and are a 100% kubernetes shop. What's the plan for granting users access to kubernetes?

[npoturnak]

Thank you for taking a look, appreciate feedback.

In an ideal world we would like to be passwordless 100%. And we can already do that with SAML/OIDC apps, SSH, etc. For these flows passwords do not exist.

However, the companies we work with always have some legacy app that just does not support modern identity protocols. For that we have to fill passwords and provide vaulting capabilities to offer end to end experience. The reason we decided to add vault is to make things simple and integrated, so that company does not need to manage separate product. Agreed, 1P and some others are known-and-trusted, but we hope to earn this trust over time. And using our Vault is optional.

Right now we are planning to release RDP support for Windows servers, and then we were planning to focus on adding support for databases. That is why your feedback is critical as we can reassess the priorities regarding Kubernetes.

[mdaniel]

> or that we have to fill passwords ... And using our Vault is optional.

So, "optional" unless there's a legacy password flow? I'm not trying to be a troll, just understand the line between the value you offer over 1P versus the passwordless claim

> Right now we are planning to release RDP support for Windows servers, and then we were planning to focus on adding support for databases. That is why your feedback is critical as we can reassess the priorities regarding Kubernetes.

Sounds good, but what is the plan for databases and then kubernetes? I know how Hashicorp Vault solves the database problem, and suspect you're going to take the same approach, but any "this is how we think about the world" would be helpful. Same for kubernetes, which thankfully already has strong support for externalized authn

[jsethi512]

the plan is to support remote access (eliminating VPN) to cloud-hosted database (in AWS, GCP) and also self-hosted database in the on-premise infrastructure. we be be leveraging access management service (eg AWS IAM) for passwordless access to cloud-hosted and will be leveraging cert-based authentication for self-hosted database.

For kubernetes cluster, we will be delivering a kubernetes service that will facilitate to access the cluster remotely from the kubectl.

[mdaniel]

> Agreed, 1P and some others are known-and-trusted, but we hope to earn this trust over time

I thought of another question about this: did you roll your own crypto, or just re-use a proven player like Hashicorp Vault, Bitwarden, Vaultwarden, or similar?

[jsethi512]

we built on the principles of zero-knowledge cloud which means decentralizing identity + crypto on the client side. Keeping passwordless in context, we wanted to eliminate passwords completely which means not even a master password. we rolled out our own crypto for mobile, browser and desktop app.

[philsnow]

To "roll your own crypto" is to develop your own cryptographic primitives/constructions, versus using known-good, well-vetted, best-practice standard tools like NaCl / libsodium.

> we rolled out our own crypto

"roll out" means to deploy, so to "roll out your own crypto" could mean either one. Did you mean that you developed your own crypto? If so, that could be a not insurmountable, but large, impediment to gaining trust.

[jsethi512]

I apologize for not being clear. we have developed crypto using well-vetted and best practice crypto apis from android, iOS and web crypto apis available in the browser. some of the algos used for crypto operations involve ECC_NIST_P256, AES-GCM with HMAC-based KDF, RSA-OAEP, Shamir's secret sharing...