User authentication and flexible configuration on server side about yajsync HOT 5 CLOSED

The current rsync way to save a clear-text password in the secrets-file besides the module configuration is not favourable. I appreciate your choice to send the MD5-hashed password to the server.

I just realized that using the CRAM-MD5 mechanism means that the user passwords have to be saved in clear-text on the server side to be able to re-calculate the hash with the challenge.

What about doing one hash-round more?

• on the server side the hashed password is once saved, generated by (simplified):
  MessageDigest md = MD5.newInstance();
  md.update(password.getBytes());
  byte[] savedHashedPassword = md.digest();
• on the client side the clear-text password is generated at runtime by
  MessageDigest md = MD5.newInstance();
  md.update(password.getBytes());
  byte[] hashedPassword = md.digest();
  md.reset();
  md.update(hashedPassword);
  md.update(challenge.getBytes());
  byte[] hashToSendToTheServer = md.digest();
• on the server side the received hash is compared by:
  MessageDigest md = MD5.newInstance();
  md.update(savedHashedPassword);
  md.update(challenge.getBytes());
  byte[] hashToCompareWithHashFromClient = md.digest();

This way
a) there is no need to save the clear-text password on the server side
b) for each authentication there is another hash going over the wire because of the session specific digest (CRAM-MD5)

This process shouldn't be compatible with the rsync protocol: is this any problem?

from yajsync.

There is some prepared code for user authentication in
ClientSessionConfig.printLinesAndGetReplyStatus and some comment at
ServerSessionConfig.setModule that the authentication request should be
done depending on the module configuration. As far as I can see the
authentication on server side is not implemented yet?

That is right, currently only the client has support for authentication, to
support rsync servers that requires it.

Adding support for SSL by tunneling the regular rsync protocol over it
would provide a much better way of authenticating against a server.

The prepared source code in ClientSessionConfig.printLinesAndGetReplyStatus
hashes the user password by MD5.

Yes, as does rsync

Some ideas regarding the server-side implementation:

the current rsync way to save a clear-text password in the
secrets-file besides the module configuration is not favourable. I
appreciate your choice to send the MD5-hashed password to the server.

Note that this is identical to how rsync does it (see authenticate.c in
rsync)

for being able to provide a flexible configuration I'd prefer an
optional config syntax like it was used in the postfix mailserver
configuration, e.g.

user = mysql:/yajsync/user-sql.cfg
OR
path = mysql:/yajsync/path-sql.cfg
OR
path = ldap:/yajsync/path-ldap.cfg
and so on.

The config-modules (mysql or ldap or text or whatever) would have a
generic interface to set (a) the current module (b) the username to select
the configuration value from the config-module database.

The implementation of config-modules could be separate (in separate JARs
on the classpath) and each with its custom configuration, e.g. a mysql
module would refer to a path-sql.cfg that could look like this:
user = mydbuser
password = mySecPas$
hosts = 127.0.0.1
dbname = yajsync
table = userconfig
select_field = path
where_field_module = module
where_field_user = user

Regarding http://linux.die.net/man/5/rsyncd.conf this flexibility would
allow to
a) use one module configuration with different paths for different users
b) user specific exclude/include options if once implemented
c) user specific 'allow host' directives

Just to be clear, the way to do this otherwise, which you might already be
aware of is to have separate modules for each user:
[module1_user1]
path = ...

[module1_user2]
path = ...

But I understand your need to have a more flexible way of configuring the
server.

I'm thinking of allowing for a different Module provider to be injected at
startup, in combination with the regular java Properties this would be very
flexible and usable.

• considering a SSL enhancement for transport security I think users
  could use a server-side truststore optionally for client-authentication.
  I'd personally would not focus on that (maybe this part could be left to
  default JSSE security options).

Adding SSL is the way to go instead of enhancing the current
authentication mechanism (which would break compatibility with rsync anyway)

from yajsync.

I'm thinking of allowing for a different Module provider to be injected at startup, in combination with the regular java Properties this would be very flexible and usable.

Please see my pull request at #6 that allows to use those flexible modules to be injected at startup. Those modules can be mixed per configuration item, the user specific initialization is done after the transmission of the username. The open file handles/connections to databases are kept once in the server to reduce ressources and speedup lookups.
The module classes implementing the "DictionaryInterface" must reside on the classpath. Besides the samples for "File" and "SQL" I could imagine an LDAP module.

from yajsync.

Adding SSL is the way to go instead of enhancing the current authentication mechanism (which would break compatibility with rsync anyway)

Using SSL with Client-Authentication by a client SSL certificate and a truststore on the server may be possible but rather inconvenient in configuration for some people. In projects I did with customers the user/password auth style was much less costly than doing the cert auth style (regarding certificate generation, truststore import and the replacement of certificates before being outdated).
Therefore I propose to additionally support the authentication by username : base64encode(hash(password, challenge)) besides working with client certificates. In pull request #6 I added this kind of user authentication at the server.

An extended configuration (another configuration option) would optionally allow to do the additional hash-round on the client and the server like mentioned in #3 (comment) to prevent clear-text passwords being saved in the secrets file on the server.

from yajsync.

I will add support for SSL, there will also be the possibility for replacing the current configuration with something else. Adding some extra hashes on top of the weak cram-md5 auth mechnism won't happen I'm afraid - it's not compatible with rsync and does not add much extra security.

from yajsync.