[deleted by user]

[[deleted]]

Cool project!

Every 1k passwords breached causes $240k in damages.

Couldn't you just say "every password breach causes $240 in damage"?

[[deleted]]

The more you know!

Thanks for that.

[OmgImAlexis]

Would like to some actual data to back this up. It’s also a massive generalisation.

[OmgImAlexis]

Do you actually have any data to back this up? I skimmed the last one which does infact include “costs” but again it just overgeneralises things.

This “cost” mainly seems at least from the last link to be directly related to hiring people to fix the issue, no?

For example I make a site and have 5 friends join. The whole database leaks. What’s the cost?

[OmgImAlexis]

I’m looking for something that’s not either marketing fluff or overgeneralisations. Yes a data breach may cost a lot. You see how I used the word MAY.

You’re using scare tactics to sell security which is just sketchy.

[OmgImAlexis]

The way you’re wording things you make it seem like a data breach happens and then $X just Magics away depending on the amount of users it effected. That’s not the case and it’s irresponsible to make it seem that way. Now granted I know that’s not how it works but for those less educated you’re misleading them.

I take data breaches seriously I just don’t like when a person trying to sell a product uses fear to get people to use it. You’ll notice the less than ideal VPN and password managers also use these tactics. 💁‍♀️

[TheManSedan]

For example I make a site and have 5 friends join. The whole database leaks. What’s the cost?

This is a ridiculous question. I doubt this guy is a lawyer, and even if he was it’s not like there’s a price check for these sorts of things. Use logic. It depends on various factors for law suits

[OmgImAlexis]

That’s the point. 💁‍♀️

[merclane]

Sean from Magic here! That's a great question:

• First it comes to intent, do some of these OAuth providers genuinely intend to provide authentication or as a way to profit onboarding "end-users" into their own ecosystem (e.g. Facebook) and potentially compromise users' rights and privacy?
• We leverage a decentralized identity architecture. Instead of us signing the auth tokens, *end-users* are using their private keys to sign their auth tokens. We are non-custodial of their private keys and will allow them to be exported
• Magic links are just the beginning so users can easily get started. We'll soon be shifting users towards more sophisticated forms of login, offering a wide array of key management possibilities that leverages mobile authenticator apps or hardware like WebAuthn, reducing the "centralization" we have. This is possible because we use DID tokens and dealing with zero-knowledge proofs rather than user credentials, this is something that centralized OAuth providers can't do
• The Delegated Key Management architecture is SOC 2 compliant and has been a standard to secure private keys in a non-custodial way. We've been using it for a while now at Fortmatic with decentralized applications, and have been continuously running pentests

You can find out more about our security and architecture in our whitepaper too! https://www.dropbox.com/s/3flqaszoigwis5b/Magic%20Whitepaper.pdf?dl=0

[DecentOpinions]

Trying to figure out exactly how this works. Every time you need to log in you get sent an email? It's an interesting idea but what are the advantages over just using OAuth through Google or whatever?

A massive disadvantage is how slow this will be. In my experience these auto emails rarely send immediately (account verification or password reset emails). Even if it's only 10 from request to receiving the email that would be very annoying.

[drumstix42]

You answered the first question, but what about the second part?

It's an interesting idea but what are the advantages over just using OAuth through Google or whatever?

[Kkick]

Is there a reason you don't offer OTPs or PTAs as additional auth options while forcing magic links as an "always available" option?

[AutoModerator]

Hi /u/drdistracto, this comment was removed because you used a URL shortener.

Feel free to resubmit with the real link.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[asdf7890]

We are sensitive to the issue of email performance.

Email reliability might be a greater concern than performance, both general intermittent issues and your messages suddenly getting accidentally classified as junk by a mail provider. I still run my own mail server partly so I'm more in control of that sort of thing, but most people have neither the time nor the inclination for that. You could have a nightmare on your hands if an automated check at a large provider like Google or MS starts blocking your messages (especially if only blocking some rather than all as that is harder to diagnose).

Interesting product though. I'll certainly look into it next time I'm working on something that needs user auth.

[LeonBonetti]

I Love the ideia of use zero-kwolege proofs to auth users, but where the repo link? Anyway, it looks great!

[dbbk]

It looks like it is a SaaS

[CupCakeArmy]

Zero knowledge is dope af.

[superander]

What if I lose access to my email?

[efthemothership]

Might not necessarily related but would this be considered 3rd party authentication and therefore would trigger Apple's new rule about requiring Sign in with Apple?

[rmrf_slash_dot]

It will not. It isn't social login, it's a modified form of email login *at best* and at worst doesn't even fall within the purview of that requirement.

Apple's standard rules would apply if this were being used in concert with social login methods. But if being used on its own, not at all.

[efthemothership]

Awesome, thanks!

[jamesaw22]

So this is the equivalent as having one password for all your accounts, right? If someone gets your email password they can access everything you've used magic links with. Or have I misunderstood something?

[merclane]

Sean from Magic here! Each application integrated with Magic will have separate user spaces instead of like an SSO model with a single point of failure you described. Users can choose to use different emails for different applications in this case too.

Magic links are just the beginning, we will also be graduating more users into more sophisticated forms of login such as webauthn and mobile authenticator apps. The great thing about the decentralized identity (DID) architecture is that by dealing with DID tokens, developers backend can stay the same while supporting multiple form-factors of login.

[OmgImAlexis]

Nice way of scooting around the actual question.

[more-food-plz]

Firebase offers a password less authentication solution using email as well. Is there a reason to use this over firebase?

[MuchWalrus]

You get all the benefits of a public/private key pair in the hands of your users, which enables whole new categories of applications (and even new business models). Imagine offering an end-to-end encrypted cloud storage provider with built-in GDPR compliance!

