[Freeipa-users] OTP Algorithm

Wed Nov 30 13:11:42 UTC 2016

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 <abokovoy at 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 <pvoborni at 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> 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