So now I’m at the point where I need to work on the authentication part for the stats server code, and I noticed that my plan to use http digest authentication doesn’t work as that requires to store the plaintext password of clients on the server which I’d like to avoid (generally one should only store a hash of the passwords in the authentication backend).
Before going into alternatives let me list a few requirements I have for them:
– don’t require the real password in the auth backend
– don’t transmit the real password unsecured over the network
– must work with only http headers, don’t touch the body in any way
– must be easily scriptable
– preemptive authorization (e.g. send the auth data with the first request)
– should work within a webbrowser
So, what options do I have now? Well, I can’t see a single alternative that fits all requirements (if you know one let me know), the closest is http basic auth, but I really don’t want to send the password over network as almost-plaintext. This lead me to the idea of extending it with gpg-encrypting the password, but that’s not transparent when you use the browser (not that important for the current use case) and more importantly gpg adds about 600 bytes of protocol overhead for encrypted data (without using –armor), with the base64 encoding required for http that’s almost one kilobyte just for a password that originally only had a few bytes.
So, right now I have to select between a rather hackish, inefficient and untested but secure solution and a well-tested, relatively efficient and well-specified but insecure one. What would people prefer here?
Or does anyone know another solution to the problem that satisfies the above requirements? (the first four are hard requirements, the other two I could work around)
5 thoughts on “how to authenticate”
Comments are closed.
well, it would fit the requirements, but I don’t want to force people to use ssl and I’m not sure how it would affect performance. Also slightly complicates the setup and makes debugging on the transport level a little bit more difficult.
But yes, it’s an option that should be evaluated, thanks for reminding me.
I’d say you go with SSL and see if it gives performance issues like you assume(!).
How about utilizing SSL client certificates?
Each of the clients generates a certificate request during installation which is then send to the server to be signed.
The certificate is then send back to the client with an initial password.
This password could either be displayed on a dynamic webpage (whose exact URL is generated by the client before consisting of ~16 random characters … https://genone.server/hgnp9382wacnoasi/) or could be send by email.
The clients can if they like remove the password completely and/or set to one they like more.
On server side it is very easy to block out compromised certificates by simply revoking the affected certs if/when this is needed someday.
Much better than having one password for all clients imho without getting too complicated (openssl is installed on practically every client anyways; needed for creating the CSR).
The whole thing can be used via http, i’d just propose to have the initial password site ‘https-only’ for security reasons (cert stealing).
Oh, it is one user/pass combination per client, and the registration as planned currently is also quite secure, so client certificates don’t give much benefit (if any) but add a lot of complexity (and are likely bigger than gpg encrypted passwords).
s/digest/basic