5 ms·

I think the idea is that the scrypt hash does become the password, but it's a better password. A password with a lot more entropy (kinda). The increased kinda-s

I think the idea is that the scrypt hash does become the password, but it's a better password. A password with a lot more entropy (kinda). The increased kinda-sorta entropy makes the use of a slow key derivation function on the server side unnecessary, so SHA-256 becomes sufficient. Not sure how I feel about it.

sarciszewski 11y ago
I feel that this is needlessly dangerous, personally. How are the salts managed? This detail is important. SHA256(scrypt(password, constant_value_instead_of_salt)) is going to produce collisions in the stored hash.
- owenmarshall 11y ago
  I think he's going for SHA256(scrypt(password, salt, work_factor)) and saying the bare SHA256 is sufficient. As opposed to SHA256(salt+scrypt(password, salt, work_factor)). I think it's dangerous because of the dependence on the client, and useless because scrypt(password,salt,work_factor) on the server is plenty hard to attack.
  - sinatra 11y ago
    > useless because scrypt(password,salt,work_factor) on the server is plenty hard to attack. It enables DoS attacks, though, right?
  - timv 11y ago
    > scrypt(password,salt,work_factor) on the server is plenty hard to attack For a large enough work_factor. In practice "large enough" is usually interpreted to mean "something that seems safe without being so large that I need to buy lots more servers" The argument (which I'm interested in, but not yet sold on) is that moving the scrypt to the client allows you to pump up the work_factor even higher than you would have been willing to do on the server.
    - owenmarshall 11y ago
      After thinking about it more the concept is interesting, but the main fear I have is that doing it in a web browser with JS is next to impossible to secure. Maybe if vendors got on board... In general though, pushing auth down to clients in Javascript makes my skin crawl. You're one XSS away from having an attacker no-op your scrypt and return SHA256("secret-attacker-password") on registration. The logical follow-up to that: 'have the server run scrypt the first time' -- but then you've just moved the tough work to user registration, which seems just as exploitable. I dunno. Safe crypto is hard enough already; I'm not sure pushing it into Javascript on the browser makes it any easier.
      - timv 11y ago
        The proposals I've see have always had the initial scrypt be done on the server. The DOS risk on registration can be mitigated more easily than the login one. e.g. Rate limiting new registrations will often be more palatable than limiting logins, or you can require "email validation" before you set the first password. And, not every application allows self registration.
- joveian 11y ago
  The salt could be created from the username (possibly with a standardize form step for case insensitively and maybe also including a site salt). On mobile devices client side hashing could affect battery life. If done with javascript, then login won't work without javascript enabled. Also, a work factor that doesn't slow down the slowest devices that a user might use could provide much less protection than desired, although the server could also do some work.
sinatra 11y ago
I'm not sure how I feel about it either. That's why I decided to ask for feedback. As for responding to sarciszewski's comment, there will still be a salt on the client side. We obviously don't want to use a fixed salt for all users.
mnw21cam 11y ago
Since the hash is derived purely from the password, it demonstrably does not have any more entropy than the password. Before you mention the salt - the salt is only useful if it if available. The client needs to know the salt in order to perform the calculation, therefore your attacker will also know the salt, so that doesn't count as entropy in the hash, either.

sarciszewski 11y ago

I feel that this is needlessly dangerous, personally. How are the salts managed? This detail is important. SHA256(scrypt(password, constant_value_instead_of_salt)) is going to produce collisions in the stored hash.

owenmarshall 11y ago
I think he's going for SHA256(scrypt(password, salt, work_factor)) and saying the bare SHA256 is sufficient. As opposed to SHA256(salt+scrypt(password, salt, work_factor)). I think it's dangerous because of the dependence on the client, and useless because scrypt(password,salt,work_factor) on the server is plenty hard to attack.
- sinatra 11y ago
  > useless because scrypt(password,salt,work_factor) on the server is plenty hard to attack. It enables DoS attacks, though, right?
- timv 11y ago
  > scrypt(password,salt,work_factor) on the server is plenty hard to attack For a large enough work_factor. In practice "large enough" is usually interpreted to mean "something that seems safe without being so large that I need to buy lots more servers" The argument (which I'm interested in, but not yet sold on) is that moving the scrypt to the client allows you to pump up the work_factor even higher than you would have been willing to do on the server.
  - owenmarshall 11y ago
    After thinking about it more the concept is interesting, but the main fear I have is that doing it in a web browser with JS is next to impossible to secure. Maybe if vendors got on board... In general though, pushing auth down to clients in Javascript makes my skin crawl. You're one XSS away from having an attacker no-op your scrypt and return SHA256("secret-attacker-password") on registration. The logical follow-up to that: 'have the server run scrypt the first time' -- but then you've just moved the tough work to user registration, which seems just as exploitable. I dunno. Safe crypto is hard enough already; I'm not sure pushing it into Javascript on the browser makes it any easier.
    - timv 11y ago
      The proposals I've see have always had the initial scrypt be done on the server. The DOS risk on registration can be mitigated more easily than the login one. e.g. Rate limiting new registrations will often be more palatable than limiting logins, or you can require "email validation" before you set the first password. And, not every application allows self registration.
joveian 11y ago
The salt could be created from the username (possibly with a standardize form step for case insensitively and maybe also including a site salt). On mobile devices client side hashing could affect battery life. If done with javascript, then login won't work without javascript enabled. Also, a work factor that doesn't slow down the slowest devices that a user might use could provide much less protection than desired, although the server could also do some work.

sinatra 11y ago

I'm not sure how I feel about it either. That's why I decided to ask for feedback. As for responding to sarciszewski's comment, there will still be a salt on the client side. We obviously don't want to use a fixed salt for all users.

mnw21cam 11y ago

Since the hash is derived purely from the password, it demonstrably does not have any more entropy than the password. Before you mention the salt - the salt is only useful if it if available. The client needs to know the salt in order to perform the calculation, therefore your attacker will also know the salt, so that doesn't count as entropy in the hash, either.