geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aman Nanner/MxI Technologies <>
Subject Re: Plaintext passwords in Geronimo plans and config files
Date Thu, 22 Feb 2007 18:07:41 GMT

> Another approach for the db/jms connectors that I like although I'm
> not sure if its completely tested is to leave out the user/pw from
> the plans and use Subject based authentication.  With this approach
> you'd add a login module to the security realm that would insert
> appropriate UserPassword credentials into the subject for each db/jms
> you need to use.  When you need a connection to a db/jms these
> credentials would be used instead of those from the db/jms connector
> plan.

Is there any documentation on this?  I don't think I could use it anyhow
though, since our login module is DB-based, and so the login module itself
needs a pre-authenticated DB connection.

> Well, if say AMQ accepted hashes, that just means that the passwords
> are less likely to be remembered by a human.... the hashed value has
> become a password.

I don't think the hashed value wouldn't need to be known or remembered by
any human as a human would always configure AMQ or an AMQ client with a
plaintext password.  The client would hash the value and send the hashed
value to AMQ, and then AMQ would recognize that the password is hashed.  If
AMQ were itself to store the password as hashed, it would simply do a
direct comparison.  Otherwise, it would hash its stored password, and
compare that hash with the hash received from the client.

> I think this is definitely a topic that needs further consideration.
> My preference is that we come up with a solution that actually
> provides some level of security rather than relying on obscurity and
> as a result my bias is to object to schemes that simply obscure
> information.  They could still be useful and a good idea :-)

The hashing mechanism provides actual security, rather than just obscurity,
since a hash is one-way by definition (a plaintext password cannot be
recovered from a hash).

That being said, I think that obscurity is part of the security process.
Even if something can still be theoretically cracked, it's always good to
make it that much harder to crack.  An analogy is a lock for your bicycle;
somebody that's determine to steal your bike will likely be able to break
the lock, but nobody would argue that a bicycle lock doesn't add a great
deal of protection.  Maybe a better analogy is how Java code is obfuscated;
theoretically it could still be reverse-engineered, but it's much harder.


* This message is intended only for the use of the individual or entity to which it is addressed,
and may contain information that is privileged, confidential and exempt from disclosure under
applicable law. Unless you are the addressee (or authorized to receive for the addressee),
you may not use, copy or disclose the message or any information contained in the message.
If you have received this message in error, please advise the sender by reply e-mail , and
delete the message, or call (collect) 001 613 747 4698. *

View raw message