[HN Gopher] Launch HN: Idemeum (YC S21) - Passwordless access to...
___________________________________________________________________
Launch HN: Idemeum (YC S21) - Passwordless access to apps and
infrastructure
Nik and Jagjit here, founders of Idemeum
(https://www.idemeum.com/). We are excited to share our product
with HN! Idemeum is a SaaS platform that offers a single place to
manage access to applications and infrastructure. We let businesses
eliminate passwords for everything employees access: devices,
applications, servers, and networks. Our cloud platform eliminates
VPNs and allows access to applications and infrastructure from
anywhere with a single click. In industry terms, we combine
Privileged Access Management (PAM), Identity and Access Management
(IAM), and passwordless technologies. In simpler terms: you
install our mobile application, navigate to your SaaS idemeum
tenant, scan a QR-code, and login with biometrics. Once you are in,
you can access anything with a single click - SAML Single Sign-On
apps, hosted on-premises apps, password apps, SSH servers, and
more. There's a quick overview here:
https://www.youtube.com/watch?v=-3StOlDjMrQ We spent more than a
decade in identity access management and threat detection at
VMware, Facebook, and Cisco, building platforms to manage user
access. That experience left us excited about two things: (1) kill
passwords; (2) make things simple. We started our company with the
mission to eliminate passwords in the workplace. That's important--
80% of breaches involve passwords--but our vision gradually evolved
into an all-in-one platform to manage employee access. First we
built Passwordless MFA, a mobile app that replaces passwords with
biometrics and certificates. You can login into any company
resource - SSO portal, Windows or Mac desktop, Wi-Fi, VPN - with a
simple Face ID scan. But behind the scenes we use a lot of
technology to make our MFA unphishable and secure (FIDO2, hardware-
backed crypto, device attestation, and more). Second, we added a
full-featured Single Sign-On Identity Provider. It is a web and
mobile portal to centralize access to all apps and infrastructure.
Unlike other Identity Providers that focus only on SAML SaaS
applications, we added all resources to the same portal, so you can
access apps, servers, databases and more from the same place. Today
we support hundreds of SAML integrations, offer account
provisioning, RBAC, auditing, group management and more. Next, we
added a password vault. Companies asked us to add a password
management capability to safely store credentials, share amongst
employees, and autofill on websites. But unlike other password
managers, we do not use a master password. Instead you login into
your vault (on desktop or mobile) with mobile biometrics such as
Face ID. The vault is end to end encrypted, and your passwords can
not be seen in our cloud. Last but not least, we realized that SSO
for cloud applications is solving only part of the problem, as
engineers need to access hosted apps and compute infrastructure. As
a result we added a cloud proxy to our platform to offer remote
access to on-premises applications and SSH servers. Not only do we
provide connectivity, but also handle authentication, authorization
and auditing for infrastructure access. For example, we replace SSH
passwords and keys with short-lived certificates. We will release
RDP access shortly, and will then start adding database access to
our platform. Security is critical for us - we have been
prioritizing security from day one. We are open with how our system
is architected, and published all designs on our docs portal
(https://docs.idemeum.com/mobile-app-security.html). We also
conducted our first penetration test with Cure53 to validate our
designs, crypto, and security principles. We are also SOC2
compliant. We offer a free plan and would love your feedback if
you give us a try: https://idemeum.com/try. We would be very
grateful to hear your feedback, ideas, and experiences from the
identity and access management domain. Thank you!
Author : npoturnak
Score : 82 points
Date : 2022-10-26 16:39 UTC (6 hours ago)
| mdaniel wrote:
| 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?
| water8 wrote:
| npoturnak wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| water8 wrote:
| Sounds like one big security nightmare by a startup who wont have
| the resources to manage it all. Trusting someone else to manage
| your secrets is big mistake e in almost every aspect in life.
| Crystal ball says: Hacked, Bankrupt
| npoturnak wrote:
| Appreciate your feedback. We have been prioritizing security
| from day one. We are SOC2 compliant, have conducted white box
| penetration with Cure53 to validate designs and crypto,
| architected our platform with modern protocols such as FIDO2,
| DID, OIDC. And we have been very transparent with what we do,
| so everyone can see the detailed flows and how the platform
| works https://docs.idemeum.com/security-whitepaper.html
| danenania wrote:
| In most cases, attempting to roll your own secrets management
| (or just ignoring secrets management entirely) will end up
| spraying access across _all kinds_ of third party services
| (usually in plain text), as engineers resort to sharing secrets
| via email, chat, file sharing, and other tools to get their
| work done. The cost /benefit/risk calculation of trying to do
| this all yourself isn't good.
|
| Using open source/self-hosted secrets management tools can be a
| good middle ground that requires less trust while still
| providing secure sharing options to engineers so they don't
| resort to egregiously insecure methods. Disclaimer: I'm the
| founder of just such a tool - https://envkey.com (we're
| adjacent to Idemeum but are focused specifically on
| application-level configuration and secrets, not passwords or
| SSO).
| vermon wrote:
| How does it compare to Cloudflare Access?
| npoturnak wrote:
| To my knowledge Cloud Flare is about connectivity and
| authorization. They outsource authentication to external
| identity provider (Okta, etc.) and do not actually log you into
| downstream resources. Cloud Flare can also do basic device
| posture telemetry, meaning identifying risky devices and
| blocking access from those devices.
|
| idemeum on the other hand covers access end to end -
| connectivity through proxy, passwordless authentication to
| downstream resource (for example certificate based auth for SSH
| servers), granular authorization policies, and auditing
| including sessions recordings.
|
| You can think of Cloud Flare Access as remote access solution.
|
| idemeum is remote access + SAML identity Provider + password
| vault.
| SoftTalker wrote:
| > (1) kill passwords; (2) make things simple.
|
| Two diametrically opposed things in my experience.
|
| Not a comment on this product specifically, but I have not used
| any authentication mechanism that is simpler than passwords. A
| password flows from my fingertips with almost no context switch.
| For everything else, I have to stop what I'm doing, find my phone
| or some other device, unlock it, do something with that, put that
| away, while in the process waiting for various browser redirects
| and hoping none of them fail, and then return my attention to
| what I was doing (if I can remember).
|
| Passwords are simple. Everything else is not, in comparison.
| npoturnak wrote:
| Great perspective, thank you for sharing. I might agree with
| this statement in the context of consumer authentication - when
| I am accessing my personal apps, websites, etc. Especially
| e-commerce is sensitive to login friction.
|
| In my opinion in the business / workplace setting, "simple" has
| additional context to consider, such as how do you distribute a
| password to an employee, how do you pair password with MFA, how
| you manage the user records, what happens when employee forgets
| the password, who do you call when you need to reset a password
| or MFA, etc.
|
| Therefore taking a mobile app and scanning a QR code to login
| is not quite hard after all...
| Grustaf wrote:
| I don't think the sentiment that "typing a password is easier
| to use than FaceID or TouchID" is very common.
| shaeqahmed wrote:
| okay but what about biometric auth via fingerprint -
| passwordless & zero context switches (provided your device
| supports this)
| william_T wrote:
| How are you managing biometric data to comply with BIPA?
| npoturnak wrote:
| Thank you for your question.
|
| We do not touch or manage biometric data.
|
| When you use our Passwordless MFA mobile application to login,
| you use Face ID to unlock the certificate in the hardware
| backed storage, and then that certificate is used to
| authenticate user to our platform. Biometrics processing is
| happening only on end user devices.
| traceroute66 wrote:
| > In industry terms, we combine Privileged Access Management
| (PAM), Identity and Access Management (IAM), and passwordless
| technologies.
|
| In plain terms, this sounds like a classic "Jack of All Trades,
| Master Of None" waiting to happen. Personally I prefer more
| focused products rather than those trying to be all things to all
| people.
|
| It is also kind of an area with a lot of competition, I would be
| interested to know how you compare yourselves to, for example,
| the OKTA's of this world.
|
| Which then brings me to the topic already mentioned by others. As
| OKTA and others have shown us, outsourcing your secrets to others
| is a bit of a risky game to play.
|
| You say you are SOC2 compliant and this that and everything else,
| but so are OKTA and look what happened.
| npoturnak wrote:
| Thank you. Very valid points and feedback.
|
| We would not position our product to very large enterprises
| with thousands of users. Indeed, they will deploy best of breed
| products - separate SSO, separate password manager, separate
| VPN etc. The key is that companies like that have the resources
| to manage all these products separately - sync users back and
| forth, onboard users into each of those products separately,
| manage SSH keys, answer call center calls resetting passwords,
| and more.
|
| We position our product for organizations with 1000 employees
| and below. We want an employee to install a mobile app, access
| company portal and have access to ALL she needs in one place.
| Simplicity of integrated solution paired with passwordless is
| what we focus on currently. Why use 5 different tools and login
| 5 times?
|
| Okta is a great product with deep enterprise roots and a lot of
| integrations with legacy systems. We focus on simplicity and
| provide major Single Sign-On capabilities today that an
| organization of 1000 employees would need - catalog of SAML
| pre-integrated applications https://integrations.idemeum.com,
| SCIM provisioning, integration with HR system for user
| management, native passwordless, RBAC, auditing, password
| vault.
|
| Regarding the secrets we believe that going passwordless and
| applying strong decentralized authentication will significantly
| reduce attack vector and compromise probability. If I recall
| correctly, Okta breach was due to a stolen password.
| netman21 wrote:
| Sounds like the best of Axis Security and Beyond Identity. Well
| done. Kudos for not using "Zero Trust" in your description!
| Wronnay wrote:
| Why don't you offer self-hosted solutions? A lot of companies in
| this space offer self-hosted software because companies don't
| want to trust external providers for auth...
| jsethi512 wrote:
| idemeum has been built from ground up with cloud-first
| principles of high availability, scalability, resiliency and
| observability. Currently we support multi-tenant and dedicated-
| tenant SAAS maturity models depending on the customer need for
| isolation.
| debarshri wrote:
| I just saw the demo of SSH looks very similar to Teleport and
| StrongDM.
|
| I think both the solution solve this problem gracefully and has
| been around doing this.
|
| [1] https://goteleport.com
|
| [2] https://www.strongdm.com
| npoturnak wrote:
| Thanks for taking a look. Both are great platforms indeed. To
| my knowledge StrongDM is only connectivity, no passwordless
| authentication to downstream resources. We offer similar
| functionality to that of Teleport, but try to abstract
| complexity such as managing yaml files and manual
| configurations.
|
| Infrastructure is only part of the story for us, as we offer
| SAML SSO, Password Vault, Radius, our own MFA.
| debarshri wrote:
| Strongdm also has passwordless authentication to downstream
| [1]
|
| Complexity is a relative term in this case. There is no
| complex yaml files when you want to setup simple SSH in
| teleport. The complexity arrives when you want to custom
| configure everything, which I think is same in your case.
|
| [1] https://www.strongdm.com/blog/passwordless-authentication
| kpdemetriou wrote:
| > Zero knowledge cloud > Data in our cloud is end to end
| encrypted so your credentials are never exposed to anyone but
| you.
|
| A few comments:
|
| 1. You might want to avoid calling this zero-knowledge. While
| your docs suggest some use of E2EE, there seems to be a
| significant amount of metadata that remains both unencrypted and
| unauthenticated.
|
| 2. Having read your white paper, it appears your E2EE setup is
| vulnerable to various forms of forgery. In a simple case, an
| attacker that has compromised your infrastructure can easily
| substitute the credentials of arbitrary users in a way that is
| NOT tamper-evident.
|
| 3. There seems to be no post-compromise security. If your user
| private key is compromised (e.g. extracted from the extension's
| local storage), there seems to be no way to reset it.
|
| 4. The recovery flow is questionable. Do you really want to store
| critical cryptographic material in plaintext and in a third-party
| cloud?
|
| When rolling out E2EE from scratch, it's very easy to give rise
| to issues like #2. At Backbone[1], we've created a framework for
| building end-to-end encrypted applications with building blocks
| designed to preserve confidentiality, integrity and
| nonrepudiatiability under a strict threat model.
|
| Feel free to reach out, we're happy to share how we solved issues
| like the above.
|
| [1] https://backbone.dev/
| npoturnak wrote:
| Thank you for reading through the security paper. Please find
| relevant points that explains the product security.
|
| 1. We have been very diligent and do not expose any sensitive
| user related metadata in any public api that is
| unauthenticated. The API's are protected using authenticated
| session that are established with unphishable passwordless MFA.
|
| 2. There are multiple things to highlight here. First of all,
| the user credentials use client-side cryptography and there are
| no keys in the cloud infrastructure to decrypt for attacker or
| even idemeum team. Second, the credentials are protected with
| AEAD that adds an additional integrity and authenticity check
| on the encrypted data. Third, we have diligently provisioned
| the cloud infrastructure using private vpc, subnets, security
| groups and role-based access that makes it harder for attacker.
|
| 3. idemeum password vault does not persist the user key in the
| extensions local storage. The key is broken into shares using
| cryptographic algorithm and distributed using multiple parties.
| the key is reassembled when a sufficient number of shares are
| combined and is used on-demand when required and discarded.
|
| 4. saving the recovery in the third-party cloud is optional.
| users can choose to save the recovery key in their personal
| backup if needed.
___________________________________________________________________
(page generated 2022-10-26 23:01 UTC)