Implemented a SCRAM server, with testing

[dyule]

As the message says, I implemented a SCRAM server that uses a trait to provide password information.

I did end up modifying a little bit of the client code, but only to move some code that I was also using to a utils module.

I think I've followed the pattern established in the client module pretty well, and I've updated the documentation to reflect how the server works. I also added some tests in tests/client_server.rs that verify they work properly together.

I'm happy to adjust anything you like, or explain any decisions I made.

[dyule]

I'm not sure why it's failing on the nightly build, since it builds fine on nightly for me, and cargo fails on --version on Travis

[tomprogrammer]

The build failed due to an error in cargo (rust-lang/cargo#3819) which was just fixed.

I'll review your server implementation tomorrow, but at first glance it seems pretty straightforward. Thanks for your PR!

[tomprogrammer]

I suggest to use borrowed values instead of owned values in PasswordInfo. I've explained my motivation in the comment.

Thanks for the server implementation, the code is very clean and well documented. Great work!

[tomprogrammer]

I think that this should store bytes slices instead of vectors. I have two arguments for this change:

• The ownership of these values is often held by other data structures. Taking a slice avoids copies (like in tests/client_server.rs line 27).
• Salt and hashed password can be stored together and sliced individually. Short example:

const SALT_LENGTH: usize = 20;
let (hashed_password, iterations) = password_db.get(&username).unwrap();
let password_info = PasswordInfo::new(&hashed_password[SALT_LENGTH..], 
                                      iterations,
                                      &hashed_password[..SALT_LENGTH]);

[dyule]

I originally had this as a borrowed value, but switched it to owned after implementing TestProvider. The issue with borrowing the password is that the object which owns it is the database query, which drops out of scope when the lookup method ends, as opposed to the database object itself, which lives longer. It's possible with some memory trickery to switch ownership of the password to the database object, but that's hardly ideal.

As long as the password database is entirely stored in memory, then borrowed values work. If there is any part which isn't, memory management becomes a nightmare, which is why I switched to owned, and took the small hit on copying.

However, there might be something obvious I'm missing here, so I'm perfectly happy to switch it to borrowed if that's the case.

[tomprogrammer]

I get your arguments and agree that the ownership of the password (query result) shouldn't be linked to the database connection. I think that the API can be refined later, when the library gets some usage.

[tomprogrammer]

That's nice! 👍