Rethinkdb: Request to add new utility command r.bcrypt()

[nodesocket]

Would make storing sensitive values such as passwords and api keys easier as it would prevent requiring a 3rd party library.

Command API:

r.bcrypt([string], integer);

The 2nd integer parameter is the cost factor, defaulting to a reasonably secure value of 12.

Inserting:

r.table("users").insert({
    "name": "John Doe",
    "password": r.bcrypt("mySuperPassword")
});

Select _(as normal)_:

r.table("users").pluck("name", "password");

[danielmewes]

Thanks for the proposal @nodesocket .

Is there a benefit of offering this in ReQL, compared to doing the encryption on the client?

I feel like this would be better handled on the client-side, since it's fairly specific (what about password encryption methods other than bcrypt?). I could be wrong of course.

[nodesocket]

Having RethinkDB do the bcrypt hashing is actually quite nice as it reduces the amount of code and required 3rd party libraries. Some examples, MySQL has aes_encrypt() and aes_decrypt(). Would this add a ton of code into RethinkDB to deal with the bcrypt hashing?

[danielmewes]

@nodesocket Probably not a ton of code, but it will require work for all drivers and I'm a bit concerned that this will lead us to feature-creep, which will add additional maintenance work down the road.

I don't think we should add functions to ReQL just because they require additional libraries in some of our supported client languages, unless running them on the database adds some additional benefits.

Encryption is somewhat on the edge, since doing encryption and decryption on the database can sometimes allow you to do things that aren't otherwise possible, such as indexing encrypted data (though the index would need access to the encryption key). I don't think this applies to bcrypt though.

I'm going to close this for now. If you feel strongly that this should become a part of ReQL, I'm happy to give it more consideration.