4 ms·
Nice to see someone actually using SRP. And understanding what's actually possible in Javascript (note that Zed very carefully doesn't say that this is "host-pr
by JoachimSchipper 16y ago
Nice to see someone actually using SRP. And understanding what's actually possible in Javascript (note that Zed very carefully doesn't say that this is "host-proof" or something along those lines.)
- tptacek 16y agoHelp me out here, Joachim, because you know where I'm coming from: what's the setting in which this Javascript SRP implementation could improve things over stock-standard HTTPS login?
- JoachimSchipper 16y agoI replied to your top-level comment: http://news.ycombinator.com/item?id=2034926 http://news.ycombinator.com/item?id=2034926.
- zedshaw 16y agoYou'd use both HTTPS and this, as I mentioned before. This just means that a site using the service, if they use it right (big if), doesn't have to worry about password storage or securing them and leaves it to autho.me. Otherwise, everything else is pretty much the same as what you got on existing websites.
- tptacek 16y agoYou read my whole comment. You know you can't just use HTTPS for your part of it; that you have to have clean-room purity for every piece of content that builds any page that ever deals with any of the mechanics of this code. Everybody who ever thought "oh, I'll just AES encrypt passwords in Javascript instead of using HTTPS" later came up with "oh, then I'll serve just the JS for this crypto off some HTTPS site somewhere" when someone pointed out how crazy that was. It is nowhere near that easy.
- zedshaw 16y agoLike I keep telling you, this isn't any more or less secure than any existing solution because the browser is not secure in the face of an attack. Even with HTTPS if I can inject some javscript then it's a one-liner to get your password. So no, even with HTTPS and your proposed solution you'd still be screwed.