For example, the Client stores information in self.state2nonce and uses that later to validate that the nonce did not change - and if it's not present, that check is silently skipped. Does this have security implications? Honestly, I don't know.
The client example in the docs does store state and nonce in the session, but never reads back the nonce...
Except for very small applications where you only have a single process/thread, chances are good that a webapp using this library runs on multiple servers or simply with multiple processes - so different Client instances will generate the request and process it, resulting in no match in state2nonce. Does this result in a security risk? Again, I don't know, and I think when just using the library I shouldn't need to know it (the whole point of a library like this is to not have to know all the details of the protocol).
It would be nice if there was clear documentation on what kind of persistent internal state the Client stores, and whether it's safe to reuse a Client or if it's better to create a new Client whenever you want to authenticate a user.
Also, I think it would be nice if there was some documentation on what a user of the library needs to validate or simply be explicit, e.g. requiring you to pass the original nonce to the function that validates it instead of relying on something stored within the Client. That way you are forced to keep track of it (e.g. using a session) and passing it back, instead of silently skipping a check that might be important.
For example, the Client stores information in
self.state2nonceand uses that later to validate that the nonce did not change - and if it's not present, that check is silently skipped. Does this have security implications? Honestly, I don't know.The client example in the docs does store state and nonce in the session, but never reads back the nonce...
Except for very small applications where you only have a single process/thread, chances are good that a webapp using this library runs on multiple servers or simply with multiple processes - so different Client instances will generate the request and process it, resulting in no match in
state2nonce. Does this result in a security risk? Again, I don't know, and I think when just using the library I shouldn't need to know it (the whole point of a library like this is to not have to know all the details of the protocol).It would be nice if there was clear documentation on what kind of persistent internal state the Client stores, and whether it's safe to reuse a Client or if it's better to create a new Client whenever you want to authenticate a user.
Also, I think it would be nice if there was some documentation on what a user of the library needs to validate or simply be explicit, e.g. requiring you to pass the original nonce to the function that validates it instead of relying on something stored within the Client. That way you are forced to keep track of it (e.g. using a session) and passing it back, instead of silently skipping a check that might be important.