Not really. In the scrypt paper, cperciva recommends parameters that allow it to do a single password hash in 64 ms, and in the process use only 4k of RAM. Nowa

Not really. In the scrypt paper, cperciva recommends parameters that allow it to do a single password hash in 64 ms, and in the process use only 4k of RAM. Nowadays, as processors are faster and ram is cheaper, you'd probably want to up the parameters a bit, so that the encryption time will be similar (between 50-100 ms) on modern hardware, and the RAM usage will scale proportionally (probably 128k, based on the ratio of RAM prices between 2002 and now). That means that you would be able to handle 10-20 logins per second per core, using no more than 2.5 MB in the process (if they were all run in parallel on separate threads and so all of that memory was needed at once; that's obviously a worst case, most likely they would be scheduled more sequentially and use proportionally less RAM as you would free the memory after finishing an encryption). On a 12 core machine, you might wind up using 30 MB at at time, to support 240 logins per second. If you need to handle 240 logins per second (which presumably means many many more requests per second, as there are usually many requests per login), 30 MB of RAM is the least of your worries. Note that these numbers are simply extrapolations from the ones in the original scrypt paper, I haven't actually tried this on modern hardware. Regardless, there are parameters that allow you to trade off CPU time and RAM usage, so you can tweak it to provide the level of performance that you require (with the understanding that the faster it is and less RAM it uses, the faster cracking it would be).