Improving OFBiz security

[Ted Byers]

I need to add use of PKI, with document signing, to OFBiz

What would I need to do to configure OFBiz to require client side
certificates, and where would I modify the forms sent to the client's
browser so that it includes a JavaScript file that will support use of
the client's private key to sign and encrypt the document/data
submitted when the form's submit button is clicked?  I guess this is
two questions, the first being use/requirement for the client to
supply a client side certificate, and the second involves modification
of the interface so that data can be encrypted and signed.

In due course, I may even need to alter the content displayed to the
client depending on whether or not there is a client side certificate.

Thanks

Ted

[Paul Foxworthy]

Hi Ted,

You could use standard SSL support for client certificate authentication. You can configure the web server to require a client certificate. Here's how to to it in Apache: http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html#allclients

You need to find a secure way to send a client certificate to your users, and they need to import the client certificate into the browser. This would be external to OFBiz. The entire web application, not just form submission, would be encrypted, tamper-proof and authenticated, and that would be transparent to the OFBiz application.

Web browsers and operating systems already have certificate stores, and you could just use them without needing to do anything special. Certificate deployment would be an annoyance, but a one-off annoyance.

If you want to do it internal to the application with Javascript, you are in effect rewriting the SSL infrastructure in your own Javascript code. Your code doesn't have a secure key store and is subject to risks of code injection and so on. See the rant on this subject at

http://www.matasano.com/articles/javascript-cryptography/

If you must build something like this in Javascript, these are some libraries that might help:

http://ats.oka.nu/titaniumcore/js/crypto/readme.txt
http://crypto.stanford.edu/sjcl/ (symmetric AES only)
http://www-cs-students.stanford.edu/~tjw/jsbn/

Hope that helps.

Cheers

Paul Foxworthy

Ted Byers wrote

I need to add use of PKI, with document signing, to OFBiz

What would I need to do to configure OFBiz to require client side
certificates, and where would I modify the forms sent to the client's
browser so that it includes a JavaScript file that will support use of
the client's private key to sign and encrypt the document/data
submitted when the form's submit button is clicked?  I guess this is
two questions, the first being use/requirement for the client to
supply a client side certificate, and the second involves modification
of the interface so that data can be encrypted and signed.

In due course, I may even need to alter the content displayed to the
client depending on whether or not there is a client side certificate.

Thanks

Ted

[varun]

CONTENTS DELETED

The author has deleted this message.

[Ted Byers]

Hi Paul,

Thanks.

On Thu, May 23, 2013 at 2:25 AM, Paul Foxworthy <[hidden email]> wrote:
> Hi Ted,
>
> You could use standard SSL support for client certificate authentication.
> You can configure the web server to require a client certificate. Here's how
> to to it in Apache:
> http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html#allclients
>
Yes, I am aware of this, as well as how to do it using Apache's httpd
server.  But I was under the impression that OFBiz used a customized
version of Apache Tomcat, and I do not know how to handle SSL in
Tomcat in general nor how to configure it to use or better require use
of client side certificates.  I do not even know where OFBiz puts its
container when it is installed (in my case on Suse Linux).

> You need to find a secure way to send a client certificate to your users,
> and they need to import the client certificate into the browser. This would
> be external to OFBiz. The entire web application, not just form submission,
> would be encrypted, tamper-proof and authenticated, and that would be
> transparent to the OFBiz application.
>
I am aware of this too.  I have a handle on that, involving contact
between a registration authority and the users, and issuance of single
use credentials to the users, for access (over HTTPS) to a specific
website (written in Perl),  The RA would establish, also, a set of
challenge and response questions and answers with the users, so that
the identity of the user can be verified by the combinatin of single
use credentials and challenege/response questions.  This part of the
process, along with documentation the shows the RA's processes indeed
verify the users' identities, is entirely external to OFBiz, which is
why I didn't mention it before in this context.

> Web browsers and operating systems already have certificate stores, and you
> could just use them without needing to do anything special. Certificate
> deployment would be an annoyance, but a one-off annoyance.
>
Yes, I was planning on using this.

