[jboss-as7-dev] Relaxing password requirements for add-user script?

Jason Greene jason.greene at redhat.com
Mon Oct 15 11:04:18 EDT 2012 

Also I forgot to mention that all current digest protocols do not allow for salting the password, which is our out of the box security mechanism. To do so they would have to add an exchange phase where the server informs the client the salt of a user. However, there is some per-user uniqueness in that the username itself is also used in the hash. 

That said if someone chooses to pass clear text passwords over the transport, instead of digest, there is a strong case for using salting.

Another thing I would like to see happen in 8, is to look into the JS code of the admin console negotiating http auth. This would allow us to implement RFC 5843.

On Oct 15, 2012, at 9:01 AM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:

> Hi Jason,
>   right. I forgot about the "realm".  This is indeed a step ahead of 
> just hashing the password, but close to the unique salt per password 
> approach.  I think this should be sufficient for the AS version.
> 
> I will try to work with Darran on getting the IDM approach palatable for AS.
> 
> Regards,
> Anil
> 
> On 10/15/2012 08:56 AM, Jason Greene wrote:
>> Since the security store uses the realm name in the hash, which acts like a salt,  it is a step beyond the LinkedIn situation.
>> 
>> Sent from my iPhone
>> 
>> On Oct 15, 2012, at 8:36 AM, Anil Saldhana <Anil.Saldhana at redhat.com> wrote:
>> 
>>> Darran,
>>>   I have been thinking about the properties file strategy.  I support
>>> your thinking. But I want to put forward some thoughts:
>>> 
>>> From the LinkedIn password fiasco, the general industry philosophy is
>>> that passwords that are just hashed are prone to dictionary/brute force
>>> attacks, irrespective of how strong the password is. There is a
>>> necessity to introduce a salt per password.
>>> Introduction of a salt per password is just going to make the usability
>>> aspects challenging with the properties file strategy.
>>> 
>>> We should consider the PicketLink IDM work for storing passwords. The
>>> password management becomes a responsibility of the IDM framework.
>>> Discussion on this framework is happening in the security-dev mailing list.
>>> 
>>> Regards,
>>> Anil
>>> 
>>> On 10/11/2012 09:09 AM, Andrig Miller wrote:
>>>> ----- Original Message -----
>>>>> From: "Darran Lofthouse" <darran.lofthouse at jboss.com>
>>>>> To: "Andrig Miller" <anmiller at redhat.com>
>>>>> Cc: "Jason Greene" <jason.greene at redhat.com>, jboss-as7-dev at lists.jboss.org
>>>>> Sent: Thursday, October 11, 2012 3:01:57 AM
>>>>> Subject: Re: [jboss-as7-dev] Relaxing password requirements for    add-user    script?
>>>>> 
>>>>> Hi Andy,
>>>>> 
>>>>> It may be missing at the moment but this complexity check was
>>>>> supposed
>>>>> to have a modifiable policy file that the administrator could update
>>>>> to
>>>>> specify the rules they really want.  How would any auditors consider
>>>>> that?
>>>> That, in my opinion, would be fine.  The only issue would be how you protect that policy file from be tampered with, but this is true of all configuration.
>>>> 
>>>>> To me the modifying of a policy to weaken it is a deliberate act by
>>>>> an
>>>>> administrator, that same administrator also has the capability to
>>>>> reconfigure the server to use BASIC authentication or store the
>>>>> passwords in plain text instead of pre-hashed.
>>>>> 
>>>>> However the --force option does feel too easy for someone to use and
>>>>> then forget they forced through a weak password just to get their
>>>>> production server online.
>>>> Agreed.
>>>> 
>>>> Andy
>>>> 
>>>>> Regards,
>>>>> Darran Lofthouse.
>>>>> 
>>>>> 
>>>>> On 10/10/2012 08:29 PM, Andrig Miller wrote:
>>>>>> Not to my knowledge.  My point, is whenever you give have these
>>>>>> allowances, you make the customer have to prove to the auditors
>>>>>> that you are not using them.
>>>>>> 
>>>>>> Auditors love these kinds of things, because it gives them
>>>>>> something to poke into.  More billable hours ;-)
>>>>>> 
>>>>>> Andy
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>>> From: "Jason Greene" <jason.greene at redhat.com>
>>>>>>> To: "Brian Stansberry" <brian.stansberry at redhat.com>
>>>>>>> Cc: jboss-as7-dev at lists.jboss.org
>>>>>>> Sent: Wednesday, October 10, 2012 1:22:32 PM
>>>>>>> Subject: Re: [jboss-as7-dev] Relaxing password requirements for
>>>>>>>    add-user    script?
>>>>>>> 
>>>>>>> As someone mentioned earlier RHEL lets you set a bad password (if
>>>>>>> you
>>>>>>> agree to it). Is there a special compliance distro of RHEL?
>>>>>>> On Oct 10, 2012, at 12:45 PM, Brian Stansberry
>>>>>>> <brian.stansberry at redhat.com> wrote:
>>>>>>> 
>>>>>>>> Interesting. This enforcing of password rules is new in AS
>>>>>>>> master;
>>>>>>>> AFAIK
>>>>>>>> we've never had this kind of thing before.
>>>>>>>> 
>>>>>>>> On 10/10/12 12:19 PM, Andrig Miller wrote:
>>>>>>>>> We might run afoul of PCI and SOX requirements for customers
>>>>>>>>> with
>>>>>>>>> that kind of option.
>>>>>>>>> 
>>>>>>>>> Personally, I think just having some text that says the password
>>>>>>>>> requirements when you create a user, to make it more usable is
>>>>>>>>> what we should do, and not relax the requirements.
>>>>>>>>> 
>>>>>>>>> Andy
>>>>>>>>> 
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Jason Greene" <jason.greene at redhat.com>
>>>>>>>>>> To: "Darran Lofthouse" <darran.lofthouse at jboss.com>
>>>>>>>>>> Cc: jboss-as7-dev at lists.jboss.org
>>>>>>>>>> Sent: Wednesday, October 10, 2012 7:46:54 AM
>>>>>>>>>> Subject: Re: [jboss-as7-dev] Relaxing password requirements for
>>>>>>>>>> add-user    script?
>>>>>>>>>> 
>>>>>>>>>> Maybe we should allow a --force option, which bypasses that
>>>>>>>>>> stuff?
>>>>>>>>>> 
>>>>>>>>>> On Oct 10, 2012, at 4:49 AM, Darran Lofthouse
>>>>>>>>>> <darran.lofthouse at jboss.com> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Agreed, a prompt would help so a feature request would be
>>>>>>>>>>> welcome.
>>>>>>>>>>> 
>>>>>>>>>>> This will be an interesting contributor task I think as we
>>>>>>>>>>> would
>>>>>>>>>>> need to
>>>>>>>>>>> be mapping between the configured policy and appropriate log
>>>>>>>>>>> messages.
>>>>>>>>>>> 
>>>>>>>>>>> Regards,
>>>>>>>>>>> Darran Lofthouse.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 10/10/2012 09:02 AM, Stuart Douglas wrote:
>>>>>>>>>>>> Also, at the very least this should tell you the requirements
>>>>>>>>>>>> before you
>>>>>>>>>>>> have to go through the trial and error process to figure out
>>>>>>>>>>>> what
>>>>>>>>>>>> they are.
>>>>>>>>>>>> 
>>>>>>>>>>>> Stuart
>>>>>>>>>>>> 
>>>>>>>>>>>> Jaikiran Pai wrote:
>>>>>>>>>>>>> I think it's been a while since I used the add-user script
>>>>>>>>>>>>> to
>>>>>>>>>>>>> add
>>>>>>>>>>>>> application users. Turns out the password for the new user
>>>>>>>>>>>>> is
>>>>>>>>>>>>> now
>>>>>>>>>>>>> checked for strength and the rules are a bit annoying [1],
>>>>>>>>>>>>> at
>>>>>>>>>>>>> least for
>>>>>>>>>>>>> me. As a developer, I just want to test a scenario for EJB
>>>>>>>>>>>>> invocations.
>>>>>>>>>>>>> I tried using "test" as a password and it failed with "too
>>>>>>>>>>>>> few
>>>>>>>>>>>>> characters". Then I tried "test12345" failed again with
>>>>>>>>>>>>> "your
>>>>>>>>>>>>> password
>>>>>>>>>>>>> should have combination of upper case, lower case, ...". I
>>>>>>>>>>>>> never
>>>>>>>>>>>>> have
>>>>>>>>>>>>> understood this specific requirement of passwords being
>>>>>>>>>>>>> forced
>>>>>>>>>>>>> to
>>>>>>>>>>>>> be of
>>>>>>>>>>>>> certain type (many sites do it). So, would it be possible to
>>>>>>>>>>>>> somehow
>>>>>>>>>>>>> relax this requirement?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I'm not a security expert, but is this "your password has to
>>>>>>>>>>>>> have
>>>>>>>>>>>>> upper
>>>>>>>>>>>>> case, lower case, digit, special char" requirement really
>>>>>>>>>>>>> worth
>>>>>>>>>>>>> it in a
>>>>>>>>>>>>> real application?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1]
>>>>>>>>>>>>> https://issues.jboss.org/browse/AS7-2756?focusedCommentId=12653165&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12653165
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -Jaikiran
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>>>>> 
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

More information about the jboss-as7-dev mailing list