4 ms·

The problem with using a scheme designed to be computationally intensive is that it doesn't scale. How can I justify 0.3 seconds of computation time if I'm deal

The problem with using a scheme designed to be computationally intensive is that it doesn't scale. How can I justify 0.3 seconds of computation time if I'm dealing with tens of thousands of connections per second?

derefr 17y ago
Make the client's computer do the work.
- deleted 17y ago
  [deleted]
- ErrantX 17y ago
  That defeats the point of the hashing :)
  - cperciva 17y ago
    Actually, it doesn't.
    - KirinDave 17y ago
      In this case, it does. If the client's job is to hash the password then send it to the server for comparison, you've basically got plaintext passwords. They may be quite long, but we're at that place where things don't scale anymore.
      - cperciva 17y ago
        Derive a 256-bit key from your password, then send that 256-bit key to the server. Nobody is ever going to perform a brute-force search against the 256-bit derived keyspace, so any attack will need to run the KDF against a list of likely passwords in order to get a list of likely keys.
        KirinDave 17y ago
        "Never", huh? Seems to me like an extremely strong statement for a security officer for a major operating system to be bandying about. Your proposal also treats a 2-way cryptographic function as a 1-way cryptographic function. That is, optimistically, a questionable thing to do.
        tptacek 17y ago
        It's an idea roughly analogous to SRP, which is well-studied. Share a key, then later prove you still know it. Client-side hashing would be great, if there was a way to do it that didn't involve Javascript.
        cperciva 17y ago
        I am perfectly willing to stake FreeBSD's security on the belief that nobody will ever perform a brute-force search against a 256-bit keyspace. For that matter, Microsoft, Apple, RedHat, Debian, and Ubuntu all make the same or (usually) even weaker assumptions in their respective packaging and/or updating systems.
tptacek 17y ago
First, tens of thousands of connections per second boils down to orders of magnitude fewer logins. In a typical modern web app, plenty of entire sessions are completed off a stored session token and never touch the login code. Second, plenty of apps that are far bigger than yours have scaled bcrypt without event. 37signals is a public example. Other larger apps are using it without talking about it. Third, in the spectacularly unlikely event that password hashing became a scalability obstacle, it's pure compute and scales horizontally without a problem. Note: I've never heard of someone having to do this. Finally, the whole point of bcrypt is that it's tuneable. You dial it up to your pain threshold, and in the process cripple brute force attackers.
ErrantX 17y ago
If those tens of thousands of connections per second are tens of thousands on logins, per second, then the computational value of your hash function seems likely to be the least of your problems :)

derefr 17y ago

Make the client's computer do the work.

deleted 17y ago
[deleted]
ErrantX 17y ago
That defeats the point of the hashing :)
- cperciva 17y ago
  Actually, it doesn't.
  - KirinDave 17y ago
    In this case, it does. If the client's job is to hash the password then send it to the server for comparison, you've basically got plaintext passwords. They may be quite long, but we're at that place where things don't scale anymore.
    - cperciva 17y ago
      Derive a 256-bit key from your password, then send that 256-bit key to the server. Nobody is ever going to perform a brute-force search against the 256-bit derived keyspace, so any attack will need to run the KDF against a list of likely passwords in order to get a list of likely keys.
      - KirinDave 17y ago
        "Never", huh? Seems to me like an extremely strong statement for a security officer for a major operating system to be bandying about. Your proposal also treats a 2-way cryptographic function as a 1-way cryptographic function. That is, optimistically, a questionable thing to do.
        tptacek 17y ago
        It's an idea roughly analogous to SRP, which is well-studied. Share a key, then later prove you still know it. Client-side hashing would be great, if there was a way to do it that didn't involve Javascript.
        cperciva 17y ago
        I am perfectly willing to stake FreeBSD's security on the belief that nobody will ever perform a brute-force search against a 256-bit keyspace. For that matter, Microsoft, Apple, RedHat, Debian, and Ubuntu all make the same or (usually) even weaker assumptions in their respective packaging and/or updating systems.

tptacek 17y ago

First, tens of thousands of connections per second boils down to orders of magnitude fewer logins. In a typical modern web app, plenty of entire sessions are completed off a stored session token and never touch the login code. Second, plenty of apps that are far bigger than yours have scaled bcrypt without event. 37signals is a public example. Other larger apps are using it without talking about it. Third, in the spectacularly unlikely event that password hashing became a scalability obstacle, it's pure compute and scales horizontally without a problem. Note: I've never heard of someone having to do this. Finally, the whole point of bcrypt is that it's tuneable. You dial it up to your pain threshold, and in the process cripple brute force attackers.

ErrantX 17y ago

If those tens of thousands of connections per second are tens of thousands on logins, per second, then the computational value of your hash function seems likely to be the least of your problems :)