pyauth / pyotp

Python One-Time Password Library
https://pyauth.github.io/pyotp/
Other
3.03k stars 326 forks source link

Can you help me understand the secret please? #70

Closed ghost closed 6 years ago

ghost commented 6 years ago

Your documentation suggest using qrious - this is fine and works well.

The thing that puzzles me is that the provisioning URI contains the secret key, and yet we send this URI to the client end to be turned into a QR code by qrious. So the secret key isn't secret because it has been sent to the client.

I would have expected that the secret key must never be sent out of the back end - what am I failing to understand?

thanks

tilkinsc commented 6 years ago

Also, check out QRCoder (C#)

Here is the flow:

  1. A base32 string is generated randomly
  2. It is agreed upon by all clients to use it and the generator transfers it via plain text or qr code scanning to said clients
  3. Numbers are generated based on a truncated hmac'd version, time, etc on the unbase32 version of the string
  4. Numbers are agreed upon by the unreversable truncated hmac

So basically as long as your base32 string doesn't get sniffed from the get go, you are fine.

ghost commented 6 years ago

Am I correct in understanding that:

kislyuk commented 6 years ago

@bootrino your interpretation is correct. HOTP and TOTP are based on a shared secret. Keeping the secret confidential between your application and the user's user agent is your responsibility as the application developer (and is typically done via HTTPS as you mention).

You can find a detailed discussion of the shared secret strategy in https://tools.ietf.org/html/rfc4226#section-7.5. This design element is shared between TOTP and HOTP.

Because of the shared secret design, TOTP and HOTP are fundamentally less secure than FIDO U2F and other standards derived from it.

kislyuk commented 6 years ago

Closing this issue, but feel free to comment if you need further clarification.