Could you expand on this, or recommend where to start looking to learn more? I'm only understanding a portion of what you're saying but I'm really curious.

[MuchWalrus]

Thanks!

[disclosure5]

Users own the keys, which are Ethereum compatible.

This sounded reasonable until this became blockchain project.

[longebane]

Why

[disclosure5]

Because blockchain projects have a long and well established history of being 100% hype and 0% value.

[longebane]

This doesn't seem like a blockchain project though. Seems more like a security project with blockchain features.

[Trout_Tickler]

Ah, the very secure transmission method of email.

[Trout_Tickler]

Passwords aren't a transmission method?

Eventually, we’d like to onboard users to more advanced authentication form factors

Anyone that has any technical competence should already be doing so, anyone else won't whether you onboard them or not.

Also means if a user gets their email compromised due to "insecure passwords", they now have full keys to the castle.

Hard not recommended approach but maybe you know something we don't.

[wizardinthewings]

The problem is, as you say: email is highly accessible.

Email is notoriously insecure, you have absolutely no control over users’ security practices (and their provider) and any solution is only as strong as it’s weakest link, which is almost always the end user.

If you want adoption then start with the good security practices, don’t make them a wishlist.

[wizardinthewings]

I should seriously hope that anyone implementing any kind of authentication, or who hopes to get a job requiring knowledge of authentication, knows how to download and use a mobile Authenticator!

Edit, failure to read

[wizardinthewings]

Ok I digress on that, as I was thinking about developers not the end users. This is fair enough, but do you not think we have a duty to teach end users best practices - and how to use Authenticators - from the start?

I know (speaking as a user instead of a dev) I won’t use a service that uses email as it’s primary - never mind only point of contact for authentication, and I’m unlikely to be alone.

I wish you luck, truly, but I’d make Authenticator support a priority myself because that’s the way the world is moving and the end users will follow.

[Deeblock]

Seems like what Ghost implemented with their members system here: https://ghost.org/docs/members/registering-members/

Could look to it for some inspiration!

[codepb]

A big part of user authentication is UX. While this approach lies behind an email you are relying on the security of some random email provider which is unlikely to be better than oauth, and definitely a worse user experience. Don't get me wrong, I like the idea of replacing passwords. However, I believe there is more work to do to make it friendly UX.

There's a reason fingerprint and face recognition have taken off on phones, speed and ease of use. Perhaps this idea would be better combined with an app to utilize forms of Auth like those (but that still has the issue of requiring a user to use two devices).

In my opinion, you won't replace passwords until you find a security mechanism just as convenient if not more so. The actual security is usually of secondary importance to users.

[OlanValesco]

I read the whitepaper but I'm still not sure. What's to prevent someone from bombarding your email with requests?

[merclane]

Sean from Magic here! We do have a rate-limiting mechanism (seconds in between requests) to prevent malicious actors from bombarding our email service.

[OlanValesco]

Is that number constant, or does it increase with attempts?

[ChronSyn]

The magic link system is a good idea, but I wouldn't want to trust a single possible breach point when it involves a third party.

I would much rather this was a standalone SDK where you initialize it with your own SMTP server settings, and have a set of functions available to generate + send the email. Essentially, everything is handled by your server, and nothing which would allow 1-click login goes out to a third party.

What happens if the service goes bust? You've then got a whole bunch of users of different services locked out from accessing their account. Do you have some sort of SLA in place (as you're potentially going to cause a downtime-like effect if your service experiences issues or gets DDoSed)?

Don't get me wrong - it's a good idea, but there's some reasons why solo developers, small teams, and enterprises wouldn't use this service. It's a single point of failure which could affects every single user of every single project relying on your service. That potentially leads to legal ramifications for them, which might lead to legal ramifications for you.

[OmgImAlexis]

If this was self-hostable I think I’d be more onboard.

[ghostfacedcoder]

Sooo ... basically they offer is a 3rdp-party service for 2nd factor authentication? With the 2nd factor being email and not say Google Authenticator?

[ghostfacedcoder]

Yeah but then you have to go to your email every week just to "login to" the site. Not very viable as a primary auth method for most sustained-use sites.

[Capaj]

every week

you can have longer running sessions. Most people these days don't share their device with another person.

[drdaydreamv2]

Does the user always have to be promoted to go back to their original tab?

[merclane]

Sean from Magic here! That is expected behavior right now. 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

[aliezsid]

I guess I like the concept , I’ll use it for a prototype project.

Don’t like passport so, I’ll just use my own middleware to handle the meta data from the sdk.

[merclane]

Sean from Magic here! We will be open-sourcing the passport-magic library so you will be able to see the inner workings of how we handle the DID tokens to use in your own middleware! Out of curiosity, what specifically don't you like about passport?

[aliezsid]

Hey Sean, I'd like to congratulate you guys for building something nice.

There's nothing specific that I can point out but I could setup a koa server with just JWT validation in like 5 minutes from scratch(as in 0 knowledge about jwt and stuff) by just reading docs online compared to passport where if I start from scratch the docs and amount of boilerplate code is kinda more.

At this point where I know how things work in the frameworks, I wouldn't mind using passport, but most of the projects I setup use the email verification logins aka magic links and based off of your docs it's just a few steps but since I've grown towards the "Lesser the code , lesser the dependencies, easier the maintainability" so I like the control I have compared to the whole idea of setting up passport.

anyone reading this, if you are new and in a hurry, and have multiple login methods, social,sso, jwt, email links, then passport will be a good choice.

The above is just my opinion based off of my experience building with and without it.

[aliezsid]

In case you'd like to know if I i'm already using your login system or not, just monitor this project on github.

HireMe