dspace.cfg in plain text

[Ramón Cordeiro]

Hi!

How can I hidden the credentials inside dspace.cfg. These data are in plain text and I worry about hacker atack.

Is there a way to encryp or hidden these data in the same time the dspace work without problem ?

[Mark H. Wood]

No. This is a general problem, not restricted to DSpace. If the
credentials in the DSpace configuration were encrypted, DSpace could
not start without the decryption key, which would have to be stored on
the system in plain text.

No closed system can be fully protected by secrets. It must hold at
least one unprotected secret or it cannot fully start. That one
unprotected secret could be used by an intruder to get the other
secrets.

The only way around this that I know of is to open the system:
require an operator to provide the key at startup. How to do that
would be very dependent on the local operating environment and
policies.

Here we use normal filesystem permissions to restrict access to the
DSpace configuration from console users; use the DBMS' access controls
to limit which remote hosts can connect to the database; and do not
expose remote console access on a public address.

--
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

[Adigun Samuel Akinwale]

have a firewall on it and only open the port to jspui or xmlui

> --
> All messages to this mailing list should adhere to the DuraSpace Code of
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-communi...@googlegroups.com.
> To post to this group, send email to dspace-c...@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-community.
> For more options, visit https://groups.google.com/d/optout.
>

[Kim Shepherd]

Yep, in general, not much you can do about this.

If it's the Postgres database credentials in particular you're worried about, you don't *have* to use password authentication, you could look into some Host-based Auth instead:

https://www.postgresql.org/docs/9.1/auth-pg-hba-conf.html  

https://www.postgresql.org/docs/9.1/auth-methods.html 

And potentially cert auth could be included as well.

 

...however, this doesn't help with API keys, SMTP passwords, etc. -- as they're all stored plaintext in the config file right now, for practical reasons, as Mark explained. This is fairly common for web applications -- if an attacker gains read access to your application directory on the webserver, you probably have bigger problems! And if they've only read files (ie. have not gained shell access or local network access) they should still be firewalled off from the database.

Related note: This is one reason why it's very important to *never* commit your local changes to dspace.cfg if they will end up in a shared repository somewhere, and to use gitignored local.cfg and build.properties instead.

M: k...@shepherd.nz
T: @kimshepherd
P: +6421883635

W: www.shepherd.nz

0CCB D957 0C35 F5C1 497E CDCF FC4B ABA3 2A1A FAEC

Virus-free. www.avg.com