Thread: Best Practices - Securing an Enterprise application using JBOSS & Postgres

On 06/08/11 12:18 AM, eyal edri wrote:
>
> currently i've chosen MD5 as the auth, but is that the best option?
>

thats the usual choice for JDBC apps.


--
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast

On 8/06/2011 3:18 PM, eyal edri wrote:
> What settings would you recommend for using postgres in an enterprise
> application together with jboss?

Most such applications have the database servers on an isolated network
only accessible to the app server, not to the wider world. In these
cases you'd usually limit the IP range(s) the database servers will
accept connections from, firewall them off, and use a decent auth scheme
like md5 or Kerberos. I suspect that most configurations use md5 auth
for simplicity, and it's a reasonable choice.

Kerberos is certainly stronger and should be used if your database
server and app server are not on the same machine and your network has
Kerberos infrastructure already deployed. I wouldn't bother rolling out
Kerberos just for PostgreSQL and PgJDBC.

In smaller configurations the database is often on the same machine as
the appserver and set to only listen on the loopback address
(127.0.0.1). In this case md5 auth is more than sufficient.

Because most app servers use a single username and password to connect
to the database and provide a pool of connections, there isn't much
advantage to using LDAP or other directory auth schemes. It's really
intended for situations where you already have a user directory and you
want users in it to all have direct logins to the database system. In an
application server you'd usually configure the *app* *server* to auth
users against LDAP, using fixed credentials unrelated to the logged in
user for its database connections behind the scenes.

Certificate auth with SSL is useful, but probably not necessary or
worthwhile for an app server environment.

I'd stick to md5 unless you're already used to Kerberos and have
Kerberos infrastructure.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

 On Wed, 8 Jun 2011 10:18:23 +0300, eyal edri wrote:
> What settings would you recommend for using postgres in an enterprise
> application together with jboss?
>
> there are numerous auth options (from the documentation):
>
>  19.3.1. Trust authentication [1]19.3.2. Password authentication [2]
> 19.3.3. GSSAPI authentication [3]19.3.4. SSPI authentication [4]
> 19.3.5. Kerberos authentication [5]19.3.6. Ident-based
> authentication [6] 19.3.7. LDAP authentication
> [7]19.3.8. Certificate authentication [8] 19.3.9. PAM authentication
> [9]
> and im not sure that the jdbc driver even supports all of them when
> jboss needs to access the db.
> currently ive chosen MD5 as the auth, but is that the best option?
> thanks
> Eyal.
>
> Links:
> ------
> [1]
>
> http://www.postgresql.org/docs/8.4/interactive/auth-methods.html#AUTH-TRUST
> [2]
>
> http://www.postgresql.org/docs/8.4/interactive/auth-methods.html#AUTH-PASSWORD
> [3]
>
> http://www.postgresql.org/docs/8.4/interactive/auth-methods.html#GSSAPI-AUTH
> [4]
>
> http://www.postgresql.org/docs/8.4/interactive/auth-methods.html#SSPI-AUTH
> [5]
>
> http://www.postgresql.org/docs/8.4/interactive/auth-methods.html#KERBEROS-AUTH
> [6]
>
> http://www.postgresql.org/docs/8.4/interactive/auth-methods.html#AUTH-IDENT
> [7]
>
> http://www.postgresql.org/docs/8.4/interactive/auth-methods.html#AUTH-LDAP
> [8]
>
> http://www.postgresql.org/docs/8.4/interactive/auth-methods.html#AUTH-CERT
> [9]
> http://www.postgresql.org/docs/8.4/interactive/auth-methods.html#AUTH-PAM


 It doesn't matter so much. I actually prefer storing user
 names/password in not a system accounts (so password in db, or LDAP -
 simpler to migrate settings). Certificate maybe hard to configure on
 JBoss and other application servers (this includes if something will go
 wrong long time to restore), but I think it's most secure, as your key
 store may be encrypted.

 You should actually only consider safty of storing of such passwords in
 database. If with md5 the password isn't digested like in DIGEST HTTP
 auth, and only md5 shortcut is transfferd it has no meaning if you will
 transfer over network clear password or md5 password (ok has if you use
 same password in at least two services both storing password with md5).
 On higher level you may note that MD5 is little bit out-dated and it's
 not considered secure, currently I think only SHA-256 is secure.

 If you suspect that someone on your network may sniff password use cert
 auth or kerberos or one of it mutations.

 Regards,
 Radek

