this post was submitted on 19 Jul 2023
742 points (98.2% liked)
Asklemmy
43856 readers
2267 users here now
A loosely moderated place to ask open-ended questions
Search asklemmy π
If your post meets the following criteria, it's welcome here!
- Open-ended question
- Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
- Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
- Not ad nauseam inducing: please make sure it is a question that would be new to most members
- An actual topic of discussion
Looking for support?
Looking for a community?
- Lemmyverse: community search
- sub.rehab: maps old subreddits to fediverse options, marks official as such
- !lemmy411@lemmy.ca: a community for finding communities
~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The system mentioned by Established here is called VRF, there is also technology called Self-Sovereign Identity aka DiD (a w3c standard)
To keep it simple, essentially we are moving to authenticators using systems that are similar to how a website identifies itself and secures your connection. For the user it will still be mostly the same, unlock device, unlock data (which I bet in some cases will STILL be password during the transition) do your thing. As time goes on and things like identity keys that we carry with us become a thing (think like a fancy version of the electronic door cards).
In general it will be much easier and less an issue to get into most systems and all of your accounts become more secure as we move away from having any data on the provider that could be used to reconstruct your password. Ofc all of this is still a bit away from being fully realized, expect rollouts to become more serious by the end of the decade.
Wouldn't that not be great for privacy?
this is not dissimilar to how high security setups work for organizations now, really what this is is a scaling up of the kind of things IT administrators are already doing when locking down production among other systems (its a very common login pattern for Linux based systems for thier SSH terminals).
The big difference here is that your password changes from a password to a digital signature bound to time, hardware and the user. If the user so chooses they can always put a many levels on top of that that they want, be it passwords, additional keys, biometrics, what-have-you.
Since your credentials never leave your device data breeches do not compromise your account or access to it (only the data the provider failed to protect). This also enables even higher levels of security through the whole credential chain, want to end-to-end-encrypt your data and encode it with your own cipher while storing it in the providers database? This is not only possible it will end up changing how we develop some applications. As a developer I just want to give you the utility, if I can ensure strong encryption that I NEVER have access to, its a whole boat of liability I don't even have to worry about.
In short we are taking the mechanics of auth and making it entirely cryptographic with keys without any worry about compromising a simple text input box. The possible combinations of certificate data and system parameters alone increases the difficulty of a breech through login significantly.
It will not stop everything of course, and the usual risks around a bad release, a failed audit and an admin bypassing things knowing or unknowingly are all still problems.
The other thing this enables, should it get that far, decentralized replacement of Google/MS/Amazon auth systems many of us MUST gate our sites with, youll be able to accept logins from multiple systems without ever having to write any new code. As the standard becomes adopted and supported firing up a site with all the usual traditional logins combined with the more-modern cert-style setup will no longer be a game of dealing with app setups and IAM, you can just load and go.
Example of difference here: I could paste my public key to my prod systems here on lemmy and it would not change a thing about access to my systems, no one with the key or any of my signatures could do anything. With certificate based auth we know both sides of the transaction as well so MITM is not a thing in most scenarios.
Thank you for the detailed reply. I just had other things in mind. For important things, sure, but I kind of appreciate the ability to give some website a username, password, and maybe an email and that's all the ask.
I know IPs and browser fingerprinting kind of make this moot anyway.
you won't even give them that in this kind of system. you will get a user hash that is based of your signature, the system your using's key and some mux of time and entropy input. This hash will be how they track you in a database and as systems evolve could even be a way to communicate with the user directly (like email) without knowing or holding any PII/NPI
Anything you assign to them would be data they have (maybe a common display name). Anything truly important that needs to be up there can be encrypted with different techniques that would allow the provider to work with your data without ever having to access or decrypt your data.
so the idea of them "needing to have something" to function is true, but fundamentally, they don't need as much to operate in this system and its possible to have standards that enforce security on your more sensitive details that are sent. Imagine the security of your data, on thier system, still being ruled by your security. Even if hackers get in and copy the entire database its effectively useless.