Web Client Security/Smart Client Security
Many of our Clients’ custom applications involve management of highly sensitive,
proprietary business data e.g. financial records, patient records, legal contracts,
transaction data, etc. The Smart Client platform is built to enable a trusted Client-Server
connection over the Internet, and can be readily configured to support
the most rigorous data security requirements.
Secure data storage, fully-encrypted data transfer payload, and privileged-based access to
the application at the feature-, data-, and reporting-levels are essential considerations for securing
proprietary business data and meeting your internal and external security requirements.
For example, the Smart Client architecture (based upon Microsoft SQL Server and the .NET
Framework) supports HIPAA standards for electronic information storage, encryption,
transfer and processing of patient-sensitive healthcare and patient data.
HTTPS
We care about integrity and security of your data, that's why we are using HTTPS.
It helps prevent attackers from tampering with the communications between Browser/Smart Client and Servers.
HTTPS protects the privacy and security of our users, it prevents intruders from being able to passively
listen to communications and steal sensitive data.
SQL Server Encryption
Server-based database security and management is a core consideration within secure
business application environments. MS SQL Server fully complies with technical requirements
for server-side data storage. Individual Database data elements can be stored, tracked
and secured and audited in any variety of methods supported by SQL Server.
Password Hashing
We use cryptographic hash functions to hash user passwords and other data which is to be stored in the
database one-way (unhashable back to original). With this approach even if the DB is compromised there is no way
to get back the original values, and we ourselves don’t know what they are. For example, a user enters their
password which is hashed and compared to the stored hash, PCA has no way of knowing their real password
even with access to the DB and our own hashing code.
File Security
We have a secure file service which uses keys to obfuscate the location of files on the server so that the client/server
do not expose information about the server’s file system over the network. Files can be manipulated (upload, download, moved, etc)
using these keys, which also check the user’s authorization.
Role-based User Privileges
All Smart Client applications use a standard, Admin-managed role-based security
framework for determining who gets access to what, at the application feature-, data-, and reporting-levels.
We use session keys, created after successful sign-in, for most calls to the database which identify the user,
their roles/permissions, and their access to data. These sessions can be managed via UI and terminated.
User accounts can also be disabled from signing-in and locked-out based on a pre-determined number of failed sign-ins.
Attempt to sign-in with or use older versions of the application can be allowed or disabled as well. All users are
assigned roles, privileges, and access to various subsets of data (organizations) if available inside the application.
There are robust configurations to manage the timeout of passwords, the strength of passwords, and approaches
for users to reset their own passwords if they forget.
Other Secure Implementations
Our product is signed making it easy to use and install on Windows. Our sensitive code is obfuscated,
making reverse-engineering difficult thus protecting from attackers that are searching for vulnerabilities.
Our application allows for a number of sign-in options which include application-managed users/passwords,
domain logins managed by through Windows services, Google sign-in, other Single Sign On options,
and two-step authentication using email. More than one sign-in method can be specified for an application.
For information stored to disk, such as in cases of “remember me” for sign-in, we use ProtectedData (.NET library from MS).
This uses the Data Protection API (DPAPI) of Windows OS and the current Windows user’s credentials to protected data.
We use EAS (.NET library from MS) for cases where we need two-way encryption. This can also be used for usernames and passwords,
such as when communicating to our sign-in service under SSL. In this way, sensitive information is not sent in clear-text
even though SSL in place in case there is some on-machine network snooping. Our service then decrypts the user/pass and stores
the password using SHA512 to DB, thereby securing it permanently for storage.