I keep seeing responses like this but they never make sense to me.
Your argument basically boils down to "JS-based SRP is insecure because JavaScript crypto is insecure, which is because of the web page delivery mechanism". Well, yes, web crypto has a chicken and egg trust issue, but this problem *already exists in the current traditional login methods*! If a malicious actor can inject HTML/JS into your login page, *both* SRP and traditional password logins would both be hosed, since it would be trivial to just listen to all the keyboard inputs and query the password field's value.
Browser JS-based SRP can't defend against JS injection, but it defends against other things. It protects again careless mistake like the recent ones (Github and Twitter accidentally logging traffic). It also increases trust. In the traditional method, failures are silent. A malicious or incompetent actor could silently log all the passwords without you the user knowing about it. All you have is their word. For SRP though, an attack is much more visible and much less likely to be due to a coding error. Since it requires changing the login page's code and will send more information back, it's likely to be caught by security researchers unless it's a *really* targeted attack.
SRP also protects against MITM attacks. These are not theoretical. Look up BEAST/CRIME/BREACH which were attacks on TLS protocol itself, or Cloudbleed (https://en.wikipedia.org/wiki/Cloudbleed) where CloudFlare had a bug in their SSL proxy which led to anyone being able to intercepts their SSL traffic (incidentally 1Password traffic was intercepted too but was fine because they used SRP...). These kinds of attacks are passive MITM listening attacks, and a browser-based SRP would still be fine since the attacker isn't injecting content.
Browser SRP is not perfect, but it doesn't need to be! It just needs to be *better* than traditional password entries. In this case it's actually *strictly* better, since all the failure cases for SRP are also failure cases for traditional passwords.
I do agree a native browser SRP solution rather than one based on JS would be nice, but perfect is the enemy of good. JS-based SRP is already better than traditional login pages, and if you build a website you can already deploy it.
"All this to solve a problem that the wider community generally considers 'solved'"
Well...as we can see from these two instances it's clearly not solved. Defense in depth means you reduces risks in multiple layers. Also, as I mentioned, we are thinking on the side of server administrators. Even if you claim you are practicing good security practices, there's no way for a user to know as he's just sending the raw password to you anyway. If you use SRP though, I can actually hold you accountable since I know there's literally no way for you to steal my passwords. It's like in SSH where I know it's literally impossible for the server to steal my private key.
Slashdot Mirror
I keep seeing responses like this but they never make sense to me.
Your argument basically boils down to "JS-based SRP is insecure because JavaScript crypto is insecure, which is because of the web page delivery mechanism". Well, yes, web crypto has a chicken and egg trust issue, but this problem *already exists in the current traditional login methods*! If a malicious actor can inject HTML/JS into your login page, *both* SRP and traditional password logins would both be hosed, since it would be trivial to just listen to all the keyboard inputs and query the password field's value.
Browser JS-based SRP can't defend against JS injection, but it defends against other things. It protects again careless mistake like the recent ones (Github and Twitter accidentally logging traffic). It also increases trust. In the traditional method, failures are silent. A malicious or incompetent actor could silently log all the passwords without you the user knowing about it. All you have is their word. For SRP though, an attack is much more visible and much less likely to be due to a coding error. Since it requires changing the login page's code and will send more information back, it's likely to be caught by security researchers unless it's a *really* targeted attack.
SRP also protects against MITM attacks. These are not theoretical. Look up BEAST/CRIME/BREACH which were attacks on TLS protocol itself, or Cloudbleed (https://en.wikipedia.org/wiki/Cloudbleed) where CloudFlare had a bug in their SSL proxy which led to anyone being able to intercepts their SSL traffic (incidentally 1Password traffic was intercepted too but was fine because they used SRP...). These kinds of attacks are passive MITM listening attacks, and a browser-based SRP would still be fine since the attacker isn't injecting content.
Browser SRP is not perfect, but it doesn't need to be! It just needs to be *better* than traditional password entries. In this case it's actually *strictly* better, since all the failure cases for SRP are also failure cases for traditional passwords.
I do agree a native browser SRP solution rather than one based on JS would be nice, but perfect is the enemy of good. JS-based SRP is already better than traditional login pages, and if you build a website you can already deploy it.
"All this to solve a problem that the wider community generally considers 'solved'"
Well...as we can see from these two instances it's clearly not solved. Defense in depth means you reduces risks in multiple layers. Also, as I mentioned, we are thinking on the side of server administrators. Even if you claim you are practicing good security practices, there's no way for a user to know as he's just sending the raw password to you anyway. If you use SRP though, I can actually hold you accountable since I know there's literally no way for you to steal my passwords. It's like in SSH where I know it's literally impossible for the server to steal my private key.