On Wed, Jun 8, 2011 at 11:43 AM, Radosław Smogura
<rsmogura@softperience.eu> wrote:
>
> You should actually only consider safty of storing of such passwords in
> database. If with md5 the password isn't digested like in DIGEST HTTP auth,
> and only md5 shortcut is transfferd it has no meaning if you will transfer
> over network clear password or md5 password (ok has if you use same password
> in at least two services both storing password with md5). On higher level
> you may note that MD5 is little bit out-dated and it's not considered
> secure, currently I think only SHA-256 is secure.
>
> If you suspect that someone on your network may sniff password use cert auth
> or kerberos or one of it mutations.

While MD5 is considered broken for certain applications, it's still
perfectly valid for auth purposes.

On 09/06/11 03:07, Isak Hansen wrote:

> While MD5 is considered broken for certain applications, it's still
> perfectly valid for auth purposes.

MD5 rainbow tables can be calculated quickly using services easily
available to anyone (eg: EC2) and rainbow tables for passwords up to 8
chars have been successfully used in demo and real attacks several times
in the last year. It's looking pretty shakey.

That said, _properly_ _salted_ md5 is still likely to be strong enough
for most people's likely attack scenarios for quite some time to come.
It's only unsalted md5 that's dangerously stupid to use now - and it was
never exactly a good idea.

If you do your own user/password storage with a "users" table in the
database or whatever, make sure you salt the passwords for encryption.

--
Craig Ringer

 On Wed, 8 Jun 2011 21:07:12 +0200, Isak Hansen wrote:
> On Wed, Jun 8, 2011 at 11:43 AM, Radosław Smogura
> <rsmogura@softperience.eu> wrote:
>>
>> You should actually only consider safty of storing of such passwords
>> in
>> database. If with md5 the password isn't digested like in DIGEST
>> HTTP auth,
>> and only md5 shortcut is transfferd it has no meaning if you will
>> transfer
>> over network clear password or md5 password (ok has if you use same
>> password
>> in at least two services both storing password with md5). On higher
>> level
>> you may note that MD5 is little bit out-dated and it's not
>> considered
>> secure, currently I think only SHA-256 is secure.
>>
>> If you suspect that someone on your network may sniff password use
>> cert auth
>> or kerberos or one of it mutations.
>
> While MD5 is considered broken for certain applications, it's still
> perfectly valid for auth purposes.

 Just one tip, if you will trust all of 127.0.0.1 pleas bear in mind,
 that everyone who has access to db server may be a db superuser.

 Regards,
 Radek

In response to Craig Ringer <craig@postnewspapers.com.au>:

> On 09/06/11 03:07, Isak Hansen wrote:
>
> > While MD5 is considered broken for certain applications, it's still
> > perfectly valid for auth purposes.
>
> MD5 rainbow tables can be calculated quickly using services easily
> available to anyone (eg: EC2) and rainbow tables for passwords up to 8
> chars have been successfully used in demo and real attacks several times
> in the last year. It's looking pretty shakey.
>
> That said, _properly_ _salted_ md5 is still likely to be strong enough
> for most people's likely attack scenarios for quite some time to come.
> It's only unsalted md5 that's dangerously stupid to use now - and it was
> never exactly a good idea.
>
> If you do your own user/password storage with a "users" table in the
> database or whatever, make sure you salt the passwords for encryption.

Having recently researched this ...

If you're going to create your own password database, your best bet is
to use the system's supplied crypt() implementation to hash the passwords,
this avoids you having to know everything about safe salting and all that.

Once you've got access to a crypt() (or equivalent) implementation, however,
md5 looks kind of silly.  I agree that it's probably strong enough still,
but why bother?  Once you have access to crypt() you have a number of
hashing algorithms available, such as the obscenely powerful SHA512.  At
that point, the only reasons I can think of to still use md5 would be
compatibility with other systems that can't be improved, or if you're
on extremely limited hardware (like a mobile device).

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/

Bill Moran <wmoran@potentialtech.com> Thursday 09 of June 2011 14:44:31
> In response to Craig Ringer <craig@postnewspapers.com.au>:
> > On 09/06/11 03:07, Isak Hansen wrote:
> > > While MD5 is considered broken for certain applications, it's still
> > > perfectly valid for auth purposes.
> >
> > MD5 rainbow tables can be calculated quickly using services easily
> > available to anyone (eg: EC2) and rainbow tables for passwords up to 8
> > chars have been successfully used in demo and real attacks several times
> > in the last year. It's looking pretty shakey.
> >
> > That said, _properly_ _salted_ md5 is still likely to be strong enough
> > for most people's likely attack scenarios for quite some time to come.
> > It's only unsalted md5 that's dangerously stupid to use now - and it was
> > never exactly a good idea.
> >
> > If you do your own user/password storage with a "users" table in the
> > database or whatever, make sure you salt the passwords for encryption.
>
> Having recently researched this ...
>
> If you're going to create your own password database, your best bet is
> to use the system's supplied crypt() implementation to hash the passwords,
> this avoids you having to know everything about safe salting and all that.
>
> Once you've got access to a crypt() (or equivalent) implementation,
> however, md5 looks kind of silly.  I agree that it's probably strong
> enough still, but why bother?  Once you have access to crypt() you have a
> number of hashing algorithms available, such as the obscenely powerful
> SHA512.  At that point, the only reasons I can think of to still use md5
> would be compatibility with other systems that can't be improved, or if
> you're on extremely limited hardware (like a mobile device).

