CBCrypt: Encrypt from the client rather than send passwords to servers

Re:CBCrypt: Encrypt from the client rather than send passwor... by aggieben on Tuesday October 06, 2015 @11:48AM (#10339674)

My reaction is one of those "I'm not sure if I should feel stupid or not" moments, but: rightly-built applications already don't expose passwords to employees in that they aren't (or at least, shouldn't be) generally persisted. Usually the plaintext passwords live in volatile memory briefly while the server computes a hash of some kind for comparing with what is stored. I suppose an admin could run a web application under some sort of memory profiler, or take a dump at exactly the right moment, and capture a plaintext password, but that seems pretty far-fetched.

CBCrypt seems to me to introduce a lot more complexity into the entire application space with very little real gain. I'm certainly open to being convinced (especially because I'm waffling on whether or not this is a dumb reaction).

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by ybx on Tuesday October 06, 2015 @11:53AM (#10339743)

The idea is that you're implicitly trusting the company (or website), as well as anyone who has (whether legit or not) access, to only keep that password in memory, and it's preferable to authenticate without requiring that trust.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by aggieben on Tuesday October 06, 2015 @05:46PM (#10342645)

I can agree to this: this allows a user to not have to trust that the company running the application set up password authentication properly.

But still: I just can't get worked up about this at all. I'd rather see pgp get implemented in browsers before this.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by k3d3 on Tuesday October 06, 2015 @07:12PM (#10343090)

You can already use TLS client certificates - the UI is just terrible is all.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by joeuser3932 on Wednesday October 07, 2015 @09:23AM (#10345810)

The momentary exposure in memory was the downfall of Lavabit. It is actually trivial to capture passwords submitted to servers during the momentary exposure. For example, when you login to a Drupal or Wordpress site over HTTPS, the POST gets submitted to a particular form - which is just a PHP file on the server, trivially editable. The password exists as one of the submitted form variables, which PHP then passes to bcrypt (or whatever).

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by Freaky on Tuesday October 06, 2015 @01:26PM (#10340605)

People generally aren't carefully clearing passwords from memory after use, and ideally GC runs aren't happening all that often. "Exactly the right moment" could easily extend out to many minutes.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by aggieben on Tuesday October 06, 2015 @05:43PM (#10342632)

Right. So there's an I suppose in there somewhere, and my response is still pretty much: "meh". The people who might could possibly get access to that password already have access to all the data being protected by that password, and if they were so hell-bent on using your password to break into other sites, they could do that anyway by brute forcing what CBCrypt produces.

[ Parent | on HN ]

Re:CBCrypt: Encrypt from the client rather than send passwor... by Freaky on Wednesday October 07, 2015 @10:49AM (#10346334)

Brute forcing a password hash is a lot different from being able to trivially extract it from memory long after it's been used.

[ Parent | on HN ]