Hello jbilling dev. team,

After evaluating the software, I have to admit that business logic and GUI are really great. However, security of sensitive data is the area requires more improvement especially if jbilling aims for mid and large corp market.

Please feel free to discuss this proposal and let everyone know if it is realistic or not.

-------------------------------------------------------------------
Suggested security framework logic for Jbilling (draft v.1)

Note: recommendations are based on JB v.1.0.7

Used terminology:

* sensitive data: clients'/customers' financial data like credit card number and name, bank information. If I've missed something, please add more;

* data encryption key (or data key): key which is used to encrypt/decrypt sensitive data;

* key enabler: one time key to enable jbilling standard run mode. Can be a password, symmetric key, or a private key if asymmetric encryption used;

* jbilling secure run mode: no access to sensitive data and no auto billing, customers can only delete sensitive data. Any modification and addition for sensitive data are not allowed;

* jbilling standard run mode: all jbilling functionality is available, including sensitive data manipulation;

I. User authentication

Recommended changes:

1. separate security methods for user authentication and sensitive data encryption since they have different logics and requires different protection techniques;

2. for user authentication use one way hashing with salting. SHA-256 is a default protocol. Keep MD5 as an optional for backward compatibility and SHA-384/SHA-512 as optional if company, using jbilling, requires more strict authentication. Using SHA-384/SHA-512 could result in performance issue so more performance testing needs to be done.

3. account locking after N-times unsuccessful logins. Default locking time - 30 mins. Admins should have ability to change these two variables (number of unsuccessful logins and locking period).

II. Sensitive data protection

1. Data encryption method:

- Based on jbilling specifics, using symmetric data encryption is the most recommended in regards to performance, ease of implementation in the code and key management. Recommended protocol is AES 256 bit.

2. Key management:

a. Data encryption key has to be long enough and difficult to memorize. This can be achieved by automatic key generation process during the initial jbilling installation.

b. Generated data key has to be encrypted and stored in jbilling configuration file.

c. key enabler, which is used to protect a data key, is not stored on a system where jbilling is installed. Access to a key enabler is a one time access process, during jbilling start, and can be achieved by many ways (see section III.2).

III. Jbilling standard run mode:

1. Start. During the jbilling start (or after the start), application gains access to a key enabler and decrypt data key stored in a configuration file. Decrypted data key will be stored in the application memory (never on a file system, db or inside the code) and will be used as long as application running. If application stops/crashes, data key in the memory will be destroyed automatically.

OPTION: For higher protection, located in the memory decrypted data key, will be randomly moved from time to time withing an application memory map. This will be even harder for attacker to find a key within application memory. Shifting key in the memory could be overkill for jbilling but worth to suggest smile

2. Access methods to a key enabler. (This is the most tricky part)

a. provide a key enabler up front from a console during jbilling start. Key can be generated during initial application install;

b. during the application start, email will be sent with URL how to enter a key enabler and finish jbilling start. Key can be generated during initial application install;

c. jbilling starts completely and sends acknowledge email to a monitoring/admin team to provide a key enabler by accessing a specific URL which jbilling creates temporarily (and removes it after a key is entered). During the "wait" period, jbilling operates in the secure mode. Key can be generated during initial application install;

Last option (III.3.c) is the most attractive for me since it gives great flexibility to manage/administer jbilling and protect customers' data at the same time.

---------------------------------------------------
I think this is pretty much it :)

Please note, due to limited resources, we cannot implement everything on this proposal. If general framework logic is accepted, we are going to add SHA-256 and do quick "work around" for data key protection.

Thank you all.
Oleg Andriyevsky