51 ms·

The reason I had difficulty using scrypt is because I didn't want to DoS my own server. Script asks you to choose a "work factor," and the higher the work fast

The reason I had difficulty using scrypt is because I didn't want to DoS my own server. Script asks you to choose a "work factor," and the higher the work faster, the harder it is to reverse the hash. Trouble is, if you set it too high, it's a bit painful to change it later. If you make a computationally difficult hashing scheme, then a lot of simultaneous logins can therefore force your server to use all of its CPU. Does this suffer from the same issue? It isn't necessarily an important issue. Maybe nobody will figure out they can take down your service that way. Maybe rate limiting is enough. Maybe you can solve it by having servers dedicated to hashing. I was just curious about the performance characteristics: Suppose that three people have passwords that are each randomly chosen and 6 characters long. A typical laptop can crack those passwords in about 1 hour. If you take the same passwords and protect them with PolyPasswordHasher, every computer on the planet working together cannot crack the password in 1 hour. In fact, to search the key space, it would take every computer on the planet longer than the universe is estimated to have existed. The contradiction is that if users can log in to your service quickly, then they can try a lot of passwords quickly. So is this more expensive than scrypt? If an attacker has read-only disk access, they can swipe any unencrypted data. Scrypt protects you from this, and it's straightforward about the requirements and computation costs. In practice, what kind of CPU usage would a PolyPasswordHasher scheme need?

kijin 11y ago
One way to prevent DoSing your own server while using expensive hashing algorithms is to offload some or all of the computation to client-side JavaScript (if it's a website) or client-side native code (if it's an app). This is called "server relief" [1]. Experts have said that scrypt can be safely used with server relief (see link below). But I'm not sure whether PolyPasswordHasher can be safely used with server relief (i.e. without leaking secrets to the client). Perhaps someone more knowledgeable will pitch in with a better answer. [1] https://news.ycombinator.com/item?id=9305504 https://news.ycombinator.com/item?id=9305504
nly 11y ago
Online DoS shouldn't really be a problem, since you should be rate limiting logins on a per-IP basis to prevent online brute-force anyway. Of course, typically nobody does that. 'Server relief' is dumb... correctly implementing a 'hashcash'-like scheme to prevent excessive CPU resource commitment is non-trivial. It will require either persistent pre-login server state, and/or cryptographic IP/session binding, both of which open up a second DoS vector. Implementing Scrypt etc in the browser doesn't completely prevent DoS, and sacrifices your ability as an operator to ensure passwords are being appropriately salted and munged (because of third party clients, unauthorised API users etc). Plus, attackers can just start using malicious webpages or botnets to crowdsource their hashing efforts which, because it scales horizontally, could actually speed things up for an attacker if you're server isnt doing any rate-limiting on the final hash+authentication stage.
- saurik 11y ago
  Limiting logins per IP address is a luxury that cannot be afforded by developers of applications targetting some Eastern countries or which are expected to be primarily used by mobile devices, due to pervasive usage of NAT and shared IP addresses. You are simply trading one form of DoS for another :/.
  - gkanapathy 11y ago
    Seems like it should be possible to rate limit failed logins, and of course failed logins on a per-account basis.
    - balls187 11y ago
      Failed logins, yes. However What the original comment was getting at scrypt would in effect, reduce the number of simultaneous login requests a server can handle, so legitimate usage could bog the server down.
    - leni536 11y ago
      >per account Nobody stops an attacker to use a fixed password and cycle the username. If your site has lots of users this could work pretty well. Your site could even "leak" (like forums) usernames making this approach more efficient.
    - zkhalique 11y ago
      Either way, how are you going to rate-limit failed logins while at the same time not allowing a DDOS of a user login? If I am using a botnet to keep trying passwords for Sarah Palin, how are you going to know when the real Sarah Palin logs in from a new computer? Sarah Palin will never be able to log in again from a new computer, unless she uses a key from her old one.
      - Ntrails 11y ago
        I would assume that you'd simply do (increasing) timed lockout periods by user/ip combination. At some point you have to accept that administrators will need to do some work, and if 200 IPs are trying to log into the same account 5 times every 15 minutes you should probably email the user and lock the account.

kijin 11y ago

One way to prevent DoSing your own server while using expensive hashing algorithms is to offload some or all of the computation to client-side JavaScript (if it's a website) or client-side native code (if it's an app). This is called "server relief" [1]. Experts have said that scrypt can be safely used with server relief (see link below). But I'm not sure whether PolyPasswordHasher can be safely used with server relief (i.e. without leaking secrets to the client). Perhaps someone more knowledgeable will pitch in with a better answer. [1] https://news.ycombinator.com/item?id=9305504 https://news.ycombinator.com/item?id=9305504

nly 11y ago

Online DoS shouldn't really be a problem, since you should be rate limiting logins on a per-IP basis to prevent online brute-force anyway. Of course, typically nobody does that. 'Server relief' is dumb... correctly implementing a 'hashcash'-like scheme to prevent excessive CPU resource commitment is non-trivial. It will require either persistent pre-login server state, and/or cryptographic IP/session binding, both of which open up a second DoS vector. Implementing Scrypt etc in the browser doesn't completely prevent DoS, and sacrifices your ability as an operator to ensure passwords are being appropriately salted and munged (because of third party clients, unauthorised API users etc). Plus, attackers can just start using malicious webpages or botnets to crowdsource their hashing efforts which, because it scales horizontally, could actually speed things up for an attacker if you're server isnt doing any rate-limiting on the final hash+authentication stage.

saurik 11y ago
Limiting logins per IP address is a luxury that cannot be afforded by developers of applications targetting some Eastern countries or which are expected to be primarily used by mobile devices, due to pervasive usage of NAT and shared IP addresses. You are simply trading one form of DoS for another :/.
- gkanapathy 11y ago
  Seems like it should be possible to rate limit failed logins, and of course failed logins on a per-account basis.
  - balls187 11y ago
    Failed logins, yes. However What the original comment was getting at scrypt would in effect, reduce the number of simultaneous login requests a server can handle, so legitimate usage could bog the server down.
  - leni536 11y ago
    >per account Nobody stops an attacker to use a fixed password and cycle the username. If your site has lots of users this could work pretty well. Your site could even "leak" (like forums) usernames making this approach more efficient.
  - zkhalique 11y ago
    Either way, how are you going to rate-limit failed logins while at the same time not allowing a DDOS of a user login? If I am using a botnet to keep trying passwords for Sarah Palin, how are you going to know when the real Sarah Palin logs in from a new computer? Sarah Palin will never be able to log in again from a new computer, unless she uses a key from her old one.
    - Ntrails 11y ago
      I would assume that you'd simply do (increasing) timed lockout periods by user/ip combination. At some point you have to accept that administrators will need to do some work, and if 200 IPs are trying to log into the same account 5 times every 15 minutes you should probably email the user and lock the account.