spotify / crtauth-java

Java port of the crtauth authentication library

crtauth-java

crtauth-java is a public key backed client/server authentication system written in Java.

crtauth-java is the Java port of the original crtauth implementation that can be found here. The java implementation is fully wire compatible with the python version.

crtauth itself is a system for authenticating a user to a centralized server. The initial use case is to create a convenient authentication for command line tools that interacts with a central server without resorting to authentication using a shared secret, such as a password.

If you are looking at building a client in Java and would like to connect to a local ssh-agent, here's how:

final AgentSigner signer = new AgentSigner();
final byte[] signed = signer.sign(new byte[] {1, 2, 3, 4}, new Fingerprint(publicKey));

License

crtauth-java is free software, this code is released under the Apache Software License, version 2. The original code is written by Federico Piccinini with contributions from Noa Resare, John-John Tedro, Martin Parm and Nic Cope.

All code is Copyright (c) 2015 Spotify AB

crtauth-java's Issues

RFC: refactoring exceptions

I think that the goal of the code should be that it is as easy to consume as possible; as simple as possible but no simpler. In line with this I propose the following changes:

• Replace the generic InvalidInputException with the JRE provided generic IllegalArgumentException as they are pretty much the same and less code > more code.
• Replace DeserializationException with IllegalArgumentException for things like illegal base64 character in input, invalid msgpack in once base64 is decoded.
• Introduce a new AuthenticationFailureException for when a Response has an invalid signature or when the public key is not found. It is important that this exception doesn't reveal a difference between the key not being found and signature mismatch to avoid leaking information about valid users.
• Remove SerializationException as serialization shouldn't fail (unless there is an internal problem with the software, in which case I think a RuntimeException is appropriate)
• It is also unclear to me whether we want have a catch all exception for Signer failures (SingerException). There is obviously plenty of things that can go wrong during signing but having client code casting that into a SignerException provides limited benefit IMO. Let's throw unchecked exceptions from the signer implementations instead.

What do you guys think about this? @udoprog @parmus @fpiccinini

Usage docs?

Is there any usage documentation or example implementations available?

Xdr encoding allocates .5M of data on per invocation

I'm thinking that we should move to Object{Input|Output}Stream for the backing data structure, which would enable dynamic allocation of backing buffers (ArrayOutputStream). Opinions?

Can we upload a release to maven central?

It seems like this project hasn't been uploaded to maven? http://search.maven.org/#search%7Cga%7C1%7Ccom.spotify.crtauth

Is CrtAuthServer.createChallenge susceptible to timing attacks?

It kind of looks like createChallenge will leak whether a user's key exists on the server or not if subjected to a timing attack.