Burrow requires passwords to be at least 12 characters. Sending via email is a form of 2FA, since you need access to the password, and to the email account. That is at the expense of exposing the key to email servers, which you're right, isn't ideal.

Reply to this note

Please Login to reply.

Discussion

couldn't it just be a HTTP GET?

oh never mind i was thinking the "set" side not the "recover" side or ? i'm not sure i understand

I do appricate the resonance with login flows the user might be familiar with but character length doesn't always equate to good entropy.

That's true. But I think it's a well enough understood problem that it is the user's responsibility at this point. Are there user-friendly ways of ensuring high-entropy passwords though? The "at least one number" policies are both obnoxious and ineffective.

The average person's understanding of password strength in the context of a system where the password can be changed later to protect the account. I'm not aware of any user friendly ways. Generate a random 4 word combo for the user that they will probably forget?

That's a good call, encrypting an nsec is a very different thing. Hmmmm

The main problem is that you ask for a password to create the account, I would avoid that and simply use a login via email using a temporary token with a very long session.

When the nsec must be exported, just create a password with some random words to have a good entropy, ask the user to repeat/write it down, and send the email with the ncryptsec.

But I need a password on signup anyway in order to authenticate with the server. Having two passwords seems unnecessarily confusing. Otherwise I like the idea.

Why do you need one password to authenticate with the server? A token sent via email with a 10 minutes expiration is fine. The signup can require only the email and validate the account at the first login (step that usually is necessary anyway).

I was thinking to authenticate further sessions, but you're right, you could do the email login every time, that's fairly familiar.

And the average user has just one device, max two, and don't has any tool to aggressively clear cookies (= sessions), so the need to redo the login should be quite rare.