4 ms·

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 i

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

ybx 11y ago
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.
- aggieben 11y ago
  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.
  - k3d3 11y ago
    You can already use TLS client certificates - the UI is just terrible is all.
Freaky 11y ago
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.
- aggieben 11y ago
  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.
  - Freaky 11y ago
    Brute forcing a password hash is a lot different from being able to trivially extract it from memory long after it's been used.
joeuser3932 11y ago
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).

ybx 11y ago

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.

aggieben 11y ago
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.
- k3d3 11y ago
  You can already use TLS client certificates - the UI is just terrible is all.

Freaky 11y ago

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.

aggieben 11y ago
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.
- Freaky 11y ago
  Brute forcing a password hash is a lot different from being able to trivially extract it from memory long after it's been used.

joeuser3932 11y ago

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