I agree - you’ve said what has been at the back of my mind - that email isn’t typically securely transmitted, and relying on it for authenticating a web service, is just shifting the security problem from an app related server to an email server.
RisingFromAshes
RisingFromAshes
It is presumably easier than remembering passwords (needs more research though). What’s worse is that most people don’t know the existence of password managers, so you end up with reused passwords across sites. In essence, passwordless auth is just a revamped forgot-password feature
I agree, more research is needed, but I wonder if it’s easier for someone to crack the password for a user’s email account than it is an app server? If not, does it really matter if a user uses the same password for several different apps?
At least they remember their commonly used/abused password, and if not, I often see people use built-in browser password saving services, if not a third party password manager, and on mobile eg iOS the auto-generated passwords that are saved to their iCloud keychain.
It would be interesting to see stat’s across sites/apps on the percentage of forgotten passwords, particularly immediately after sign-up. My guess is, that most people check their email, or do a password reset, or even sign up again if they aren’t yet ‘entrenched/invested’ in an existing user account.
There are many ways to look at the login problem from a time/age/memory curve across possible target demographics to others. An at the other end of the problem, where a login fail may be a a sign of a security issue, depending on the app - a trust based incentive for users to earn access eg email auth first, then password later - and anything in between, could be a solution.
I’m not sure if there’s a panacea for all sites/services/apps.
However, the main thing as a dev appeas to be to make sure:
-
A signed up, non-first time user - can get access to their ‘super cool original username account’ (although many sites now allow any number of the same usernames based on a deeper ID) if they forgot their password or some part of their username after signup, and many are now moving to emails as the username as that’s easiest for users to remember, and thus reset their passwords to access their account and start using for the first time post-signup.
-
Regular/‘frequently-enough’ users can reset their password easily, should it be forgotten, and when possible/if beneficial to the app, actually consider offering them a social login option for data/revenue sharing.
-
There’s a policy in place for duplicate accounts from the same user eg whether it’s easy or not for an existing user to create a new account as a backup of sorts, or start a new one using the same email/phone no., should they have locked themselves out and not be invested/entrenched in their other user account. Email as passwordless auth can limit this, or an app can, as Facebook tends towards real names and phone numbers etc tied to them. The policy an chooses will depend on the growth/business model of the app, and perhaps ultimately dictate whether usernames/passwords are king or email is or not?
Hmm, I don’t think I understand the question. But yes you need to provide email address for logging in (just as it is on @dennisreimann’s post). The security of saving user details on DB seems a different problem altogether
To rephrase my question - wouldn’t it be just as easy, if not easier, for a cracker to get a user’s email address from an app’s DB than a password, as emails are not often hashed like passwords? Sure, an email-based auth system may do that, but just as many big sites/apps continue to get in the news for plain text password storage, I imagine many will be caught out doing the same with email addresses for passwordless auth using email.
Social logins are also a form of passwordless auth for your app. However I know a number of people that mind using their social account for signing into a service.
I agree - I prefer not to use social logins for apps, and I think many developers that aspire to creating the ‘next big thing’ want to do so in a way that is attractive enough to encourage users to create a new account for their app. But sites like Facebook could easily swallow most of the web, apps, and any service in-between if there weren’t possible monopoly legal issues, simply because they are so popular, which means eventually not logging in via Facebook etc will be only for outliers. Personally, I’d prefer to put my trust in TouchID or something like it, but that’s a long way from being as mainstream as a social login, at least until Facebook does it (do they, I haven’t checked lately).
This is as far as I know what Slack does. They still accept passwords, but encourage the user (at least on mobile) to use the magic links.
That’s good, because in marketing terms, the price of something was traditionally the ‘entry point’, and there should be as many to cater to the spectrum of the demographic your business/service is targeting, and in the age of free social media/services/apps, there’s the need for as many entry points as possible - passwords, email, social logins, etc.
As an aside, this is a problem that I’ve been thinking about for sometime, and one that I think I’ve solved enough for enough uses cases to generalise beyond logins, and forms the foundation of the app I recently asked for developer interest from this community. Done right, it does a lot of interesting things, and many I think we can’t yet imagine. I’ve been chatting privately with a few here about working together, and if this topic is of interest to you and you can show aptitude in work related to it, PM me.
0
RisingFromAshes
Thanks for the article/how-to Dennis, it has been well timed for my app, and I my apologies if I appeared to dismiss it, but I think it’s worth debating the current interest in using email as a passwordless auth for sites/apps.
As you say, you provided links in your article, and there have been other posts here recently with passworldless authentication using email, so keeping in the spirit of discussing design to IDEs to everything developer related, I thought it would be good to examine auth strategies related to passwordless auth using email here. Perhaps I should have created an entirely different post, but the other day, an announcement about a great new open source Elixir/Phoenix app turned into a discussion about the screengrabbing tool used to generate the .gif of the app rather than a discussion of how cool the actual app is, so I thought this community could accept a digression from your initial post to discuss the actual topic at hand - the merits and strategies/applications for passwordless auth using email.
Personally, I think it’s dance around a future solution, if not a backwards step - if we are trying to find a universal solution to logins, but it’s a step in the right direction for some demographics who may not remember their password or frequently challenged when logging in.
That’s not to diminish the technical achievement of your how-to - as I’ve written, it was timely for me and no doubt many others. Thanks!
1
Most
Can someone weigh in on what some of the tradeoffs might be between creating a separate model for the auth_token and associating it with the user model like in the tutorial here, versus adding an auth_token field directly to the user model, similar to how this guide approaches it.
0
LostKobrakai
By doing it like the guide you linked it’s not possible to have multiple tokens associated to any single user. If users request multiple tokens before authenticating you need to store them separately otherwise you cannot handle proper timeouts for those separately.
0