Websites are much easier if they allow the use of nip-07. You don’t need to worry that much honestly.
But iOS apps it’s kinda risky, last year we went through the ZBD fiasco, who knows if many of us got compromised nsecs.
Discussion
There are 3 types of login: a nsec, an extension and a seed phrase. We offer all three, but from a security perspective, I want to have confidence and I want users to have confidence that all are secure.
nostr:npub16v82nr4xt62nlydtj0mtxr49r6enc5r0sl2f7cq2zwdw7q92j5gs8meqha would like your perspective on how we can improve both security and confidence🤔
I haven't surveyed what's out there (beyond what I saw on nostr.cooking) but the first thing that comes to mind is the website issues a challenge (e.g. a 32-byte long random number) and the user has to post that to a relay. If they can do so, the website knows the user controls the keys and can authenticate that session.
This challenge would need to include the site you are logging into, otherwise I could pass along a challenge for nostr.cooking and tell the user this challenge is for my site (which it would be, but then I could tell nostr.cooking that I signed the thing so I should be authenticated).
With the FQDN in there, when I hand a challenge to a user that says the FQDN is nostr.cooking, they should know I'm trying to scam them and refuse to post.
The upshot is that the user only provides their npub, the URL for a relay they're going post to, and the post.
This is basically how FIDO2 works, so if you think this sounds like a good system, give them the credit. I just read the spec, wrote some little implementations of it, and can vouch that it seems solid.
