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, <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 >>> >> > Disclaimer: > > Privileged & confidential information is contained in this message > (including all attachments). If you are not an intended recipient of this > message, please destroy this message immediately and kindly notify > the sender by reply e-mail. Any unauthorised use or dissemination of this > message in any manner whatsoever, in whole or in part, is strictly > prohibited. This e-mail, including all attachments hereto, (i) is for > discussion purposes only and shall not be deemed or construed to be a > professional opinion unless expressly stated otherwise, and (ii) is not > intended, written or sent to be used, and cannot and shall not be used, for > any unlawful purpose. This communication, including any attachments, may > not be free of viruses, interceptions or interference, and may not be > compatible with your systems. You should carry out your own virus checks > before opening any attachment to this e-mail. The sender of this e-mail and > *Fynarfin Tech Private Limited* shall not be liable for any damage that > you may sustain as a result of viruses, incompleteness of this message, a > delay in receipt of this message or computer problems experienced. >
