Code Monkey home page Code Monkey logo

scram's People

Contributors

ahachete avatar begonapm avatar dependabot[bot] avatar jorsol avatar kdubb avatar reneleonhardt avatar teoincontatto avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar avatar avatar avatar avatar

Forkers

ahachete alexanderkjall ujjwalsh dthadi3 hemiltherebel julianladisch helen-gu janvladimirmostert winner658 jorsol reneleonhardt

scram's Issues

Scram Diver raises an error when entering a Password with non-ASCII chracters in DBeaver

Not 100% sure if I am right here, but I experienced the following Issue when Using DBeaver: dbeaver/dbeaver#11320

It is caused by a non-ASCII Character in my password.
As far as I know, DBeaver is using the the ongres srcam driver. DBeaver team said this is a problem on your end, thats why I am reporting it here

This is the Stacktrace of the error:

java.lang.IllegalArgumentException: value contains character '§' which is non US-ASCII at org.postgresql.shaded.com.ongres.scram.common.util.UsAsciiUtils.toPrintable(UsAsciiUtils.java:45) at org.postgresql.shaded.com.ongres.scram.common.stringprep.StringPreparations$1.doNormalize(StringPreparations.java:43) at org.postgresql.shaded.com.ongres.scram.common.stringprep.StringPreparations.normalize(StringPreparations.java:53) at org.postgresql.shaded.com.ongres.scram.common.ScramFunctions.saltedPassword(ScramFunctions.java:62) at org.postgresql.shaded.com.ongres.scram.client.ScramSession$ClientFinalProcessor.<init>(ScramSession.java:198) at org.postgresql.shaded.com.ongres.scram.client.ScramSession$ClientFinalProcessor.<init>(ScramSession.java:165) at org.postgresql.shaded.com.ongres.scram.client.ScramSession$ServerFirstProcessor.clientFinalProcessor(ScramSession.java:132) at org.postgresql.jre8.sasl.ScramAuthenticator.processServerFirstMessage(ScramAuthenticator.java:131) at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:678) at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:141) at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:192) at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49) at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:195) at org.postgresql.Driver.makeConnection(Driver.java:454) at org.postgresql.Driver.access$100(Driver.java:57) at org.postgresql.Driver$ConnectThread.run(Driver.java:364) at java.base/java.lang.Thread.run(Unknown Source)

Session data:

eclipse.buildId=unknown java.version=11.0.5 java.vendor=AdoptOpenJDK BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de Command-line arguments: -os win32 -ws win32 -arch x86_64

Is there any fix?
Thank you in advance.

change module name from 'client'

Hi

I'm working on adding SCRAM support to https://github.com/pgjdbc/pgadba and that is a library that uses the module system.

The default module that this library gets published under is named 'client' and that is extremely generic.

It also gives me this warning when compiled with maven:
[WARNING] * Required filename-based automodules detected. Please don't publish this project to a public artifact repository! *

Would you consider adding a module-info.java file?

Improve tests and report coverage

Many tests require refactoring and improvements to make it more robust, some parts could need better coverage, so a coverage report would be nice.

  • Add coverage report
  • Refactor old tests
  • Add more tests
  • Improve coverage

SCRAM-SHA3-512(-PLUS) supports

Dear @ongres team,

After:

  • SCRAM-SHA-1
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-256
  • SCRAM-SHA-256-PLUS
  • SCRAM-SHA-512
  • SCRAM-SHA-512-PLUS

Can you add supports of :

  • SCRAM-SHA3-512
  • SCRAM-SHA3-512-PLUS

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

SCRAM-SHA-1(-PLUS):

SCRAM-SHA-256(-PLUS):

SCRAM-SHA-512(-PLUS):

SCRAM-SHA3-512(-PLUS):

SCRAM BIS:

SASL2

https://xmpp.org/extensions/inbox/hash-recommendations.html

-PLUS variants:

LDAP:

  • RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

HTTP:

2FA:

IANA:

Linked to:

Consider using the JDK java.util.Base64 instead of shaded bouncycastle version

JDK 8 now has a java.util.Base64 class for encoding and decoding, meaning that once you upgrade your baseline from Java 7 to Java 8, you can remove com.ongres.scram.common.bouncycastle.base64.Base64 and the other classes in that package. The removal can then be picked up by pgjdbc, which shades this class once again as org.postgresql.shaded.com.ongres.scram.common.bouncycastle.base64.Base64, etc.

