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 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.

Reply via email to