4 ms·

Functionally that's what it sounds like they've done with their offline mode. They use "wave" style images instead of qr codes. They also use asymmetric crypt

Functionally that's what it sounds like they've done with their offline mode. They use "wave" style images instead of qr codes. They also use asymmetric crypto I think, like FIDO, but unlike OTP. It might not be feasible to offer a 6-digit code fallback, though, unless you can map RSA or ECDSA or whatever they're using into a problem with a 20-bit solution space without allowing offline brute forcing. Their offline mode seems like FIDO but with a bidirectional wave image / camera requirement to get around lack of a better data channel (like u2f-hid support that FIDO requires).

e12e 12y ago
> It might not be feasible to offer a 6-digit code fallback, though, unless you can map RSA or ECDSA or whatever they're using into a problem with a 20-bit solution space without allowing offline brute forcing. Probably not. Supporting traditional (T)OTP is more about interop than anything else (the back-end just gets a one-time code to check against a list/counter or against a time-derived token, checking for drift etc. Main point is you can keep your auth-stack as-is, and your shared totp-secret in the same place[t]). You could probably do assymetric crypto fine with qr-codes[1] they pack a lot of data. If an ECDSA signature is ~48 bytes[2] -- that's going to be hard to compact down to a reasonable fallback... maybe. If the idea is to use asymmetric crypto as a backing for OTP, I suppose you'd do something like signing TIME+salt, and transmit the signature and the salt. Unless there is some trick one can do with checking partial asymmetric signatures, I don't see how you could get away with sending less than SIG+salt, or ~50 bytes. That's way too long for typing in, as a usable fall-back. It might actually involve less typing to generate a shared secret -- but that'd completely break the UX -- so it doesn't sound like a sane fall-back to me. [1] http://en.wikipedia.org/wiki/QR_code http://en.wikipedia.org/wiki/QR_code [2] http://crypto.stackexchange.com/questions/3216/signatures-rsa-compared-to-ecdsa http://crypto.stackexchange.com/questions/3216/signatures-rs... [t] http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google-authenticator.shtml http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google...

e12e 12y ago

> It might not be feasible to offer a 6-digit code fallback, though, unless you can map RSA or ECDSA or whatever they're using into a problem with a 20-bit solution space without allowing offline brute forcing. Probably not. Supporting traditional (T)OTP is more about interop than anything else (the back-end just gets a one-time code to check against a list/counter or against a time-derived token, checking for drift etc. Main point is you can keep your auth-stack as-is, and your shared totp-secret in the same place[t]). You could probably do assymetric crypto fine with qr-codes[1] they pack a lot of data. If an ECDSA signature is ~48 bytes[2] -- that's going to be hard to compact down to a reasonable fallback... maybe. If the idea is to use asymmetric crypto as a backing for OTP, I suppose you'd do something like signing TIME+salt, and transmit the signature and the salt. Unless there is some trick one can do with checking partial asymmetric signatures, I don't see how you could get away with sending less than SIG+salt, or ~50 bytes. That's way too long for typing in, as a usable fall-back. It might actually involve less typing to generate a shared secret -- but that'd completely break the UX -- so it doesn't sound like a sane fall-back to me. [1] http://en.wikipedia.org/wiki/QR_code http://en.wikipedia.org/wiki/QR_code [2] http://crypto.stackexchange.com/questions/3216/signatures-rsa-compared-to-ecdsa http://crypto.stackexchange.com/questions/3216/signatures-rs... [t] http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google-authenticator.shtml http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google...