3 ms·
> Most notable for large-scale deployments is yescrypt's optional initialization and reuse of a large lookup table, typically occupying at least tens of gigabyt
by miav 5y ago
> Most notable for large-scale deployments is yescrypt's optional initialization and reuse of a large lookup table, typically occupying at least tens of gigabytes of RAM and essentially forming a site-specific ROM. This limits attackers' use of pre-existing hardware such as botnet nodes.
Is this needed? Assuming proper salting it is not feasible to crack SHA-2,blake2 etc hashes, let alone bcrypt and argon2 with thousands of iterations of them, is that not correct?
- tialaramex 5y agoIndeed. There are diminishing returns with this whole approach, all the way back to Unix crypt. If you have a good password (say, 16 alphanumerics = 36^16) even if the password storage is literally MD5 you're fine, I can't get anywhere. Fancier password schemes make no difference. If you have a bad password (say "password") then even if the storage uses an incredibly complicated GPU-hardened, ultra-impossible hash I can just guess "password" and I'm in, fancier password schemes still make no difference. So these schemes are intensely focused on the middle - trying to shore up the quite-bad passwords, the people who don't actually have a random password, but they put a little work in. Maybe bad guys would need a million guesses to find their password, and if we can make that cost $1000 instead of $1 they won't bother? I don't believe this justifies continued effort and instead we should throw those resources at getting rid of passwords. I wanted a way to allow a temporary machine (new employer wants me to be productive from day one but can't ship me company hardware in the first week) to share data with my own systems. I almost added a password step, with a random secret known to the temporary machine and in my password store. And then I stopped myself and just gated the whole data sharing behind WebAuthn. Tap tap, temporary laptop and main systems are both signed in, done. No passwords.
- adrian_b 5y agoI agree with you, except for the opportunity of getting rid of passwords. When its about company property, you might not care too much about the consequences so a solution without passwords can be fine. On the other hand, when it is about your personal data or devices, it may be unwise to trust anything else except the passwords stored in your head. If I would design myself some kind of security token with a microcontroller or better with a FPGA, I could trust it, but I could never trust any kind of commercial device to be free of backdoors or defects. So the most secure method for most people remains to memorize passwords.
- tialaramex 5y agoThe conspiracy required to have say, FIDO Security Keys secretly recruited to help the conspirators not you, while somehow your entire general purpose computer still ensures the passwords you're typing in remain secret, seems I think pretty laughable. In principle you can use a human memorable password to do something like the Socialist Millionaire's Protocol by hand, and thus escape any need for unanalysable hardware but the whole point of the SMP is that it's done in real time between humans, so you'd better get really good at maths and find a really patient correspondent to wait while you do it. If you're typing the password into, say, GMail, your worry makes no sense.
- tedunangst 5y agoThis is the notion of a "pepper" which isn't really necessary, but some people seem to like, except implemented in a way that makes it actually useful.