> If you want to do it internal to the application with Javascript, you are in
> effect rewriting the SSL infrastructure in your own Javascript code. Your
> code doesn't have a secure key store and is subject to risks of code
> injection and so on. See the rant on this subject at
>
> http://www.matasano.com/articles/javascript-cryptography/
>
OOPS, we have a misunderstanding here.  The objective is NOT to
rewrite the SSL infrastructure, although it will be used extensively.
Rather, the objective is to provide support for non-repudiation, hence
relating the client side certificate provided by the client machine to
the identity of the user.  Further, as an example, consider the nature
of ecommerce: this is essentially a sales contract, and while one
dimension of the security need for the integrity of such a contract
involves assuring the identities of the parties to the contract, the
contract itself needs to be handled in a way in which the details of
it can readily be verified and assured against subsequent modification
without the express consent of both parties.  Thus, in ecommerce, at
the checkout page, we need all the data in the shopping cart to be
included on the checkout page, and we want that, along with the amount
of the transaction, timestamp, &c., to be put into a single document
and signed and encrypted.  The resulting binary data would be stored
with the transaction data, and made easily retrievable/viewable by
both both parties to the sales contract and the banks used by the
merchant and customer (in case the custmer takes a dispute to the
issuing bank and demands a chargeback - such a document would be
priceless for the bans to determine whether or not there was a valid
sales contract between a merchant and client and is presently
generally unavailable in card not present transactions).  While
ecommerce is an obvious application for what I have in mind, I can see
other parts of OFBiz which may involve some sort of contract between
parties and which may benefit from having this sort of capability
(relations between different departments within a company?
accountability of staff to their supervisor? others, to be requested
by parties using ofbiz?).

The thing is that if the application server asks for a client side
certificate, the client's browser will offer one from the browser's or
OS' store (I am not sure if, when the store contains more than one
client side certificate if the browser asks the user which one to
send, but I'll examine this complication in due course).  But then, I
would expect that one can get at the client's ID from that certificate
using code written in Java just as one can using Perl (I dont recall
the details, or whether I'd need to use openssl installed on the
server and invoked from Perl, but I recall seeing it can be done
without too too much pain), so that what the certificate says about
the client's identity can be stored with the signed and encrypted
document (which, of course, the client's public key can be used to
decrypt the document and verify the signature).  At this stage, I am
not entirely certain whether or not this document really needs to be
encrypted or if it can simply be signed (what is critical is that any
alteration of the document be readily detected, that the signature
reliably identifies the client, and that both parties have a copy).
These are considerations that use of SSL or TLS do not address (as far
as I can tell, anyway).

> If you must build something like this in Javascript, these are some
> libraries that might help:
>
> http://ats.oka.nu/titaniumcore/js/crypto/readme.txt
> http://crypto.stanford.edu/sjcl/ (symmetric AES only)
> http://www-cs-students.stanford.edu/~tjw/jsbn/
>
> Hope that helps.
>

Thanks, I will take a look at these resources.

> Cheers
>
> Paul Foxworthy
>

Cheers

Ted

>
> Ted Byers wrote
>> I need to add use of PKI, with document signing, to OFBiz
>>
>> What would I need to do to configure OFBiz to require client side
>> certificates, and where would I modify the forms sent to the client's
>> browser so that it includes a JavaScript file that will support use of
>> the client's private key to sign and encrypt the document/data
>> submitted when the form's submit button is clicked?  I guess this is
>> two questions, the first being use/requirement for the client to
>> supply a client side certificate, and the second involves modification
>> of the interface so that data can be encrypted and signed.
>>
>> In due course, I may even need to alter the content displayed to the
>> client depending on whether or not there is a client side certificate.
>>
>> Thanks
>>
>> Ted
>
>
>
>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.coherentsoftware.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Improving-OFBiz-security-tp4641462p4641485.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

[Paul Foxworthy]

Hi Ted,

OK, I understand your goals better now.

