[RADIATOR] New eToken PASS import files have longer secret keys (64 chars vs. 48 chars)

[Linuxchuck]

Mike, apologies in advance for the double-post to you.  Since this is a little time-sensitive, I am posting this to the list.

I just received an update from Safenet.  Here is the quoted response:

"""
eToken PASS 6.2 use SHA256 as default hashing algorithm, hence the longer seed.
See for example http://www.openauthentication.org/webfm_send/47.

We have 3 options:

1) Ask your radius vendor to support HMAC-SHA256
2) Reprogram the tokens with SHA1 (Programmer is available, part number 13681, around 390.- €)
3) Replace the tokens with SHA1 programmed tokens.

For the latter I have to first check the current process on ordering them.
"""

So my questions are:  how long will it take to add SHA256 support, and is that even a feasible request?  
If this is something I need to request through our official support channel (we have a support contract), just say the word, and I'll send it through.

This is something of a time-sensitive issue.  We have clients waiting to be issued their tokens.

Thanks

On 05/13/2011 08:16 PM, Mike McCauley wrote:
> Hi,
> 
> Can you please send an example of a key, counter and resulting correct OTP, so 
> we can investigate?
> 
> Cheers.
> 
> On Saturday 14 May 2011 05:35:32 am Linuxchuck wrote:
>> Hello again,
>>
>> I've been successfully using eToken PASS tokens since we moved to Radiator
>> without issue.  We've recently purchased an additional set of 100 tokens
>> because we were running low, and the DigiPass Go-7 tokens we recently
>> received turn out to be unable to support changing PINs. During the process
>> of importing the new eToken PASS secret keys, I found that the token key
>> import files shipped with the tokens have changed now since SafeNet has
>> taken over ownership of Aladdin.
>>
>> The new files are called "AlpineXml.xml" and "importAlpine.dat".  The first
>> is an XML file formatted exactly like the old XML files I'm familiar with
>> from the original Aladdin days.  The second file is an ldif-formatted file
>> with basically the same information in it.  I built an XML parsing PHP
>> script to perform bulk-imports for the older Aladdin import files, and it
>> works fine with the new XML files as well.
>>
>> I've noticed a particularly important change, however.  The token secrets
>> are now 64 characters long, and will not properly import into the standard
>> secret column in the hotpkeys MySQL table which is a varchar(60) based on
>> the sql table built in hotp.cfg.  (FYI, the original keys in my first
>> couple-hundred tokens were all 48 characters long.)  In addition, the
>> "version" string in the older XML files is "6.0", and in the newer version,
>> is "6.20".
>>
>> I figured it would be a simple task to extend the storage of that column to
>> compensate for the longer keys, and applied an alter table command to do
>> just that.  I then updated the keys for each token, ran a few queries to
>> ensure they matched exactly with the keys provided in the XML file, and
>> reloaded my Radiator servers.  So far, so good...
>>
>> However, even though the new and longer secret keys now fit in the column,
>> I can not get any of these newly imported tokens to authenticate properly. 
>> All of my older eToken PASS tokens with the shorter keys still work without
>> issue.  It's these new tokens with the longer keys that refuse to
>> authenticate.
>>
>> Does anyone have an idea what could be going wrong here?  I am not a Perl
>> coder by any stretch of the imagination, and my rudimentary scan of the
>> HOTP-related modules in Radiator did not give me any clues where things
>> could be going wrong.
>>
>> Thanks in advance...
>> _______________________________________________
>> radiator mailing list
>> radiator at open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
> 
> 
>