4 ms·

The hard part is getting browsers to all implement something like this (all with the same specification), which for some reason hasn't been happening, despite t

• deleted 11y ago
  [deleted]
• dorfsmay 11y ago
  Browser support would be better, but sites could already implement it in JavaScript.
  • devit 11y ago
    That would destroy security, since a compromised server could now get your password by serving malicious JavaScript...
    • jonknee 11y ago
      Can't a compromised server already get your password by serving malicious JavaScript?
      • Stefan-H 11y ago
        A malicious server doesn't need malicious javascript to do it, it already receives the password in the plain, but that is what is trying to be mitigated in these efforts.
        • jonknee 11y ago
          I was thinking a malicious 3rd party JS (say a CDN copy of jQuery or something).
          • k3d3 11y ago
            You might find interest in https://hacks.mozilla.org/2015/09/subresource-integrity-in-firefox-43/ https://hacks.mozilla.org/2015/09/subresource-integrity-in-f...
        • jessaustin 11y ago
          So you agree that a js lib would be an improvement over the status quo?
          • Stefan-H 11y ago
            Using a JS lib would not mitigate any risk here unless the compromising of the server that hosts the JS is separate from the compromsing of your web server.
            • k3d3 11y ago
              It mitigates passive MITM attacks, for one. On the other hand, there's nothing that's made _worse_ by choosing to do it that way. Plenty of things that are the same, some things better, but nothing worse.
              • Stefan-H 11y ago
                Hardly - if you are not using HTTPS in the first place then sending the hash across the wire instead of the password are the least of your worries.
• stan_rogers 11y ago
  It's been done, most notably in IBM/Lotus Notes, but that also brings its own set of problems to the table. In the Notes system, the user has an encrypted local credential store (part of the ID file) which contains, among other things, the user's private key and any shared secret keys the user may have been granted. The ID file also contains (in the clear) a certified public key, user name, and other information that should not be considered secret. The only password authentication is locally with the ID file. The password is salted and stretched with a key derivation function; the derived key is used to attempt to decrypt the encrypted portion of the ID file. "Success" is determined entirely by padding and checksums. Neither the password nor any variation on the theme of a hash of the password is stored anywhere. The "safe" portions of the ID (username and public key) are used to create a user account on the server. Authentication proceeds much like this: "Hi, server! I'm this guy according to that guy." "Oh yeah? Well, this guy (if that's your real name), you ought to be able to answer this encrypted question and send me a signed response." (Determining whether that guy actually vouched for this guy is standard signature stuff, assuming the check is needed at all. For stand-alone clients, a locally-generated certifier is SOP.) That does raise a couple of potential pain points, though. One is simply managing the local store, making sure that the users always have access to their credentials. Another is that when a store dies, the private key dies with it (secret keys can always be re-issued to a new credential store once the user is satisfactorily vetted). And users have this horrible, horrible habit of either never backing anything up or "backing up" to the same physical medium. In the corporate Notes world, that's not such a problem since updated ID files mail themselves off to an ID vault, but who gets that trust in the civilian world? And there's the little matter of password recovery (in Notes, a KDF state accessible using a combination of something like Shamir secret sharing and the private keys of k of n trusted administrator IDs) — one probably doesn't want to throw recoverable credential stores into the wild hoping that trust is never broken. Without password recovery (which isn't actually password recovery; it simply allows the user to re-encrypt the I with a key derived from a new password they choose) of some sort, anything that requires your private key is lost when your password is lost. Automating the resetting of a server account brings us back into the realm of highly insecure things like "security questions" (since it's very likely these days that the second factor of 2FA is the same lost/stolen device that prompted the need to reset the account in the first place). Nothing's perfect... or easy.