For Tomcat, see http://tomcat.apache.org/tomcat-7.0-doc/config/http.html and search for the clientAuth setting.

Are you envisaging that the registration authority you mention will be your own server or a third party? If the RA receives valid authentication information and issues the customer with a certificate containing a private key, you should be able to demonstrate that you don't know the key, and therefore you are not in a position to forge an order from the customer.

I doubt that a bank, faced with a chargeback request from a customer, will set any store on a document that you claim has been signed with a private key known only to the customer. Their choices are:

1. Audit your application to verify your claim that the customer must have signed and approved the contract. Verify the encrypted document is tamper-proof. Verify that the customer is indeed the owner of the relevant client certificate, and nobody else could possible know the key. Evaluate the veracity of the customer's claim that the key "must have been pinched by somebody else". Cost: weeks of time and thousands of dollars
2. Just repay the customer and claw the money back from the merchant's bank account. Cost: almost zero.

If you haven't ahead of time negotiated with every bank that any customer might use, they would, I think,   be on the customer's side and not yours in the case of any dispute.

Have you considered one of the e-signature services like Echosign (www.echosign.adobe.com), Secured Signing (www.securedsigning.com), Docusign (www.docusign.com/) or SignNow (signnow.com)? I see SignNow talks about an API so you can integrate their service into applications. I presume others do a similar thing. The bank may have heard of them before, and you have an audit trail provided by an independent third party. You could receive an order via a shopping cart in the usual way, and say to the customer the contract will be sent via one of these services, and the order will be filled once they sign the contract.

If part of the point is that a customer or the bank can independently verify that the transaction was done and hasn't been altered by you, why should they believe anything that comes from your web site? While you could deliver a document with a signature created with your private key, the software that verifies that signature would need to be from a third party and not you to give the customer any confidence no tampering was done.

And one more thing I'd consider: bricks and mortar retailers need to factor "shrinkage" like pilfering and shoplifting into their pricing. If you think that a minority of customers might repudiate a transaction, would you be better off self-insuring for the risk? You could set your prices to cover the risk, make provision for it as part of every sale's proceeds, and live with it when the bad thing happens. That might be more cost-effective than investing in an elaborate non-repudiation scheme.

One of our clients had a situation where the goods were delivered and the courier had a record of the deliveree's name and a signature which appeared to be the right name. The customer said it wasn't them, somebody else was pretending to be them, don't know who. Short of suing, our client could only refund their credit card and refuse to do business with them again. So a customer can conceivably repudiate a sale even when the sales contract is agreed by everyone.

I haven't done it, but I agree it should be possible to map from a client certificate to a user's identity. Similar things are discussed here http://www.servlets.com/archive/servlet/ReadMsg?msgId=518530&listName=tomcat-user and here (for Spring) http://static.springsource.org/spring-security/site/docs/3.0.x/reference/x509.html

Cheers

Paul Foxworthy

[Ted Byers]

Thanks Paul,

