January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-41) Password Recognition and Parsing Framework

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-41?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse updated ELY-41: -------------------------------- Fix Version/s: 1.0.0.Beta1 (was: 1.0.0.Alpha1) > Password Recognition and Parsing Framework > ------------------------------------------ > > Key: ELY-41 > URL: https://issues.jboss.org/browse/ELY-41 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > > I don't think having a single PasswordUtils that recognises and parses all password types is going to be a good idea long term - I think a lot of the responsibility for what is supported needs to come from the realm. > A scenario I am thinking is an LDAP server is configured to support clear text passwords, that server verifies the strength of the password before letting a user set it - this could be circumvented by setting the password value to something we would parse as one of the other password types. The problem is the user could just hash 'password' - this would pass the LDAP servers dictionary attack check. > The second issue is that different formats could be realm specific, e.g. LDAP supports trival digests in formats slightly different to those we already support. > One idea I am starting to think about it a password parser that a realm can build up with a set of supported password types, working on LDAP it is apparent realms potentially need configuration for the credential types they will claim to support before the RealmIdentity is identified so not a major deviation from the work I am already finding necessary. > Looking at the current PasswordUtils.java the following public utility methods are exposed: - > {code} > org.wildfly.security.password.PasswordUtils > org.wildfly.security.password.PasswordUtils.identifyAlgorithm(char[]) > org.wildfly.security.password.PasswordUtils.identifyAlgorithm(String) > org.wildfly.security.password.PasswordUtils.getCryptStringChars(PasswordSpec) > org.wildfly.security.password.PasswordUtils.getCryptString(PasswordSpec) > org.wildfly.security.password.PasswordUtils.parseCryptString(String) > org.wildfly.security.password.PasswordUtils.parseCryptString(char[]) > {code} > From the perspective of a realm the primary task I am trying to achieve is to take a password string and convert it to a PasswordSpec. Algorithm identification seems to be used primarily by tests, not convinced it is justified in an API. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-29) Common Use Cases

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-29?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse updated ELY-29: -------------------------------- Fix Version/s: 1.0.0.Beta1 (was: 1.0.0.Alpha1) > Common Use Cases > ---------------- > > Key: ELY-29 > URL: https://issues.jboss.org/browse/ELY-29 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > > The API/SPI of Elytron is based around numerous discussions on the scenarios we need to support in an application server environment - this is a parent task to start adding some test cases that cover these scenarios. > Any subsequent API evolution has to take into account the scenarios we must - this will also be key to identifying backwards compatibility going forward. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-67) Password type: SCRAM pre-digested

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-67?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse updated ELY-67: -------------------------------- Fix Version/s: 1.0.0.Beta1 (was: 1.0.0.Alpha1) > Password type: SCRAM pre-digested > --------------------------------- > > Key: ELY-67 > URL: https://issues.jboss.org/browse/ELY-67 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: David Lloyd > Assignee: Stefan Guilhen > Fix For: 1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-56) Bridge Compatibility Between Existing SASL Mechanisms and Factories and Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-56?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse updated ELY-56: -------------------------------- Fix Version/s: 1.0.0.Beta1 (was: 1.0.0.Alpha1) > Bridge Compatibility Between Existing SASL Mechanisms and Factories and Elytron > ------------------------------------------------------------------------------- > > Key: ELY-56 > URL: https://issues.jboss.org/browse/ELY-56 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > > To be designed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-85) Support GSS-Proxy

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-85?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse updated ELY-85: -------------------------------- Fix Version/s: 1.0.0.Beta1 (was: 1.0.0.Alpha1) > Support GSS-Proxy > ----------------- > > Key: ELY-85 > URL: https://issues.jboss.org/browse/ELY-85 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SASL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > > GSS Proxy is something we should consider being able to support when running on an OS that supports it: - > https://fedorahosted.org/gss-proxy/ > The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-129) Choose SASL mechanisms based on better criteria

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-129?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-129: --------------------------------- Fix Version/s: 1.0.0.Beta1 > Choose SASL mechanisms based on better criteria > ----------------------------------------------- > > Key: ELY-129 > URL: https://issues.jboss.org/browse/ELY-129 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: David Lloyd > Fix For: 1.0.0.Beta1 > > > SASL mechanism selection is based on properties right now, that specify only a few very limited criteria. > We should provide a better selection mechanism that allows selection based on the following criteria: > * Specify requirements of the mechanism itself > ** Algorithm usage > ** Key length (where applicable) > ** Parameters similar to existing Sasl ones, like: > *** QOP > *** Forward secrecy > *** Plaintext > *** Active attack susceptibility > *** etc. > * Specify requirements around the mechanism's circumstance > ** Restrict by enclosing channel security > *** Require TLS cipher suite parameters (using existing database parameters) > *** Require channel binding > In the end the client or server user should be able specify SASL mechanism usage using expressions that can express things like: > * Use PLAIN only if TLS is in use with AES encryption > * Use EXTERNAL only if TLS is in use > * Use no SASL mechanisms employing weak hash algorithms (MD5 and worse) > * Use only SASL mechanisms employing SHA-256 > * Use only SASL mechanisms that provide channel binding and require TLS > * Use only ANONYMOUS -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-88) Command line utilities

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-88?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse updated ELY-88: -------------------------------- Fix Version/s: 1.0.0.Beta1 > Command line utilities > ---------------------- > > Key: ELY-88 > URL: https://issues.jboss.org/browse/ELY-88 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: David Lloyd > Fix For: 1.0.0.Beta1 > > > We should provide easy-to-use command line tools from the Elytron JAR as a main class that provide useful functions to users like: > * Creating password hashes > * Creating certificates and certificate requests > * Creating key pairs of various types > * Managing key stores (everything keytool does) > * Get the library version -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-12) Interoperability Testing with PicketLink

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-12?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse updated ELY-12: -------------------------------- Fix Version/s: 1.0.0.Beta1 (was: 1.0.0.Alpha1) > Interoperability Testing with PicketLink > ---------------------------------------- > > Key: ELY-12 > URL: https://issues.jboss.org/browse/ELY-12 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-128) RFC 5843 additional hash types for Digest authentication, applied to SASL

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-128?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-128: --------------------------------- Fix Version/s: 1.0.0.Beta1 (was: 1.0.0.Alpha1) > RFC 5843 additional hash types for Digest authentication, applied to SASL > ------------------------------------------------------------------------- > > Key: ELY-128 > URL: https://issues.jboss.org/browse/ELY-128 > Project: WildFly Elytron > Issue Type: Enhancement > Components: SASL > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.0.0.Beta1 > > > http://tools.ietf.org/html/rfc5843 specifies three additional SHA-based digest schemes. Apply these to SASL. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-124) Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-124?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-124: --------------------------------- Fix Version/s: 1.0.0.Beta1 > Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value > -------------------------------------------------------------------------------- > > Key: ELY-124 > URL: https://issues.jboss.org/browse/ELY-124 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > > Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null. If null, the server name is considered "unbound" and the client can select what server name it wants to use. > The release notes say: > {quote} > SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803. > {quote} > The updated JavaDoc says: > {quote} > serverName - The fully qualified host name of the server to authenticate to, or null if the server is not bound to any specific host name. If the mechanism does not allow an unbound server, a SaslException will be thrown. > {quote} > The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803 > The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015