How to encrypt registry key value

NTDEV
1

Greetings;

I have a technical problem that some of you might be able to help. Any
pointer is greatly appreciated.

We are maintaining a Windows application on NT 4.0 written in Visual C++.
The application reads in the userrid and password at initialization from the
registry key, to log on to Oracle database.

Our client now wants us to modify the code so that the userid and password
stored in the Registry is encrypted, ie. is user open the registry using
regedt32 they won’t be able to see the real value of userid and password.
But at the same time, if we read the value from these registry key using the
API for WinNT then we are still able to see them.

Is there a quick way to modify the code to accommodate this request or I
have to write my own encrypt/decrypt utiltiy for this task. Does NT
Registry has a property to turn on the security shield so that user won’t be
able to see it?

Any advices and/or suggestions are greatly appreciated.

Regards,
A. Nguyen
Project Manager
Metro Information Services
(713) 917-0833 (MetroIS)

2

The registry APIs allow you to set security (on NT/2000, not 95/98)
that will hide the contents of a key from ordinary users. See
RegSetKeySecurity() and SetSecurityInfo() APIs. But Admin users can
use RegEdt32.exe to change the security to allow them to see the
contents of the key.

There is no built-in support for encrypting registry key data.

You might leverage the Crypt* APIs to implement your own.

Dave Cox
Hewlett-Packard Co.
HPSO/SSMO (Santa Barbara)
https://ecardfile.com/id/Dave+Cox

-----Original Message-----
From: Anhlan Nguyen [mailto:xxxxx@pdq.net]
Sent: Wednesday, May 24, 2000 1:00 PM
To: NT Developers Interest List
Subject: [ntdev] How to encrypt registry key value

Greetings;

I have a technical problem that some of you might be able to help. Any
pointer is greatly appreciated.

We are maintaining a Windows application on NT 4.0 written in Visual C++.
The application reads in the userrid and password at initialization from the
registry key, to log on to Oracle database.

Our client now wants us to modify the code so that the userid and password
stored in the Registry is encrypted, ie. is user open the registry using
regedt32 they won’t be able to see the real value of userid and password.
But at the same time, if we read the value from these registry key using the
API for WinNT then we are still able to see them.

Is there a quick way to modify the code to accommodate this request or I
have to write my own encrypt/decrypt utiltiy for this task. Does NT
Registry has a property to turn on the security shield so that user won’t be
able to see it?

Any advices and/or suggestions are greatly appreciated.

Regards,
A. Nguyen
Project Manager
Metro Information Services
(713) 917-0833 (MetroIS)

You are currently subscribed to ntdev as: david_cox2@hp.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)

3

>Our client now wants us to modify the code so that the userid and password

stored in the Registry is encrypted, ie. is user open the registry using
regedt32 they won’t be able to see the real value of userid and password.
But at the same time, if we read the value from these registry key using the
API for WinNT then we are still able to see them.

Is there a quick way to modify the code to accommodate this request or I
have to write my own encrypt/decrypt utiltiy for this task. Does NT
Registry has a property to turn on the security shield so that user won’t be
able to see it?

Any advices and/or suggestions are greatly appreciated.

It sounds like your trying to prevent any user from having access to data
in the registry. This is especially sticky if your trying to prevent
administrators from having access. If you encrypt the data, you will either
have to store the encryption password or else ask a user at some time (like
system boot). So the options are to have a security risk or to be annoying
operationally.

The squeaky secure way this should work is: the remote server (Oracle
database) should send a random token to your machine. Your machine should
then ask something like a crypto smart card to hash the token with the
stored password (which is write only to the smart card), and you send the
hashed token back to the server. The server then also hashes the original
token with it’s stored copy of the password, and the result should match
your hashed token. This way, it’s impossible to retrieve the actual
password on the local machine. This also assumes that physical possession
of the smart card gives you access to the database, so there is no data of
any kind that can be “stolen” from the local machine to get access to the
database. You could use some password stored on the local machine to unlock
access to the smart card, so BOTH physical possession of the smart card and
the local machine password value would be required to access the Oracle
server. The downside is, I’m not sure Oracle has any way to handling secure
password authentication this way (a password helper app on the server may
be required), and don’t know if your willing to take the trouble to have
smart cards+readers.

You could also potentially use Kerberos security, which is available in
W2K. NT 4 can probably access Kerberos key servers through a library too.

I think you should ask your client exactly how secure they want the
password stored. The answer is usually based on what are the implications
of security being broken. If’s it’s something serious, then serious
security measures are appropriate.

  • Jan
4

At 03:20 PM 5/24/2000 -0700, you wrote:

>Our client now wants us to modify the code so that the userid and password
>stored in the Registry is encrypted, ie. is user open the registry using
>regedt32 they won’t be able to see the real value of userid and password.
>But at the same time, if we read the value from these registry key using the
>API for WinNT then we are still able to see them.
>

If all you want to do is verify correct values for userid and password,
you can just store the MD5 hash of the userid and passwords in the
registry and you won’t need to encrypt the data since it can’t be decrypted.
(Note no key is required either).

You establish a match by using the hash algorithm on login data and
then comparing the hashed login id, password with that stored in the registry.
Note you still need to protect the registry entries from modification.
It might be easier to store the hash data in the file system.