4 ms·

Wow, this is still even a thing. The form, all its js assets and form api endpoint all have to be secured. And https for everything that contains code. Deplo

by dh997 11y ago

Wow, this is still even a thing. The form, all its js assets and form api endpoint all have to be secured. And https for everything that contains code. Deploying SRI for web pages over https is also another layer of defense against js tampering. Also, sending passwords across the wire in any reversible manner is really more dangerous than is necessary. Passwords/passphrases could be salted hashed by the browser in JavaScript using a PBKDF similar to scrypt or bcrypt, before being sent to the backend for constant-time comparison... it just takes a little more prudence and effort, but it's absolutely doable.

jstanley 11y ago
> Passwords/passphrases could be salted hashed by the browser in JavaScript using a PBKDF similar to scrypt or bcrypt, before being sent to the backend for constant-time comparison... it just takes a little more prudence and effort, but it's absolutely doable. This is not safe! Now an attacker just needs to intercept the hashed password and replay that, and he gets to login without knowing what the password is. Use https. And don't do client-side hashing, it's no improvement.
- cyphar 11y ago
  > Use https. And don't do client-side hashing, it's no improvement. Well, it's an improvement if your users are reusing their passwords. Then multiple different sites will have different hashes sent. But that's all besides the point, we should've been using zero knowledge proofs for authentication since the beginning.
  - kqr 11y ago
    With HTTPS, multiple different sites will have different "hashes" sent anyway, so no, it's not an improvement over just good ol' HTTPS.
    - cyphar 11y ago
      Well, sure. But then you have to worry about how well the website is storing your passwords. Meh, password managers are the way to go to be honest.
      - dh997 11y ago
        Most websites with any sense dont store actual passwords, they usually store salted PBKDF hashed that are compared in constant time.
- megous 11y ago
  This doesn't make any sense to me. If attacker can intercept connections I'd rather he get the hash than the plaintext password. At least then actual password is still not compromised, which is good, given how many people share passwords accross services. If he can tamper with connections, there's nothing that can be done anyway. It would be very nice if there was a feature in web browser that allowed user to opt in to something like this: When there's a password input on a website: 1] automatically take website's domain concatenate it to plaintext password 2] generate a secure hash from 1] 3] Derive some reasonably portable text password (20-30 characters) from 2] 4] Make it so that original web page never has access to user's plaintext password 5] Submit result of 3] Downsides: 1] Stupid websites enforcing password rules other than length (can be worked around mostly transparently). 2] Extra stupid websites limiting password length. (requires user interaction and configurable exceptions for such websites) 3] Can't login with browsers that don't implement this. This would be very nice for people who share passwords between services. Also would make web service data leaks less valuable to attackers. User would not depend on service password handling quality and/or operator's morality. I use different passwords for each and every service. But many people can't be bothered or don't get the risks of password sharing, so it would be at least some help to them.
  - dh997 11y ago
    Exactly. That's the risk to mitigate. Here's scrypt for js using emscripten on actual scrypt C source... the site has to provide and adjust/migrate the three factors over time to ensure a sane amount of cpu/memory is used: https://github.com/tonyg/js-scrypt https://github.com/tonyg/js-scrypt For real-world, practicality's sake, the client-side of an app would contain the PBKDF or some AA code, as opposed to the traditional, slightly-riskier "let the server handle all of it"-approach... the server still has final say on authentication and authorization, just move some of it into client-side js. There's really not much impact on FE development considering most FEs and BEs are codeveloped these days anyhow. Btw, for web devs Two-factor auth is cheap and easy to do, Google Authenticator OTP has open source libs and requires no calls to Google to work.
- dh997 11y ago
  You're wrong because it's a strawman since if an attacker can intercept the hash they could as easily intercept the plaintext in your traditional server-side architecture. The attacker cannot replay a TLS unless there is a problem with it, there have been many issues in TLS stacks, but it's the most widely deployed. Furthermore, using plaintext any further from the owner or exposed longer than is necessary is inherently less secure because your breach of https would also compromise users' passwords.
ewindisch 11y ago
The worst offender I interact with frequently is Hulu.com. This is a high-profile site with millions of users. It's one of those tell-tale signs as a consumer where I really can't say I trust them with my data. I really wonder, once they have a high-profile "hack" (I assume this will happen), if the state can charge them with criminal negligence?
wtbob 11y ago
> Passwords/passphrases could be salted hashed by the browser in JavaScript Not the worst idea from the developer's point of view, but it doesn't protect the user: the site could still serve bad JavaScript which didn't properly hash the password (this, for example, is why Mozilla accounts are completely, totally and utterly insecure, and why Firefox password storing should never be used by anyone who doesn't wish to share his passwords with Mozilla, any Mozilla employee and any state which can compel any Mozilla employee). The browser needs to natively support doing this. There's also the issue of replays. This topic has been well-studied; I believe that Secure Remote Password (SRP) is currently the gold standard for this.
timberburn 11y ago
Still happens. I pay rent through RentPayment.com, but their homepage (which contains a login form) is served over HTTP.

