I usually try to be more responsive than this, but I'm currently caught up in a flurry of work-related activity getting ready for a product update, and it's threatening to take up my whole week.
As soon as the air clears on that, I'm hoping to do a big push on getting Passlib 1.7 out the door (I was planning on doing that back in July... and not sure where the time went!)
The offer to help is great! Good news -- the code is pretty close to complete already. The main thing two things that need doing are 1) writing tutorial on how to use the new TOTP code (might not be easy to delegate, I just need to buckle down and do it); and 2) have the code get some real-world beta testing outside of my own software.
I'm going to make myself start in on the tutorial later this week; but there's already some rough api documentation (
http://passlib.readthedocs.io/en/latest/lib/passlib.totp.html). If you wanted to go ahead and check out a copy of the passlib default branch, and start trying to integrate it into your codebase, I'll love feedback on the design, as well as any bug reports/fixes.
I know integration might not be that easy without a tutorial explaining how all the bits fit together -- but the "passlib.totp.TOTP" class is a good place to start. The ".to_uri()" method can be used to generate something suitable for qrcode, the ".consume()" method handles verifying tokens on the server side, and ".from_json" / ".to_json" handle serializing the server-side state of the TOTP object between uses.
Let me know if you have any questions, etc!
P.S. - I appear to have some uncommitted bits that change the totp API around a little bit, which I'll try to get committed by tomorrow.
P.S. #2 - One small bit that isn't quite done in the TOTP code is server-side estimation of the client's clock skew. I've got *something* implemented, but it could use improving. If you happened to know of a good algorithm that'd be great -- or a good set of realworld (timestamp, token skew) data pairs that I have the unittests chew on.
- Eli