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

[Darran Lofthouse]

On 10/15/2012 02:56 PM, 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.

It is a step beyond, also I have an outstanding Jira to force the 
administrator to actually choose a realm name the first time they add a 
user to move towards having unique realm names.

>
> 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
>>>>>>>
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Principal Software Engineer
>>>>>>> JBoss by 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
>