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 <[email protected]> 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, <[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. >> >
