4 ms·

Not a crypto person. I'm pretty sure this is going to be ripped apart by tptacker, NateLawson or cperciva. But I'll speak up anyway :-) I see a lot of sites us

by sriramk 17y ago

Not a crypto person. I'm pretty sure this is going to be ripped apart by tptacker, NateLawson or cperciva. But I'll speak up anyway :-) I see a lot of sites use HTTP basic auth to do usernames/passwords (especially startups). Or worse, they send it over the clear (for e.g., some very popular APIs out there which I shall not name). Their reasons vary but typically it is one of cost and convenience. It is of course a terrible practice. Compared to HTTP basic auth, this seems less evil. In this case, with no implementation issues, I assume you need an active attacker. With HTTP basic, you can just grep logs and decrypt credentials. This seems the lesser of two evils. Please be gentle :-)

NateLawson 17y ago
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?

by sriramk 17y ago

NateLawson 17y ago

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?