[lucb1e]

This headline is weird. I thought it was going to be about doing computations client side since it says "serverless", but what they mean is "without a dedicated instance running all the time" (about halfway through the article, I figured out what "lambdas" are in this context).

So if there goes so much effort into calculating costs for PBKDF2 on servers (ahem, "serverless"), why not move it to the client side? I like client side hashing a lot because it transparently shows what security you apply, and any passive or after-the-fact attacks (think 1024 bit encryption decryption which will slowly move from 'impossible for small governments' to 'just very slow' soon) are instantly mitigated. The server should still apply a single round of their favorite hash function (like SHA-2) with a secret value, so an attacker will not be able to log in with stolen database credentials.

But that's probably too cheap and transparent when you can also do it with a Lambda™.

[kentonv]

"Serverless" is a recent industry buzzword which roughly means: "Server hosting environment where you upload code representing some sort of event handler and let the host decide where and when to run it. You are billed per event rather than per server instance."

This article is comparing the raw CPU power provided by two different serverless products. PBKDF2 is used only as an example of a computation requiring a lot of CPU.

[lucb1e]

> PBKDF2 is used only as an example of a computation requiring a lot of CPU.

Oh wow, I completely missed the point here. Having worked on strong client-side hashing in browsers and being into crypto generally, I saw this problem being presented and completely mistook it. Thanks!