4 ms·

Interestingly in a world of front-end JS frameworks you could fix this by encoding client-side before submission.

by nopassrecover 13y ago

hfern 13y ago
I believe vBulletin actually does this.
- davidsong 13y ago
  It's a good idea IMO, I don't understand why it gets so much flak. A server who doesn't want to know your secret is more trustworthy than one that does, a MITM might be able to hijack your account but he won't see your favourite password and you don't have to trust that the server is hashing the password at their end. To avoid the "hash is a plaintext password" problem you save double-hashed passwords to your database, once in the browser and once on the back-end, twice on the back-end if JavaScript was disabled in your user-agent. Of course that doesn't solve the problem above, but it still ought to be common practice.
  - dingdingdang 13y ago
    "A server who doesn't want to know your secret is more trustworthy than one that does" - I totally agree here, in many ways that's why projects like http://openpgpjs.org/ http://openpgpjs.org/ are fundamentally MORE important that more/newer layers of centralized encryption like TLS that are fundamentally bust in that we have to blindly trust the server. yesyes, i know JS on untrusted/leaky browsers isn't totally bingo but at least someone is TRYING!
Xorlev 13y ago
Or, use TLS and get it for free. Crypto on JS is a scary, scary world.
- nopassrecover 13y ago
  I don't think I was proposing not using TLS, just that if you interpret sending cleartext password over TLS as "plain-text" then sending it encoded over TLS sounds better.
subb 13y ago
Well, if you hash your password client-side, what's the difference from using clear text? A MITM will intercept your hashed password and use that to login.
- tedunangst 13y ago
  In theory, you could use something like MD5 auth, but really there's not much point.
annnnd 13y ago
DON'T! Just don't. Encrypting user credentials in JS is probably even worse than parsing HTML with regular expressions: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 http://stackoverflow.com/questions/1732348/regex-match-open-... Just send it in cleartext, but over properly verified https.
- mr_luc 13y ago
  I've read the Matasano whitepaper on why you can't count on Javascript for security, as I imagine you have, and it makes sense. Use https. That being said, look at something like blockchain.info. It adds javascript security on top of https, and for (what seems like) excellent reasons.
- nopassrecover 13y ago
  I was just musing hypothetically, but can you elaborate on why this is bad? Surely sending an encoded password is better than a non-encoded one, and in a worst case only as bad as sending a cleartext password (i.e. what happens now).

Interestingly in a world of front-end JS frameworks you could fix this by encoding client-side before submission.

hfern 13y ago

I believe vBulletin actually does this.

davidsong 13y ago
It's a good idea IMO, I don't understand why it gets so much flak. A server who doesn't want to know your secret is more trustworthy than one that does, a MITM might be able to hijack your account but he won't see your favourite password and you don't have to trust that the server is hashing the password at their end. To avoid the "hash is a plaintext password" problem you save double-hashed passwords to your database, once in the browser and once on the back-end, twice on the back-end if JavaScript was disabled in your user-agent. Of course that doesn't solve the problem above, but it still ought to be common practice.
- dingdingdang 13y ago
  "A server who doesn't want to know your secret is more trustworthy than one that does" - I totally agree here, in many ways that's why projects like http://openpgpjs.org/ http://openpgpjs.org/ are fundamentally MORE important that more/newer layers of centralized encryption like TLS that are fundamentally bust in that we have to blindly trust the server. yesyes, i know JS on untrusted/leaky browsers isn't totally bingo but at least someone is TRYING!

Xorlev 13y ago

Or, use TLS and get it for free. Crypto on JS is a scary, scary world.

nopassrecover 13y ago
I don't think I was proposing not using TLS, just that if you interpret sending cleartext password over TLS as "plain-text" then sending it encoded over TLS sounds better.

subb 13y ago

Well, if you hash your password client-side, what's the difference from using clear text? A MITM will intercept your hashed password and use that to login.

tedunangst 13y ago
In theory, you could use something like MD5 auth, but really there's not much point.

annnnd 13y ago

DON'T! Just don't. Encrypting user credentials in JS is probably even worse than parsing HTML with regular expressions: http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454 http://stackoverflow.com/questions/1732348/regex-match-open-... Just send it in cleartext, but over properly verified https.

mr_luc 13y ago
I've read the Matasano whitepaper on why you can't count on Javascript for security, as I imagine you have, and it makes sense. Use https. That being said, look at something like blockchain.info. It adds javascript security on top of https, and for (what seems like) excellent reasons.
nopassrecover 13y ago
I was just musing hypothetically, but can you elaborate on why this is bad? Surely sending an encoded password is better than a non-encoded one, and in a worst case only as bad as sending a cleartext password (i.e. what happens now).