Thank you for taking a look. Magic plays in a different market. There are primarily 2 markets for identity - consumer identity and enterprise identity.
Consumer identity - you are developing a scheduling application. You need to log the users in into your platform. You can build the auth layer yourself, or get an SDK from someone like Magic / Stytch / Auth0 to outsource authentication. Magic offers SDKs for logins with magic links and web3 wallets.
Enterprise identity - you run a company of 100 employees. They are remote and need to access a variety of systems, including on-premises apps, servers, etc. This is where we come is helping you centralize, manage, and secure employee access to anything.
In summary - magic helps with authenticating users to your application. We help with authenticating your employees to company resources.
Ping Identity is heavily enterprise centric. Have on-premises and cloud offerings. Great for SAML Single Sign-On. Ping Identity does not do anything for infrastructure access. You have to have a separate product for that.
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.
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.
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...
I hear what you are saying, but I think this comment in conjunction with the parent comment speak to the bigger issue which is how do you make something easy for both IT and the end user? Yes, a solution like this may make it easier for IT to set things up and support their users but I have had the same experience as OP with similar products at companies I’ve worked at. Logging into a system now means I have to find my phone, unlock it, open the app, scan the code, and provide a biometric (or passcode) again. That’s if everything goes smoothly I might be prompted to change my phone’s password if I’m using a company phone with a password change policy, something might happen with a redirect or the app. Now I’m completely out of the zone of what I was working on.
Or I can have SSO or a password manager and be logged-in in less time then it takes me to grab my phone. As an end user I would much prefer the latter.
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.
I'm the founder of Typing AI Biometrics ( https://typing.ai ). We also applied to YC but we weren't accepted. Typing AI indentifies users by the way they type and can also act as a standalone Passwordless authentication method.
In case that you want to add an extra Multi Factor Authentication (MFA) method to your product offering (typing biometrics user identity check, known as keystroke dynamics), we can arrange an agreement.
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.
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.
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.
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
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.
> 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
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.
> 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?
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.
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.
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...
Consumer identity - you are developing a scheduling application. You need to log the users in into your platform. You can build the auth layer yourself, or get an SDK from someone like Magic / Stytch / Auth0 to outsource authentication. Magic offers SDKs for logins with magic links and web3 wallets.
Enterprise identity - you run a company of 100 employees. They are remote and need to access a variety of systems, including on-premises apps, servers, etc. This is where we come is helping you centralize, manage, and secure employee access to anything.
In summary - magic helps with authenticating users to your application. We help with authenticating your employees to company resources.