I have a security question as someone that doesn't know things 

Say I have a client that has a keypair. This keypair is the user's identity. The client will need to make various authenticated requests to the server. Would it be considered secure to:

* Upon registration with the server, the server generates some long random string and encrypts it with the client's public key which the client then decrypts and sends back to prove it controls the keypair and so is who it says it is.
* This random string is then used as the auth token for all requests by the client.

Like, on the one hand, this feels like the same kind of thing that's done with other stuff to remember logins. But on the other hand, something about exactly the same string being used for extremely long periods of time seems a bit sus (for lack of a better term).

Would doing that but having this string be automatically renewed periodically be the best idea?

Or is all of this terrible security and I should do something completely different? (if so what?)

All this remembering that I do not know things.

· · Web · 2 · 0 · 2

I have a security question as someone that doesn't know things 

@miramira what is the underlying transport, and what is the exact scenario?

Generally inventing your own security protocols is a bad idea, and for example https has built-in client authentication with client certificates (it negotiates a temporary session key using Diffie-Hellman algorithm btw), why is it not applicable in your case?

I have a security question as someone that doesn't know things 

@IngaLovinde Ooh, was not aware of that client authentication. That's probably gonna be the best option. My understanding of http only went as far as each request being completely distinct from any others, so I thought I'd need some persistent data in all of them to say "hello yes this is me".

re: I have a security question as someone that doesn't know things 

@miramira even if connections were not reused, client certificate is a way of saying "this is me" in case of HTTPS, just like the server says "this is me" with its server certificate :)

(in TLS which is a transport layer for HTTPS there is some sort of negotiation going on, when both sides present their certificates, then agree on a common session key, and only after that the actual HTTP request is made; but both the client and the server are still aware of each other identities associated with this request)

re: I have a security question as someone that doesn't know things 

@IngaLovinde Ah ok, so more broadly: if the client has a certificate that is its identity, would this then be reasonable:

* Have e.g. some /register endpoint that'll have the server associate the profile provided with the certificate and remember that this user exists and other information. It would obviously fail if the cert had already been registered.
* In all other requests, the server checks the client cert and uses that to identify the user so e.g. sending a message shows up with the correct username if this was a chat program for example.

Though this would rely on the client cert being directly accessible from each request right?

re: I have a security question as someone that doesn't know things 

@miramira yes, if requests are coming from the browser, the user would have to install that certificate into their system or browser certificate/key storage. That's why I asked you about the scenario :)

(If the client is a standalone application, the application can manage certificates by itself)

Oh, and the bonus point, certificates can also be stored on smart cards etc, with private key never leaving the card (in which case the card itself would do all the encryption and signing)!

And if your question is whether client will have to do some certificate-related operations on every request: it won't in case you use websockets for example (which is a long-living connection that could be used to send multiple requests and get multiple responses or push events over days)

re: I have a security question as someone that doesn't know things 

@miramira @IngaLovinde Client certs are AWESOME and completely underused. Something to note tho:

- The endpoint or termination for TLS authentication is probably your webserver or load balancer. It can conditionally set a HTTP header sent with the reverse proxy request to your application and the application needs to 'trust' that the webserver or anyone in between (which is why unix sockets or localhost is important) didn't spoof it.

- nginx would for example forward this variable as a header: $ssl_client_fingerprint
which is the unique fingerprint of the client certificate which can be used to associate that TLS session with a user with the same fingerprint in your applications database.

- PKI is not an easy feat and has a lot of depth. In simplest terms, you need to build your own Certificate Authority and sign certificate requests with it to issue certificates to clients that can be used for client authentication (specific feature/usage flag).
Then tell the TLS endpoint (webserver/loadbalancer) to use this CA to authenticate clients.
Browsers can do key generation but I haven't looked in to how to issue certificates with an webapp yet. I use a tool called XCA ( to manually create certs for myself and my servers.

Client private keys should never leave the client. Clients send a certificate request which the CA can choose to sign and issue a certificate for which the client can then download.

Mostly anything that uses TLS can support client authentication but it must be explicitly implemented and it's not entirely easy to get it right.

re: I have a security question as someone that doesn't know things 

@Luna @IngaLovinde Ah, yeah this sounds far more complicated than I was expecting.

Immediate issue I'm seeing is the need for a CA. Because the client would be using the same identifier on multiple distinct servers, the only "central" part anywhere in the cert's use would be the client itself and that would mean going self-signed and I don't know to what extent that would/wouldn't work.

That plus wanting to be able to import/export the identifier so the user can "login" from multiple clients/devices.

On that 2nd point I do wonder about the security implications of making the identifier derivable a priori so you're not having to move files around.

The 2 goals I have are basically:
1: be secure enough for a user that would be sharing potentially personal/intimate information but that won't be being targeted by someone that knows what they're doing i.e. average person on a chat program. Also like you can make your client authentication basically impenetrable but message logs will be unencrypted on the server so making it more secure than the server itself isn't gonna help.
2: be as accessible to implement as possible else writing new servers/clients becomes too hard and you get unwanted centralisation in software selection.

re: I have a security question as someone that doesn't know things 

@miramira @Luna I'm not sure why would one need a CA to do that? Self-signed certificates should do just as well.

But even with CA, you might want to identify client by their public key rather than a certificate, and client could have a certificate signed by several different CAs, or several certificates all signed by different CAs, for the same public key.

For using the service from several devices you might want to consider the following:

* Primary keypair, with public key used to identify an user, probably stored somewhere airgapped or even off the grid (or on smart card etc) for especially paranoid users;
* Secondary keypairs, generated on every device an user wants to use, with every device using a certificate with a relevant secondary public key, signed by primary private key; a certificate would also contain a chain including a primary certificate;
* So that a primary private key is only used to sign secondary certificates, and for nothing more;
* "Register" endpoint would accept connections from users with secondary certificates, but register them under their primary public keys;
* You will probably also need to support the ability to revoke a certificate (in case some device was compromised), so you'll need a "revoke" endpoint that would accept certificate revocation list signed by primary private key.

I have a security question as someone that doesn't know things 

@miramira Security is usually "weaker", as in the server sends a string in plain text and that is used as-is as authentication instead of passwords, often implemented as session cookie. As https sessions are (ephemerally) authenticated and encrypted , it usually provides enough security. A viable alternative are JWT which are server-signed. And as only the server can emit those, those secure as well. 1/2

I have a security question as someone that doesn't know things 

@miramira Even when send over plan http (though you shouldn't, because they are not encrypted). Though both methods presume a prior registration with an alternative authentication (i.e. password). If you need to know users before they contact you, one usually uses a PKCS#12 person certificate, which is basically SSL for users (e.g. Smime (encrypted email) uses this). 2/(oops) 3

I have a security question as someone that doesn't know things 

@miramira Though this requires users register with a chain of trust, just as you need to register you https certificate with a certificate issuing authority. Another alternative (though in it's early stages) is Identity Based Encryption. This allows for bi-directional encryption, without having prior exchanges or either side existing (i.e. you could encrypt something for a user, which does not have an account yet). 3/4

I have a security question as someone that doesn't know things 

@miramira (is it just me or is the character limit getting smaller for each toot?) One disadvantage of IBE is that there is a central authority, which in theory can decrypt everything or authenticate as anybody. 5/5

Sign in to participate in the conversation
is not alive

"are you a boy or a girl?"
"im dead!"