Benefits:

  • Java 8 is a good baseline. You can profit from this in various ways, including availability of lambda expressions and default methods for yourselves
  • You can remove some of your outdated code
  • Pgjdbc will automatically remove some of their outdated code
  • Everyone will have less outdated bytecode in their dependencies

Implement Channel Binding

PostgreSQL 11 will have channel binding.
We'll need to extend the TLS interface to provide access to the Finished message and the peer certificate.

SCRAM-SHA-224(-PLUS) + SCRAM-SHA-384(-PLUS) + SCRAM-SHA-512(-PLUS) supports

Dear @ongres team,

After:

  • SCRAM-SHA-1
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-256
  • SCRAM-SHA-256-PLUS

Can you add supports of :

  • SCRAM-SHA-224
  • SCRAM-SHA-224-PLUS
  • SCRAM-SHA-384
  • SCRAM-SHA-384-PLUS
  • SCRAM-SHA-512
  • SCRAM-SHA-512-PLUS
  • SCRAM-SHA3-512
  • SCRAM-SHA3-512-PLUS

"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".

SCRAM-SHA-1(-PLUS):

SCRAM-SHA-256(-PLUS):

SCRAM-SHA-512(-PLUS):

SCRAM-SHA3-512(-PLUS):

https://xmpp.org/extensions/inbox/hash-recommendations.html

-PLUS variants:

LDAP:

  • RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803

HTTP:

2FA:

IANA:

Linked to:

RuntimeException in common.util.CryptoUtil.hmac() should include its cause

Hi, this is Francisco from the OpenJDK team at Red Hat.

While working in Red Hat Customer Portal: postgresql jdbc driver not able to connect in FIPS mode (also reported in StackOverflow: How to configure openjdk for FIPS and simple postgres connection example), I've spotted the following minor issue:

scram/common/src/main/java/com/ongres/scram/common/util/CryptoUtil.java

Lines 143 to 151 in 779351d

public static byte[] hmac(SecretKeySpec secretKeySpec, Mac mac, byte[] message) {
try {
mac.init(secretKeySpec);
} catch (InvalidKeyException e) {
throw new RuntimeException("Platform error: unsupported key for HMAC algorithm");
}
return mac.doFinal(message);
}

The exception thrown at line 147 should include e as its cause, this way, the stack trace would include subsequent Caused by: parts with useful debug information:

            throw new RuntimeException("Platform error: unsupported key for HMAC algorithm", e);

Current stack trace:

org.postgresql.util.PSQLException: Something unusual has occurred to cause the driver to fail. Please report this exception.
               at org.postgresql.Driver.connect(Driver.java:280)
               at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:677)
               at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:228)
               at gms.pgtest.PostgreSQLJDBC.connect(PostgreSQLJDBC.java:24)
               at gms.pgtest.PostgreSQLJDBC.main(PostgreSQLJDBC.java:41)
Caused by: java.lang.RuntimeException: Platform error: unsupported key for HMAC algorithm
               at org.postgresql.shaded.com.ongres.scram.common.util.CryptoUtil.hmac(CryptoUtil.java:147)
               at org.postgresql.shaded.com.ongres.scram.common.ScramMechanisms.hmac(ScramMechanisms.java:143)
               at org.postgresql.shaded.com.ongres.scram.common.ScramFunctions.hmac(ScramFunctions.java:70)
               at org.postgresql.shaded.com.ongres.scram.common.ScramFunctions.clientKey(ScramFunctions.java:85)
               at org.postgresql.shaded.com.ongres.scram.client.ScramSession$ClientFinalProcessor.<init>(ScramSession.java:188)
               at org.postgresql.shaded.com.ongres.scram.client.ScramSession$ClientFinalProcessor.<init>(ScramSession.java:194)
               at org.postgresql.shaded.com.ongres.scram.client.ScramSession$ClientFinalProcessor.<init>(ScramSession.java:163)
               at org.postgresql.shaded.com.ongres.scram.client.ScramSession$ServerFirstProcessor.clientFinalProcessor(ScramSession.java:130)
               at org.postgresql.jre7.sasl.ScramAuthenticator.processServerFirstMessage(ScramAuthenticator.java:147)
               at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:816)
               at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:180)
               at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:235)
               at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49)
               at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:223)
               at org.postgresql.Driver.makeConnection(Driver.java:400)
               at org.postgresql.Driver.connect(Driver.java:259)
               ... 4 more

