Appboard/2.5/admin/security - Revision history

imported>Jason.nicholls: /* Passwords & Secrets */

2015-02-02T11:07:30Z

Passwords & Secrets

← Older revision		Revision as of 11:07, 2 February 2015
Line 23:		Line 23:
	* Single-Sign-On (SSO) tokens for proxied web applications (if not using auth pass-through)		* Single-Sign-On (SSO) tokens for proxied web applications (if not using auth pass-through)
	* access credentials if using an external configuration database		* access credentials if using an external configuration database
			* access credentials for LDAP repositories
	* access credentials for AppBoard Data Sources		* access credentials for AppBoard Data Sources
	* AppBoard session variables set ''encrypted''		* AppBoard session variables set ''encrypted''

imported>Jason.nicholls: /* Features & Recommendations */

2014-11-18T08:48:51Z

Features & Recommendations

← Older revision		Revision as of 08:48, 18 November 2014
Line 39:		Line 39:
	# Implement system-wide or domain-specific password policies to ensure end-users have secure passwords.		# Implement system-wide or domain-specific password policies to ensure end-users have secure passwords.
	# Use multi-factor authentication. For example, we have customers using CAC that makes use of HTTPS client authentication. Other options are possible via our extensible authentication handlers.		# Use multi-factor authentication. For example, we have customers using CAC that makes use of HTTPS client authentication. Other options are possible via our extensible authentication handlers.
	# Change the default encryption key as mentioned in the ''Passwords & Secrets'' section above.		# Change the default encryption key as mentioned in the ''Passwords & Secrets'' section above. Refer to the <tt>KeyCreate</tt> option in the [[enportal/5.5/admin/system_administration/CLI_utilities#Portal_Commands\|Portal Commands]] documentation.
	# If upgrading from a version prior to 2.5.2 then existing local user passwords would have been hashed using SHA-1. These cannot be automatically upgraded and it is recommended to change / force-change all local user passwords which will then be stored using SHA-256. This is ''not'' necessary for user accounts authenticated using external authentication providers such as Active Directory or any LDAP based provider as these passwords are not stored locally.		# If upgrading from a version prior to 2.5.2 then existing local user passwords would have been hashed using SHA-1. These cannot be automatically upgraded and it is recommended to change / force-change all local user passwords which will then be stored using SHA-256. This is ''not'' necessary for user accounts authenticated using external authentication providers such as Active Directory or any LDAP based provider as these passwords are not stored locally.
	# Disable the default accounts. Administrator privileges can be assigned to other users as needed (<tt>/portalAdministration</tt> role)		# Disable the default accounts. Administrator privileges can be assigned to other users as needed (<tt>/portalAdministration</tt> role)

imported>Jason.nicholls: /* Features & Recommendations */

2014-11-18T08:16:17Z

Features & Recommendations

← Older revision		Revision as of 08:16, 18 November 2014
Line 40:		Line 40:
	# Use multi-factor authentication. For example, we have customers using CAC that makes use of HTTPS client authentication. Other options are possible via our extensible authentication handlers.		# Use multi-factor authentication. For example, we have customers using CAC that makes use of HTTPS client authentication. Other options are possible via our extensible authentication handlers.
	# Change the default encryption key as mentioned in the ''Passwords & Secrets'' section above.		# Change the default encryption key as mentioned in the ''Passwords & Secrets'' section above.
			# If upgrading from a version prior to 2.5.2 then existing local user passwords would have been hashed using SHA-1. These cannot be automatically upgraded and it is recommended to change / force-change all local user passwords which will then be stored using SHA-256. This is ''not'' necessary for user accounts authenticated using external authentication providers such as Active Directory or any LDAP based provider as these passwords are not stored locally.
	# Disable the default accounts. Administrator privileges can be assigned to other users as needed (<tt>/portalAdministration</tt> role)		# Disable the default accounts. Administrator privileges can be assigned to other users as needed (<tt>/portalAdministration</tt> role)
	# Customize the login page. This can be used to disable form pre-fill or to provide/remove content as deemed necessary.		# Customize the login page. This can be used to disable form pre-fill or to provide/remove content as deemed necessary.

imported>Jason.nicholls: /* Passwords & Secrets */

2014-11-18T08:06:19Z

Passwords & Secrets

