image created by Margaux Peltat for the Chilled Cow YouTube channel
Time for #DevDiscuss — right here on DEV 😎
...
For further actions, you may consider blocking this person and/or reporting abuse
I'd say very much yes that passwords probably are this really funny "early days of computers" thing that won't stick around usefully longterm.
The problem is that we are sort of in an extended hellish in between of all the different ways to authenticate, and we might be that way for a while.
I think the right authentication for the future has to be sort of an abstraction over all the different stuff that came before it, and I don't know if we're there yet.
Just discovered passwordless.dev/ recently acquired by Bitwarden.
Commercial providers are popping up more and more lately. They noticed too the breakthrough that WebAuthn provides and now race for market share and early adopters. Here are some: passageid, hanko, ownid, corbado, orysh, cisco... And bigger auth providers like auth0/okta, onelogin and others are stepping up too.
Nevertheless, as far as I know, Passwordless.ID is the only one which attempts to make a free public identity provider, which is crazy enough in itself.
Hum, makes sense. Thank you @dagnelies ! Was not aware of that. In any case, it's probably the sign of a deep-rooted trend.
For me, it's a good choice to avoid accounts hacked with a normal credential email + password. This is very simple and securised.
Got a private key like a SSH key, is just awesome ✨
I'm using some websites who using just email, and you do check your email to click on the link and validate is you. That is the one of better way to authentification! 🙌
it's called "magic links," and it's quite handy, but you have to be careful with the implementation. Otherwise, it can be vulnerable.
Oh thanks for telling me what it was called. I couldn't remember. 😆👍🏼
And yes, like all systems, we must be careful indeed
Indeed, but this one is quite critical. I was thinking as a dev who has to implement it. While there are some cons, you'd better use libraries in this case.
I've seen live projects where you can inject parameters in the URL, or with non-expiring tokens. These projects had memberships and payments associated.
Outch 🙁
(Full disclosure: I am the Developer Advocate at passage.id)
Passwordless authentication via WebAuthn is a powerful, secure, easy, useful, and outstanding way to authenticate.
It is easier on your users. They love not hunting up, creating, and dealing with passwords. Registering is as easy as a FaceID or a fingerprint. So is logging in.
Companies like mine make it really easy to implement. So easy, it is hard to convince developers that it really is that easy.
It's way, way, way more secure. I liken the threat surface of passkeys to a small puddle, where passwords have the threat surface of Lake Michigan.
I don't see how passwords are used at all at some point in the future. Hopefully the near future. ;-)
As a lifelong Michigander, I appreciate your analogy 😁
Passkeys finally look like a usable and safe (by synching the passkeys between devices) way to do passwordless auth.
It's a bit too early for passkeys but at least applications could propose WebAuthn as a compliment to passwords for now.
Passkeys absolutely are intended to be the winner here, and because passkeys are now possible in iOS and, I believe at least in Chrome Canary/Beta, I think that this is the time to start progressively enhancing registration/login flows to work alongside passwords for now and eventually replace them.
The syncing part of passkeys is cool, but we do need to get users used to it, as well as used to the QR code method of using a passkey across device when syncing isn't available. There might be some short term user experience degradation as people figure that out, but once we're over that passwords can be buried
That's an interesting topic, I'll stick around.
I want to apply passwordless into a project but further developments on other projects are consuming my time (and my soul 😂) so I don't think it will be till march when I'm able to start the given side-project, and the info shared here can be quite useful!
I like to use public/private keys (e.g., ssh), which can be considered as a passwordless auth.
This one is easy to set.
I don't understand password less authentication. Firebase offers it but I don't see the benefit of signing into your emails to sign into another site. Seems like it adds more friction.
I see why having email and password are sometimes bad but do we not use email/ password to get into our emails? So our app is secure but what if someone gets into our emails?
Are we not just passing the email password issues over to our email provider?
Try the demo in the article, no email nor password necessary. It's about passwordless authentication using fingerprint, face, swipe pattern or any local device authentication for the web. ;)
In that case I'm all for fingerprint/ face unlocking but I don't understand firebases passwordless solution. What are your thoughts?
A user clicks a link in their emails to login to another website
It's thrilling to see this discussion going on! If you ask me, passwordless authentication is certainly the future, without a doubt, as it is both way more secure and much more convenient for the user ...but there are hurdles and it's only half the story.
The hurdle is that the specification itself is very complex, making it challenging for developers and adoption slower. Moreover, it requires re-thinking authentication procedures since only registered devices can authenticate (*). Lastly, the user experience may vary depending on device/OS/browser and it is new and unfamiliar concept for users too. Nevertheless, I think it's just a question of time until it becomes the default login option for the MS, Google, Apple accounts.
This brings us to the second half of the story. In the long term, people would be annoyed to re-register their multiple devices for various websites, or call the account recovery procedure just because they bought a new phone. And that is what lead to the so-called "passkeys". (*) It is the same protocol, the same access keys, but they (MS, Google, Apple) will synchronize your keys accross all your devices. Sounds great, right, but also note that it is a weakening of the protocol since the keys are not so secret anymore.
Now, if you think even further ahead, I think it will lead to a kind of user aquisition war. I mean, you can either (passwordlessly) sign in accross all android devices or all windows devices or all apple devices, but not mix them, except if the website goes the extra mile to support it. Binding the user's access keys to the platform is kind of binding the user itself.
The only alternative to that is a platform neutral identity provider. That way, your credentials would not be bound to the platform and would be a central place to manage all allowed devices for all apps at once. I guess you see where I'm heading to, that's exactly what Passwordless.ID is meant to be.
I'd say it's one-part marketing gimmick, and 2 parts evolving the consumer end of authentication to reflect the state of technology we have at our disposal.
This may sound arrogant or crass but I'm going to say yes as the concepts of Passwordless authentication aren't new. SAML for example will federate authentication without a password.
Broadly speaking - be aware that Auth as a mature feature is not a small effort. Building your own user/password auth is a good exercise for learning, but not something you necessarily want to scale & maintain for the next 10 years. I avoid building my own auth these days, instead favoring third-parties like Auth0 or Okta.
No stories, but I'll take the opportunity to give 1Password a shout out. They're an awesome product as a User for password management, and I'm loving their solution for managing and deploying secrets across my environments. The developer experience working with them has been awesome!
I struggle keeping track of all my passwords and different 2FAs and making sure i don’t fall into the habit of reusing a password because i can’t be bothered to think of a new one 🥴😅
I personally now use a password manager and have it on my phone and pc as I’m not a fan of the apple “suggest password “ because by the time it pops up with remember password, it’s refreshed and it’s gone forever 😂
Having apps use touch or Face ID was a game changer so I’m always interested in the next thing to help with this but keeping skeptical as to making sure my passwords are secure.
I've been allowing my members to login via metamask to use the tools in the back office.
While still learning how to give access to special features if they hold a certain amount of membership tokens
List of NFT representing roles binding, like "bob is blog moderator" sounds more meaningful approach than number of tokens representing permission flags, to my taste. This also allows to tweak actual permissions role gives, and also if somehow bob would transfer this NFT to alice, e. g. by mistake or justforlulz, it will not give permissions to alice.
As folks already pointed out, there's no easy answer to this question. I also don't think it is a one-size-fits-all solution kinda thing either. Some devs believe, me included, that it's more secure than the traditional username/password method, while others believe that it's not the case and could lead to more security breaches. The truth is probably somewhere in between.
On one hand, passwordless authentication can provide a layer of protection against brute force attacks in the current quantum computing era (there is always the possibility that passwords could become obsolete altogether as quantum computing becomes more powerful 1.), making it much more secure than traditional password authentication. That's one of the reasons why many companies are moving towards passwordless authentication 2.
Another advantage to highlight is the usability of this method. We all know that there is a problem with keeping track of various passwords associated with different accounts. This method, however, makes it easier for us to access our accounts quickly and securely.
On the other hand, if an attacker gets access to a user's device (Stealing the browser tokens/cookies, or gaining physical access to devices, for instance), they could potentially gain access to everything.
Another issue is that PA can create a false sense of security and users may become less careful about protecting their account information.
Now, back to the original question: is passwordless authentication the future? Well, it's hard to say for sure. But it certainly seems like the right direction when it comes to authentication.
Nope. I will try it on the weekend. Less gooo!
Chang Wei Goh, (Mar 4, 2022), What does the rise of quantum computers mean for encryption technology?, Retrieved Jan 18, 2023. ↩
securitymagazine.com, (October 2, 2020), 92% of businesses believe going passwordless is the future, Retrieved Jan 18, 2023. ↩
Not only is it seen as more secure and user-friendly, it _*is *_more secure and user friendly. ;-)
I'm amazed that we haven't come up with the ability for people to leverage blockchain for securing their online and digital identity. The blockchain could be leveraged for so many digital tasks it makes it the perfect solution. This would allow citizens to do things such as pay for services, vote, and communicate online securely and with validation and verification.
It's an interesting idea but the blockchains are public normally and anonymous so not sure how you could record something in it that helped. I think this is one of blockchain's biggest problems as a payment gateway, wallets get identified and then you have a permanent record of all of your financial transactions available to anyone, avoiding that for passwords would be vital. Blockchain funds very much work on the principle of passwords (or keys) - "Your keys, your bitcoin, not your keys, not your bitcoin" is the problem with exchanges and hacks etc.
Why we need a blockchain if we can have a federated app based on standard tech? Like ActivityPub, Nodejs, Mongo or MariaDB, and some React/react-native UI? Why to blockchain? If it just will be some append-only database, deployed in federated per-server fashion?
In context of identity, such federated app en essence can be an analog of a federated keybase app, store public keys and signed (with related private keys) annotations/binding to keys. Without storing any private keys on servers.
If you're on NextJS, I'd rather use Next Auth + Mongo to setup my magic links authentication.
If scared about the data, then a Mongo Atlas instance with redundancy. It's dirt cheap to begin with and you own the data.
I feel like auth should be hardware based.
I don't know if it is properly passwordless or not, but I implemented only OTP based authentication system. I was thinking about implementing 2-factor authentication with email/ phone. That time I realized if I need to secure passwords with 2-step verification then why do I need a password? there is no point in using the password. at the same time with OTP base authentication, I dont need to create any API route for resetting passwords also. here is my git: github.com/ishafiul/passwordless-auth
Passwordless authentication is the future, but this future can be either bright or bleak, depending on details.
Big chances that magic links, or one-time codes will be used instead of the classic passwords.
WebAuthn must become unobtrusive (using built-in UI, like digest and basic auth, without client-side script) to be really widely adopted.
Centralized providers can be enforced by governments to validate users identity or age, and actually to track user activity or restrict user access to "bad" sites.
loss of device as way to lose access to (eventually) pile of sites - is not so nice too - so it may end up with wearable (ring? bracelet? "amulet"?) or implant? as way of identification and private keys storage.
It may sound as a comfortable thing, but eventually due nature of state and bureau-ocracy it will be used to restrict people rights and to track people activity.
I sound to grim or may too vague, but this side effect of topic being discussed - future of passwordless auth, without any constraints specified, actually.
mistake