linacs opened a new issue #1575: very slow (scrypt) calculation since CouchDB2.2 URL: https://github.com/apache/couchdb/issues/1575 Since I updated CouchDB from 2.1 to 2.2, CouchJS calculation with an implementation of Scrypt algorithm has become very slow (2 to 3 times more computation time). ## Expected Behavior Scrypt is used by my webapp (CouchApp) for password hash. Usually, it took 5 seconds to compute. ## Current Behavior Most of the time, the login request sends back a 500 error (timeout). I had to raise os_process_timetout to 20000 and it is still failing sometimes. It has become very long to log in. Performance depends on the machine. On AWS, it takes around 12 seconds to log in, now. On Scaleway (ATOM CPU) it fails most of the time. ## Possible Solution Except from increasing CPU performance (which is very complicated: most of the time you can get more CPUs, but they are all the same, and the JS algorithm is of course not threaded), I see only one solution for me right now: put the scrypt hash checking (and JWT generation) outside of my CouchApp. I already saw two years ago that NodeJS was way quicker than CouchJS to compute... Otherwise, I will have to use another password hash algorithm (with the risk of being as slow), and so to ask all my users to change their password with an email campaign... ## Steps to Reproduce (for bugs) This may be complicated. I use this implementation: https://github.com/tonyg/js-scrypt I had to adapt it to work with couchJS. I can send the file. However, I guess this is not due to this specific algorithm but that it reveals a global problem of performance whenever a CouchApp is computing a lot... ## Context The time for hashing must not be too long for my users, but it must be long enough to ensure strong security. My main users are school administrators. They can download (for backup) the whole database concerning their school (i.e. a Json document), which includes the hashed passwords. So there's a risk of a leak, hence the strong security. This is really annoying for my users who now have to wait a lot more to log in (and using my failover cluster has become almost impossible to log in). ## Your Environment * Version used: 2.2 * Browser Name and version: whatever browser * Operating System and version (server): Debian Jessy * Link to your project: www.omniscol.com (I can provide a full test account on a dedicated preprod server with more info if anyone can help me with this, but for security+business reason, I cannot put anything more precise publicly) Thanks! Gilles
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