I think going with spirit of time SHA-256 should be considered. Personally I
use it sometimes insead of SHA-128. Only one problem may be availibility of
this for all drivers environments.

Regards,
Radek.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Thu, Jun 9, 2011 at 5:46 AM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> On 09/06/11 03:07, Isak Hansen wrote:
>
>> While MD5 is considered broken for certain applications, it's still
>> perfectly valid for auth purposes.
>
> MD5 rainbow tables can be calculated quickly using services easily
> available to anyone (eg: EC2) and rainbow tables for passwords up to 8
> chars have been successfully used in demo and real attacks several times
> in the last year. It's looking pretty shakey.

I'd think rainbow tables pose a similar threat to short passwords no
matter which algorithm is used.


> That said, _properly_ _salted_ md5 is still likely to be strong enough
> for most people's likely attack scenarios for quite some time to come.
> It's only unsalted md5 that's dangerously stupid to use now - and it was
> never exactly a good idea.

Indeed, algorithm selection is just one small piece of getting crypto right.

Note that I'm not recommending MD5 for anything new; the hash is
certainly flawed and could contain more vulnerabilities. I'm just
speaking up against advice to stay away from md5 auth in postgres,
which AFAIK is just ignorant parroting.


Isak

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Bill Moran <wmoran@potentialtech.com> Thursday 09 of June 2011 14:44:31
> In response to Craig Ringer <craig@postnewspapers.com.au>:
> > On 09/06/11 03:07, Isak Hansen wrote:
> > > While MD5 is considered broken for certain applications, it's still
> > > perfectly valid for auth purposes.
> >
> > MD5 rainbow tables can be calculated quickly using services easily
> > available to anyone (eg: EC2) and rainbow tables for passwords up to 8
> > chars have been successfully used in demo and real attacks several times
> > in the last year. It's looking pretty shakey.
> >
> > That said, _properly_ _salted_ md5 is still likely to be strong enough
> > for most people's likely attack scenarios for quite some time to come.
> > It's only unsalted md5 that's dangerously stupid to use now - and it was
> > never exactly a good idea.
> >
> > If you do your own user/password storage with a "users" table in the
> > database or whatever, make sure you salt the passwords for encryption.
>
> Having recently researched this ...
>
> If you're going to create your own password database, your best bet is
> to use the system's supplied crypt() implementation to hash the passwords,
> this avoids you having to know everything about safe salting and all that.
>
> Once you've got access to a crypt() (or equivalent) implementation,
> however, md5 looks kind of silly.  I agree that it's probably strong
> enough still, but why bother?  Once you have access to crypt() you have a
> number of hashing algorithms available, such as the obscenely powerful
> SHA512.  At that point, the only reasons I can think of to still use md5
> would be compatibility with other systems that can't be improved, or if
> you're on extremely limited hardware (like a mobile device).

I think going with spirit of time SHA-256 should be considered. Personally I
use it sometimes insead of SHA-128. Only one problem may be availibility of
this for all drivers environments.

Regards,
Radek.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

On Thu, Jun 9, 2011 at 5:46 AM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> On 09/06/11 03:07, Isak Hansen wrote:
>
>> While MD5 is considered broken for certain applications, it's still
>> perfectly valid for auth purposes.
>
> MD5 rainbow tables can be calculated quickly using services easily
> available to anyone (eg: EC2) and rainbow tables for passwords up to 8
> chars have been successfully used in demo and real attacks several times
> in the last year. It's looking pretty shakey.

I'd think rainbow tables pose a similar threat to short passwords no
matter which algorithm is used.


> That said, _properly_ _salted_ md5 is still likely to be strong enough
> for most people's likely attack scenarios for quite some time to come.
> It's only unsalted md5 that's dangerously stupid to use now - and it was
> never exactly a good idea.

Indeed, algorithm selection is just one small piece of getting crypto right.

Note that I'm not recommending MD5 for anything new; the hash is
certainly flawed and could contain more vulnerabilities. I'm just
speaking up against advice to stay away from md5 auth in postgres,
which AFAIK is just ignorant parroting.


Isak

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general