6 ms·

Not quite - a malicious server would receive the plaintext password in the current status quo.

by Stefan-H 11y ago

StavrosK 11y ago
You could scrypt on the client.
- ybx 11y ago
  You're still passing the output to the server, which can be repeated. Certainly better than just a password, but not as good as public key crypto. In the end, I'd probably prefer something like SRP
  - deleted 11y ago
    [deleted]
  - imaginenore 11y ago
    > You're still passing the output to the server, which can be repeated. Not if the server generates a unique ID for each attempt, and that ID must be used in hashing. It can be as simple as a timestamp.
    - k3d3 11y ago
      Which is then going beyond just using scrypt on the client. What you explain is simply challenge-response authentication.
Retric 11y ago
If a server just wants a hash, then that hash becomes the password. MITM attacks still work as long as all server credentials are public. EX: A fake wifi hotspot wants to MITM a connection and can fake any public information (public key's, IP's, DNS, etc.) Further, a fake website can sidestep this by not using a secured connection and just faking the UI.
- Stefan-H 11y ago
  If you read the mechanism, you'll see that this involves more than a site faking the UI - it requires browser integration. This mechanism does not protect a single site, but rather the ability to pivot from one site to another with the same password or key. You also breeze over "can fake any public information" - I have no idea what you are trying to say by the ability to fake public keys - that is not really a thing. HTTPS rides on having a trusted intermediary and so even a malicious MITM couldn't simply fake a public key.
  - Retric 11y ago
    You run into the question, is this the 'magic' UI or a PNG send from HAXORU. Windows reserves CTRL + ALT + DEL for this reason, but doing that on a tablet / phone that's already in production quickly runs into issues. Also, windows had plenty of issues with fake login screens. PS: I suspect protecting people from such things ends up requiring fairly strong AI or significant compromises.

Not quite - a malicious server would receive the plaintext password in the current status quo.

StavrosK 11y ago

You could scrypt on the client.

ybx 11y ago
You're still passing the output to the server, which can be repeated. Certainly better than just a password, but not as good as public key crypto. In the end, I'd probably prefer something like SRP
- deleted 11y ago
  [deleted]
- imaginenore 11y ago
  > You're still passing the output to the server, which can be repeated. Not if the server generates a unique ID for each attempt, and that ID must be used in hashing. It can be as simple as a timestamp.
  - k3d3 11y ago
    Which is then going beyond just using scrypt on the client. What you explain is simply challenge-response authentication.

Retric 11y ago

If a server just wants a hash, then that hash becomes the password. MITM attacks still work as long as all server credentials are public. EX: A fake wifi hotspot wants to MITM a connection and can fake any public information (public key's, IP's, DNS, etc.) Further, a fake website can sidestep this by not using a secured connection and just faking the UI.

Stefan-H 11y ago
If you read the mechanism, you'll see that this involves more than a site faking the UI - it requires browser integration. This mechanism does not protect a single site, but rather the ability to pivot from one site to another with the same password or key. You also breeze over "can fake any public information" - I have no idea what you are trying to say by the ability to fake public keys - that is not really a thing. HTTPS rides on having a trusted intermediary and so even a malicious MITM couldn't simply fake a public key.
- Retric 11y ago
  You run into the question, is this the 'magic' UI or a PNG send from HAXORU. Windows reserves CTRL + ALT + DEL for this reason, but doing that on a tablet / phone that's already in production quickly runs into issues. Also, windows had plenty of issues with fake login screens. PS: I suspect protecting people from such things ends up requiring fairly strong AI or significant compromises.