On 30/11/16 15:30, Callum Guy wrote:
Hi David,

I can confirm that using FreeOTP resolves the problem for me.

What a frustration, I am surprised that Google wouldn't add support beyond
SHA1 - perhaps a notice on the OTP documentation page would help others in
this situation.

Thank you so much for your assistance and links to explain the situation. I
hope to pay back the favour in due course.

Best Regards,

Callum

I'm glad I could help. I was very surprised that Google Authenticator is missing this and even worse don't error out about it. At first I was convinced that FreeOTP and FreeIPA has some shared bug and generates the codes in wrong way.

I've added a paragraph to Troubleshooting page [1]. Could you please send me a link to the page where you were trying to find information at first? I would like to add a note and link there so other users with the same issue have it easier.

[1] http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_user_with_OTP_with_Google_Authenticator


On Wed, Nov 30, 2016 at 1:11 PM David Kupka <dku...@redhat.com> wrote:

On 30/11/16 10:13, David Kupka wrote:
On 29/11/16 12:57, Callum Guy wrote:
Hi Alexander,

I can confirm that I am using version 4.2.0.

The bug link provided mentions that it caused GA to fail to scan the
codes.
In my situation it is FreeIPA (or related service) which appears to
fail to
validate codes generated, meaning that only OTP codes generated using
sha1
are validated and accepted.

Just for clarity I can confirm that I have only tested OTP codes
generated
and configured via the FreeIPA web interface. I will check the command
line
generation and let you know if this makes a difference.

Best Regards,

Callum

Hello Callum,
I've tried it with FreeIPA 4.3.2 (stock Fedora 24) and FreeOTP. I've
generated 3 OTPs (with sha256, sha384 and sha512) for tuser in the WebUI
and was then able to login into WebUI without problems.


$ ipa otptoken-find --owner tuser --all
--------------------
3 OTP tokens matched
--------------------
  dn:

ipatokenuniqueid=3c899764-7abf-459d-bf2b-7ba4af978a8b,cn=otp,dc=dom-058-216,dc=example,dc=com

  Unique ID: 3c899764-7abf-459d-bf2b-7ba4af978a8b
  Type: TOTP
  Owner: tuser
  Key: U5XDN0BYc9KbvG1iYuVPuVHB448=
  Algorithm: sha256
  Digits: 6
  Clock offset: 0
  Clock interval: 30
  ipatokentotpwatermark: 49349880
  objectclass: top, ipatokentotp, ipatoken

  dn:

ipatokenuniqueid=40ad189b-7b7c-44b9-8450-b3eb78057ef6,cn=otp,dc=dom-058-216,dc=example,dc=com

  Unique ID: 40ad189b-7b7c-44b9-8450-b3eb78057ef6
  Type: TOTP
  Owner: tuser
  Key: C79y2W+I0z429eRzsRP7qdpROaI=
  Algorithm: sha512
  Digits: 6
  Clock offset: 0
  Clock interval: 30
  ipatokentotpwatermark: 49349882
  objectclass: top, ipatokentotp, ipatoken

  dn:

ipatokenuniqueid=baf6d329-61ad-46f1-beca-6ddb55ba9bb4,cn=otp,dc=dom-058-216,dc=example,dc=com

  Unique ID: baf6d329-61ad-46f1-beca-6ddb55ba9bb4
  Type: TOTP
  Owner: tuser
  Key: 2hxrsJjQ6e+3qzVPZremtsB/NCg=
  Algorithm: sha384
  Digits: 6
  Clock offset: 0
  Clock interval: 30
  ipatokentotpwatermark: 49349881
  objectclass: top, ipatokentotp, ipatoken

I've tried with Google Authenicator too and was unable to login.

Alexander found issue [1] asking for SHA256 support. From comment on the
issue it appear that SHA1 is the only supported hash.

I compared codes generated by oathtool [2] and find out that Google
Authenticator just ignores the information about used hash function and
uses SHA1 without any error or warning.

So I can only recommend switching to FreeOTP or returning to SHA-1 hash
function.

[1] https://github.com/google/google-authenticator-libpam/issues/11
[2] http://www.nongnu.org/oath-toolkit/oathtool.1.html





On Tue, Nov 29, 2016 at 11:51 AM Alexander Bokovoy <aboko...@redhat.com

wrote:

On ti, 29 marras 2016, Callum Guy wrote:
Hi Petr,

Thanks for coming back to me on this.

I have only tried using Google Authenticator. The generated QR code
successfully scans and codes are then generated on the GA device as
normal.
The problem is that the codes simply do not work.

My current thinking is that the service which interprets the codes
server-side is not configured to use the same algorithm meaning that
it is
trying to validate sha256/sha512 (both tested and not functional for
me)
etc codes against codes perhaps generated with sha1 (the only
algorithm
that appears to work).

I apologise in advance for my naive interpretation of the situation,
this
really isn't an area where i have experience. I'd love to understand
whats
going on however I can't find what i need in the OTP documentation.
Which IPA version we are talking about? There was a case when the URI
generated by 'ipa otptoken-add' was using a wrong case in the algorithm
value and this was breaking Google Authenticator.

https://fedorahosted.org/freeipa/ticket/5047

This bug was fixed since 4.1.5 release.


Best Regards,

Callum


On Tue, Nov 29, 2016 at 11:10 AM Petr Vobornik <pvobo...@redhat.com>
wrote:

On 11/28/2016 01:03 PM, Callum Guy wrote:
Hi All,

I wanted to ask a quick question - perhaps a more experienced user
will
be able
to help or point me to the correct documentation.

Basically we have implemented password+OTP type authentication which
works great.

When adding a OTP code using the admin login you can choose an
algorithm. For us
the generated codes only work properly if the weakest sha1 algorithm
is
chosen/
To be clear the code generation works fine but the codes are not
valid
when
logging in. Is there a related setting we must change?

Thanks,

Callum


What type of otp token do you use? Does it work with some different?
E.g. FreeOTP vs Google Authenticator ...


--
Petr Vobornik


--



*0333 332 0000  |  www.x-on.co.uk <http://www.x-on.co.uk>  |   **
<https://twitter.com/xonuk>
<http://www.linkedin.com/company/x-on/products>
<https://www.facebook.com/XonTel> *
X-on is a trading name of Storacall Technology Ltd a limited company
registered in England and Wales.
Registered Office : Avaland House, 110 London Road, Apsley, Hemel
Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
The information in this e-mail is confidential and for use by the
addressee(s) only. If you are not the intended recipient, please
notify
X-on immediately on +44(0)333 332 0000 <+44%20333%20332%200000>
<+44%20333%20332%200000> and
delete the
message from your computer. If you are not a named addressee you
must not
use, disclose, disseminate, distribute, copy, print or reply to this
email. Views
or opinions expressed by an individual
within this email may not necessarily reflect the views of X-on or its
associated companies. Although X-on routinely screens for viruses,
addressees should scan this email and any attachments
for viruses. X-on makes no representation or warranty as to the
absence of
viruses in this email or any attachments.


--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project


--
/ Alexander Bokovoy








--
David Kupka




--
David Kupka

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to