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

2017-09-27 Thread Pete Brown 
Brian,


We're still okay there.  Cisco hasn't changed the algorithm used to store 
passwords in platformConfig.xml, so the UCOS Password Decrypter still works.


I know you're familiar with this next part, but I'll include it for the public. 
 When backups are generated, the encrypted security password is copied directly 
from platformConfig.xml and hashed.  The results of that hash are used as a key 
to encrypt the random backup password which then gets stuffed into the backup 
set XML.  The algorithm used for the hash in this process is what they changed.


One option would be to roll the UCOS Password Decrypter functions into the new 
command line Java app.  That way you could run it directly on a rooted UCOS VM 
to dump the platformConfig.xml passwords.


Thanks,

Pete



From: bmead...@gmail.com <bmead...@gmail.com> on behalf of Brian Meade 
<bmead...@vt.edu>
Sent: Wednesday, September 27, 2017 10:10 AM
To: Pete Brown
Cc: Anthony Holloway; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

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 
<j...@chykn.com<mailto:j...@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: bmead...@gmail.com<mailto:bmead...@gmail.com> 
<bmead...@gmail.com<mailto:bmead...@gmail.com>> on behalf of Brian Meade 
<bmead...@vt.edu<mailto:bmead...@vt.edu>>
Sent: Tuesday, September 26, 2017 3:51 PM
To: Anthony Holloway
Cc: Pete Brown; cisco-voip@puck.nether.net<mailto:cisco-voip@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-v...@gmail.com<mailto:avholloway+cisco-v...@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 
<bmead...@vt.edu<mailto:bmead...@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 
<j...@chykn.com<mailto:j...@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

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

2017-09-27 Thread 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 <j...@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:* bmead...@gmail.com <bmead...@gmail.com> on behalf of Brian Meade <
> bmead...@vt.edu>
> *Sent:* Tuesday, September 26, 2017 3:51 PM
> *To:* Anthony Holloway
> *Cc:* Pete Brown; cisco-voip@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-v...@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 <bmead...@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 <j...@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@puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>>
>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

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

2017-09-27 Thread Pete Brown 
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: bmead...@gmail.com <bmead...@gmail.com> on behalf of Brian Meade 
<bmead...@vt.edu>
Sent: Tuesday, September 26, 2017 3:51 PM
To: Anthony Holloway
Cc: Pete Brown; cisco-voip@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-v...@gmail.com<mailto:avholloway+cisco-v...@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 
<bmead...@vt.edu<mailto:bmead...@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 
<j...@chykn.com<mailto:j...@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@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

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

2017-09-27 Thread Pete Brown 
(sorry, replied to Stephen but forgot to Reply All to include the list)


Stephen,

Thanks again for the great advice; I'm going that route.  I was able to get an 
updated version of the DRSD working with newer backups by using a Java app.  
Using IKVM has proved a little trickier since the new algorithm requires a 
security provider in cryptojFIPS.jar.  Unfortunately there are security checks 
in that JAR's classes which check for the container name at runtime.  If 
they're repacked into another JAR, they fail to execute.  I may go back and 
play with that later, but for now the Java app on the local host will suffice.


Thanks,

Pete



From: Stephen Welsh <stephen.we...@unifiedfx.com>
Sent: Tuesday, September 26, 2017 9:51 AM
To: Pete Brown
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input

Hi Pete,

Would it not be better to create a small Java application that takes the 
encrypted content and returns the decrypted content (possibly passing in a file 
and creating a new file with the decrypted content?).

You can also compile Java to a .Net DLL using (https://www.ikvm.net), so you 
can call it directly without passing files backward/forward.
IKVM.NET Home Page<https://www.ikvm.net/>
www.ikvm.net
IKVM.NET is an implementation of Java for Mono and the Microsoft .NET 
Framework. It includes the following components: A Java Virtual Machine 
implemented in .NET



Kind Regards

Stephen Welsh
CTO

[cid:CBBF0493-235C-43D2-A874-9FB3D95AF598@b2.unifiedfx.com]

On 26 Sep 2017, at 15:38, Pete Brown <j...@chykn.com<mailto:j...@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@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

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

2017-09-26 Thread mtarpey1 
too late, the problem has been resolved

- Original Message -
From: Brian Meade 
Date: Tuesday, September 26, 2017 4:51 pm
Subject: Re: [cisco-voip] DRS Backup Decrypter Workaround - Need Input
To: Anthony Holloway 
Cc: "cisco-voip@puck.nether.net" 

> 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-v...@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 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 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@puck.nether.net
> >>> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>>
> >>>
> >> ___
> >> cisco-voip mailing list
> >> cisco-voip@puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

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

2017-09-26 Thread Brian Meade 
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-v...@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  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  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@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

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

2017-09-26 Thread Anthony Holloway 
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  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  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@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

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

2017-09-26 Thread Stephen Welsh 
Hi Pete,

Would it not be better to create a small Java application that takes the 
encrypted content and returns the decrypted content (possibly passing in a file 
and creating a new file with the decrypted content?).

You can also compile Java to a .Net DLL using (https://www.ikvm.net), so you 
can call it directly without passing files backward/forward.

Kind Regards

Stephen Welsh
CTO

[cid:CBBF0493-235C-43D2-A874-9FB3D95AF598@b2.unifiedfx.com]

On 26 Sep 2017, at 15:38, Pete Brown > 
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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

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

2017-09-26 Thread Brian Meade 
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  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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip