«Swordfish» – Secure password storing in Microsoft Dynamics CRM


In response to the post "Password field" describing the script that hides user's password in the CRM record.

The current version of Microsoft Dynamics CRM does not support the so-called field level security - access rights management at the field-level. Security roles configured access to the entire entity. There are often situations where you want to protect or hide some fields from certain groups of users in CRM. For such cases, the best way is to add separated entity (it will keep the secret values), link it to the main entity, and grant permissions for privileged users in security roles.

Secret, MSCRM Entity, Users, Roles

But this implementation is not always fit.

Consider this scenario: you want to keep mother's maiden name of contact in CRM, and the users (eg. operators) should not see it, but to be able to compare the value stored in the CRM (for example, received from the client during a phone call - standard situation when serving in the bank by phone).

It is clear that you must avoid to store name in plain text. But in that answer field (for the value of maiden name, although it can be any secret value, including the password) you can put a hash value (checksum), calculated for a particular lastname (secret, pass, etc.).

A digest or hash is a fixed-size value computed by hash function from any data. The identity of the data can be checked at any later time by recomputing the hash and comparing it with the stored one. If the checksums match, the data was almost certainly not altered.

Thus, instead of plain text value "Hancock" in the CRM will be stored "jCVf/9aS9M+zSUeg/gBBZ/nrvIg=". That's enough to compute a digest for value provided by client and compare it with the stored one. Note, you compare digests not secret values themselves.

Let's see an example.

To calculate the hash values, we will use the System.Security.Cryptography.HMACSHA1 type from the .NET Framework Class Library. This class computes a Hash-based Message Authentication Code (HMAC) using the SHA1 hash function.

HMACSHA1 hash = new HMACSHA1();    

// use algorithm with key (see reference below); key value could be stored in configuration file like app.config or web.config
hash.Key = GetSHA1Key();

// get secret value
string secretText = "The_secret_value_of_mother's_maiden_name";

// compute the hash, and convert it to Base64 string
string hashValue = Convert.ToBase64String(hash.ComputeHash(Encoding.Unicode.GetBytes(secretText)));

After that, the hash value is simply stored in CRM. It's impossible to reconstruct the secret from digest because it's the result of one-way function. The value of this hash are not interesting, it can be only altered or removed, but the secret value will remain unknown.

In proper time a client calls the secret value, which has to be compared with available in CRM. Compute the digest for client's secret with the same algorithm that was used before. If digests are equal - client's secret value is confirmed.

Now, imagine that instead of the bank call center, and mother's maiden name we have access to a Personal Account with password... Nothing changes, except that the calculation and verification of hashes is automatic, and the secret value is known only to the client.


HMACSHA1 reference:

HMACSHA1 is a type of keyed hash algorithm that is constructed from the SHA1 hash function and used as an HMAC, or hash-based message authentication code. The HMAC process mixes a secret key with the message data, hashes the result with the hash function, mixes that hash value with the secret key again, then applies the hash function a second time. The output hash is 160 bits in length.

An HMAC can be used to determine whether a message sent over an insecure channel has been tampered with, provided that the sender and receiver share a secret key. The sender computes the hash value for the original data and sends both the original data and hash value as a single message. The receiver recalculates the hash value on the received message and checks that the computed HMAC matches the transmitted HMAC.

Any change to the data or the hash value will result in a mismatch, because knowledge of the secret key is required to change the message and reproduce the correct hash value. Therefore, if the original and computed hash values match, the message is authenticated.

The SHA-1 (Secure Hash Algorithm, also called SHS, Secure Hash Standard) is a cryptographic hash algorithm published by the United States Government. It produces a 160-bit hash value from an arbitrary length string.

HMACSHA1 accepts keys of any size, and produces a hash sequence of length 160 bits.

Ваша оценка: Пусто Средняя: 2.9 (33 голосов)


Отправить комментарий

Содержание этого поля является приватным и не предназначено к показу.
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Доступны HTML теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.
  • Syntax highlight code surrounded by the {syntaxhighlighter SPEC}...{/syntaxhighlighter} tags, where SPEC is a Syntaxhighlighter options string or "class="OPTIONS" title="the title".

Подробнее о форматировании

Enter the characters shown in the image.
Работает на Drupal, система с открытым исходным кодом.