Database use
Closed this issue · 2 comments
Question regarding the database, specifically in the perl implementation. When the client responds by posting the decrypted token and keyid, the server is supposed to make sure the corresponding token in the db for that keyid matches, correct me if I'm wrong. Right now the perl code just selects based on keyid, and never verifies the token (index.pl: line 219). Basically if it finds an entry, it sets headers to authenticated. I think we need to confirm the token matches right? Otherwise a client can get their keyid in the db, and respond incorrectly to the challenge by providing any plaintext token, but will still be authenticated.
Let me know if I'm way out in left field here.
Nope you're absolutely correct.
I did this on purpose to play around with what actually constitutes an authenticated user.
One situation could be that I want to personalize my site to public/anonymous people. I offer the gpgauth headers on my site, and if someone responds with a keyid, I can now look up their public key and display there real name on my site. This corresponds to how I implemented the perl database -- any user is added into the database permantly (actually it should be that the database is only used to track the nonce for auth -- as soon as auth succeeds/fails delete the user from the db).
Another situation is where you want only users that are registered to be able to log in -- al a the php db implementation that has a strict whitelist for users.
Honestly there is no right answer because there are many use cases for our system. At any rate this should probably be abstracted away so we can choose from multiple authentication contexts.
No worries, I did notice the username etc, and that made sense. Agree it should be abstracted. I just wanted to make sure you weren't assuming that because keyid was in db that user was authenticated.