SIF v3 Framework uses shared secret passwords saved in clear text

[kunalyadavdfe]

Environment - "Security": SIF v3 Framework uses shared secret passwords saved in clear text. This is not secure for any implementation. SIF Framework needs to incorporate OAUTH as part of its core code.
Shared Secret – This is like a typical password field and is stored unencrypted within the SIF framework database. Potentially anyone who has access to the database can read this and create fake consumer applications easily to send spurious data to the functional service. SIF needs to be secure across all its framework components rather than just relying on transport level security

[iantasker]

@kunalyadavdfe I am going to split OAuth into a separate tickets as this is an enhancement. Please see ticket #25

[iantasker]

@drjonnicholson & @rafidzal What are your thoughts on this? Should the field be migrated to a hash or reversible password?

@joerghuber How is this handled in the java version?

Encrypting the database can mitigate this so have tagged this issue as an enhancement instead of a bug.

[joerghuber]

In the Java version it is held as clear text in a DB. If some one get access to your database you have other problems than just the password. Your database should be well protected through firewalls and other means. Also since the password or related environment is for integration purpose between systems rather holding sensitive data it is not a critical issue.

[rafidzal]

By default, the SIF Framework provides a simple implementation for the management of Consumer and Provider settings through the IFrameworkSettings interface. The current implementation uses a configuration file purely for the sake of convenience and to simplify the provided demo projects. This includes the clear text storage of the shared secret. It is expected that for an enterprise-level solution, developers implement their own settings class and update the SettingsManager class (until such time as a DI framework can be incorporated). The documentation will be enhanced to better explain how this can be achieved.

[mattharris5]

My understanding is that the shared secrets in SIF work as a symmetric key, not a password. Since it is used in unattended settings (system to system communication) the server has to know the value and therefore it needs to be stored in some sort of decryptable format. You could store the keys encrypted and maintain the decryption key in application memory, but if someone compromises the system or the application they'll likely have access to both anyway, so multi-layer system security is imperative (as @joerghuber stated previously).

Regardless, I agree that implementation of OAuth is a better solution and SIF supports that too.

[dingvarson]

The Ricone.org Implementation Used OAuth successfully, but there is the communications between the auth and DataAPI server which need to be considered. The designs done prior to building R1 I would be happy to share and all our learnings. D. Daniel Ingvarson dan@the.inter.net.au AU: +61 (0)403 832 621 US +1 (202) 604 1686 Skype: m-dingvarson

…

On Dec 22, 2016, at 12:51 PM, Matt Harris ***@***.***> wrote: My understanding is that the shared secrets in SIF work as a symmetric key, not a password. Since it is used in unattended settings (system to system communication) the server has to know the value and therefore it needs to be stored in some sort of decryptable format. You could store the keys encrypted and maintain the decryption key in application memory, but if someone compromises the system or the application they'll likely have access to both anyway, so multi-layer system security is imperative (as @joerghuber <https://github.com/joerghuber> stated previously). Regardless, I agree that implementation of OAuth is a better solution and SIF supports that too. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIqqZcJ7SUj0M8HVXp2V7Wp1f6DumZcpks5rKriSgaJpZM4LNE9Q>.