I want to do this for the purpose of building a server in pure-Julia with a user-login system.
I thought Genie.jl would have something like this implemented, but I tried to search for hash and I found that Genie.jl only has an encryption module but no hashing module. I am not sure if the Base’s hash is safe for hashing (salt & pepper) passwords.
I’m not sure cryptographically secure hashing is even possible in julia - to prevent side channel attacks via timing, you need predictable constant time runtime at the assembly level, which seems very hard to get with julias JIT on different machines. Even with different languages it’s an ongoing problem, with the simplest solution being handwritten assembly routines made specifically for that purpose.
Your best bet is probably wrapping some other existing library for cryptographically secure hashing, like Nettle.jl (may need to be updated to the latest Julia version) or similar.
to do that they would have to hack into my server? At that point they would have access to the salted (& peperred) passwords anyway. The only attack is via a rainbow table. Or I need to actually read a book? A quick search on google turns up this post which says that " timing attack in this case is irrelevant ." which seems to be aligned with my understanding.
It’s not necessary to have direct access to the server in order to perform a timing attack - as far as I know, it’s (at least theoretically) possible to do the same kind of attack via an ordinary connection. An attacker would have to measure a lot of tries in order to average out latency, but if there is a meaningful difference between comparisons some information can still be gained about the hash. That’s why that stack exchange post says “access to the salt means access to the password”. But as that post also says, better be safe than sorry and take care of those kinds of attacks anyway
In any case, this is orthogonal to the point I was trying to make: Because of the new compilations for each different machine, I’m not sure certain guarantees you could make in pseudo code (I.e. No hotwiring) are still valid in Julia (e.g. Maybe the compiler “optimizes” the comparison and inserts the hotwired early escape?). Maybe it’s not a problem as long as the routine itself always compiles to the same machine code, but as the compiler is somewhat in flux at the moment, I don’t think that’s a guarantee we get.
That being said, if it’s just about calling bcrypt and comparing the hashes, is there any reason not to call into trusted and often used implementations other than having it in pure Julia? Don’t get me wrong, having reliable bcrypt in pure Julia would be really awesome, but I’m not sure it’s achievable for all possible compilation targets, at least right now.
Found Crypt.jl which implements bcrypt, but given it needs to be used for secure hashing. Let me just say that it’s unverified at the moment. As @Sukera suggests, it might be safer to just use something like https://github.com/Tarsnap/scrypt which is open-source and appear widely used.
To be clear, I’m not saying bcrypt itself is bad or untested - just that it’s probably better to call out to trusted implementations of it in other languages until there’s a trusted/verified/proven to be correct julia version. See here for some great discussion and for some more reasoning as to why e.g. scrypt might not be simply better than bcrypt. The same reasoning will apply to a new implementation of bcrypt in julia - it “just” has to be tested and looked at thoroughly.
Crypt.jl is sadly 3 years old judging by the last commit and requires julia 0.4, so that’s no good in any case
Base.hash is certainly not designed for this. It’s designed for speed (for hash based data structures like Dict). hash(::String) currently uses MurmurHash internally which is not a cryptographic hash.
From some reading online it looks like PBKDF2 with salt, SHA-256 and an appropriately chosen number of iterations is still a respectable choice. For this you’ve got several implementations to choose from, such as the ones in nettle and mbedtls, both of which have julia wrapper libraries. Unfortunately it looks like neither Nettle.jl or MbedTLS.jl wrap the associated C functions, so you’d need to figure out how to call those correctly.
Would be nice if someone made a wrapper for the Argon2 reference implementation which apparently won the password hashing competition a few years ago but I don’t see one.
Btw I am not a cryptographer, merely a curious bystander
I wouldn’t be surprise if servers implement this equal time response, so that each request is responded after a certain time has passed even if the requests completes before that. Firstly this is to hide the time it took to compare hashes. But this is likely to be a icing-on-the-cake measure as backend servers have so many middleware nowadays that it’s almost impossible to tell where the fastness/slowness came from. Also, if the attacker is so sophisticated, why target me? I am keen to revive the Julia implementation and take it for a spin sometime. Although I am likely to end up calling the verified C implementation.
