(ot/get-totp-token secret-key) failing with Github 2fa, any ideas? about one-time HOT 8 CLOSED

Actually it may be something like hmac-sha-type or the nature of the key, I now have a secret key that causes this error: IllegalArgumentException Empty key javax.crypto.spec.SecretKeySpec. (SecretKeySpec.java:96)

from one-time.

Found it. Github prints the secret keys in lower case. While one of those keys parsed fine, the other failed the hmac-digest routine (using both your lib and clj-otp). That was my clue. Doing a (.toUpperCase secret-key) before requesting the token fixed it.

from one-time.

Not sure how you were using this lib with Github 2FA (instead of using the Authenticator apps I'm assuming), but glad to know that it's working for you.
Could you still explain a bit more what you were working on, and where in the flow you were using this lib ?

from one-time.

Turns out to be very simple. When you go to the Github settings to activate 2fa in security, you can click a link for the shared secret (vs. QR codes/urls and other stuff for normal apps).

So I was cutting and pasting the shared secret into my calls to your library. On the first shared secret key I was getting tokens, but Github was rejecting them all. Later I tried again with a new shared secret key from Github, but that key was getting the exception I reported above ("empty key"). I got the same exception when I tried the Github supplied shared secret in another java based library too.

I guess one of the properties of base32 encoding is that it's a single case encoding (not mixed alphabetic case). So I upcased the Github supplied shared secret and that fixed the problem.

So my advice is to document in README.md and/or docstrings that the secret key be upcased, or perhaps just put a call to upcase into the code.

Meanwhile, I signed into Github today with 2fa using your lib, yay!

from one-time.

Thanks for the explanation.
Seems like an issue that'll confuse more users. I'll do some research on this before adding documentation/implementing string cleanup. 🍻

On २०१६ अगस्ट १, at २:५८ अपराह्न, dtenny [email protected] wrote:

Turns out to be very simple. When you go to the Github settings to activate 2fa in security, you can click a link for the shared secret (vs. QR codes/urls and other stuff for normal apps).

So I was cutting and pasting the shared secret into my calls to your library. On the first shared secret key I was getting tokens, but Github was rejecting them all. Later I tried again with a new shared secret key from Github, but that key was getting the exception I reported above ("empty key"). I got the same exception when I tried the Github supplied shared secret in another java based library too.

I guess one of the properties of base32 encoding is that it's a single case encoding (not mixed alphabetic case). So I upcased the Github supplied shared secret and that fixed the problem.

So my advice is to document in README.md and/or docstrings that the secret key be upcased, or perhaps just put a call to upcase into the code.

Meanwhile, I signed into Github today with 2fa using your lib, yay!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

from one-time.

Okay, I seem to understand the issue. (Base32 encoding only allows A-Z0-9, so valid secrets should be of that subset)
Something like below should suffice. If this is a big issue, I might consider adding this to util and update the docs to make it more clear.

(defn sanitize-string-to-base32-subset
  "Uppercase a string and cleanup everything that is not A-Z or 0-9"
  [string]
  (-> string
      (str/upper-case)
      (str/replace #"[^A-Z0-9]" "")))

from one-time.

Not that my opinion counts for much, but if it were me I'd rather get an
exception on a string with outright non-compliant characters.

So I think the upper-casing of the input is okay, but the translation of
other invalid chars I would rather get an exception than have them silently
altered, it seems like a source of confusion down the road.

On Tue, Aug 2, 2016 at 9:46 AM, Suvash Thapaliya [email protected]
wrote:

Okay, I seem to understand the issue. (Base32 encoding only allows A-Z0-9,
so valid secrets should be of that subset)
Something like below should suffice. If this is a big issue, I might
consider adding this to util and update the docs to make it more clear.

(defn sanitize-string-to-base32-subset
"Uppercase a string and cleanup everything that is not A-Z or 0-9"
[string](-> string
%28str/upper-case%29
%28str/replace #"[^A-Z0-9]")))

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#2 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGMwDzO2pPTsK8WLcdDcBgzzjCFkGSL9ks5qb0oogaJpZM4JYK5V
.

from one-time.

As a user, your feedback definitely counts.
Let me give this a thought and bake a good fix for the possible confusion into the next release, probably in a month or so.

On २०१६ अगस्ट २, at ३:५२ अपराह्न, dtenny [email protected] wrote:

Not that my opinion counts for much, but if it were me I'd rather get an
exception on a string with outright non-compliant characters.

So I think the upper-casing of the input is okay, but the translation of
other invalid chars I would rather get an exception than have them silently
altered, it seems like a source of confusion down the road.

On Tue, Aug 2, 2016 at 9:46 AM, Suvash Thapaliya [email protected]
wrote:

Okay, I seem to understand the issue. (Base32 encoding only allows A-Z0-9,
so valid secrets should be of that subset)
Something like below should suffice. If this is a big issue, I might
consider adding this to util and update the docs to make it more clear.

(defn sanitize-string-to-base32-subset
"Uppercase a string and cleanup everything that is not A-Z or 0-9"
[string](-> string
%28str/upper-case%29
%28str/replace #"[^A-Z0-9]")))

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#2 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGMwDzO2pPTsK8WLcdDcBgzzjCFkGSL9ks5qb0oogaJpZM4JYK5V
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

from one-time.