Is there no better way?
This post was inspired by this comment of @orthwyrm:
Can confirm this works. I'm not sure what stops the issuer from using your Mullvad token, though.
Nothing stops the issuer from using your Mullvad token. But at least they give you the option to just buy a voucher.
However, I think it's bad to even give people the option to enter their Mullvad token. This just reinforces already existing bad habits when it comes to security (online).
But this is imo very similar to how authentication on nostr clients usually works. They just straight up ask for your nsec. As if that's not the wet dream of any phishing site. Phishing sites can now just ask you to enter your private key and this wouldn't even raise suspicion. Since apparently, "that's just how things are".
But I believe there is a better way. At least for the login, you could use Challenge-Response Authentication:
In computer security, challenge–response authentication is a family of protocols in which one party presents a question ("challenge") and another party must provide a valid answer ("response") to be authenticated.
The simplest example of a challenge–response protocol is password authentication, where the challenge is asking for the password and the valid response is the correct password.
An adversary who can eavesdrop on a password authentication can then authenticate itself by reusing the intercepted password. One solution is to issue multiple passwords, each of them marked with an identifier. The verifier can then present an identifier, and the prover must respond with the correct password for that identifier. Assuming that the passwords are chosen independently, an adversary who intercepts one challenge–response message pair has no clues to help with a different challenge at a different time.
That's also how SN does it. We just make you sign an event (which includes a timestamp) and then verify that this event was signed by the private key belonging to the included public key. If that's the case, great, we verified that you indeed own the corresponding private key.
So I don't really understand why that's not the standard. Because there isn't an easy to use library out there? Then my question would be: Why isn't there one? Nostr is already at least one year old!
And I would consider my digital identity to be similar important as my bitcoin private keys.
Identity theft is nothing to joke about. But why does it seem like the nostr space doesn't take security or encryption serious?
I guess the answer is something along these lines:
Because it's convenient and some people might not have a nostr signer extension installed. Also, it's not only for authentication but also for creating posts and more. How would that work for people without a nostr signer extension?
Oh well then, missing adoption of nostr signer extensions is not going to change if you keep accepting nsec keys.
Sorry not sorry for the rant.
I mentioned in a thread the other day how we're white-boarding authentication for like the 5th time for Lightning.Video - It's a tough problem.
Decentralized tech becomes pointless if you depend on existing authentication systems and patterns... but we also can't onboard the masses with easy to fuck-up key pasting or extensions that expose your entire browser storage and don't work on mobile.
It's not a new problem for Bitcoin/Nostr either, grizzled old *nix administrators still manage SSH keys in convoluted ways, and we've had since the dawn of computing basically to figure that out.
The most promising thing I see out there now, and we'll be working on moving to, is something based on nsecBunker (h/t Pablof7z)
Bunker is a service you can either host yourself or have hosted, and works kind of like a browser extension in signing events and keeping the key away from apps, but does so remotely by wire which solves the countless issues present with extensions.
Mainstream users could still use conventional email auth with a bunker service, and the flow for using new apps would be similar to OAuth patterns.
It'll be custodial for most people, but the important thing is it's trivially self-hostable and portable, which should keep it far more decentralized and permission-less than Google/FB/Apple Auth.
I'm hoping that with some attention to this we'll finally be able to bring users into these apps that aren't otherwise willing or able to deal with handling private keys.
reply
It'll be custodial for most people, but the important thing is it's trivially self-hostable and portable, which should keep it far more decentralized and permission-less than Google/FB/Apple Auth.
I agree. I think the biggest problem with custodial services is not that they are custodial, but that they lock users in. So as long as it's trivially self-hostable and portable (as you mentioned), it's a good way to onboard new users.
reply
they think their clients are so good they can ask for my nsec… they arent.
reply
Yes I was on nostr before I discovered SN and signing in to SN just using your qr code from your Ln wallet was amazing 👏
I use amethyst and you must use nsec to log in
I agree, nos2x is what I use as a security signer and works great, it should be an option
reply
Btw, I really like the idea of nostr and I see great potential in it. Saying this before anyone thinks I am just writing this because "SN is competing with nostr". I am not.
I am writing this because I want to believe in nostr but sometimes, it gets really hard.
The combination of bitcoin as a network for value and nostr as a network for identity sounds very promising.
But sometimes, it feels we're building identity theft in a honeypot disguised as a SaaS product and not a "decentralized, truly censorship-resistant open protocol".
Even @fiatjaf openly claims that he would like to fork the NIPs and while searching the note about this, I even found this note:
Cryptography is only needed in Nostr because relays are many and not just one. The relay infrastructure precedes the need for keys.
Maybe this is obvious, but just in case.
That's another indicator that nostriches really don't take cryptography serious like this comment in the NIP-44 PR about a note from @jb55:
You’ve mentioned “We now have more breakage between clients though. yay?” - seemed like a complaint. 🤷‍♂️
As for your question “how does it reduce metadata leakage”, the answer is simple: padding helps a lot, esp with small messages.
before it was “yes” => 3b ciphertext, which is really bad.
Can’t reply on nostr, because my client doesn’t see your post there
And apparently, nostr.com also still sees nostr mainly to be about social networks:
A decentralized social network with a chance of working Learn about Nostr: A simple, open protocol that enables a truly censorship-resistant and global social network.
Imho, continuing to advertise nostr like this is stifling innovation in the space.
reply