3 ms·

I always worry about those, because it suggest that they might be using those passwords to build a string of some sort, like a database query, or a json object.

by jl2718 4y ago

I always worry about those, because it suggest that they might be using those passwords to build a string of some sort, like a database query, or a json object. This is a problem firstly because string libraries are notoriously vulnerable, secondly because the password is being sent somewhere, and thirdly because it’s probably being stored somewhere. Stop doing this! Un-hashed* passwords should never leave the browser. * don’t forget salt. Mmmm… salty hash brown passwords

jagged-chisel 4y ago
Encrypted over TLS is fine. You don’t gain anything by digesting salts, peppers, and passwords on the client side. You’re ultimately handing an string to a server, and if your backend just takes that scrambled text and compares it to a database entry, it’s no better against MITM attacks than not digesting. You’ve also increased the complexity and bug surface area of the client-side code for any client that needs to log in. Just don’t send plaintext passwords over raw HTTP, enforce TLS.
- jl2718 4y ago
  Passwords have low entropy and high reuse, so they can be used outside of their purpose, which is to allow access to a single resource. A salted hash is only useful to the resource it provides access to, and a salted and peppered hash provides resistance from external unsalted disclosures. TLS in the browser is intentionally insecure. All browsers allow a back door . certificate to MITM every connection through proxies. Guess what happens to that traffic? Decrypted, stored, sent off to third parties, who knows what. Every major corporate network does this. An actually-secure protocol would enforce client certification to the device manufacturer’s authority, or at least to the browser vendor’s authority. Regarding the attack surface, use this: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt... Please do not send passwords off the client. Use a standard (I’m surprised that no such thing exists in an accessible way from the browser), but the protocol should look something like: enter password, digest, salt, digest, tls, pepper, digest, encrypt, store. Asking HN: is there an open standard that actually spells out 100% of a password management protocol with highly trusted implantations on both sides?
  - jagged-chisel 4y ago
    > Every major corporate network … That specific complaint seems to me more about trusted roots - corporate can just install their own CA cert on each machine. What backdoor are you talking about? Sounds like administrative access to the computers owned by the company. The seasoning and digesting doesn’t solve that problem. Every company also has the wherewithal to copy/store/transmit anything typed into an input field on computers they own. If there’s some other intentional “browser backdoor” (not social engineering attempts against end users) for installing random signing certs, I’d like to read about it. If I own the hardware and control the software installed on it (notwithstanding infiltration), none if my TLS traffic is peeled open on the way to its destination.
    - jl2718 4y ago
      Please understand that a CA is a human person, subject to all laws of the jurisdictions in which they reside, as well as human nature.
  - GoblinSlayer 4y ago
    >Asking HN: is there an open standard that actually spells out 100% of a password management protocol with highly trusted implantations on both sides? If you don't want to go full asymmetric cryptography, there's SCRAM. It doesn't specify pepper, but pepper can be added to salt like for any salted scheme: salt=hash(pepper, stored salt);
- GoblinSlayer 4y ago
  The request can be logged on server side. Twitter thus logged passwords in plain text some time ago.
  - jagged-chisel 4y ago
    There’s nothing that can be done on the client to prevent this. Either your plaintext password can be used directly to login to a system, or your seasoned (on the client) password is effectively the same. Either of these logged can then be used to impersonate you.
    - GoblinSlayer 4y ago
      It prevents leak of plaintext passwords. I suppose impersonation by a twitter employee is not a concern, because they already have access to the twitter system from inside.
    - a1369209993 4y ago
      Yes there is. Use a PBKDF to turn the password into a (public key,signature of session cookie or challenge nonce) pair, and send that to the server. The server stores the public key in place of a salted password and validates the signature in place of password comparison. The 'seasoned' key-signature pair is useless for any later session.

by jl2718 4y ago

jagged-chisel 4y ago

Encrypted over TLS is fine. You don’t gain anything by digesting salts, peppers, and passwords on the client side. You’re ultimately handing an string to a server, and if your backend just takes that scrambled text and compares it to a database entry, it’s no better against MITM attacks than not digesting. You’ve also increased the complexity and bug surface area of the client-side code for any client that needs to log in. Just don’t send plaintext passwords over raw HTTP, enforce TLS.

jl2718 4y ago
Passwords have low entropy and high reuse, so they can be used outside of their purpose, which is to allow access to a single resource. A salted hash is only useful to the resource it provides access to, and a salted and peppered hash provides resistance from external unsalted disclosures. TLS in the browser is intentionally insecure. All browsers allow a back door . certificate to MITM every connection through proxies. Guess what happens to that traffic? Decrypted, stored, sent off to third parties, who knows what. Every major corporate network does this. An actually-secure protocol would enforce client certification to the device manufacturer’s authority, or at least to the browser vendor’s authority. Regarding the attack surface, use this: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt... Please do not send passwords off the client. Use a standard (I’m surprised that no such thing exists in an accessible way from the browser), but the protocol should look something like: enter password, digest, salt, digest, tls, pepper, digest, encrypt, store. Asking HN: is there an open standard that actually spells out 100% of a password management protocol with highly trusted implantations on both sides?
- jagged-chisel 4y ago
  > Every major corporate network … That specific complaint seems to me more about trusted roots - corporate can just install their own CA cert on each machine. What backdoor are you talking about? Sounds like administrative access to the computers owned by the company. The seasoning and digesting doesn’t solve that problem. Every company also has the wherewithal to copy/store/transmit anything typed into an input field on computers they own. If there’s some other intentional “browser backdoor” (not social engineering attempts against end users) for installing random signing certs, I’d like to read about it. If I own the hardware and control the software installed on it (notwithstanding infiltration), none if my TLS traffic is peeled open on the way to its destination.
  - jl2718 4y ago
    Please understand that a CA is a human person, subject to all laws of the jurisdictions in which they reside, as well as human nature.
- GoblinSlayer 4y ago
  >Asking HN: is there an open standard that actually spells out 100% of a password management protocol with highly trusted implantations on both sides? If you don't want to go full asymmetric cryptography, there's SCRAM. It doesn't specify pepper, but pepper can be added to salt like for any salted scheme: salt=hash(pepper, stored salt);
GoblinSlayer 4y ago
The request can be logged on server side. Twitter thus logged passwords in plain text some time ago.
- jagged-chisel 4y ago
  There’s nothing that can be done on the client to prevent this. Either your plaintext password can be used directly to login to a system, or your seasoned (on the client) password is effectively the same. Either of these logged can then be used to impersonate you.
  - GoblinSlayer 4y ago
    It prevents leak of plaintext passwords. I suppose impersonation by a twitter employee is not a concern, because they already have access to the twitter system from inside.
  - a1369209993 4y ago
    Yes there is. Use a PBKDF to turn the password into a (public key,signature of session cookie or challenge nonce) pair, and send that to the server. The server stores the public key in place of a salted password and validates the signature in place of password comparison. The 'seasoned' key-signature pair is useless for any later session.