[JBoss JIRA] (ELY-1445) Jdbc-realm with scram mapper and empty password
by Martin Choma (JIRA)
Martin Choma created ELY-1445:
---------------------------------
Summary: Jdbc-realm with scram mapper and empty password
Key: ELY-1445
URL: https://issues.jboss.org/browse/ELY-1445
Project: WildFly Elytron
Issue Type: Bug
Components: Passwords
Affects Versions: 1.2.0.Beta9
Reporter: Martin Choma
Assignee: David Lloyd
This is follow up on ELY-1435, but in this case trying scram hash.
In DB there is
{noformat}
Salt: c2FsdA==
Password: YywoEuRtRgQQK6dhjp1tfS+BKPYma0oDJk0qBGC33LM=
Salt: 1000
{noformat}
I get these values by
{code:java|name=ScramDigestPasswordTest.java}
digest = ScramDigestPasswordImpl.scramDigest(ALGORITHM_SCRAM_SHA_256, "password".getBytes(StandardCharsets.UTF_8), "salt".getBytes(StandardCharsets.UTF_8), 1000);
assertEquals("632c2812e46d4604102ba7618e9d6d7d2f8128f6266b4a03264d2a0460b7dcb3", ByteIterator.ofBytes(digest).hexEncode().drainToString());
spec = new IteratedSaltedHashPasswordSpec(digest, "salt".getBytes(StandardCharsets.UTF_8), 1000);
impl = new ScramDigestPasswordImpl(ALGORITHM_SCRAM_SHA_256, spec);
assertTrue(impl.verify("password".toCharArray()));
assertFalse(impl.verify("bad".toCharArray()));
Encoder encoder = Base64.getEncoder();
String elytronSalt = encoder.encodeToString( impl.getSalt() );
String elytronHash = encoder.encodeToString( impl.getDigest() );
int itertationCount = impl.getIterationCount();
{code}
When user provides empty password "", there is error.
{noformat}
17:05:40,723 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser
17:05:40,723 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser]
17:05:40,727 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD, SALT, ITERATION FROM USERS WHERE NAME = ? with value correctUser
17:05:40,813 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser
17:05:40,817 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD, SALT, ITERATION FROM USERS WHERE NAME = ? with value correctUser
17:05:40,865 ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /elytron-app/protected/printRoles: java.lang.IllegalArgumentException: Empty key
at javax.crypto.spec.SecretKeySpec.<init>(SecretKeySpec.java:96)
at org.wildfly.security.password.impl.ScramDigestPasswordImpl.getMacInstance(ScramDigestPasswordImpl.java:281)
at org.wildfly.security.password.impl.ScramDigestPasswordImpl.scramDigest(ScramDigestPasswordImpl.java:240)
at org.wildfly.security.password.impl.ScramDigestPasswordImpl.verify(ScramDigestPasswordImpl.java:195)
at org.wildfly.security.password.impl.PasswordFactorySpiImpl.engineVerify(PasswordFactorySpiImpl.java:755)
at org.wildfly.security.password.PasswordFactory.verify(PasswordFactory.java:209)
at org.wildfly.security.credential.PasswordCredential.verify(PasswordCredential.java:116)
at org.wildfly.security.credential.Credential.verify(Credential.java:79)
at org.wildfly.security.auth.realm.jdbc.JdbcSecurityRealm$JdbcRealmIdentity.verifyEvidence(JdbcSecurityRealm.java:199)
at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1977)
at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:759)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:992)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:902)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1052)
at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:76)
at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:152)
at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9553) PooledConnectionFactoryAdd adds a resource with no registration
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-9553?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-9553:
-----------------------------------
[~brian.stansberry] Couldn't we check if value of statistics-enabled in the populateModel method and if it's true, then install the statistics resource?
This would ensure that the resource is only modified during the MODEL stage and the runtime resource is only created when stats are actually enabled.
> PooledConnectionFactoryAdd adds a resource with no registration
> ---------------------------------------------------------------
>
> Key: WFLY-9553
> URL: https://issues.jboss.org/browse/WFLY-9553
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Priority: Minor
>
> When working on WFCORE-2930 I was investigating discrepancies in mbean counts generated via the method in that fix vs current code. I discovered one in WildFly's messaging-activemq that is a result of a statistics resource being added to the resource tree even if attribute that triggers registration of the related ManagementResourceRegistration isn't set. So we have an undescribed resource.
> This likely has no other impact than a slightly inaccurate result from MBeanServerConnection.getMBeanCount() but we don't want this kind of thing anyway.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2235) ConcurrentModificationException when resend pending lock requests
by Bram Klein Gunnewiek (JIRA)
Bram Klein Gunnewiek created JGRP-2235:
------------------------------------------
Summary: ConcurrentModificationException when resend pending lock requests
Key: JGRP-2235
URL: https://issues.jboss.org/browse/JGRP-2235
Project: JGroups
Issue Type: Bug
Reporter: Bram Klein Gunnewiek
Assignee: Bela Ban
While testing JGRP-2234 we saw a ConcurrentModificationException in the locking protocol in some (rare) situations:
{noformat}
09:46:42.856 [jgroups-7,TEST,B] ERROR org.jgroups.protocols.pbcast.GMS - JGRP000027: failed passing message up
java.util.ConcurrentModificationException: null
at java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1630) ~[?:1.8.0_151]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) ~[?:1.8.0_151]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) ~[?:1.8.0_151]
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151) ~[?:1.8.0_151]
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174) ~[?:1.8.0_151]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:1.8.0_151]
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418) ~[?:1.8.0_151]
at org.jgroups.protocols.Locking$ClientLockTable.lambda$resendPendingLockRequests$3(Locking.java:1085) ~[classes/:?]
at java.util.concurrent.ConcurrentHashMap$ValuesView.forEach(ConcurrentHashMap.java:4707) ~[?:1.8.0_151]
at org.jgroups.protocols.Locking$ClientLockTable.resendPendingLockRequests(Locking.java:1084) ~[classes/:?]
at org.jgroups.protocols.CENTRAL_LOCK.handleView(CENTRAL_LOCK.java:147) ~[classes/:?]
at org.jgroups.protocols.Locking.up(Locking.java:218) ~[classes/:?]
at org.jgroups.protocols.FRAG2.up(FRAG2.java:163) ~[classes/:?]
at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:702) ~[classes/:?]
at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:135) ~[classes/:?]
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:918) ~[classes/:?]
at org.jgroups.stack.Protocol.up(Protocol.java:364) [classes/:?]
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:293) [classes/:?]
at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:428) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:962) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.removeAndDeliver(NAKACK2.java:896) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.handleMessages(NAKACK2.java:870) [classes/:?]
at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:690) [classes/:?]
at org.jgroups.stack.Protocol.up(Protocol.java:372) [classes/:?]
at org.jgroups.protocols.TP.passBatchUp(TP.java:1255) [classes/:?]
at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.passBatchUp(MaxOneThreadPerSender.java:284) [classes/:?]
at org.jgroups.util.SubmitToThreadPool$BatchHandler.run(SubmitToThreadPool.java:136) [classes/:?]
at org.jgroups.util.MaxOneThreadPerSender$BatchHandlerLoop.run(MaxOneThreadPerSender.java:273) [classes/:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_151]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_151]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_151]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (ELY-1444) Jdbc-realm with simple digest mapper
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1444?page=com.atlassian.jira.plugin.s... ]
Martin Choma edited comment on ELY-1444 at 11/14/17 4:02 AM:
-------------------------------------------------------------
In DB there should be stored byte hash encoded with base64, e.g XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg=
plain: password
hex form: 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8
encoded byte array: XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg=
{code:java}
// #1 approach
byte[] preDigested = CodePointIterator.ofString(hexDigest).hexDecode().drain();
// #2 approach
PasswordFactory factory = PasswordFactory.getInstance(algorithmName);
EncryptablePasswordSpec encryptableSpec = new EncryptablePasswordSpec(password, null);
SimpleDigestPassword simplePassword = (SimpleDigestPassword) factory.generatePassword(encryptableSpec);
Encoder encoder = Base64.getEncoder();
System.out.println(encoder.encodeToString( simplePassword.getDigest()));
System.out.println(encoder.encodeToString( preDigested ));
{code}
I think it is usual to store hashes in hex format. Could there be way to store hex format directly into DB? In that case there should way to disable jdbc-realm password mapper base64 utilization.
was (Author: mchoma):
In DB there should be stored byte hash encoded with base64, e.g XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg=
plain: password
hex form: 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8
encoded byte array: XohImNooBHFR0OVvjcYpJ3NgPQ1qq73WKhHvch0VQtg=
{code:java}
// #1 approach
byte[] preDigested = CodePointIterator.ofString(hexDigest).hexDecode().drain();
// #2 approach
PasswordFactory factory = PasswordFactory.getInstance(algorithmName);
EncryptablePasswordSpec encryptableSpec = new EncryptablePasswordSpec(password, null);
SimpleDigestPassword simplePassword = (SimpleDigestPassword) factory.generatePassword(encryptableSpec);
Encoder encoder = Base64.getEncoder();
System.out.println(encoder.encodeToString( simplePassword.getDigest()));
System.out.println(encoder.encodeToString( preDigested ));
{code}
> Jdbc-realm with simple digest mapper
> ------------------------------------
>
> Key: ELY-1444
> URL: https://issues.jboss.org/browse/ELY-1444
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Passwords
> Affects Versions: 1.2.0.Beta9
> Reporter: Martin Choma
>
> This is inspired by ELY-1435, but in this case trying simple digest hash.
> In db is stored this sha-256 password hash: 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8
> I get these values by http://passwordsgenerator.net/sha256-hash-generator/
> {noformat}
> 17:30:50,211 DEBUG [org.wildfly.security] (default task-3) Using UsernamePasswordAuthenticationMechanism for username authentication. Realm: [Some Realm], Username: [correctUser].
> 17:30:50,211 TRACE [org.wildfly.security] (default task-3) Handling RealmCallback: selected = [Some Realm]
> 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser
> 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser]
> 17:30:50,215 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser
> 17:30:50,301 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser
> 17:30:50,306 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser
> 17:30:50,324 DEBUG [org.wildfly.security] (default task-3) User correctUser authentication failed.
> 17:30:50,324 TRACE [org.wildfly.security] (default task-3) Handling AuthenticationCompleteCallback: fail
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JGRP-2234) Unlocked locks stay locked forever
by Bram Klein Gunnewiek (JIRA)
Bram Klein Gunnewiek created JGRP-2234:
------------------------------------------
Summary: Unlocked locks stay locked forever
Key: JGRP-2234
URL: https://issues.jboss.org/browse/JGRP-2234
Project: JGroups
Issue Type: Bug
Reporter: Bram Klein Gunnewiek
Assignee: Bela Ban
Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt
As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure.
What we think is happening:
In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has and recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever.
Attached is the testng test we wrote and the output of a test failure.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months