Re: Fineract 1.x and RSA Encryption PR review
Could those same engaged Committers answer: * Does this provide an optional enhancement that can be ignored by implementations that don't want it? * If optional, is there a way to enforce it across a domain of APIs? i.e. require it. * Given that this creates a security model or enhances the fineract security model, what security framework are you referencing overall? (PCI is one, but somewhat limited) * If this breaks, or fails, or someone identifies an exploit that by-passes this, is this functionality and code sufficiently documented so that it can be maintained? On Sun, Aug 2, 2020 at 4:55 PM Michael Vorburger wrote: > I encourage the 3 committers engaged on this email thread to review and > merge that PR related to this if they stand behind it. I cannot. > > > On Sun, 26 Jul 2020, 21:12 Avik Ganguly, wrote: > >> Hi everyone, >> >> Thank you for showing interest in discussing this bit of infrastructure. >> >> My opinion is that it's valuable for black box pen testing and passing >> audits. Note that most auditors (especially outside the PCI space) don't >> have a fixed set of rules, guidelines or best practices. Even if they do >> have internal policies and guidelines, they are usually not updated for >> ages. What that means is that on the discretionary powers of an auditor, >> users of Fineract can be dragged through a lot of arbitrary rules. It is >> usual from an auditor perspective to think about :- >> >>- Request multiple layers of security. Additional encryption for "in >>transit" (ignoring that Fineract enforces HTTPS). Their concern can be >> what >>if HTTPS isn't always enforced - perhaps for communication between reverse >>proxy and application server or between API gateway and identity provider >> / >>application services. >>- Request sensible defaults for builds. ./gradlew clean war doesn't >>use OAuth or 2FA security profiles. >> - Regarding the general concern which Michael highlighted that >> "Web UI and App clients of the Authentication API to encrypt username >> and >> password will add significant complexity to such clients." - I agree >> but >> that is exactly what they want. Don't shoot the messenger. Perhaps we >> can >> explore if OAuth is implemented in all the client applications and >> make it >> the default or encrypt the username/password combo with this key in a >> new >> security profile. The build property -Penv=dev flag which you >> introduced >> can continue with the unencrypted basicauth security profile. >>- In the absence of SSO, other services which communicate with >>Fineract (perhaps the Twilio service is an example) uses basicauth with a >>system user's credentials stored in plaintext at rest in a properties >> file. >>- While there are other threads and activities discussing which >>industry standards can be adopted to make an audit go smoother, this is a >>bare bones implementation of asymmetric encryption which can be used for >>fields or request bodies in any API call and not tied to authentication. >> In >>addition to the use case mentioned by Vishwas, let's consider a biometric >>based txn use case. An Aadhaar User Agency (AUA) expects the request body >>to be encrypted using their public key. For user experience purposes, we >>don't want to use the same public key to encrypt at source as we want to >>add some fields to the request body from the backend. So the source / >>client applications use Fineract's biometric public key to encrypt which >> is >>then decrypted on platform side so that additional fields can be added to >>the request, encrypted using AUA public key and forwarded to AUA. >>- Digital signatures? >>- Setting password during user creation or first login or force >>password reset after time interval or change password APIs? >> >> >> P.S. - This is separate from any discussion around symmetric encryption >> use cases like encrypting PII, logs, variables stored in local storage >> (browser, Android), third party public keys, using tomcat DBCP to avoid >> cleartext DB username / password in server.xml and in Twilio service's >> properties file, etc. >> >> With best regards, >> Avik. >> ᐧ >> >> On Mon, Jul 20, 2020 at 8:25 AM Vishwas Babu >> wrote: >> >>> From reading a description of the issue in 1034 (have not looked into >>> the PR), an example where this functionality could eventually help (and is >>> distinct from our usage of HTTPS) would be in scenarios involving PCI >>> compliance in server to server communications. >>> >>> Assume Org A offers Fineract on a SaaS model. Further assume that Org A >>> is PCI SAQ D compliant, which means that this organization may >>> store/transmit personal details (Card number, CVV code, and expiry date) >>> linked to cards. >>> >>> Assume Org B is a lending Fintech that builds on top of the API's >>> offered by Org A and has use cases like
Re: Fineract 1.x and RSA Encryption PR review
I encourage the 3 committers engaged on this email thread to review and merge that PR related to this if they stand behind it. I cannot. On Sun, 26 Jul 2020, 21:12 Avik Ganguly, wrote: > Hi everyone, > > Thank you for showing interest in discussing this bit of infrastructure. > > My opinion is that it's valuable for black box pen testing and passing > audits. Note that most auditors (especially outside the PCI space) don't > have a fixed set of rules, guidelines or best practices. Even if they do > have internal policies and guidelines, they are usually not updated for > ages. What that means is that on the discretionary powers of an auditor, > users of Fineract can be dragged through a lot of arbitrary rules. It is > usual from an auditor perspective to think about :- > >- Request multiple layers of security. Additional encryption for "in >transit" (ignoring that Fineract enforces HTTPS). Their concern can be what >if HTTPS isn't always enforced - perhaps for communication between reverse >proxy and application server or between API gateway and identity provider / >application services. >- Request sensible defaults for builds. ./gradlew clean war doesn't >use OAuth or 2FA security profiles. > - Regarding the general concern which Michael highlighted that "Web > UI and App clients of the Authentication API to encrypt username and > password will add significant complexity to such clients." - I agree but > that is exactly what they want. Don't shoot the messenger. Perhaps we > can > explore if OAuth is implemented in all the client applications and make > it > the default or encrypt the username/password combo with this key in a > new > security profile. The build property -Penv=dev flag which you introduced > can continue with the unencrypted basicauth security profile. >- In the absence of SSO, other services which communicate with >Fineract (perhaps the Twilio service is an example) uses basicauth with a >system user's credentials stored in plaintext at rest in a properties file. >- While there are other threads and activities discussing which >industry standards can be adopted to make an audit go smoother, this is a >bare bones implementation of asymmetric encryption which can be used for >fields or request bodies in any API call and not tied to authentication. In >addition to the use case mentioned by Vishwas, let's consider a biometric >based txn use case. An Aadhaar User Agency (AUA) expects the request body >to be encrypted using their public key. For user experience purposes, we >don't want to use the same public key to encrypt at source as we want to >add some fields to the request body from the backend. So the source / >client applications use Fineract's biometric public key to encrypt which is >then decrypted on platform side so that additional fields can be added to >the request, encrypted using AUA public key and forwarded to AUA. >- Digital signatures? >- Setting password during user creation or first login or force >password reset after time interval or change password APIs? > > > P.S. - This is separate from any discussion around symmetric encryption > use cases like encrypting PII, logs, variables stored in local storage > (browser, Android), third party public keys, using tomcat DBCP to avoid > cleartext DB username / password in server.xml and in Twilio service's > properties file, etc. > > With best regards, > Avik. > ᐧ > > On Mon, Jul 20, 2020 at 8:25 AM Vishwas Babu > wrote: > >> From reading a description of the issue in 1034 (have not looked into the >> PR), an example where this functionality could eventually help (and is >> distinct from our usage of HTTPS) would be in scenarios involving PCI >> compliance in server to server communications. >> >> Assume Org A offers Fineract on a SaaS model. Further assume that Org A >> is PCI SAQ D compliant, which means that this organization may >> store/transmit personal details (Card number, CVV code, and expiry date) >> linked to cards. >> >> Assume Org B is a lending Fintech that builds on top of the API's offered >> by Org A and has use cases like pushing loan disbursals directly to >> external debit/credit cards (think of a country like the US where payment >> rails provided by card networks are faster/cheaper than account to account >> transfer alternatives like ACH or FedWire). To reduce compliance costs, Org >> B decides to opt for PCI compliance level SAQ A, this means that Org B >> will not have any card personal data (in un-encrypted format) flow through >> their network (or be stored by their servers). >> >> If Org B wants to allow their clients to provide details of >> their external debit /credit cards (assume from a mobile device) , these >> details need to be encrypted from the Clients device, flow to Org B's >> backend, from where a request is made to Org A's API. Org
Re: Fineract 1.x and RSA Encryption PR review
Hi everyone, Thank you for showing interest in discussing this bit of infrastructure. My opinion is that it's valuable for black box pen testing and passing audits. Note that most auditors (especially outside the PCI space) don't have a fixed set of rules, guidelines or best practices. Even if they do have internal policies and guidelines, they are usually not updated for ages. What that means is that on the discretionary powers of an auditor, users of Fineract can be dragged through a lot of arbitrary rules. It is usual from an auditor perspective to think about :- - Request multiple layers of security. Additional encryption for "in transit" (ignoring that Fineract enforces HTTPS). Their concern can be what if HTTPS isn't always enforced - perhaps for communication between reverse proxy and application server or between API gateway and identity provider / application services. - Request sensible defaults for builds. ./gradlew clean war doesn't use OAuth or 2FA security profiles. - Regarding the general concern which Michael highlighted that "Web UI and App clients of the Authentication API to encrypt username and password will add significant complexity to such clients." - I agree but that is exactly what they want. Don't shoot the messenger. Perhaps we can explore if OAuth is implemented in all the client applications and make it the default or encrypt the username/password combo with this key in a new security profile. The build property -Penv=dev flag which you introduced can continue with the unencrypted basicauth security profile. - In the absence of SSO, other services which communicate with Fineract (perhaps the Twilio service is an example) uses basicauth with a system user's credentials stored in plaintext at rest in a properties file. - While there are other threads and activities discussing which industry standards can be adopted to make an audit go smoother, this is a bare bones implementation of asymmetric encryption which can be used for fields or request bodies in any API call and not tied to authentication. In addition to the use case mentioned by Vishwas, let's consider a biometric based txn use case. An Aadhaar User Agency (AUA) expects the request body to be encrypted using their public key. For user experience purposes, we don't want to use the same public key to encrypt at source as we want to add some fields to the request body from the backend. So the source / client applications use Fineract's biometric public key to encrypt which is then decrypted on platform side so that additional fields can be added to the request, encrypted using AUA public key and forwarded to AUA. - Digital signatures? - Setting password during user creation or first login or force password reset after time interval or change password APIs? P.S. - This is separate from any discussion around symmetric encryption use cases like encrypting PII, logs, variables stored in local storage (browser, Android), third party public keys, using tomcat DBCP to avoid cleartext DB username / password in server.xml and in Twilio service's properties file, etc. With best regards, Avik. ᐧ On Mon, Jul 20, 2020 at 8:25 AM Vishwas Babu wrote: > From reading a description of the issue in 1034 (have not looked into the > PR), an example where this functionality could eventually help (and is > distinct from our usage of HTTPS) would be in scenarios involving PCI > compliance in server to server communications. > > Assume Org A offers Fineract on a SaaS model. Further assume that Org A > is PCI SAQ D compliant, which means that this organization may > store/transmit personal details (Card number, CVV code, and expiry date) > linked to cards. > > Assume Org B is a lending Fintech that builds on top of the API's offered > by Org A and has use cases like pushing loan disbursals directly to > external debit/credit cards (think of a country like the US where payment > rails provided by card networks are faster/cheaper than account to account > transfer alternatives like ACH or FedWire). To reduce compliance costs, Org > B decides to opt for PCI compliance level SAQ A, this means that Org B > will not have any card personal data (in un-encrypted format) flow through > their network (or be stored by their servers). > > If Org B wants to allow their clients to provide details of their external > debit /credit cards (assume from a mobile device) , these details need to > be encrypted from the Clients device, flow to Org B's backend, from where a > request is made to Org A's API. Org A would then decrypt the card details, > tokenize this card and pass an identifying token back to Org B's > backend, which is then used for identifying this card for future > transactions. > > Regards, > Vishwas > > On Thu, 16 Jul 2020 at 09:58, Awasum Yannick wrote: > >> Hi All, >> >> Is there anyone here with experience on how
Re: Fineract 1.x and RSA Encryption PR review
>From reading a description of the issue in 1034 (have not looked into the PR), an example where this functionality could eventually help (and is distinct from our usage of HTTPS) would be in scenarios involving PCI compliance in server to server communications. Assume Org A offers Fineract on a SaaS model. Further assume that Org A is PCI SAQ D compliant, which means that this organization may store/transmit personal details (Card number, CVV code, and expiry date) linked to cards. Assume Org B is a lending Fintech that builds on top of the API's offered by Org A and has use cases like pushing loan disbursals directly to external debit/credit cards (think of a country like the US where payment rails provided by card networks are faster/cheaper than account to account transfer alternatives like ACH or FedWire). To reduce compliance costs, Org B decides to opt for PCI compliance level SAQ A, this means that Org B will not have any card personal data (in un-encrypted format) flow through their network (or be stored by their servers). If Org B wants to allow their clients to provide details of their external debit /credit cards (assume from a mobile device) , these details need to be encrypted from the Clients device, flow to Org B's backend, from where a request is made to Org A's API. Org A would then decrypt the card details, tokenize this card and pass an identifying token back to Org B's backend, which is then used for identifying this card for future transactions. Regards, Vishwas On Thu, 16 Jul 2020 at 09:58, Awasum Yannick wrote: > Hi All, > > Is there anyone here with experience on how this PR can help Fineract? > https://github.com/apache/fineract/pull/1032 > > This might be valuable work but I don't understand the use case and > am reaching out to you all to see if someone can help. > > I tried to review it but could not understand it adequately to comfortably > merge. > > > Here is the JIRA: https://issues.apache.org/jira/browse/FINERACT-1034 > > Thanks. > Awasum >
Fineract 1.x and RSA Encryption PR review
Hi All, Is there anyone here with experience on how this PR can help Fineract? https://github.com/apache/fineract/pull/1032 This might be valuable work but I don't understand the use case and am reaching out to you all to see if someone can help. I tried to review it but could not understand it adequately to comfortably merge. Here is the JIRA: https://issues.apache.org/jira/browse/FINERACT-1034 Thanks. Awasum
