Subscribe
Sign in
Magic — Make passwords disappear with a touch of Magic
Passwords are the bane of app security. With a few lines of code and no bloat, Magic lets you build apps with blazing-fast, customizable, passwordless login - with future-proof crypto and identity tech under the hood.
126
Replies
Best
Lyondhür Picciarelli
Apologies, but I am not a big fan. Loved the time and effort put on the sec paper, however, how can gaining access evolve from passwords to magic links, but still rely on the oldest and most corruptible of tools.. emails?
Maybe I'm missing something here, but wouldn't this mean that anybody who gained access to someone's main email account could basically bypass password gateways?
Passwords are not great, but at least they can be complex and individual enough (one to each service). It is definitely not an elegant solution, but when that is paired with authentication codes and 2-factor authentication, the user has at least enough time to intervene in the event of a breach.
One email link greatly reduces that variability to essentially one source of access. Being in control of one's 'magical' account, a malicious user could then reset 2-factor authentication features, reattribute accounts and basically wreak a whole load of havoc.
I would be all over this if the other side of the handshake was NOT an email. Maybe a ping on Signal, Wire, Keybase or any other reasonably safe messenger? Why the hell emails? :D
Perhaps an ultra-personal device with AT REST or BC encryption - preferably heavy on biometrics - such a smartwatch or a ring or else.
Report
Share
@lyondhur No need to apologize and thank you for your transparency! We started with email links because that's the easiest way for mainstream users to get started. Magic practices progressive disclosure religiously and the goal is to eventually graduate users into more sophisticated forms of login such as webauthn and mobile authenticator apps.
Under the hood, Magic uses decentralized identity (DID), developers only need to deal with DID tokens (signed by user private keys) to grant user access to their backend resource server, and the front-end key management form-factor can be very flexible (magic links, mobile authenticator, webauthn etc.) without having to change the backend code! This is a bit like the Docker for auth 😆
@_SeanLi another awesome product! Congrats on the launch. I know Fortmatic recently introduced a pricing model. Do you have a plan around pricing for Magic?
@jehunter5811 Thanks Justin!! The pricing model will actually be quite similar to the Fortmatic pricing model. We are finalizing the details and eventually the goal is to fold Fortmatic whitelabel SDK users into Magic, and the free base plan is going to also be in Magic!
Great to see that you all will be integrating with Zeit / Next.js! Any timeline on those projects?
Congrats on the launch--product looks incredible
@ggarnhart Thanks Greg!! Zeit/Next.js will be one of our next examples! 😉We've already started writing the example code for this, but couldn't make it for this launch :p I'll be jumping back to it after this launch and am looking to get this out in a couple weeks! Also feel free to suggestion other examples we should write too!
@_seanli Awesome to hear! The express example is the one I'm looking at now, but I'd love to see this work in other apps. Might be neat to do something with Flutter 😮(i'd peg that at a far lower priority, as far as my needs go, though!)
Thanks for building cool things :)
@ggarnhart Thanks for the suggestions - love making fun toys for developers! Flutter is an interesting suggestion - I can talk to my team about it. Though RN, iOS and Android native SDKs should be coming soon 😄
I'm really impressed by this.
Let me start from the landing page - immediately gives you all the information you want : what is this, why would you need it, what are the benefits and how to use it - without cluttering and while looking pretty good (not a fan of the mint, even tho its associated with security).
The SDK is simple and readable, the documentation is nice and readable - and answers all of the questions I might have regarding present and the future of using Magic.
And the product is awesome! First time I saw a magic link like that I was wondering why more services don't use it, and this makes it super easy to implement. And I love that the blockchain side is hidden from the user but still accessible - as it should be!
Mad props! 🌊
@ianissoawesome Thank you so much for the kind words and great feedback Ian!! 💜
Your "Security" section is a great read in and of itself. Thanks for this product. How common is the "passwordless" approach at the moment?
@devishnya1 Thanks!! We are very optimistic that it's a matter of time before passwordless auth start to catch on in mainstream applications! It's already been used as a predominant form of login for companies like Slack, Medium and Substack, with great results in terms of security and conversion, and we are in conversation with many more companies ranging from startups to enterprises who wants to switch over to Magic links! Passwords introduce so much overhead and risks these days giving the current cybersecurity climate and increasing number of data breaches.
There are many caveats and challenges for developers to roll their own magic link, but that's what we are trying to make easier with Magic! We will provide not only just magic link login, but other form-factors like WebAuthn and mobile authenticator apps - passwordless login is looking to surpass password login as a predominant form of login within 10 years!
@devishnya1 it's certainly growing in popularity we launched our own solution on producthunt this month https://www.producthunt.com/post... and are excited to see more people in the space.
What's the difference between Magic and a product like Fast?
Regardless, the integration is super seamless... Wow
@trigun0x2 Thanks so much Jeff!
Fast is focused on e-commerce companies with a streamlined checkout experience, while Magic is focused on providing a robust identity service that can be used for both startups and enterprise companies (SOC 2 compliant).
The other major difference is that Fast in this case is a centralized identity provider with a SSO-like experience, which also means that developers will have to expose the Fast brand on top of their own UX (like Facebook or Google auth). Magic instead gives users decentralized identity which is self-sovereign without having to trust centralized identity providers. Magic also gives developers the ability to customize the magic link experience, giving them a lot more control over the UX!
A cool secret with Magic is that every single user will be issued a blockchain key pair, which means for advanced developers, they'll be able to easily tap into the power of blockchain and cryptocurrency to build future-proof and innovative applications!
@trigun0x2 @_seanli When you say "without having to trust centralized identity providers", aren't you still trusting AWS? Afaiu, they hold all users' private keys in clear.
@trigun0x2 @_seanli @paul_mckenzie I think that's a choice for developer. like their is a concept of User Agent (It could be mobile device or a cloud) . It depends on security vs Usability what devs want more
Magic has nice pricing for startups. Free for first year, and half off 2nd year.
Wrote about why that is genius here.
https://twitter.com/JoshDance/st...
@_seanli I was very impressed when I signed up on my laptop and when I clicked the email link on my phone I was instantly signed into the dashboard on my laptop....
BUT then I opened a new window and signed up with my coworkers email who is currently across town and he clicked the email and I was instantly signed in to HIS account. This seems very insecure. This is why providers like Auth0 require magic links to be opened in the same browser session to be valid.
Maybe I missing something here?
Besides this seemingly big security flaw I am very impressed with the simplicity and execution. Love the brand and great documentation. Way to go 🙌
@jpamorgan Thanks so much for the help testing and the feedback John! We're aware of the potential phishing risks like you described, and will be releasing the feature to detect where and how the user has opened the magic link in order to prevent users from accidentally clicking on a malicious login attempt!
There's only so much that can be done in terms of email security. In the future, through progressive disclosure, we'll be gradually introducing users to more sophisticated form-factors of login we are working on like WebAuthn / mobile authenticator apps.
Looks really interesting. Passwords can be a real access barrier for many people with cognitive and learning disbaiities.
However I'm concerned about how this will work when you do NOT have access to email? I know this is seen as very unlikely but it's not impossible. For example might be in a private session on unknown computer without phone and extra hasslie of signing into web mail not wanted. Or just left your phone somewhere out of reach. Or just using someone else's device.
How does this mesh with offline and PWAs - that problem is probably out of scope for you but interested to know.
> The cool thing with using decentralized identity (DID) is that developers only need to deal with DID tokens signed by keys on the backend, and the front-end key management form-factor can be very flexible without having to change the backend code!
That probably answers my last Q :)
Is it safe to store token in local storage as some OAUTH / OPENID solutions do?
@stevealee Thanks for the great questions Steve!
- The magic link for now will piggyback users' email provider's recovery mechanism
- In the near future we will have other hardware/device login which can be added by users for added security and recoverability! Progressive disclosure is key for Magic, ease users in with magic links, and then graduate them into more advanced ways to login
- Definitely looking to be able to support offline and PWAs, as well as native mobile applications (coming soon)
- If you are referring to the DID token, under the storage associated to your domain, it will be up to your web app's security strength. With proper web security configuration (e.g. CSP) and watching out for the top 10 OWASP vulnerabilities like XSS, it will be safe to store it in the localstorage. In our documentation we've showed some example on how a replay attack can be prevented as well!
@stevealee: Thanks for the questions! Happy to take a stab at this one :)
> Is it safe to store token in local storage as some OAUTH / OPENID solutions do?
It is definitely very true that many things come into play to determine if it is safe to store data on the client side. It largely depends on what information a token is bearing and the current security strength of the web applications. The rule of thumb is always to avoid storing any sensitive information on the client side and handling it on the server side.
OAuth's access token is a good example of a token that should be handled on the server side. The token itself has been authorized for some scopes, and it can be used to modify or retrieve user info from the OAuth providers. If this token is stolen without notice, the sensitive information can be altered and leaked.
As for the OpenID Connect, since the protocol wraps OAuth to provide the identity layer that OAuth doesn't support (it is a common misconception in the ecosystem that people misuse/abuse OAuth as the identity where it should only be used as a resource authorization scheme), it provides both ID token and access token. The access token here is the same as the OAuth's, and by the best practice, it is strongly recommended to handle the access tokens on the server side. As for the new ID token, it is used to provide web applications with user info from Identity providers, serving like a client side caching layer with a TTL (token expiry). It is not indented to be used to gain access to act on behave of the users. if an ID token carries a field like `nick_name` (besides all the required fields), I would actually consider that it is safe to be stored on the client side. Having this data in the LocalStorage can improve the overall user experience because the application doesn't need to make another network call to retrieve `nick_name` when it needs to show the user profile page. It can read the info directly from the ID token. If the tokens expire, users will just have to re-authenticate again.
Provided with the right balance and the intent of the token, it can be helpful to determine if it is safe to store on the client side. Even though server side handling is always recommended, developers still have the ultimate control. The application security posture will then become super important :).
This is so relevant. Great job! Love it. One question: how much does/will it cost? Couldn't find it on website.
@sergey_lukin Thanks so much Sergey! Pricing page is coming very soon! We'll be charging a base fee a fixed charge per active user per month. We'll be carrying over the pricing from our existing key management product (https://fortmatic.com/pricing) and make slight adjustments. Love to hear your feedback on the price range as we are trying to make this an optimal choice for startups and growing companies too!
This is the authentication I've been waiting for! Seamlessly integrating web3 into web2 apps is now super easy!
@coderberry Thank you so much Eric!! Simplicity will be our focus - we'll carefully and gradually introduce more amazing web 3 features to web 2 in a super accessible way!
@cx42net looks like someone productized password-less login - just like the one you had on improvmx! :-)
@_seanli Great product. I was lucky to have the glimpse of this during ETHDenver :)
I have a basic doubt here -
Consider a case where someone stole my device and somehow managed to get the device password. Now that person will be able to get into the app via clicking on the magic link from the email client. How do you take care of the security in this case?
@meakaakka Thanks Akash! Magic link relies on the users' security of their email. It's a good place to help users get started, the goal here is progressive disclosure, eventually graduate users towards more sophisticated device based login via WebAuthn / our own mobile authenticator app
@_seanli got it. The challenge here is to let users get familiar with the magic link flow. And I think a mobile authenticator app would surely fix this security issue.
1. Why would I share my customers data with 3rd party when password/2fa are pretty well tested workflows/implementations?
2. GDPR compliant?
3. If slack used your service - how much would it costs for them monthly? (12M active users)
- I cannot login to my email right away from the phone (for example) - without 2FA token (for security reasons) - so link based passwords are pain to use. Nevertheless, you basically move the whole threat from passwords maintenance on the shoulders of the email - "congratulation"
I'm a little confused. So is the no password login using magic links or codes sent to email or text? But you still need to login to email right to get your link and on the homepage it's showing social media logins so that also uses username and password. So can someone explain or have I missed something?
Password-only security is obsolete and dangerously insecure. I've been hoping for a solution like this for more than a decade. The danger and the stakes for user authentication security are growing exponentially by the day. As we add more valuable asset transactions to our applications, the need for non-custodial solutions with minimal vendor lock-in grows as well.
Magic was easy to learn and easy to integrate with EricElliottJS.com, and we intend to use it as our exclusive auth solution for all of our new applications. The Magic team has created an elegant solution to a very challenging problem that every application team needs solved, but almost none should try to solve alone.
Magic is a non-custodial key management solution that stores user keys in cloud-based Hardware Security Modules (HSMs). Private keys are never exposed to the internet, and your users don't even need to know they exist. All users need is access to an email address and the ability to click a button. It's the most user-friendly, secure authentication solution I have ever seen.
@alex_kim4 Thanks so much! It's awesome that you noticed it and asked, we log users into the "original context" after the magic link is clicked, and we do this for several reasons:
* Taking modern user behaviors into account with users going between laptop and phone. Users are gravitating more towards their phone. Generally with web applications like Medium, users are logged into the tab where the magic link is clicked, but this may be a problem when users clicked on the link on their phone and is logged with the phone rather than the laptop, making editing very inconvenient. With Magic's model we can get through complications with Incognito mode too. (Though we will be exploring deep linking with our mobile SDKs)
* If the magic link URL get hijacked somehow, the hackers will only be able to login users into their original tab, which can mitigate damages.
* Training user behavior to gradually shift to user an authenticator app like DUO on their phone by subtly encouraging users to use both laptop and phone to authenticate
@_seanli I see. I was able to figure out that I had to go back to the original tab. For non tech-savvy users that may not be able to figure this out, how are you planning on improving your UX to make sure they know / learn that they need to use their original tab?
I remember the error showed "magic link expired", not "You closed your original tab, try again" P.S. I really like how you guys are tackling passwordless login from UX and security point of view.
@alex_kim4 I'd be really interested to see how this turns out. At did.app we used to direct users back to the original tab, we even tried using alerts to pull the focus. In the end though we moved away from it because non-technical users kept getting frustrated.
Like I said tho interesting to see if they can polish the UX
Wow! I'm very excited. I can't wait when I try it :)
Congratulations! What will be the next steps?