Add Change Log to the lib

In jasync-sql there is a PR to start using ongres/scram (this lib).

Trying to understand what is the latest version it seems like 2.1 from readme badges and maven, but the pom is not up-to-date, nor releases. So I found it a bit confusing to understand what was changed.

In addition issue #1 (comment) hints there has been some changes in 2.0 (Java7 and full StringPrep) but I haven't seen those in commit log.

If it's possible to shed light on previous versions and the difference between them, here or as a changelog file it will be great.

Thanks!

Removing iterations >= 4096 check in ServerFirstMessage

While testing out some non-standard parameters for the pgjdbc driver, ran into this exception while using exactly one (1) iteration for SCRAM credentials:

FAILURE   0.1sec, org.postgresql.test.util.PasswordUtilTest > testCustomScramParams
    java.lang.RuntimeException: Failed to authenticate using supplied user and password
        at org.postgresql.test.util.PasswordUtilTest.assertValidUsernamePassword(PasswordUtilTest.java:41)
        at org.postgresql.test.util.PasswordUtilTest.testUserPassword(PasswordUtilTest.java:70)
        at org.postgresql.test.util.PasswordUtilTest.testCustomScramParams(PasswordUtilTest.java:146)
        Caused by: org.postgresql.util.PSQLException: Something unusual has occurred to cause the driver to fail. Please report this exception.
            at app//org.postgresql.Driver.connect(Driver.java:320)
            at platform/[email protected]/java.sql.DriverManager.getConnection(DriverManager.java:681)
            at platform/[email protected]/java.sql.DriverManager.getConnection(DriverManager.java:190)
            at app//org.postgresql.test.TestUtil.openDB(TestUtil.java:401)
            at app//org.postgresql.test.util.PasswordUtilTest.assertValidUsernamePassword(PasswordUtilTest.java:39)
            ... 2 more
            Caused by: java.lang.IllegalArgumentException: Argument 'iteration must be >= 4096' is not valid
                at com.ongres.scram.common.util.Preconditions.checkArgument(Preconditions.java:70)
                at com.ongres.scram.common.message.ServerFirstMessage.<init>(ServerFirstMessage.java:75)
                at com.ongres.scram.common.message.ServerFirstMessage.parseFrom(ServerFirstMessage.java:153)
                at com.ongres.scram.client.ScramSession$ServerFirstProcessor.<init>(ScramSession.java:107)
                at com.ongres.scram.client.ScramSession$ServerFirstProcessor.<init>(ScramSession.java:102)
                at com.ongres.scram.client.ScramSession.receiveServerFirstMessage(ScramSession.java:281)
                at org.postgresql.jre7.sasl.ScramAuthenticator.processServerFirstMessage(ScramAuthenticator.java:132)
                at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:863)
                at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:203)
                at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:258)
                at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:54)
                at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:263)
                at org.postgresql.Driver.makeConnection(Driver.java:444)
                at org.postgresql.Driver.connect(Driver.java:297)
                ... 6 more

The library is hard coded to to a minimum of 4096. I'd like to use a single iteration as the password itself is already long and cryptographically random (64 random bytes from /dev/urandom). The extra iterations are not needed to stretch the password and a single iteration would lend itself to faster connection startups.

Interestingly generating the credentials is fine and I'm pretty sure the server doesn't care about the iteration count. It's the Java client that is complaining that it does not want to try continuing with the SCRAM handshake because it thinks the server's suggested iteration count is too low.

Can the check be removed or disabled without compiling a custom version of the library?

Here's some precedent from the PG hackers list of people discussing the same idea: https://www.postgresql.org/message-id/1d669d97-86b3-a5dc-9f02-c368bca911f6%40iki.fi

RFC 9266: Channel Bindings for TLS 1.3 support

Dear @ongres team,

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?

Little details, to know easily:

  • tls-unique for TLS =< 1.2
  • tls-server-end-point
  • tls-exporter for TLS = 1.3

I think that you have seen the jabber.ru MITM and Channel Binding is the solution:

Thanks in advance.

Linked to:

Add Java 9+ modules

There are two distinct modules in this project, the scram-common which contains the SCRAM messages and utilities/functions, and the scram-client module.

Add Java modules using MR-JARs:

  • com.ongres.scram.common
  • com.ongres.scram.client

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.