Consider using scrypt instead of bcrypt

[garrettr]

scrypt is another adaptive key stretching algorithm in the vein of bcrypt. Unlike bcrypt, however, it was specifically designed to thwart attacks by powerful adversaries capable of building large clusters of custom hardware for password cracking. Given securedrop's threat model, scrypt might a better choice than bcrypt; however, scrypt is significantly newer and comparatively less tested.

[fpietrosanti]

At globaleaks we're using too scrypt by following this specific approach, described in our application security design and details: https://docs.google.com/a/apps.globaleaks.org/document/d/1SMSiAry7x5XY9nY8GAejJD75NWg7bp7M1PwXSiwy62U/pub#h.ibk1v235g7wb

[Taipo]

The reason I think scrypt should be eventually implemented is because of our threat model. When bcrypt was designed back in 1999 its threat was application specific hardware bruteforcing arrays. However we need to be thinking about FPGA arrays and cost to the adversary. scrypt has the potential to pretty much force an adversary to have to use FPGAs, and via the memory hardening settings you can also increase the cost factor ( for example of ram ) from a few million dollars to crack a codename in say one year, to the potential of billions of dollars.

[garrettr]

@Taipo, do you have evidence for your claims regarding the use of FPGA arrays for cracking bcrypt?

[Taipo]

I derived my opinion from reading this 'STRONGER KEY DERIVATION VIA SEQUENTIAL
MEMORY-HARD FUNCTIONS'
From: https://www.tarsnap.com/scrypt/scrypt.pdf

Also see "Table 1. Estimated cost of hardware to crack a password in 1 year."

I am not saying that there is anything specific about scrypt that means an adversary has to use FPGAs, or that FPGA's could increase the effectiveness of determined attacks even further than ASIC's, I am looking at which method gives us the potential to make bruteforcing attempts the most expensive.

Also:

• http://www.openwall.com/presentations/Passwords12-The-Future-Of-Hashing/

Future dev of 'supercomputers':

• "James Bamford's book The Shadow Factory reported that NSA told the Pentagon it would need an exaflop computer by 2018." - https://en.wikipedia.org/wiki/Shadow_Factory p339
• http://www.infoworld.com/t/networking/ibm-breaks-petaflop-barrier-263
• http://www.defencenews.in/defence-news-internal.asp?get=new&id=500
• http://www.h-online.com/newsticker/news/item/IDF-Intel-says-Moore-s-Law-holds-until-2029-734779.html

[Taipo]

One of the difficulties is finding working benchmarks for attacking scrypt key hashes. For now I can only go by information mostly authored by Colin Percival.

Summary of points where scrypt is said to get one over bcrypt ( plus some extras ):

• scrypt, via its memory cost and parallelization settings, can be configured to extend the cost to the attacker, considerably past the highest practical bcrypt cost setting without incurring memory and cpu costs on the host webserver.
• although its hard to find info on this, it appears that there is a limited password byte length for bcrypt. "Finally, the key argument is a secret encryption key, which can be a user-chosen password of up to 56 bytes (including a terminating zero byte when the key is an ASCII string)."
  from: https://www.usenix.org/legacy/events/usenix99/provos/provos_html/node4.html
  see also: http://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length
• Opinion: these organisations: NSA, GCHQ, CSE of Canada and the Chinese Governments, do not publish the amount of money they have invested into building custom password-cracking units, so while 'more' might be insane in some thinking, more is better than not enough because we are largely left making guesses by comparing what is the best of the best being developed and in play currently. So it looks like we will be contending with exaflop rigs ( see links above ) in about 5 years time.
• according to Percival, scrypt is 2⁵ times more expensive to attack than bcrypt
  from: https://www.tarsnap.com/scrypt/scrypt-slides.pdf slide 19
  So in my thinking, if those other two cost settings cannot be bypassed, then that makes scrypt the number 1 contender method for some future version of SecureDrop.

[garrettr]

These are all great points and resources, thanks @Taipo! It should be pretty easy for someone to implement this using this Python library.