by dh997 11y ago

jstanley 11y ago

> Passwords/passphrases could be salted hashed by the browser in JavaScript using a PBKDF similar to scrypt or bcrypt, before being sent to the backend for constant-time comparison... it just takes a little more prudence and effort, but it's absolutely doable. This is not safe! Now an attacker just needs to intercept the hashed password and replay that, and he gets to login without knowing what the password is. Use https. And don't do client-side hashing, it's no improvement.

cyphar 11y ago
> Use https. And don't do client-side hashing, it's no improvement. Well, it's an improvement if your users are reusing their passwords. Then multiple different sites will have different hashes sent. But that's all besides the point, we should've been using zero knowledge proofs for authentication since the beginning.
- kqr 11y ago
  With HTTPS, multiple different sites will have different "hashes" sent anyway, so no, it's not an improvement over just good ol' HTTPS.
  - cyphar 11y ago
    Well, sure. But then you have to worry about how well the website is storing your passwords. Meh, password managers are the way to go to be honest.
    - dh997 11y ago
      Most websites with any sense dont store actual passwords, they usually store salted PBKDF hashed that are compared in constant time.
megous 11y ago
This doesn't make any sense to me. If attacker can intercept connections I'd rather he get the hash than the plaintext password. At least then actual password is still not compromised, which is good, given how many people share passwords accross services. If he can tamper with connections, there's nothing that can be done anyway. It would be very nice if there was a feature in web browser that allowed user to opt in to something like this: When there's a password input on a website: 1] automatically take website's domain concatenate it to plaintext password 2] generate a secure hash from 1] 3] Derive some reasonably portable text password (20-30 characters) from 2] 4] Make it so that original web page never has access to user's plaintext password 5] Submit result of 3] Downsides: 1] Stupid websites enforcing password rules other than length (can be worked around mostly transparently). 2] Extra stupid websites limiting password length. (requires user interaction and configurable exceptions for such websites) 3] Can't login with browsers that don't implement this. This would be very nice for people who share passwords between services. Also would make web service data leaks less valuable to attackers. User would not depend on service password handling quality and/or operator's morality. I use different passwords for each and every service. But many people can't be bothered or don't get the risks of password sharing, so it would be at least some help to them.
- dh997 11y ago
  Exactly. That's the risk to mitigate. Here's scrypt for js using emscripten on actual scrypt C source... the site has to provide and adjust/migrate the three factors over time to ensure a sane amount of cpu/memory is used: https://github.com/tonyg/js-scrypt https://github.com/tonyg/js-scrypt For real-world, practicality's sake, the client-side of an app would contain the PBKDF or some AA code, as opposed to the traditional, slightly-riskier "let the server handle all of it"-approach... the server still has final say on authentication and authorization, just move some of it into client-side js. There's really not much impact on FE development considering most FEs and BEs are codeveloped these days anyhow. Btw, for web devs Two-factor auth is cheap and easy to do, Google Authenticator OTP has open source libs and requires no calls to Google to work.
dh997 11y ago
You're wrong because it's a strawman since if an attacker can intercept the hash they could as easily intercept the plaintext in your traditional server-side architecture. The attacker cannot replay a TLS unless there is a problem with it, there have been many issues in TLS stacks, but it's the most widely deployed. Furthermore, using plaintext any further from the owner or exposed longer than is necessary is inherently less secure because your breach of https would also compromise users' passwords.

ewindisch 11y ago

The worst offender I interact with frequently is Hulu.com. This is a high-profile site with millions of users. It's one of those tell-tale signs as a consumer where I really can't say I trust them with my data. I really wonder, once they have a high-profile "hack" (I assume this will happen), if the state can charge them with criminal negligence?

wtbob 11y ago

> Passwords/passphrases could be salted hashed by the browser in JavaScript Not the worst idea from the developer's point of view, but it doesn't protect the user: the site could still serve bad JavaScript which didn't properly hash the password (this, for example, is why Mozilla accounts are completely, totally and utterly insecure, and why Firefox password storing should never be used by anyone who doesn't wish to share his passwords with Mozilla, any Mozilla employee and any state which can compel any Mozilla employee). The browser needs to natively support doing this. There's also the issue of replays. This topic has been well-studied; I believe that Secure Remote Password (SRP) is currently the gold standard for this.

timberburn 11y ago

Still happens. I pay rent through RentPayment.com, but their homepage (which contains a login form) is served over HTTP.