[cisco-voip] DRS Backup Decrypter Workaround - Need Input

[Brian Meade]

Pete,

I'm assuming we won't be able to decrypt the password from the
platformConfig.xml anymore?

Thanks,
Brian

On Wed, Sep 27, 2017 at 11:01 AM, Pete Brown <jpb at chykn.com> wrote:

> Thanks for the feedback everyone, I really appreciate it.
>
>
> Anthony - Great idea, will keep that one in mind.
>
>
> Brian - You mentioned using it to verify the cluster security passwords on
> backups.  Given that the workaround has changed from a webservice to a
> local Java app, the Java app could be used via command line under Windows
> and Linux.  Maybe have a switch on it to verify the password for a backup
> set.  Feed it the cluster security password and backup set location and it
> will kick back a pass or fail.  That way you could do one off checks or
> run nightly scripts to make sure the cluster security passwords for your
> backups haven't changed.
>
>
>
> ------------------------------
> *From:* bmeade90 at gmail.com <bmeade90 at gmail.com> on behalf of Brian Meade <
> bmeade90 at vt.edu>
> *Sent:* Tuesday, September 26, 2017 3:51 PM
> *To:* Anthony Holloway
> *Cc:* Pete Brown; cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input
>
> Definitely a good tip.
>
> That does assume you can guess the password.  I've had a bunch of
> customers have some random cluster security password they had never heard
> of.
>
> On Tue, Sep 26, 2017 at 4:24 PM, Anthony Holloway <
> avholloway+cisco-voip at gmail.com> wrote:
>
>> There's an easier (IMO) way to check cluster security passwords.
>>
>> 1) Enter the change password CLI command, and enter the password you have
>>
>> admin:set password user security
>> Please enter the old password: My$3cuR1tyW0rd1
>>
>> 2) Enter the new password as a dictionary word (I like to use banana):
>>
>>    Please enter the new password: banana
>> Reenter new password to confirm: banana
>>
>> 3) Say yes to the big scary warning:
>>
>> WARNING:
>> You're handing in your resignation letter at 2:00pm today.  Cool?
>>
>> Continue (y/n)? y
>>
>> 4) Get nervous for a minute and second guess your choice to follow some
>> sketchy advice from some stranger online
>>
>> Please wait...
>>
>> 5) Observe the outcome
>>
>> One of two things will now have happened:
>>
>> 1) "The old password did not match."  This means that you do not have the
>> cluster security password correct, and you can try again with some other
>> guesses.
>> 2) "BAD PASSWORD: it does not contain enough DIFFERENT characters" This
>> means that your password was correct, and the "banana" you fed it was
>> rotten.
>>
>> There you go.  No need to have 3rd party software (not counting an SSH
>> client) to help you anymore.
>>
>>
>> On Tue, Sep 26, 2017 at 9:43 AM Brian Meade <bmeade90 at vt.edu> wrote:
>>
>>> I'd probably use it less.  Right now, I use it for almost every project
>>> to verify cluster security passwords.
>>>
>>> I'd probably have to make this more of a last resort in that case and
>>> make sure to get sign-off from the customer.
>>>
>>> On Tue, Sep 26, 2017 at 10:38 AM, Pete Brown <jpb at chykn.com> wrote:
>>>
>>>> I could use some public input regarding the next release of the DRS
>>>> Backup Decrypter.  In a nutshell, the application will have to be online in
>>>> order to decrypt backup sets from newer UCOS versions.
>>>>
>>>> Last year Cisco started patching DRS with a new algorithm (
>>>> PBEWithHmacSHA1AndDESede) to encrypt the random backup passwords.  I
>>>> haven't been able to find a .NET implementation of this algorithm.  The
>>>> only workaround I've come up with is to have the DRS Backup Decrypter make
>>>> a call to a Java webservice that can perform the decryption.
>>>>
>>>> The problems with this approach are pretty obvious.  Aside from having
>>>> to be online, the encrypted cluster security password and 'EncryptKey' from
>>>> a backup set will need to be submitted to a web service that I've
>>>> written for decryption.  I can publish a public copy of this webservice,
>>>> but for those behind corporate proxies (myself included), the code could be
>>>> made available to run the service within their own networks.  In that case
>>>> the DRS Backup Decrypter would be pointed to the internal copy of the
>>>> webservice.
>>>>
>>>> I personally detest utilities that can't operate offline, but it's the
>>>> only workaround I can come up with at this point.  So my question is this -
>>>> would anyone actually use it given the webservice dependency?
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170927/04c7cfaa/attachment.html>