It is, notably, not enough to safeguard the JS code with HTTPS/TLS (which, if you do that, SRP is of virtually no utility anyways). To protect the Javascript runtime, you'd also need to ensure that no element of the page was ever cached from a non-HTTPS connection, that no element of the page is currently fed from a non-HTTPS connection, and that the page is free from any and all DOM or CSS corruption issues.

Obviously, you'd also need to implement SRP safely, which very few people do; more than half of the SRP implementations I've ever tested have been trivially bypassed due to math flaws.

SRP is a terrible suggestion for generalist devs and for authentication in a web setting. If you want to do something advanced, go two-factor; I like Duo Security, which will be easier for you to integrate than SRP anyways:

http://www.duosecurity.com/

EDIT: To practice what I preach: Duo Song has made an impressive network sniffer and some other cool stuff, and Jon apparently is a security guru who, among other things, has found several security related Android bugs.

Looks like Duo has more options for receiving the code as well as the ability to enable manual approve/deny for another user role. It also looks like a private service I have to rely on though.

I definitely hear you on the better user/dev experience. That's very clear from the variety of methods and slick screenshots they've got.

https://tiqr.org/

1. Get a signed cert from a recognized CA (fraudulently - not impossible).

2. Hijack the DNS (e.g., get their GoDaddy password, or point them to a DNS server you control)>.

3. The user is directed to the fake server with the fraudulently obtained cert, and does not receive a warning.