Is there async bcrypt? coz bcrypt is so slow.

[Phyo Arkar]

Is there async bcrypt or what encryption is recommended for tornado. Want to store encrypted user passwords. , it is so slow to just crypt in bcrypt.

And SHA is too easy to crack.

[Kevin LaTona]

On Sep 11, 2015, at 12:23 PM, Phyo Arkar <phyo.ar...@gmail.com> wrote:

> Is there async bcrypt or what encryption is recommended for tornado. Want to store encrypted user passwords. , it is so slow to just crypt in bcrypt.

bcrypt was designed to be slow to make it harder and take longer to crack….. 100ms comes to mind.

>
> And SHA is too easy to crack.

SHA 512 easy to crack….. hmmmmm…….. well then what about doing some kind of multiple runs on a sha512 or other such idea.


-Kevin

[Russ Weeks]

You should use run_on_executor[1] to offload the bcrypt processing from the IOLoop.

readthedocs.org/en/latest/concurrent.html#tornado.concurrent.run_on_executor

-Russ

--
You received this message because you are subscribed to the Google Groups "Tornado Web Server" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-tornad...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Darnell]

bcrypt is a perfect use case for a ThreadPoolExecutor. There is some sample code in this question: 

http://stackoverflow.com/questions/28243430/can-threadpoolexecutor-help-single-threaded-application-efficiency

On Fri, Sep 11, 2015 at 3:23 PM, Phyo Arkar <phyo.ar...@gmail.com> wrote:

Is there async bcrypt or what encryption is recommended for tornado. Want to store encrypted user passwords. , it is so slow to just crypt in bcrypt.

And SHA is too easy to crack.

--

[Phyo Arkar]

Thanks Ben and everyone . how about reducing rounds in bcrypt? is that very dangerous ? Have to keep 12 round default (6 rounds is only 3 ms , tempting lol) .

[Kevin LaTona]

I came across this blog post a few weeks back while looking for some other thing….. see if there is anything in there for you on this.

http://dustwell.com/how-to-handle-passwords-bcrypt.html

-Kevin

[Ben Darnell]

On Fri, Sep 11, 2015 at 4:15 PM, Phyo Arkar <phyo.ar...@gmail.com> wrote:

Thanks Ben and everyone . how about reducing rounds in bcrypt? is that very dangerous ? Have to keep 12 round default (6 rounds is only 3 ms , tempting lol) .

Yes, it's dangerous to reduce the work factor in bcrypt. Remember that the point of bcrypt is to be slow so that brute force attacks take a long time; reducing the work factor makes the attack proportionately easier. Since logging in with a password is relatively infrequent and not performance-critical (at least in a well-designed login system. Bcrypt latency would be problematic with HTTP Basic auth, but that's just one of many reasons not to use basic auth), it should be fine to let it take 250ms or more. 

Also note that whatever value you use, it should be increased over time as computers get faster (I think the recommendation is to add 1 point every year or two). If you use the default then this will be automatic as you upgrade to new versions of the bcrypt module in the future.

-Ben

[Russ Weeks]

Remember, that number is not the number of rounds. It's the base-2 logarithm of the number of rounds. You're going from 4096 rounds to 64 rounds. So yeah, that's a security risk.
-Russ

[Phyo Arkar]

Ah ic , thanks a lot for enlightening me , then default Bcrypt with ThreadPool Executor will do the job for me :)

Thanks alot guys.