Actually, there are two other aspcts of this that may alter your
assessment,  First, I am looking to set up a prior arrangement with a
processing bank (a potential ally in any dispute with an issuing bank
- establishing a trust relationship between me and the bank, and this
would be the bank that processes the transaction for the merchant - it
only works for those merchants who can get an account with a bank with
which I have established such a relationship), and second, I am not
the merchant, but rather, providing services to merchants (including
use of OFBiz's back office functionality), so the data actually never
touches a machine in the merchant's hands.  I would provide an
interface to my RA (so they never touch the machines either, just an
interface, suitably hardened (using my Perl talents), that lets them
enter the data they need to provide), as well as a web interface to
the customers (again the only interaction I have with them).  I would
agree that this is not the sort of thing a merchant could effectively
do on his own; but it becomes feasible if a third party, like myself,
makes it happen with the aide of a prior relationship with one or more
processing banks (it would be even more effective, though, if the
issuing banks themselves became registration authorities (assuming
they do the due diligence to verify the identities of the people to
whom they issue credit cards ;-)     ).

And note, this only deals with one of the many kinds of fraud, but the
most frequent cause of ecommerce merchant bankruptcies I have seen.

Cheers

Ted

On Tue, May 28, 2013 at 2:16 AM, Paul Foxworthy <[hidden email]> wrote:

> Hi Ted,
>
> OK, I understand your goals better now.
>
> For Tomcat, see http://tomcat.apache.org/tomcat-7.0-doc/config/http.html and
> search for the clientAuth setting.
>
> Are you envisaging that the registration authority you mention will be your
> own server or a third party? If the RA receives valid authentication
> information and issues the customer with a certificate containing a private
> key, you should be able to demonstrate that you don't know the key, and
> therefore you are not in a position to forge an order from the customer.
>
> I doubt that a bank, faced with a chargeback request from a customer, will
> set any store on a document that you claim has been signed with a private
> key known only to the customer. Their choices are:
>
> 1. Audit your application to verify your claim that the customer must have
> signed and approved the contract. Verify the encrypted document is
> tamper-proof. Verify that the customer is indeed the owner of the relevant
> client certificate, and nobody else could possible know the key. Evaluate
> the veracity of the customer's claim that the key "must have been pinched by
> somebody else". Cost: weeks of time and thousands of dollars
> 2. Just repay the customer and claw the money back from the merchant's bank
> account. Cost: almost zero.
>
> If you haven't ahead of time negotiated with every bank that any customer
> might use, they would, I think,   be on the customer's side and not yours in
> the case of any dispute.
>
> Have you considered one of the e-signature services like Echosign
> (www.echosign.adobe.com), Secured Signing (www.securedsigning.com), Docusign
> (www.docusign.com/) or SignNow (signnow.com)? I see SignNow talks about an
> API so you can integrate their service into applications. I presume others
> do a similar thing. The bank may have heard of them before, and you have an
> audit trail provided by an independent third party. You could receive an
> order via a shopping cart in the usual way, and say to the customer the
> contract will be sent via one of these services, and the order will be
> filled once they sign the contract.
>
> If part of the point is that a customer or the bank can independently verify
> that the transaction was done and hasn't been altered by you, why should
> they believe anything that comes from your web site? While you could deliver
> a document with a signature created with your private key, the software that
> verifies that signature would need to be from a third party and not you to
> give the customer any confidence no tampering was done.
>
> And one more thing I'd consider: bricks and mortar retailers need to factor
> "shrinkage" like pilfering and shoplifting into their pricing. If you think
> that a minority of customers might repudiate a transaction, would you be
> better off self-insuring for the risk? You could set your prices to cover
> the risk, make provision for it as part of every sale's proceeds, and live
> with it when the bad thing happens. That might be more cost-effective than
> investing in an elaborate non-repudiation scheme.
>
> One of our clients had a situation where the goods were delivered and the
> courier had a record of the deliveree's name and a signature which appeared
> to be the right name. The customer said it wasn't them, somebody else was
> pretending to be them, don't know who. Short of suing, our client could only
> refund their credit card and refuse to do business with them again. So a
> customer can conceivably repudiate a sale even when the sales contract is
> agreed by everyone.
>
> I haven't done it, but I agree it should be possible to map from a client
> certificate to a user's identity. Similar things are discussed here
> http://www.servlets.com/archive/servlet/ReadMsg?msgId=518530&listName=tomcat-user
> and here (for Spring)
> http://static.springsource.org/spring-security/site/docs/3.0.x/reference/x509.html
>
> Cheers
>
> Paul Foxworthy
>
>
>
>
> -----
> --
> Coherent Software Australia Pty Ltd
> http://www.coherentsoftware.com.au/
>
> Bonsai ERP, the all-inclusive ERP system
> http://www.bonsaierp.com.au/
>
> --
> View this message in context: http://ofbiz.135035.n4.nabble.com/Improving-OFBiz-security-tp4641462p4641563.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.

--
R.E.(Ted) Byers, Ph.D.,Ed.D.
[hidden email]
CTO
Merchant Services Corp.
17665 Leslie st., unit 30
Newmarket , Ontario
L3Y 3E3