← Older revision		Revision as of 08:06, 18 November 2014
Line 28:		Line 28:
	In the above situations passwords and secrets are stored encrypted using AES (approved by [http://www.nist.gov/ NIST]). By default 128-bit keys are used however 192-bit and 256-bit keys are supported if using OpenJDK or the ''Unlimited Strength'' Java Cryptography Extension (JCE) is installed for [http://www.oracle.com/technetwork/java/javase/downloads/index.html Oracle Java]. Best practices are to create a new encryption key after installing the product.		In the above situations passwords and secrets are stored encrypted using AES (approved by [http://www.nist.gov/ NIST]). By default 128-bit keys are used however 192-bit and 256-bit keys are supported if using OpenJDK or the ''Unlimited Strength'' Java Cryptography Extension (JCE) is installed for [http://www.oracle.com/technetwork/java/javase/downloads/index.html Oracle Java]. Best practices are to create a new encryption key after installing the product.

	Also, for users that authenticate directly with the product versus an external authentication provider then a salted one-way hash is used to store the password. From ~~enPortal 5~~.5.2 the hashing algorithm used is SHA-256 (designed and published by [http://www.nist.gov/ NIST]), previous versions used SHA-1.		Also, for users that authenticate directly with the product versus an external authentication provider then a salted one-way hash is used to store the password. From AppBoard 2.5.2 the hashing algorithm used is SHA-256 (designed and published by [http://www.nist.gov/ NIST]), previous versions used SHA-1.

	== Features & Recommendations ==		== Features & Recommendations ==

imported>Jason.nicholls: /* Passwords & Secrets */

2014-11-18T08:06:00Z

Passwords & Secrets

← Older revision		Revision as of 08:06, 18 November 2014
Line 24:		Line 24:
	* access credentials if using an external configuration database		* access credentials if using an external configuration database
	* access credentials for AppBoard Data Sources		* access credentials for AppBoard Data Sources
			* AppBoard session variables set ''encrypted''

	In the above situations passwords and secrets are stored encrypted using ~~128-bit~~ AES (approved by [http://www.nist.gov/ NIST]). Best practices are to create a new encryption key after installing the product.		In the above situations passwords and secrets are stored encrypted using AES (approved by [http://www.nist.gov/ NIST]). By default 128-bit keys are used however 192-bit and 256-bit keys are supported if using OpenJDK or the ''Unlimited Strength'' Java Cryptography Extension (JCE) is installed for [http://www.oracle.com/technetwork/java/javase/downloads/index.html Oracle Java]. Best practices are to create a new encryption key after installing the product.

	Also, for users that authenticate directly with the product versus an external authentication provider then a salted one-way hash is used to store the password. ~~The~~ hashing algorithm used is SHA-1 (designed and published by [http://www.nist.gov/ NIST]).		Also, for users that authenticate directly with the product versus an external authentication provider then a salted one-way hash is used to store the password. From enPortal 5.5.2 the hashing algorithm used is SHA-256 (designed and published by [http://www.nist.gov/ NIST]), previous versions used SHA-1.

	== Features & Recommendations ==		== Features & Recommendations ==

imported>Jason.nicholls: /* Passwords & Secrets */

2014-10-17T09:27:24Z

Passwords & Secrets

← Older revision		Revision as of 09:27, 17 October 2014
Line 19:		Line 19:
	== Passwords & Secrets ==		== Passwords & Secrets ==

	enPortal and AppBoard need to store passwords or secrets for a number of different purposes where the passwords need to be ~~recoverable~~:		enPortal and AppBoard need to store passwords or secrets for a number of different purposes where the passwords need to be reused:

	* Single-Sign-On (SSO) tokens for proxied web applications (if not using auth pass-through)		* Single-Sign-On (SSO) tokens for proxied web applications (if not using auth pass-through)

imported>Jason.nicholls: /* Passwords & Secrets */

2014-10-17T09:25:48Z

Passwords & Secrets

← Older revision		Revision as of 09:25, 17 October 2014
Line 19:		Line 19:
	== Passwords & Secrets ==		== Passwords & Secrets ==

	enPortal and AppBoard need to store passwords or secrets for a number of different purposes:		enPortal and AppBoard need to store passwords or secrets for a number of different purposes where the passwords need to be recoverable:

	* user authentication (if not using an external auth provider such as LDAP)
	* Single-Sign-On (SSO) tokens for proxied web applications (if not using auth pass-through)		* Single-Sign-On (SSO) tokens for proxied web applications (if not using auth pass-through)
	* access credentials if using an external configuration database		* access credentials if using an external configuration database
	* access credentials for AppBoard Data Sources		* access credentials for AppBoard Data Sources

	~~By default all these~~ passwords and secrets are stored encrypted using 128-bit AES (approved by [http://www.nist.gov/ NIST]). Best practices are to create a new encryption key after installing the product.		In the above situations passwords and secrets are stored encrypted using 128-bit AES (approved by [http://www.nist.gov/ NIST]). Best practices are to create a new encryption key after installing the product.

			Also, for users that authenticate directly with the product versus an external authentication provider then a salted one-way hash is used to store the password. The hashing algorithm used is SHA-1 (designed and published by [http://www.nist.gov/ NIST]).

	== Features & Recommendations ==		== Features & Recommendations ==

imported>Jason.nicholls: Created page with 'Category:AppBoard 2.5 {{DISPLAYTITLE:Product Security}} == Overview == The security of our products, and the security features provided by the products, is of great importan...'

2014-10-03T09:48:52Z

Created page with 'Category:AppBoard 2.5 {{DISPLAYTITLE:Product Security}} == Overview == The security of our products, and the security features provided by the products, is of great importan...'

New page

[[Category:AppBoard 2.5]]
{{DISPLAYTITLE:Product Security}}
== Overview ==

The security of our products, and the security features provided by the products, is of great importance to Edge Technologies. Our commitment is realized through the adoption of best practice development processes, staying abreast of known vulnerabilities in components used in the products, and addressing or enhancing the product security features based on feedback from customers.

Our software is deployed in many different scenarios such as Internet facing portals, internal corporate usage, and secure environments with multi-factor authentication. One key reason for this is the ability of enPortal to harden proxied web applications such as restricting who and what someone can access - something the proxied web application may not be able to provide itself. enPortal has even been used to address known vulnerabilities in proxied web applications such as Cross-site scripting (XSS) if the vendor of that application is not able to address it.

AppBoard provides limited views into various data sources, allowing for tailored information to be shown based on the role of a user. This may not be possible if users would have direct access to the data, or the native application to access this data doesn't provide any kind of restriction mechanism.

== Contacting Edge ==

To report security concerns or issues regarding Edge products, please contact [[support/technical_support|Technical Support]].

== Security Patches ==

If Edge becomes aware of a vulnerability in a component used by our products, or within the product itself, depending on the severity we will either produce a patch for existing deployments or address the issue in the subsequent product release.

== Passwords & Secrets ==

enPortal and AppBoard need to store passwords or secrets for a number of different purposes:

* user authentication (if not using an external auth provider such as LDAP)
* Single-Sign-On (SSO) tokens for proxied web applications (if not using auth pass-through)
* access credentials if using an external configuration database
* access credentials for AppBoard Data Sources

By default all these passwords and secrets are stored encrypted using 128-bit AES (approved by [http://www.nist.gov/ NIST]). Best practices are to create a new encryption key after installing the product.

== Features & Recommendations ==

Edge Technologies enPortal and AppBoard have a common code base and the following set of features and recommendations apply to both unless otherwise indicated. Although we endeavour to provide a secure configuration out-of-the-box, due to interoperability and some items relying on specific configuration, it is recommended to be familiar with all the security related features and determine what suits your organization best.

# Run as non-root on Linux/UNIX systems. This is the default configuration. Running as root is possible, for instance to bind to port < 1024, however in this case it's recommended to use JSVC which can be used to bind to the port and give up privileges, or some external mechanism to act as the end point such as a load balancer which talks to the server on a port > 1024.
# enable SSL/TLS (HTTPS). The products ship with a self-signed certificate to enable for easy testing, however this certificate should be replaced as soon as possible.
# Ensure the latest supported version of Java is used on the server.
# Implement system-wide or domain-specific password policies to ensure end-users have secure passwords.
# Use multi-factor authentication. For example, we have customers using CAC that makes use of HTTPS client authentication. Other options are possible via our extensible authentication handlers.
# Change the default encryption key as mentioned in the ''Passwords & Secrets'' section above.
# Disable the default accounts. Administrator privileges can be assigned to other users as needed (<tt>/portalAdministration</tt> role)
# Customize the login page. This can be used to disable form pre-fill or to provide/remove content as deemed necessary.
# Restrict access to the host. Clients only require access to the single listening port of the server - and this should be the only port open to the clients. The server itself will need access to the proxied web applications (enPortal) and any data sources (AppBoard).
# Concurrent user sessions. By default a user can be logged in multiple times, however this can be changed so that only one session can exist for a given user. This really depends on your organizations usage and security policies.
# use the enPortal CRS to virtually harden proxied web applications. This may be to completely restrict the content that's exposed to users or even to require authentication when the web application doesn't support it.
# By default user and domain credentials are echoed in HTTP responses (but not the password). Some security analysis tools will identify this as a security vulnerability, and users can disable this functionality by editing/adding <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/custom.properties</tt> and adding the line <tt>jsp.usercookies=false</tt>.
# Cross-site scripting (XSS) and Vulnerability Tool Hardening:
#* enPortal core components are protected by performing input validation and a configurable set of rules checks all client requests (query, headers, body) for malicious matches.
#* The CRS can be used to provide protection to proxied web applications. Some default handlers are included with enPortal but disabled by default.
#* Refer to the [[enportal/5.5/admin/system_administration/security/xss_rules|Managing XSS Rules]] page for more information.
# SSL Browser Caching
#* By default, Appboard now marks all content (excpet for images, CSS, or Javascript) as non-cacheable, which is a suggestion to browsers not to retain such content for efficiency purposes. There is a property (<i>request.ssl.cache</i>, specified in WEB-INF/config/config.properties) which can be toggled to "true" and will cause XML, HTML, and SWF content to be cached, as well. Setting this to "true" may slightly increase client performance with the increased risk of possibly sensitive content being retained by browsers.