🚀 go-pugleaf

shah@wg.com wrote:
>
>Folks,
>
>I had recently posted a query for password encryption/de-cryption scheme. I
>will sum up the replies I got and post them here.  Here is my next question...
>
>The app. that I am writing needs to have a MASTER password for the
>"Supervisor".  If the "supervisor" gets hit by lightining (God forbid !) or if
>the Supervisor forgets his/her password, how does he/she get in the system ?
>Assume that NO ONE else has access level equivalent to the Supervisor.  Also
>this password needs to be different for each instance of the application i.e
>if (hopefully) someday this app. were to be marketed, then I need to have a
>different MASTER password (maybe based on the application serial number) for
>each copy of the app.; otherwise the bulletin boards and news groups will be
>flooded with this SAME MASTER password for all the copies of this app !!!
>
>Please respond directly to my email address if you can...
>
>Thanks
>Ajay Shah
>(ashah@ecevy.ncsu.edu)
>(shah@wg.com)
>
>P.S:  I am using Microsoft Visual C++ as my programming language.
>

What you are proposing seems to contradict itself.

>Assume that NO ONE else has access level equivalent to the Supervisor.

The MASTER password that you are implying would break this rule would it not?
Who ever holds the MASTER key is system GOD.

I recommend you abandon the MASTER key idea and PRINT the SUPERVISOR
key when it is first created.  You could break it into two parts that two other people
would put together at times of necessity.

Unless of course, it is you intention to design an insecure system.  Take the Canadian
government for example, although they will never admit it, they restrict exporting of
encryption technology, becuse they don't want too much security in 'certain' other countries.

Good luck!

Rolande

On Thu, 10 Aug 95 17:12:37 PDT, in comp.os.ms-windows.programmer.misc,
shah@wg.com wrote:

->The app. that I am writing needs to have a MASTER password for the 
->"Supervisor".  If the "supervisor" gets hit by lightining (God forbid !) or if

->the Supervisor forgets his/her password, how does he/she get in the system ?  
->Assume that NO ONE else has access level equivalent to the Supervisor.  Also 
->this password needs to be different for each instance of the application i.e 
->if (hopefully) someday this app. were to be marketed, then I need to have a 
->different MASTER password (maybe based on the application serial number) for 
->each copy of the app.; otherwise the bulletin boards and news groups will be 
->flooded with this SAME MASTER password for all the copies of this app !!!


It depends on whether you want the backdoor password to be *always* available,
and thus documented somewhere, or only available in absolute emergencies.

How I handled this in an application I worked on a long time ago was to have the
master password based on some scheme that included parts of today's date & time.
The actual password was generated by an algorithm that took in certain
constants, plus the day & month values, and scrunched them together to produce
an seemingly-random sequents of letters & numbers. In your case you'd want to
include some or all of the serial number in your algorithm.

Then, your customer support people would have a small utility which, when fed in
the serial number and whatever else you wanted would take the input and generate
a "one time only" password.

The benefit of using the date/time in the key is that the password automagically
becomes invalid as soon as the hour or day changes. The customer could write the
password down, but it will be useless to him if he doesn't know how to generate
a new one an hour later.

Naturally, the exact algorithm you'd use to encode/decode the password would be
a closely guarded secret within your company.

Brad.

--
Brad P. Smith - Software Designer
Cognos Inc.; 3755 Riverside Dr.; Ottawa, Ontario, CANADA; K1G 3Z4
Voice: (613) 738-1440 ext 3702      FAX: (613) 738-0002
Internet: smithb@bps.synapse.net   or   smithb@cognos.com

It depends on whether you want the backdoor password to be *always* 
available,
and thus documented somewhere, or only available in absolute 
emergencies.

How I handled this in an application I worked on a long time ago was to 
have the
master password based on some scheme that included parts of today's date 
& time.
The actual password was generated by an algorithm that took in certain
constants, plus the day & month values, and scrunched them together to 
produce
an seemingly-random sequents of letters & numbers. In your case you'd 
want to
include some or all of the serial number in your algorithm.

Then, your customer support people would have a small utility which, 
when fed in
the serial number and whatever else you wanted would take the input and 
generate
a "one time only" password.

The benefit of using the date/time in the key is that the password 
automagically
becomes invalid as soon as the hour or day changes. The customer could 
write the
password down, but it will be useless to him if he doesn't know how to 
generate
a new one an hour later.

Naturally, the exact algorithm you'd use to encode/decode the password 
would be
a closely guarded secret within your company.

Brad.
>
>--
>Brad P. Smith - Software Designer
>Cognos Inc.; 3755 Riverside Dr.; Ottawa, Ontario, CANADA; K1G 3Z4
>Voice: (613) 738-1440 ext 3702      FAX: (613) 738-0002
>Internet: smithb@bps.synapse.net   or   smithb@cognos.com
>