[jboss-as7-dev] How hard would it be to support key based auth by default to make life simpler and more secure ?

Tue Nov 15 07:26:53 EST 2011

Could there be a default setting that has local access unsecured and remote access password 
protected?

On 14/11/2011 17:00, Bill Burke wrote:
> Geez guys, we're not trying to have CIA/NSA level security out of the
> box.  We're just trying to prevent the case where a really stupid user
> (aka The Server Side) deploys their application on the internet without
> thinking one bit about security.
>
> On 11/14/11 9:56 AM, Andrig Miller wrote:
>> It's also a problem with servers with SSD's. I ran into this myself.
>>
>> Andy
>>
>> ------------------------------------------------------------------------
>>
>>      *From: *"Jason T. Greene"<jason.greene at redhat.com>
>>      *To: *"Darran Lofthouse"<darran.lofthouse at jboss.com>
>>      *Cc: *jboss-as7-dev at lists.jboss.org
>>      *Sent: *Monday, November 14, 2011 7:53:38 AM
>>      *Subject: *Re: [jboss-as7-dev] How hard would it be to support key
>>      based auth by default to make life simpler and more secure ?
>>
>>      It's something I thought about, we would have to make up a bunch of
>>      stuff in the CERT (not a big deal I guess). Although the thing I worry
>>      about is that cert generation requires gathering a major amount of
>>      entropy from /dev/random. It would seriously affect boot time, and it
>>      would potentially pause for a long period to gather more entropy. This
>>      is a problem for headless devices for example, that don't have a
>>      keyboard and mouse connected to them.
>>
>>      On 11/14/11 7:57 AM, Darran Lofthouse wrote:
>>       >  It would need to be SSL not SSH as we need to support the
>>      mechanism for
>>       >  both the Native interface and the HTTP interface but I am starting to
>>       >  like this as an out of the box scenario.
>>       >
>>       >  The advantage we have for the browser is we can always display a nice
>>       >  HTML page when they connect with full instructions, it is the other
>>       >  mechanisms where we have less opportunity to dynamically provide
>>      guidance.
>>       >
>>       >  On 11/14/2011 01:42 PM, Bill Burke wrote:
>>       >>  You could just have the app-server automatically generate the
>>      keys for
>>       >>  you the first time it ever boots (or even every boot cycle).
>>      Just have
>>       >>  the CLI look at a pre-defined directory for the generated
>>      key-pair. THe
>>       >>  idea here is that CLI works perfectly out-of-the-box with no
>>      config on
>>       >>  the same machine as the CLI runs on. What is still protected is a
>>       >>  remote machine accessing the app-server. This is fine, IMO.
>>       >>
>>       >>  Usability problems still exist though as you would need to
>>      import the
>>       >>  client-auth key into your browser. But, maybe this is a good
>>      thing as
>>       >>  it will require the user to think about how they want to secure the
>>       >>  app-server.
>>       >>
>>       >>  On 11/14/11 6:40 AM, Max Rydahl Andersen wrote:
>>       >>>>>>
>>       >>>>>>  These will make all examples that uses maven deploy plugin,
>>      cli scripts, arquillian, jboss tools etc. to somehow
>>       >>>>>>  either tell users to type in their username and full
>>      password in clear text in pom.xml and other files.
>>       >>>>>>
>>       >>>>>>  Which sounds worse to me than a default locked down to only
>>      localhost…but I'm not a security expert :)
>>       >>>>>>
>>       >>>>>>  I was wondering how hard it would be to make the
>>      authentication support key based auth by default and we make
>>       >>>>>>  the tools use ${user.name} and
>>      ${user.home}/.jboss/default.pub and .priv (or some other name) for
>>      the public/private keys ?
>>       >>>>>
>>       >>>>>  You would need a key-based SASL authentication mechanism.
>>      There are no
>>       >>>>>  standard ones as of right now. If you know of a key-based SASL
>>       >>>>>  mechanism that you think we should support, let me know and we'll
>>       >>>>>  evaluate it.
>>       >>>>
>>       >>>>  We would have to do noauth + SSL + trust. I think it's an
>>      option worth considering. The big problem though is that we have to
>>      have a setup process to generate the certs, which is greater
>>      complexity than the user/pass option. We would have to generate a
>>      host key pair and a client key pair.
>>       >>>
>>       >>>
>>       >>>  I'm not an expert on these things at all but eclipse uses
>>      http://www.jcraft.com/jsch/ to manage and create ssh keys and uses
>>      the standard .ssh location's etc.
>>       >>>
>>       >>>  Is something additional needed ?
>>       >>>
>>       >>>  /max
>>       >>>  http://about.me/maxandersen
>>       >>>
>>       >>>
>>       >>>
>>       >>>
>>       >>>  _______________________________________________
>>       >>>  jboss-as7-dev mailing list
>>       >>>  jboss-as7-dev at lists.jboss.org
>>       >>>  https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>       >>
>>       >  _______________________________________________
>>       >  jboss-as7-dev mailing list
>>       >  jboss-as7-dev at lists.jboss.org
>>       >  https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>>      --
>>      Jason T. Greene
>>      JBoss AS Lead / EAP Platform Architect
>>      JBoss, a division of Red Hat
>>      _______________________________________________
>>      jboss-as7-dev mailing list
>>      jboss-as7-dev at lists.jboss.org
>>      https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dimitris Andreadis
Software Engineering Manager
JBoss Application Server
by Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

http://dandreadis.blogspot.com/