<div dir="ltr">Hi David,<div> </div><div>I can confirm that using FreeOTP resolves the problem for me. </div><div> </div><div>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.</div><div> </div><div>Thank you so much for your assistance and links to explain the situation. I hope to pay back the favour in due course.</div><div> </div><div>Best Regards,</div><div> </div><div>Callum</div><div> <div class="gmail_quote"><div dir="ltr">On Wed, Nov 30, 2016 at 1:11 PM David Kupka <<a href="mailto:dkupka@redhat.com">dkupka@redhat.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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] <a href="https://github.com/google/google-authenticator-libpam/issues/11" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/google/google-authenticator-libpam/issues/11</a> [2] <a href="http://www.nongnu.org/oath-toolkit/oathtool.1.html" rel="noreferrer" class="gmail_msg" target="_blank">http://www.nongnu.org/oath-toolkit/oathtool.1.html</a> > > >> >> >> On Tue, Nov 29, 2016 at 11:51 AM Alexander Bokovoy <<a href="mailto:abokovoy@redhat.com" class="gmail_msg" target="_blank">abokovoy@redhat.com</a>> >> 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. >>> >>> <a href="https://fedorahosted.org/freeipa/ticket/5047" rel="noreferrer" class="gmail_msg" target="_blank">https://fedorahosted.org/freeipa/ticket/5047</a> >>> >>> This bug was fixed since 4.1.5 release. >>> >>>> >>>> Best Regards, >>>> >>>> Callum >>>> >>>> >>>> On Tue, Nov 29, 2016 at 11:10 AM Petr Vobornik <<a href="mailto:pvoborni@redhat.com" class="gmail_msg" target="_blank">pvoborni@redhat.com</a>> >>> 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 | <a href="http://www.x-on.co.uk" rel="noreferrer" class="gmail_msg" target="_blank">www.x-on.co.uk</a> <<a href="http://www.x-on.co.uk" rel="noreferrer" class="gmail_msg" target="_blank">http://www.x-on.co.uk</a>> | ** >>>> <<a href="https://twitter.com/xonuk" rel="noreferrer" class="gmail_msg" target="_blank">https://twitter.com/xonuk</a>> >>>> <<a href="http://www.linkedin.com/company/x-on/products" rel="noreferrer" class="gmail_msg" target="_blank">http://www.linkedin.com/company/x-on/products</a>> >>>> <<a href="https://www.facebook.com/XonTel" rel="noreferrer" class="gmail_msg" target="_blank">https://www.facebook.com/XonTel</a>> * >>>> 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 <a href="tel:+44%20333%20332%200000" value="+443333320000" class="gmail_msg" target="_blank">+44(0)333 332 0000</a> <+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: >>>> <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" rel="noreferrer" class="gmail_msg" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a> >>>> Go to <a href="http://freeipa.org" rel="noreferrer" class="gmail_msg" target="_blank">http://freeipa.org</a> for more info on the project >>> >>> >>> -- >>> / Alexander Bokovoy >>> >> >> >> > > -- David Kupka </blockquote></div></div></div> <img src="http://www.x-on.co.uk/email/footer/banner-x-on.jpg"> 0333 332 0000 | <a href="http://www.x-on.co.uk" target="_blank">www.x-on.co.uk</a> | <a href="https://twitter.com/xonuk" target="_blank"><img src="http://www.x-on.co.uk//images/icon/linkedin.png" width="24" height="24"></a> <a href="http://www.linkedin.com/company/x-on/products" target="_blank"><img src="http://www.x-on.co.uk//images/icon/facebook.png" width="24" height="24"></a> <a href="https://www.facebook.com/XonTel" target="_blank"><img src="http://www.x-on.co.uk//images/icon/twitter.png" width="24" height="24"></a> 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 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.