91–97 of 97 posts
Earlier quoted context omitted.
I don't know about the US but Barclays in the UK has had multi-factor authentication for years now. Is that not the case in the US?
If it is TOTP/HOTP based rather than U2F (6-digit codes), it is vulnerable to real-time spoofing.
Earlier quoted context omitted.
It's not memory-hard. That makes it much, much faster on GPUs than CPUs, which tends to mean it's much faster for attackers than legitimate users. It's also likely vunlerable to side-channel attacks, since nothing in its design tries to resist those. It's not broken by any means, and still vastly better than just a salted cryptographic hash, but it's not as good as Argon2id.
If I may ask a question: how would I use a memory hardened algorithm on a server if the server ram can't scale infinitely? It seems to me that a few concurrent user logins would effectively DOS the server for any reasonable configuration of argon2
Argon2id with t=3, m=92MiB, p=1 should be slower than bcrypt with cost 12 on most modern GPUs. That's not actually all that much memory, you can handle quite a few concurrent logins on a server with those settings. 10 concurrent logins per GiB of RAM dedicated to the task. And it should only DOS the login process, so it might make taking out your auth process (or server) easier but won't necessarily harm any other part of the site.
Earlier quoted context omitted.
As someone who worked in this field. Offering "options" when a vast majority of the user base don't even understand that their data is encrypted, is often a poor approach to take. Users will forget their Master Passwords even and because they forgot them they will believe they've been "hacked" and blame you. Users on Hacker News and similar sites where users actually understand the underlying technology to some degre…
It's a poor approach for multiple reasons. Like being the origin of downgrade attacks.
Earlier quoted context omitted.
I'm confused, 2^14 = 16384 is slightly more than 4 orders of magnitude, where did you get 20 from?
An "order of magnitude" has no precise numerical meaning, it depends on what base you're working in. If the log of the number in base b increases by 1, you've increased 1 order of magnitude with respect to that base. (I don't know why the parent said "20", my instinct is to say 14 orders of magnitude here.)
I think this misses the point: we should be doing everything we can to deprecate PBKDF2 because of the big differences between what a specialized attacker can do vs. the defender. As a rough estimate: a $2k bitcoin miner can do 2^45 SHA-256 hashes/sec whereas your $2k laptop can do 2^16 hashes/sec; the attacker has ~a billion x advantage over you that can be multiplied based on their funding. At that point, doing eve…
A $2k computer can do billions of hashes a second. 2^30 You're off by about 20 orders of magnitude (the joy of binary exponents).
From what I can see, a more realistic estimate for a single core on a desktop is in the 2^26 range. Keep in mind that the PBKDF2 defender is single-threaded by design, whereas the attacker is not.
This still represents ~a half million x advantage for the attacker/$2k they spend. For $1m, they can guess passwords ~200 million times faster than you.
If we assume memory is the limiting factor for argon2, then even if a specialized attacker can use it at scale for 1/20th the cost, a 20x advantage is much better for the defender than a 500,000x advantage.
Earlier quoted context omitted.
I think the important point is that Bitcoin mining hardware is much more specialized than that. The really crazy fast ASICs are hardwired to do SHA-256 hashes of Bitcoin block headers only and just increment the Bitcoin nonce before repeating. They can't be repurposed to crack password hashes.
They may not be repurposable per se, but they are a great benchmark for what may be realistically achievable for cracking password hashes utilizing similar base algorithms.
Someone using an FPGA or ASIC can dedicate almost all of the die to creating lots of SHA-256 units.
Earlier quoted context omitted.
If I may ask a question: how would I use a memory hardened algorithm on a server if the server ram can't scale infinitely? It seems to me that a few concurrent user logins would effectively DOS the server for any reasonable configuration of argon2
You don't actually need it to use that much RAM. It's more about memory bandwidth. An attacker can increase the memory bandwidth by using block RAM like in an FPGA or on-die RAM in an ASIC, but both of those are far more expensive than discrete DDR DRAM modules. So with appropriate memory usage (enough to saturate the cache lines) it can be cheap enough for the server to run yet still more expensive to build an ASIC…