Secure password hashing for Lua
Log | Files | Refs

commit 60e64e067e203a71c49f3430a21cfbea13aa01fe
parent 87c007f07e20b763de1a084fa7f8c9edbc9e397d
Author: Michael Savage <>
Date:   Mon,  5 May 2014 15:59:10 +0100

Rambling in README

Diffstat: | 28++++++++++++++++++++++++++++
1 file changed, 28 insertions(+), 0 deletions(-)

diff --git a/ b/ @@ -54,3 +54,31 @@ fail as early as possible on errors in the common use case. Therefore, if you wish to use chroot, you should run: mknod -m 644 /path/to/chroot/dev/urandom c 1 9 + + +Security +-------- + +You might have noticed that `luabcrypt_verify` doesn't use a constant +time comparison and `luabcrypt_digest` doesn't take steps to zero out +the entropy buffer. I don't think either of these are a problem. + +I haven't used a constant time comparison because I'm not sure how to +write one and then guarantee the compiler won't optimise it out. I don't +think this is a big deal because strong hash functions, such as bcrypt, +have good preimage resistance. That said, the code is currently relying +on this holding forever, and if you aren't happy with that you shouldn't +use it. + +I don't zero out the entropy buffer after generating a salt for the same +reason. There are two ways in which this can be obtained: + +* another program calls `malloc` and gets handed memory that was + previously used as an entropy buffer +* the entropy buffer is read directly from memory + +I don't think it matters because you shouldn't be able to predict the +output of a CSPRNG even given previous outputs. If you are worried about +the second case, note that Lua interns short strings which will include +passwords handled by your application so an attacker can read those +directly instead.