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.


really good point brother


Useful thought! And it seemed to me the convenience of logging in with Google addresses. 😮💨


:whatthefuck:


紫水晶有一个加密公钥的功能，我觉得这个功能很好


Be careful where you put your nsec in
nostr:nevent1qqszzfcz45pzkjyc2u6qj80h2ngfvpue0c4tanjnqqagsvethen4mrqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygpjuxp8vd29p6ancknaztql3eajk52y8xkppfn7au7elkw9c68zg5psgqqqqqqslp20tu


In time do you envisage a multifactor type solution being integrated into the nostr authentication process?


nostr-login is not using the same password to every website, is using the same identity.

Of course, it's not always desired to do so, and it could also be improved, specially UX-wise.

🫂


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.


Yes, subkeys fixes this


yeah, deprecating everyone’s identity is kind of a bitch though


What are subways?


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?


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.


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/


They’re login tokens that are encrypted on your device and tied to a master identity.


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


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.


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.


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.


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


Onward 🫡

Onward 🫡


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 ?


All the "hardware wallet" implementations for Bitcoin show that you can make a secure element for BIP340 just fine.


Solution: npum manager, generate a new npub for each login


Specialized SEs != TPMs in computers, SEs in phones, etc


Security is a must have borderwall .. the problem is as soon as you build one , you need one more  :-)


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.


Sounds like a massive difference. A compromised nsec would be catastrophic.


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.


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.


Onward 🫡

Onward 🫡


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.


Ah yes correct.


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."


Not if you use 2FA.


could nwc or did help?


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.


Just have many nyms (npubs) managed by a password manager with a master password :-)


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.


Yes. This discussion has changed my attitude towards Nostr Signin/Connect


Eat fresh!


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.


Is there a NIP for a “kill switch” event?
Something that would say “My nsec has been compromised”.
Relays and authentication mechanisms could ignore any further events from this nsec.


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.


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.


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.


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.


nsec needs a 12 word backup
with reset option


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.


but how do you prove that the identity is the source of the new key?

attestations i suppose, but then you start to get into the never-ending problem of inconsistency


2FA doesn't fix using the same factor everywhere else.


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.


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.


Thanks for pointing this out. From the comments it is clear much education on security is needed. Its always tradeoffs but one needs to understand them.


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.


read this thread

@note1d4u4tl72ezsjk72f45zds67nwnkx3zdqhcu9ysthjv9n4gfv880qpn5wxe


fucking legend

fucking legend


We need deriviative keys.


yes but how do you maintain identity???


Yep, that. Great idea.


Main npub could sign for valid derived keys and invalidated ones via an event?


passwords leak because they're stored in a database at each different website

nsecs never leave your device


Consistency is a big problem, events do not broadcast


what if your password manager database leaks?


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…


I thought pablo had invented an oauth-like login method, no?


*stateful


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.


Onward 🫡

Onward 🫡


Child keys should exist sequentially with short periods of overlap between them.

Oh and also delegations are called certificates in the real world so why not stick to the terminology.


Difference is people put their nsec into many different apps


This.


People don't put their nsec into "many different apps". I'm not using nostr logins but don't they use something like nsec.app. Like 1 app for many websites.

I think there's something you haven't understood.


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.


💯 Been saying this since I joined Nostr.

nostr:nevent1qqszzfcz45pzkjyc2u6qj80h2ngfvpue0c4tanjnqqagsvethen4mrqpz9mhxue69uhkummnw3ezuamfdejj7q3qxtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsxpqqqqqqz76q8lr


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 😂


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


:Heart:


Ah I misunderstood. Pasting nsec itself is bad, of course 👍


It is.  Full PKI + version control + time chain.


Passwordless.


That's not practical


HD?


Great post 👍

Great post 👍


this has never happened before...oh wait


We really need something like PKI for nostr. Assuming one would even want to link their identities.


Considering this context, it is.


Hey  - apologies for the late  .. here  ..