Richard Feldman (May 23 2024 at 16:45): Richard Feldman (May 23 2024 at 16:45):splitting off from #ideas > builtin cryptography
Richard Feldman (May 23 2024 at 16:46):here's an idea of some initial cryptographic functions we could support:
Richard Feldman (May 23 2024 at 16:47):obviously we can expand the list over time, but these three seem fairly uncontroversial as inclusions
Richard Feldman (May 23 2024 at 16:47):sha256 being used in a number of applications, and blake3 being faster than sha256 if you don't need compatibility with some other project
Brendan Hansknecht (May 23 2024 at 18:12):Argon2 is the algorithm where it is really easy to dos yourself, right? Cause it has a heavy memory footprint. Though I know that definitely depends on the exact sub variant and what not.
Richard Feldman (May 23 2024 at 18:17):hm, could be! Although I guess any "specify how many iterations you want" algorithm could have that property
Isaac Van Doren (May 23 2024 at 18:18):Looks like Stytch (an idp) uses scrypt over Argon2 because Argon2 is too time intensive for their use case https://stytch.com/blog/argon2-vs-bcrypt-vs-scrypt/#:~:text=For%20password%20protection%2C%20Argon2%2C%20bcrypt,increase%20computational%20strength%20against%20attacks.
Brendan Hansknecht (May 23 2024 at 21:46):To clarify, all of the parameters are tunable with argon2. That is one of its blessings (and also huge curse). My knowledge could be outdated, but if I recall correctly, recommended settings have quite high memory to make it hard to attack passwords with a GPU. The GPU will be out of memory long before it is able to saturate the compute units.
Brendan Hansknecht (May 23 2024 at 21:51):Ah yeah. If you look at the recommended settings here: https://en.wikipedia.org/wiki/Argon2#Recommended_minimum_parameters
Minimum memory usage and max compute still uses 7MiB per password being hashed. This may sound relatively small, but it easily explodes. Only takes a ~4.5 thousand password requests (trivial to generate from a single server) to use a full 32GiB of ram.
This is where having bcrypt, for example, as an alternative is nice. It only takes 4KiB of ram.
Brendan Hansknecht (May 23 2024 at 21:55):Oh, and it seems that the recommendation on memory use may have actually gone up based on the owasp website. Now 19 MiB. Nevermind, main recommendation is 19MiB, but they still support a 7MiB configuration.
Brendan Hansknecht (May 23 2024 at 21:59):Anyway, argon2 is probably still reasonable, but it is honestly not what I would recommend for any sort of hobbiest or small business type site. Instead I would recommend something less secure but also less resource intense to avoid crazy bills/overloaded servers/overly complex infra.
Brendan Hansknecht (May 23 2024 at 21:59):But I also am by no means even in the slightest an expert on this. Just something I find interesting and have dug into in the past.
Brendan Hansknecht (May 23 2024 at 21:59):Aside, will our builtin help users pick correct defaults with salts and peppers?
Richard Feldman (May 24 2024 at 01:31):I hope so!
Matthieu Pizenberg (Jun 23 2024 at 09:40):Brendan Hansknecht said:
Anyway, argon2 is probably still reasonable, but it is honestly not what I would recommend for any sort of hobbiest or small business type site. Instead I would recommend something less secure but also less resource intense to avoid crazy bills/overloaded servers/overly complex infra.
From my understanding of the cryptography course I'm following. If you allow human chosen passwords, the entropy is too limited to be secure. So the only defense mechanism possible against attacks is to make it expensive for an attacker. So many iterations of the hashing algorithm and lot of memory to prevent attacks with GPU and other ASICs
Matthieu Pizenberg (Jun 23 2024 at 09:43):It might also be interesting to steer hobbiest towards no-password solutions.
Brendan Hansknecht (Jun 23 2024 at 17:30):To be clear, I mention hobbiest/small businesses specifically cause often they have <= 1 tech person who may not really know security. As such, they are exceptionally unlikely to think of the cpu/memory/security trade off at all (also unlikely to know what a salt or pepper is or what he different algorithms really are). They still might be attacked by a bad actor or bot, but they are unlikely to be a target of a meaningful break due to the scope of their work.
In the modern day, memory actually tends to cost more than compute. That said, many services bill per time of usage. So it isn't a clear picture.
Fundamentally, a password auth api is one of the easiest targets for ddos. It also is pretty trivial to to protect from a small ddos. The simplest being a per ip rate limit. That leads to a fast path where the attacker mostly gets regular errors that are fast to execute and rarely gets to actually cause password hashing to occur. This brings the site from trivial to ddos to stardard difficulty to ddos.
Side note, I say ddos, but with a password auth target, a single machine might be able to incur a large bill for a hobbiest or small business.
Brendan Hansknecht (Jun 23 2024 at 17:31):It might also be interesting to steer hobbiest towards no-password solutions.
Very true
Matthieu Pizenberg (Jun 25 2024 at 10:42):Just thinking out loud.
In addition to rate limiting, what do you think of forcing the client to compute the hash, in a two-step process.
Step 1: client send username, server respond with associated salt if exists or set a new one if not (temporarily).
Step 2: given salt, the client must compute the hash and send it to the server, that just have to check if correct.
With this, the server cost is very minimal, and the one making the attack pays the compute price.
Brendan Hansknecht (Jun 25 2024 at 14:59):I don't think that works
Brendan Hansknecht (Jun 25 2024 at 14:59):Cause then you haven't verified if the client knows the password
Brendan Hansknecht (Jun 25 2024 at 14:59):You might have had a data breach and the hacker sent you the hash for an account without knowing the password.
Matthieu Pizenberg (Jun 25 2024 at 15:00):Not sure what you mean? The hash of the password is in the database, so you just check if the hash they sent is correct?
Matthieu Pizenberg (Jun 25 2024 at 15:00):Oh you mean for creation of passwords?
Matthieu Pizenberg (Jun 25 2024 at 15:02):Brendan Hansknecht said:
You might have had a data breach and the hacker sent you the hash for an account without knowing the password.
Ah right got it
Brendan Hansknecht (Jun 25 2024 at 15:04):Also, you can't properly use a pepper with client side hashing and using a pepper is considered part of best practices.
Matthieu Pizenberg (Jun 25 2024 at 15:14):Next idea, the hashing stays on server, but you send the client a random number and forces the client to do a proof of work of some kind, for example something bitcoin-like where they search a prefix or postfix that makes some hash have a given amount of leading zeros.
Matthieu Pizenberg (Jun 25 2024 at 15:15):That’s relatively cheap to verify on the server side. And if the proof of work is more expensive than the server password verification check, it might dissuade attackers.
Kiryl Dziamura (Jun 25 2024 at 18:06):pow
that's how captchas slow down agents, making an attack more expensive. however, you need to balance the difficulty and consider a wide range of clients (slow devices, smartphones etc) to not accidentally impact UX
Brendan Hansknecht (Jun 26 2024 at 00:55):Yeah, that 100% would be a solution
Brendan Hansknecht (Jun 26 2024 at 00:55):Clearly ux matters, but it definitely would make a ddos significantly harder
Last updated: Jun 16 2026 at 16:19 UTC