I ran the older OpenID protocol for years, but over time, everyone stopped supporting OpenID. Stackoverflow was the last big provider that dropped it entirely. Sure we have OpenID Connect (which is OAuth2 based) and this project mentioned both OpenID/OIDConnect and how it expands on it, but the problem is getting people to allow support on their websites.
I think the only places we may see support are newer Fediverse servers like Mastodon, Pleroma, Pixelfed, et. al.
From what I understand this handles only authentication and provides tokens that may be used for additional (undefined APIs).
What bugs me about this (and all the oAuth implementations out there) is that you never just want authentication. You also want to know things about the user (username, name, email, avatar, etc) - but to get this you have to implement a plethora of APIs for the various services, because they are all different. I wish fetching profile info would be part of the standard.
That's basically what we have to do as a SAML service provider. Most SAML identity providers don't release identifying information—out of apathy or ignorance usually, not because of privacy concerns—so we take whatever (hopefully persistent) identifier we're given, re-identify the user at registration time, and call it a day.
I've never seen a SAML IdP that can't release that stuff as claims when configured properly. Are you having trouble getting people to do that when you use SAML?
Oh sure, a SAML IdP or OIDC OP _can_ release all kinds of info, but they generally don't if our experience with InCommon and eduGAIN IdPs is any guide. We even made sure we complied with REFEDS R&S (https://refeds.org/category/research-and-scholarship/).
OpenID Connect, aka. 'OIDC', is widely deployed. It's a compatible extension on top of OAuth 2.0, the latter of which was often used to provide third-party apps some delegated access to users' data at some data silo. This all coincided with the proliferation of HTTP-native APIs inspired by the easiest-to-implement tenets of REST. The payload of OIDC and OAuth 2.0 can be carried with in HTTP headers, which is a good fit for these APIs and simplifies implementation.
OIDC is used by some branded 'sign-in' buttons like 'Sign-in with Google' [1], and the new 'Sign in with Apple' feature is a close copy of the OIDC, if not yet directly conformant and compatible [2].
OIDC, which Keycloak Supports, is a tad more versatile than IndieAuth. In my experience, IndieAuth is quite a complicated dance to perform compared to OAuth2, especially since in OIDC, JWT tokens are fairly established to enable apps to get user data.
KC's tokens can get you quite a lot of insight and data about a user if you want, or nothing if necessary. IndieAuth uses HTML scraping for that.
Yes, mainly. I vastly prefer pseudonymity/anonymity on the net and would only reveal my real identity for services that explicitly require it. For shipping, banking, etc.
Well a domain name is usually pseudonymous, although some registrars require some forms of official identification (for legal reasons).
Many individuals & organizations hand out domains for free on their zone. That's the case with eu.org or netlib.re for example (among MANY others).
Any sysadmin can - and should - run a name server with a simple web application to let other users register domains. See for example https://github.com/KaneRoot/dnsmanager
So domain name-based authentication can bring as much pseudonymity as e-mail based authentication. The difference is owning your name (as prescribed by the indieweb approach) allows you to choose your host for services (including selfhosting for your personal identity), whereas the traditional "identity provider" approach means you're dependant on that provider till the end of times.
Of course, we could argue that by owning a name in a zone, your dns provider could just wipe your zone. Although not very likely (ISP-level DNS blocking is more common than actually "seizing" domain names), theses cases are addressed by so-called "nomadic identity" protocols such as ZOT (currently implemented by Hubzilla) which rely on public-key cryptography to die different names/identities together.
Then, there's always the possibility of domain names outside of the DNS. A domain name is simply dots linking machine names together, where the DNS is the usual tree-based implementation. But many other protocols provide domain names, the most common being the tor onion services (.onion domain names).
So i'll admit actual pseudonymity on the internet remains a research topic, but there's notable progress all the time. Personally, i think we should have a separate domain name / blog / mail for each and every one of our online identities.
I guess in that case, given it's just a URL you could use ie an autogenerated URL from Netlify or an S3 bucket etc. It doesn't necessarily have to be linked back to your identity
You could easily have e.g. a site providing many URLs a la anonauth.com/<randomhash> as identities to users, with the actual users, and the mappings between them and the random IDs being secret.
Hey all. Yes using DNS is straightforward to do verified claims like this as well.
They require a website to return a public key to anyone who asks. And if the website generates a claim signed by its corresponding private key, then presumably (if they kept that key safe) you can trust that the signing party meant to endorse some claim.
A user’s identity is actually the sum total of verified claims about them, from other parties.
Those parties, in turn, have identities. With DNS, they are public identities provided by nameservers. The nameservers have identities via being issued IP numbers. Many of these identities also contain routing information for how to actually get a request routed to a specific server program running on the internet (or a relay/hub that will deliver the message to a client who will eg decrypt it).
With Javascript, we can take advantage of DNS in an even more straightforward way. Simply use postMessage to an iframe running on the user’s personal app domain. The origin in the browser is guaranteed by https, DNS and IP. The trusted computing base is the OS and browser. You can do much more than authentication with it.
I would say that we do NOT actually neeed DNS though. For example, the domain inside the iframe can be intercepted by a cordova application, and represent the LOCAL CLIENT ON YOUR PHONE. No servers needed at all. You can provide your personal data to those peers who need it, without having a “public” identity.
Your identity still consists of verified claims by other entities, but in this case the entity is the app running on your phone(s), not a website running on servers. Sure, it didn’t register a “real” domain name with the federated DNS system - and sure, it didn’t get a certificate for the https with the federated “certificate authority” PKI system - but you have previously communicated the public key to your friends in a trusted side channel, and can always prove it is still you via an interactive chat or videoconference. So they trust the identity provider running locally on your devices, and no servers needed.
The only question becomes how to route messages to you. Friends can leave them on various computers all over the internet, redundantly, encrypted with the public key. They just have to bootstrap the initial addressess of mailboxes somehow. This can happen when you send the public key in the side channel, but it DOES require some sort of global network like DNS or a DHT or Apple Notifications, some sort of singleton that both parties can reach. This is the ONLY need for it — for deliverability, NOT security.
Nice take on the issue. But why rely on the browser stack and javascript hell, though? I think the approach you describe looks a lot like the Secure Scuttlebutt (SSB) protocol : local "gossiping" with centralized hubs to relay authentication and/or encrypted information.
> using DNS is straightforward to do verified claims
That could be simpler in some regards, but not others. Consider most shared hosting name servers don't provide a simple API to update your zone, so you may have to do manual edits for key rolling, vcard changes, etc..
Also, not all implementations of domain names are alike. The traditional DNS is a tree-like datastore and many things (such as routing and security) are outside of its scope.
But take for instance tor's onion services: they don't allow you to store/retrieve arbitrary records, but ensure the routing/authentication/encryption to the service and back. On tor, owning a name on the network is the actual mathematical proof of identity (the onion is a fingerprint of the actual encryption key) so you somehow don't need to let the DNS hold your keys for you.
I think the issues you mentioned have mostly been tackled by modern P2P projects. The actual pain points are in my opinion:
- the state of client applications (usually either ugly/broken or dependent on gigabytes of Electron shit that only runs fine on your dev hardware)
- backup: democratizing encrypted friend-to-friend backups, but also building server-side stacks for hosting coops, individuals and companies alike to easily setup "seeding"/"backing up" of your data using standard protocols
- identity recovery: people often complain loosing their data/identity on P2P networks (think Bitcoin, etc.), or regret lending it to the wrong entity (cryptoscams and hacks and whatnot). Proper identity recovery can be done either by dividing a secret among friends or with passphrase-generated private keys (or both)
- key distribution: centralized key distribution is a security nightmare and web-of-trust exposes the whole social graph... i guess that's another area where we have to innovate?
I only use single serving server salt hashing for authorization and identification. It requires two requests but it's secure for login and most importantly it's simple enough to implement in javascript.
client --- server
salt? -> -> generate salt
hash(pass+salt) <- <- salt
-"- -> -> verify hash
done <- <- auth
Congratulations, if I'm not mistaken you just defeated the entire purpose of hashing passwords.
The point is that the server doesn't store what's used to verify directly, it needs to provide something that can generate it. The way you're doing it, someone can dump your DB and login as anyone. If you want a secure way to do this maybe look into SRP or similar PAKE protocols.
This is why you shouldn't "innovate" with encryption unless you are a trained cryptographer (or equivalent). Cryptographers may be programmers, but programmers are not cryptographers.
But it seems it wasn't obvious to bullen that this way the password is essentially sent in plain text. So yes, let your authentication be analyzed by an expert or use standard software.
Just to be clear with you, the mistake here is that the salt is being generated. This means that you are not storing H(salt, pass) in your DB but probably something that is “password-like,” in that if you know it you can log in as that user.
In a more secure auth flow you instead have:
Request 1:
-> Can I get a login CSRF token for `crdrost`?
- generate random string and store on the users table with an exp date
<- Sure here is a login token
Request 2:
-> Here is my token and my plaintext password. (!)
- Users table: select CSRF token, salt, KDF(salt, pass) previously computed
- compute KDF(salt, pass), compare with previous computation
- generate session token
<- Sure here is your session token
In terms of KDFs you might use Blowfish or PBKDF2 or Scrypt or more recently Argon2, you can also HMAC or hash-concat if you have strong enough complexity requirements that you are not worried about brute force attacks, e.g. “when you sign up I will generate a random password for you.”
The remaining security vulnerability is typically that you accidentally auto-log plaintext passwords so this requires vigilance around that.
But the point is that at no time does the database store anything which can be used to complete a login. Suppose I do the KDF on the client side, then its output is “password-like” and if I know that output by reading a row accidentally from the users table, I can log in as that user. Similarly by overhearing an HTTP login over WiFi, I can log in as that user.
Similarly you have a “challenge/response” system because you don't want plaintext passwords to even make it to the API, this is a noble aim but it absolutely requires public key crypto to be done correctly: you store a public key derived from the private key; login page uses password to generate private key and then signs a request to sign in, you confirm the signature with the public key. A full scheme, so that you are not rolling your own crypto, is described by the Secure Remote Password protocol.
The security risks there are just that the process has become very complex and complex things are easier to get wrong.
Yeah I mean that comment is about achieving challenge/response without storing something password-like; obviously a non-challenge/response login is not going to be a counterexample.
While CR does not need the full force of public key crypto it has properties which require a distinctive subset of those features in this context—I want to be able to take a password and derive two values (K, V) such that g(V, f(K, s)) = h(V, s) for some large family of s'es, but f(K, s) cannot be computed as j(V, s) efficiently. Public key crypto is more or less the case where h(V, s) = s, giving an option to maybe do something interesting when h is nontrivial.
[Just to give an example that I should have given yesterday for anyone who finds this in the future, in particular if you omit some of the safeguards of SRP then the “core” of it has h(V, s) = V^s (mod N) for some N and in some sense it is not doing full public key crypto but rather the seemingly-weaker subset that is Diffie-Hellman key exchange. But of course then ElGamal came and proved that at the core of Diffie-Hellman you can find a public key crypto algorithm so they are clearly very strongly related to each other even if this doesn't need to use the full force of it.]
Yes, the server also knows the "pass" (can be salted hash if you wish, I use hash(pass+name) but it doesn't change the usefulness of this simple auth) and verifies the hash by re-hashing and comparing. Edit: Sad that most people misses the forest for all the trees, should have called pass secr. instead.
Even if you used a pre-hashed (well, preferably key derived using scrypt, argon2, etc) password, the problem is that if an attacker dumped your database they can still login to every account on your system without the original password.
To perform a full challenge response system, you'd need to get some public key crypto going, be that deriving ed25519 keys on the client or going to a full PAKE algorithm like SRP. Anything short of that means your challenge response is going to prove almost as bad as clear text if an attacker steals the secrets.
Sure, if the servers are compromised, they are compromised. So you prefer more complexity in your auth; so that something that should not happen, can happen? Simplicity is important.
Congrats, you have been proposed for this years "Plaintext Password Award", the trophy that every industry professional despises but somehow many still manage to obtain one!
I think the only places we may see support are newer Fediverse servers like Mastodon, Pleroma, Pixelfed, et. al.
Here's my previous article on OpenID:
https://penguindreams.org/blog/the-decline-of-openid/