O4W Password Encryption

• Storing “clear text” passwords is bad practice. If your OpenInsight system is ever compromised, your clear text passwords can be seen (and, perhaps, used on other web sites, as most people use the same password or passwords across multiple systems);

• Transmitting “clear text” passwords is worse. Especially on non-secure connections, sending the actual password back and forth to the browser is dangerous;

• O4W developers should still have ways to “opt out” of the encryption process, and/or customize it to their specific needs

The solution:

• When passwords are defined, store them in an “encrypted” fashion (rather than clear text);

• When passwords are entered into the browser, encrypt them in some fashion _on_the_browser_ and then only send the encrypted value

Since O4W systems are already “in the wild” with clear-text passwords stored in the O4WPERMS table, the 1.0→1.1 O4WUpgrade process will:

• Generate a system-specific “seed” that is used in the encryption process;

• Go through the O4WPERMS table and encrypt all the passwords using the system-specific “seed”

• [Note: if a developer wishes to keep the passwords in clear text, they should create a record in DICT O4WPERMS named “SALT”, with an “X” in field 1 and nothing else in the record. The O4WUPGRADE process will only do the one-time encryption if it also creates the SALT record]

The user maintenance screen has been modified to comply with the ideas above:

• The existing password is never sent back to the browser when an existing user’s record is modified;

• If no “SEED” value is found (for example, on a new O4W installation), the “SEED” value is generated;

• When a password is entered in the browser, it is encrypted before being sent back to the host;

• The encrypted value is stored in the O4WPERMS record

• [Note: if a developer wishes to keep the passwords in clear text, they should create a record in DICT O4WPERMS named “SALT”, with an “X” in field 1 and nothing else in the record. The user maintenance screen will _not_ create the “SALT” record if one already exists, and will _not_ do the encryption on the password field if there is no actual seed value in field 2]

The O4W Login process has been modified to comply with the ideas above:

• When the password is entered in the browser, it is encrypted before being sent back to the host;

• If we are operating in this “encrypted” fashion, the current time is also sent to the browser – if the user does not submit the login form within 5 minutes of its creation, the logon will be invalidated;

• When the password is encrypted, it is encrypted using both the “seed” and the current time that was sent when the form was created. This will generate a unique “hash value” that can’t be reused by someone trying to “hack” the system who (somehow) intercepts the hashed value;

• [Note: if a developer wishes to use clear-text passwords, they should EITHER create the empty SEED record as described above, or specify a custom authorization routine (see below)]

The default login authorization routine (O4WI_AUTHORIZE) has been modified to accept _3_ parameters: the username, the hashed value sent by the browser, and the current time value;

O4WI_AUTHORIZE will now:

• Retrieve the password for the specified user from the O4WPERMS table;

• “hash” that value with the current time value;

• Compare the results with the hashed value sent by the brower

If the two values match, the user is authorized to proceed;

Developers who specify their own custom authorization routines (via the O4WCONFIG record) will continue to be passed 2 parameters (the username and the UNENCRYPTED password);

Developers who wish to use the encryption routines to make their systems secure, but who still wish to have a custom authorization routine, may do so by creating an authorization routine whose name ends in “ENCRYPT” (ie, “MYCUSTOMPROC_ENCRYPT”). If the authorization routine’s name ends in “ENCRYPT”, O4W’s login process will instruct the browser to encrypt the password, and send that authorization routine the same 3 parameters as O4WI_AUTHORIZE.

New utility function: O4WI_ENCRYPT

The O4WI_ENCRYPT routine takes up to 3 parameters; the first 2 are mandatory, the last one is optional:

FUNCTION O4WI_ENCRYPT(param1, param2 {, param3})

It performs a “hash” on the first two parameters, and then (optionally) hashes that value with the third parameter;

This function is used by the O4WI_AUTHORIZE and O4WUPGRADE routines to generate and validate the hashed value, and could be used by a developer’s custom authorization routine that also used encrypted values;

This function relies on an updated RTI_MD5 to perform an “hmac sha1” hash

New O4WQUALIFYEVENT event: ENCRYPT

The O4WQUALIFYEVENT function has been enhanced to support a new ‘event’, “ENCRYPT”:

O4WQUALIFYEVENT(“<sourceID>”, “ENCRYPT”, “<targetID>”, “<hash_param1>” {, “<hash_param2>”})

<sourceID> and <targetID> are the O4W IDs of the field to encrypt and destination for the hash, respectively;

<hash_param1> is the O4W ID or literal string (enclosed in quotes) to use when hashing the <sourceID>

<hash_param2>, if specified, is the O4W ID or literal string (enclosed in quotes) to use when hashing the hash generated in the previous step

Specifying this event will generate a script that, when the contents of the <sourceID> control have been modified, and the control has “lost focus”, will hash the value stored in the <sourceID> control against the one or two other values, and store the result in the <targetID> control. In addition, it will change the value in the <sourceID> control to a known value, not related to its original value, so that the original entered value is never transmitted to the host

Example:

CASE EVENT _EQC ‘CREATE’

 * … initial code ….

O4WStore(“”, “myHash”, “myHash”) ;* the control where we’ll store the hashed result

O4WPassword(“”, “”, “”, “ourPWD”, “ourPWD”) ;* the control where the user will type in the password

O4WQualifyEvent(‘ourPWD’, ‘ENCRYPT’, ‘myHash’, ‘”b8291af880217262cc82965”’) ;* hash the value that’s been entered into ourPWD against the literal string and put the hashed value into myHash

* … more code …

 CASE EVENT _EQC “CLICK”

pwdHash = O4WGetValue(“myHash”) ;* hashed password value

dummyPwd = O4WGetValue(“ourPWD”) ;* not used - always return “eNcRyPtEd” as the text

* … validation code …

In practice, the <hash_param1> will usually be the “seed” value stored in the DICT O4WPERMS “SALT” record, field 2