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.
