4 ms·

Yes, basic auth with no encryption is bad. In some cases, this is no better though. For example, if the key and JS are provided by the server, then it is the s

Yes, basic auth with no encryption is bad. In some cases, this is no better though. For example, if the key and JS are provided by the server, then it is the same as basic auth (all data needed to obtain the plaintext password is in the HTTP session). If the key is generated locally on the client, you have the problem of including a good enough PRNG, seeded from enough entropy that the attacker can't guess it. And those are all purely passive attacks (no MITM interjection). Active attacks could include modifying the JS to insert another field in the FORM POST response that is the plaintext key.

metachris 17y ago
javascript encryption will anyway only stop people at quickly decoding your data on sight. anyone who is willing to spend some time on decoding your data is able to do it, no matter which javascript library you use. also: nice idea, modifying the js to add a plain text field to the form :P
- paulbaumgart 17y ago
  That's true. Someone sitting with a wireless card in Monitor mode with Wireshark just sniffing passwords at the local cafe will probably have easier targets.
  - tptacek 17y ago
    Then just XOR your passwords against 0x41 in Javascript. Most attackers sitting the local cafe won't read this HN comment to learn your secret XOR key, your encryptor is a one-liner, and it's 95% as secure as Javascript RSA.
swolchok 17y ago
"For example, if the key and JS are provided by the server, then it is the same as basic auth (all data needed to obtain the plaintext password is in the HTTP session). If the key is generated locally on the client, you have the problem of including a good enough PRNG, seeded from enough entropy that the attacker can't guess it." What about if a public/private keypair is generated on the server and the public key is sent to the client? That sounds fine to me (implementation bugs notwithstanding) and it's what the second FAQ (http://www.jcryption.org/faq/ http://www.jcryption.org/faq/) says happens. Of course, this is still an awful idea because, as other posts have pointed out, the library itself can be doctored in transit, but I don't see a problem with the key handling design.
- tptacek 17y ago
  Even if you didn't have the JS problem here, you have the fundamental problem of not having trust anchors. You get a key over the network. How do you know it's the server's key?

metachris 17y ago

javascript encryption will anyway only stop people at quickly decoding your data on sight. anyone who is willing to spend some time on decoding your data is able to do it, no matter which javascript library you use. also: nice idea, modifying the js to add a plain text field to the form :P

paulbaumgart 17y ago
That's true. Someone sitting with a wireless card in Monitor mode with Wireshark just sniffing passwords at the local cafe will probably have easier targets.
- tptacek 17y ago
  Then just XOR your passwords against 0x41 in Javascript. Most attackers sitting the local cafe won't read this HN comment to learn your secret XOR key, your encryptor is a one-liner, and it's 95% as secure as Javascript RSA.

swolchok 17y ago

"For example, if the key and JS are provided by the server, then it is the same as basic auth (all data needed to obtain the plaintext password is in the HTTP session). If the key is generated locally on the client, you have the problem of including a good enough PRNG, seeded from enough entropy that the attacker can't guess it." What about if a public/private keypair is generated on the server and the public key is sent to the client? That sounds fine to me (implementation bugs notwithstanding) and it's what the second FAQ (http://www.jcryption.org/faq/ http://www.jcryption.org/faq/) says happens. Of course, this is still an awful idea because, as other posts have pointed out, the library itself can be doctored in transit, but I don't see a problem with the key handling design.

tptacek 17y ago
Even if you didn't have the JS problem here, you have the fundamental problem of not having trust anchors. You get a key over the network. How do you know it's the server's key?