Handling users private keys etc

Programming NodeJS
1

Hi,

I’m a ActivityOub noob and also relatively new to nodejs/express/mongodb. I’ve only been at it a few days, but I can already use Mastadon to find/follow myself myself on my custom server - great fun!

Anyway, I’m working on the user DB model, and wondering what the best way to handle logins, public/private crypto keys etc is. I want the server to handle multiple users, allow users to register/login etc.

I have done simple web-based user handling stuff in the past (in PHP) and remember using plain text passwords which were ‘salted’ before being stored in the DB.

However things are a bit more complex with ActivityPub as I also need to deal with RSA encryption. One approach I can think of that would at least work (always a good starting point!) would be:

  • When user creates an account in browser, password is passed to server as plaintext and stored in server DB after being ‘salted’. Cookies store plain text password. This is pretty awful now that I think about it, but it was pretty much what everyone was doing in the early 2k’s!

  • Server generates per user private/public keys using the crypto module which are both stored in DB along with other user info.

However, storing private key in DB sounds dodgy - the point of ‘salting’ plain passwords was preventing against passwords getting leaked if DB was cracked - leaking private rsa keys sounds even worse!

Where are private ‘per user’ rsa keys generally stored on ActivityPub servers?

Another approach would be to generate keys in the client, forward public key to server and have client do all message encryption - but how is private key then stored, in localStorage? And what happens with multiple browsers?

Bye!
Mark

2

With AP as deployed today, the server needs a private key, because it needs the ability to sign outgoing HTTP requests when the client isn’t connected (eg retransmissions, automatically generated Accept/Follows, deletions triggered by admins/moderators).

FEP-ae97 proposes a way to do client-side signing, but it’s very new, and solves a slightly different set of problems.

Personally I keep the private keys in files in the file system. I’m not sure this is any better than putting them in the DB, though.

1 Like
3

Hi Mark.

Just to make sure we are all on the same page:

  • Private keys currently used in the Fediverse belong to the servers and not to the user. Usage of these keys means that the server is doing something on the user’s behalf.
  • If one wants to do user signed stuff, one should use keys that are differently designated. I would currently go so far in saying that the identity infrastructure to do user signing will be different from the one used to do server to server communication. At least for me these are different conceptual levels.
  • Storing these keys needs to be given the same general consideration as storing credentials used by the server, e.g. the database password. There all kinds of ways to do it. For small installations: Just plain text is enough. Once you start scaling to multiple servers running an instance, proper care is needed. I have no idea what people running the big instances do.
2 Likes