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(a)redhat.com>
> *To: *"Darran Lofthouse"<darran.lofthouse(a)jboss.com>
> *Cc: *jboss-as7-dev(a)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(a)lists.jboss.org
> >>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >>
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)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