Johathan: You are correct, on sites for us that matter, we actually use one of the methods you pointed out: "Two factor seems to be the current best practice, or relying on a third party like Google via OAuth" -- we have several apps that use one of the these methods.
However, this can be overkill for some less important one off apps for which we rely only solely upon TLS by itself; it's much easier for users, and admins in many cases. Just thinking of a poor/lazy man's way of strengthening bare TLS, without OAuth, or two factor, for those lesser important sites. On Wed, Jan 4, 2017 at 7:26 AM, Jonathan Yu <jonathan.i...@gmail.com> wrote: > > > On Wed, Jan 4, 2017, 01:28 Henry <henry.adisuma...@gmail.com> wrote: > >> >> >> On Wednesday, January 4, 2017 at 1:40:40 PM UTC+7, Jonathan Yu wrote: >> >> >> >> While I agree that client-side hashing is overkill, I think the threat >> model it's intended to protect against is a compromised *server*, since >> this would prevent the server from ever seeing the plaintext password. >> >> In practice, I think most sites use TLS as you describe, and use bcrypt >> or similar on the server, along with rate limiting. This protects against >> everything except an advanced persistent threat (APT). >> >> -- >> >> >> I fail to see the purpose of client-side hashing. If the attacker gets >> the client's username and hashed password, what good does hashed password >> do if the attacker can also send the same username and hashed password to >> the server pretending to be the real client? >> > > Yes, this is true. > >> >> If the server is already compromised in such that the attacker can listen >> to clients' authentication process, there is no more value in obtaining the >> user's actual password. If the attacker compromises the server to such an >> extent, it is irrelevant whether the server receives the user's actual or >> hashed password. >> > > Well, given that many users reuse passwords everywhere, preventing the > server from seeing passwords could be a good thing. But upon reflection, I > agree that it wouldn't help in the APT case either, since whoever controls > the server could just change the JavaScript code so that the client > transmits the plaintext password. Hmm. > > Using TLS mutual authentication is better (client certificate), but there > are usability problems so few people do it. Two factor seems to be the > current best practice, or relying on a third party like Google via OAuth > (they have sophisticated fraud detection schemes, I think) > >> >> If you are talking about client-side encryption, I would think that TLS >> already does that for you. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > Jonathan Yu / *@jawnsy* on LinkedIn <https://linkedin.com/in/jawnsy>, > Twitter <https://twitter.com/jawnsy>, GitHub <https://github.com/jawnsy>, > Facebook <https://facebook.com/jawnsy> > > *“Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.”* — > Samuel Beckett, Worstward Ho (1983) > > “In an adaptive environment, winning comes from adapting to change by > continuously experimenting and identifying new options more quickly and > economically than others. The classical strategist's mantra of sustainable > competitive advantage becomes one of serial temporary advantage.” — Navigating > the Dozens of Different Strategy Options > <https://hbr.org/2015/06/navigating-the-dozens-of-different-strategy-options> > (HBR) > > -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/golang-nuts/W4Sa8gPJa1Y/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Edward B. Wilson II Systems Programmer Fire Department City of Los Angeles 213.484.6774 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
