Oddbean new post about login | logout password managers generate a unique password for each website. this means if one of your passwords leaks it won't compromise any of your other website logins. nostr-login is a regression: if you leak your nsec then they have access to every website that you've ever logged in to. using your npub for logging into everything is a really bad idea security wise, please be conscious of this before implementing or pushing this as a login solution to websites which may contain sensitive information.
Useful thought! And it seemed to me the convenience of logging in with Google addresses. 😮💨
Convenience is the enemy of security. Using Google as SSO is not great but at least you can reset your password with Google. If you NSec is leaked you are screwed.
Considering this context, it is.
That's why I don't use nostr tools that don't let me login with my nostr extension. My nostr extension is my password manager.
If your nsec is leaked, then they will be able to impersonate you forever and you would need to create a whole new account. There is no way of blocking them out….your account is DONE!
It's a good approach, actually your private key acts as the master key of a password manager, when you 'login' with NIP07 for example, actually this apps only gets your public data, the ones published in multiple relays. The debate is not whether or not to use your nostr identity to login, I think this is fine, but how to properly guard your private key. This is sometimes as valuable as a BTC private key. Sovereignty is uncomfortable, I see it as a trilemma between sovereignty, simplicity and security.
It’s even harder than BTC private key protection because the moment you suspect that your BTC key is leaked, you can transfer remaining fund to another key. This is achievable because BTC requires global strong consistency. Nostr trades consistency with availability by design so that it’s impossible to transfer the ownership of events. This problem is just so damn hard.
Yes, subkeys fixes this
yeah, deprecating everyone’s identity is kind of a bitch though
Dont need to deprecate. But I see what you mean, re inconsistent UX. You can have apps that take advantage of it, and apps that dont. Ultimately nostr is permissionless dev, so some apps do some things, others do other things. Client/client standards can only go so far, at some point, when functionality is needed.
I guess it depends on the proposal, i haven’t seen a convincing one yet
How do we solve this for wider adoption?
We have to decide if logging in with nostr is a desire-able thing to have. The ecosystem seems to be moving to passkeys, i don’t see why we necessarily need npub identities for login. There are many reasons you wouldn’t want that: privacy, etc.
Logging in with nostr was a big plus for me but I’m not a normal use case.
What are passkeys?
https://developer.apple.com/passkeys/ https://developers.google.com/identity/passkeys https://blog.google/technology/safety-security/the-beginning-of-the-end-of-the-password/
So a private key is stored locally on device and the corresponding public key is stored in the server. That’s pretty much just Nostr sign-in. The only difference is that passkey approach generates a new key for every app. It’s like using a different private key for every nostr client.
Sounds like a massive difference. A compromised nsec would be catastrophic.
Yes. This discussion has changed my attitude towards Nostr Signin/Connect
They’re login tokens that are encrypted on your device and tied to a master identity.
Passkeys are utter trash in implementation but the underlying concept is good npub login is flawed because it can’t support multi identity and is non-private by design
And also they don’t use obscure shit like BIP304 signatures so they can be put onto a secure element
All the "hardware wallet" implementations for Bitcoin show that you can make a secure element for BIP340 just fine.
Specialized SEs != TPMs in computers, SEs in phones, etc
BIP340 are Schnorr signatures? From: https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part-1-Architecture-01.07-2014-03-13.pdf Section: C.4.3 EC Schnorr "If a TPM supports ECC, it should support the TPM_ALG_ECSCHNORR scheme."
Would subkeys also allow for key rotation? Seems like if you’re going to soft-fork nostr, it better be for a 10x better solution. Just include all the key upgrades at once
Yes, to key rotation. Not a soft fork, just a NIP. Opt-in. Just like HD wallets were opt-in on bitcoin. Nostr is not that centralized, that adding functionality requires a soft-fork, imho.
If half the clients adopt the NIP and half don’t, that’s basically a fork in the network. But the number of clients is small enough that a reset wouldn’t be that bad imo. Worth doing while the network is still young. Especially lack of key rotation needs to be tackled sooner
It's not a fork in the network, because the network of relays remains the same, and all events are both standard, and according to consensus. It's a fork in the clients, not the network. But nostr is exactly designed to have diversity of clients.
I used the term “fork” in a tongue in cheek way. I have been on nostr as long as you Melvin 😂 But the point stands that the user experience is equivalent to a “fork”, yes. The user experience would be split between two incompatible key management NIPs. As mentioned in this thread, it would require a kind of reset for users. But I think it’s worth it because nostr is still quite small and it’s a necessity for growth!
I dont disagree. This is what TimBL refers to as client/client standards, which is what we tried to build into Solid. The client/client standards suffer from the weakness that first movers get an advantage and that technical debt gets ossified quickly. 2+ different key management solutions (which is where we're heading btw) would indeed be indistinguishable from a fork for the end user perspective. The NIPs are a bit of a war zone, too centralzied, and it's hard to get people to agree on something. So we are going to have this problem in any case. If you zoom out, though, there are likely to be a first gen of clients, and a next gen of clients. Subkeys are a simple non intrusive addition. Just add a subkey array to your profile or to your nip-05, and then use that key, and signal to clients provably that it's part of your master key. Those that accept it can, those that dont want to, dont have to. IMHO the only way to do it is a full solution that has full version control anchored in the time chain, but we are a long way from that. Not just nostr, every social project needs this.
I’m in favor of doing the hard thing for the greater benefit in the future. And tbh maybe your solution doesn’t even go far enough. Why not the full pki? Let’s die on a hill worth dying on 😂
It is. Full PKI + version control + time chain.
Every person will have three #nostr IDs - Work ( issued by employer) - Social ( One used for Damus Likes) - Personal ( or pivate) - for money and health and ... 21 Billion .. for hacking of personal - a user can generate as many npubs as they like .. So why password generators ?
This is also ~pretty much true of all single-sign-on schemes like Apple/Google's. I've been annoyed for a long time that logging into YouTube on a device also technically logs me into Gmail. Unique sites should get their own unique secrets.
THIS!
this is what I was actually asking chatgpt all day and it's sucks that they aren't any solution for this
What if we use OIDC. You're building your app and you want to allow nostr login. Your app uses OIDC via a nostr ID provider. This nostr ID provider connects with an app you have on your phone which is where your nsec is. Whenever you click "login with nostr" the nostr app uses OIDC and pings the nostr ID provider. Nostr ID provider then provides a NIP-97 auth URI back to the nostr app. Nostr app displays this URI as a QR code. Using the app on your phone, you scan this QR code. This will then prompt you to confirm you want to log into this site, and even what info you'd like to share with this site. All your personal info is stored only locally on device in the app and you could even create different profiles for different sites. Once you confirm, your app sends that in the form of NIP-97 auth message to nostr ID provider. Nostr ID provider then creates session token, refresh token and ID token and gives it back to nostr app. Voila you're logged in and you never had to enter your nsec anywhere.
🤔 people still use oidc ? Interesting idea, Will have to dedicate some cycles to think about this later
there is openid which no one uses and there is openid connect which is basically a majority of enterprise implementations along with SAML unfortunately no what you are saying used openid not openid connect and a “nostr identity provider” defeats the entire point since you can just use passkeys or the npub directly depending on need
Why would it defeat the point entirely? The nostr ID provider gives the nostr app a session token, refresh token and ID token so that you don't continuously have to log in everytime you click a button on the page.
what do you need a refresh token for if you are getting an npub once how do you trust the ID provider
Refresh token so you don't need to log in every 15 minutes (because session token should not be long lived). There isn't much trusting to do with the ID provider. You have to trust that the software works. It's like using the "login with Google" or "login with Facebook" buttons. They also use OIDC. In those cases, you have to trust them with your personal info. With this nostr ID provider, you hold the personal info on your device. We can maybe have some sort of encryption scheme between the nostr app and your phone app to make sure the info doesn't leak in transit. And tbh so far nostr apps have asked for your name, username, maybe an email. You can always enter fake or burner info in your device app so that nostr ID provider gets nothing. Its a very low trust system IMO.
please read up on what a refresh token is for
Lol I know what it's for. I don't think you're following this convo.
OAuth/OIDC flows are perfect for this, no need to reinvent the wheel and OIDC support in libraries/frameworks is pretty solid these days. Which makes integrating this in apps quiet easy I suppose if you can expose OIDC compliant "nsec bunker" endpoints.
What if . . . or I should say when someone starts trying random nsecs to see which accounts they can hijack? That'll be fun.
it's enough to leak your Email password and all your other website passwords will be changed.
Its a bit better than using a single password, since that password gets stored on many server side databases with varying security. At least with your nsec, it never gets sent over the internet to a server. It stays on your computer. Still a bad idea to use it to log into everything though.
We've needed a master/slave system for npubs for a while now. This just further reinforces it. In case you don't know what I mean, you have your daily use npub(s) the nsec(s) of which will often be on hot devices, and then you have an npub the nsec of which is a cold key treated with the same security as cold storage. The hot keys post a metadata note that identifies the cold npub as a master. Then should the cold npub post a note that declares one of the hot npubs burned, the participating relays reject all notes from that npub. The relays/clients could also assist in redirecting follows to a replacement npub identified by a note from the master. Such a system could drastically increase redundancy as well as allow hierarchical structures , but might have holes I haven't thought of.
Can we do something like derived keys? I know not much about cryptography. But would be cool if we could generate child keypairs from a master keypair. And you can somehow revoke/cancel a leaked child key by providing a new child key of the same parent/master.
people always propose this like an obvious and easy thing, but when you get into the weeds its not. How does querying work? Delegation was something like this, but nostr devs deprecated it because they claimed the query complexity was too high. you had to not only look up a single key, but look up N keys for every possible child key that was used for a users profile. I personally thought delegation solved it elegantly, as it’s the only way i can think of querying actually working in a multi-key setup, and it doesn’t require clients to change anything to make it work.
Yeah honestly I haven’t thought it through or looked at the old delegation implementation. Was just the first thing in my head, so posed the question. In a state full central database it’s doable but in nostr it’s way more complicated. Poopies…
The npub should only serve as something to identify you. To actually login you should sign a message with your private key. Some kind of extension perhaps. Password managers also have a single point of failure which is the password to get in the manager.
lud04 handled that well. A new private/pubkey was derived by the wallet for each domain you logged into. Since an npub is more like an identity than an identifier if you have concerns you can generate or derive a new npub for each site you log into.
Thoughts on revokable single-use passwords tied to your nsec? Create it, use it, you’re logged in until you log out, revoke it, or the cookie expires. Create a new one to log in next time. All tied to your nsec, without revealing it. There’s lots of shit wrong with Bluesky, but this feature is something they did very right.
We need deriviative keys.
yes but how do you maintain identity???
Main npub could sign for valid derived keys and invalidated ones via an event?
what if your password manager database leaks?
this has never happened before...oh wait
I don't see how it's any different from a password manager. You don't give your nsec to every service, you just use it to authenticate your identity. Yes if you get your master key compromised you are pwned but that's literally the same as having your password manager vault compromised.
Difference is people put their nsec into many different apps
Ah I misunderstood. Pasting nsec itself is bad, of course 👍
We really need something like PKI for nostr. Assuming one would even want to link their identities.
Wasn't there a whole NIP for delegation keys that got abandoned? I don't know why that one got abandoned seems like a good idea to be able to spin off subkey from your main and use those for login. nostr:nevent1qqszzfcz45pzkjyc2u6qj80h2ngfvpue0c4tanjnqqagsvethen4mrqpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsr9cvzwc652r4m83d86ykplrnm9dg5gwdvzzn8ameanlvut35wy3grqsqqqqqph2lpk7
Passwordless.