What is Nostr?
hodlbod /
npub1jlr…ynqn
2024-12-05 18:12:38

hodlbod on Nostr: Thinking about email/password login further, here's a different approach: Instead of ...

Thinking about email/password login further, here's a different approach:

Instead of encrypting at rest using a server key, what if the server never saw the key at all? Instead, the user would simply authenticate with the server, and retrieve an ncryptsec.

To avoid using the same password for the ncryptsec and the server authentication (since that would allow the server to decrypt the ncryptsec), the client could instead send the hash of the user's password to the server. (This would allow the user to avoid remembering two different passwords).

This would put key storage back on the client which comes with its own attendant risks, and benefits.

Is this better or worse than my other design?

nostr:
RFC on a new custodial signer I'm building. Highlights:

- Designed to be used with a single app rather than following the user around.
- Has email-based registration/reset workflows.
- Provides a signer/relay combo, reducing nip46 latency.
- Encourages users to "eject", which sends them an email with their ncryptsec, and deletes their account from the database.

The goal is to limit incentives for attackers to steal keys. The keys are only used for a single application, only keys for that application are stored, and the application eagerly deletes keys from the database. Keys are encrypted at rest.

Here's a demo video:



And the source code:

https://github.com/coracle-social/burrow
Author Public Key
npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn