Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #35303 > unrolled thread

Submitting *encrypted* forms via AJAX

Back to article view | Back to comp.lang.javascript

Contents

  Submitting *encrypted* forms via AJAX bit-naughty@hotmail.com - 2018-06-25 02:48 -0700
    Re: Submitting *encrypted* forms via AJAX JJ <jj4public@vfemail.net> - 2018-06-25 22:03 +0700
      Re: Submitting *encrypted* forms via AJAX "Christoph M. Becker" <cmbecker69@arcor.de> - 2018-06-25 17:21 +0200
        Re: Submitting *encrypted* forms via AJAX JJ <jj4public@vfemail.net> - 2018-06-26 14:59 +0700
          Re: Submitting *encrypted* forms via AJAX Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-06-26 16:47 +0200
            Re: Submitting *encrypted* forms via AJAX Richard Damon <Richard@Damon-Family.org> - 2018-06-26 21:09 -0400
              Re: Submitting *encrypted* forms via AJAX Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-06-27 09:45 +0200
                Re: Submitting *encrypted* forms via AJAX "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-06-27 00:54 -0700
                Re: Submitting *encrypted* forms via AJAX Jon Ribbens <jon+usenet@unequivocal.eu> - 2018-06-27 13:29 +0000
                  Re: Submitting *encrypted* forms via AJAX "Christoph M. Becker" <cmbecker69@arcor.de> - 2018-06-27 15:47 +0200
                    Re: Submitting *encrypted* forms via AJAX Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-06-27 16:00 +0100
                      Re: Submitting *encrypted* forms via AJAX Julio Di Egidio <julio@diegidio.name> - 2018-06-27 08:11 -0700
                        Re: Submitting *encrypted* forms via AJAX Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-06-28 01:53 +0100
                          Re: Submitting *encrypted* forms via AJAX Julio Di Egidio <julio@diegidio.name> - 2018-06-27 21:48 -0700
                          Re: Submitting *encrypted* forms via AJAX Jon Ribbens <jon+usenet@unequivocal.eu> - 2018-06-28 09:17 +0000
                            Re: Submitting *encrypted* forms via AJAX Julio Di Egidio <julio@diegidio.name> - 2018-06-28 03:25 -0700
                    Re: Submitting *encrypted* forms via AJAX "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-06-27 14:04 -0700
                      Re: Submitting *encrypted* forms via AJAX "Christoph M. Becker" <cmbecker69@arcor.de> - 2018-06-28 13:54 +0200
                        Re: Submitting *encrypted* forms via AJAX "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-06-28 13:46 -0700
    Re: Submitting *encrypted* forms via AJAX jecxjo <jeff@sh0.xyz> - 2018-07-02 03:21 +0000
      Re: Submitting *encrypted* forms via AJAX Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-07-15 04:56 +0200
        Re: Submitting *encrypted* forms via AJAX "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2018-07-16 01:00 +0200

Page 1 of 2  [1] 2  Next page →

#35303 — Submitting *encrypted* forms via AJAX

Hi,
I have a Login box on my website, with a name and password field. When it's submitted, I want it to happen without a refresh (ie. the authentication), and I also want the form data to be ENCRYPTED between client and server (because of the password).

Number 1) How do I submit? How do I get the form data into a format that "request.send" in the AJAX call will take? Do I have to extract the form data myself with "document.forms" and muck about with it somehow?
and 2) How do I encrypt? Is putting a "https" in the "request.open("POST", https<blah blah>);" enough, or do I have to do something else?

Thanks muchly for your help.

[toc] | [next] | [standalone]

#35308

On Mon, 25 Jun 2018 02:48:27 -0700 (PDT), bit-naughty@hotmail.com wrote:
> Hi, I have a Login box on my website, with a name and password field. When
> it's submitted, I want it to happen without a refresh (ie. the
> authentication), and I also want the form data to be ENCRYPTED between
> client and server (because of the password). 
> 
> Number 1) How do I submit? How do I get the form data into a format that
> "request.send" in the AJAX call will take? Do I have to extract the form
> data myself with "document.forms" and muck about with it somehow? and 2)
> How do I encrypt? Is putting a "https" in the "request.open("POST",
> https<blah blah>);" enough, or do I have to do something else? 
> 
> Thanks muchly for your help.

You'll have to encrypt it manually, before the form is submitted.

[toc] | [prev] | [next] | [standalone]

#35309

On 25.06.2018 at 17:03, JJ wrote:

> On Mon, 25 Jun 2018 02:48:27 -0700 (PDT), bit-naughty@hotmail.com wrote:
>
>> Hi, I have a Login box on my website, with a name and password field. When
>> it's submitted, I want it to happen without a refresh (ie. the
>> authentication), and I also want the form data to be ENCRYPTED between
>> client and server (because of the password). 
>>
>> Number 1) How do I submit? How do I get the form data into a format that
>> "request.send" in the AJAX call will take? Do I have to extract the form
>> data myself with "document.forms" and muck about with it somehow? and 2)
>> How do I encrypt? Is putting a "https" in the "request.open("POST",
>> https<blah blah>);" enough, or do I have to do something else? 
>>
>> Thanks muchly for your help.
> 
> You'll have to encrypt it manually, before the form is submitted.

Absolutely!  And by all means, use ROT13 for encryption, since it is the
strongest encryption method of all times! ;)

Kidding aside: why would you manually encrypt the form submission,
instead of relying on TLS?

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#35311

On Mon, 25 Jun 2018 17:21:14 +0200, Christoph M. Becker wrote:
> 
> Kidding aside: why would you manually encrypt the form submission,
> instead of relying on TLS?

Why ask me? Maybe he want more security.

[toc] | [prev] | [next] | [standalone]

#35313

JJ wrote:

> On Mon, 25 Jun 2018 17:21:14 +0200, Christoph M. Becker wrote:
>> Kidding aside: why would you manually encrypt the form submission,
>> instead of relying on TLS?
> 
> Why ask me? Maybe he want more security.

JFYI (as apparently you did not get the joke):

Data encryption in and by client-side script code is *false* security – 
“security by obscurity”: It does _not_ increase security *at all* because 
*you serve* the used encryption algorithm to a potential attacker.

The proper solution for more security on Web sites are authentication and 
stronger encryption on the *transport* layer (TLS with big[ger] key lengths) 
instead.  Not only does this reduce the risk of successful man-in-the-middle 
(MITM) attacks, it also allows one to determine if the data has been 
tampered with.

<https://www.keylength.com/en/compare/>
<https://www.owasp.org/>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#35315

On 6/26/18 10:47 AM, Thomas 'PointedEars' Lahn wrote:
> JJ wrote:
> 
>> On Mon, 25 Jun 2018 17:21:14 +0200, Christoph M. Becker wrote:
>>> Kidding aside: why would you manually encrypt the form submission,
>>> instead of relying on TLS?
>>
>> Why ask me? Maybe he want more security.
> 
> JFYI (as apparently you did not get the joke):
> 
> Data encryption in and by client-side script code is *false* security – 
> “security by obscurity”: It does _not_ increase security *at all* because 
> *you serve* the used encryption algorithm to a potential attacker.
> 
> The proper solution for more security on Web sites are authentication and 
> stronger encryption on the *transport* layer (TLS with big[ger] key lengths) 
> instead.  Not only does this reduce the risk of successful man-in-the-middle 
> (MITM) attacks, it also allows one to determine if the data has been 
> tampered with.
> 
> <https://www.keylength.com/en/compare/>
> <https://www.owasp.org/>
> 

You provide the attacker with no more information than they have when
you use TLS, as the encryption algorithm is just as know. Yes, you do
need to do the encryption 'right' and not use some broken encryption but
it is possible to do it right.

Yes, TLS (if the server has a properly signed key) does provide
verification that you are not being MITM attacked.

[toc] | [prev] | [next] | [standalone]

#35316

Richard Damon wrote:

> On 6/26/18 10:47 AM, Thomas 'PointedEars' Lahn wrote:
>> JJ wrote:
>>> On Mon, 25 Jun 2018 17:21:14 +0200, Christoph M. Becker wrote:
>>>> Kidding aside: why would you manually encrypt the form submission,
>>>> instead of relying on TLS?
>>> Why ask me? Maybe he want more security.
>> 
>> JFYI (as apparently you did not get the joke):
>> 
>> Data encryption in and by client-side script code is *false* security –
>> “security by obscurity”: It does _not_ increase security *at all* because
>> *you serve* the used encryption algorithm to a potential attacker.
>> […]
> 
> You provide the attacker with no more information than they have when
> you use TLS, as the encryption algorithm is just as know.

Incorrect; read again.

To use an example that you should be able to understand: Encryption by 
client-scripting that is like locking the door of my house, and pin a post-
it note to the door that says “@Burglar: The key is below the mat.”, where 
the key actually is.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#35317

On 6/27/2018 12:45 AM, Thomas 'PointedEars' Lahn wrote:
> Richard Damon wrote:
> 
>> On 6/26/18 10:47 AM, Thomas 'PointedEars' Lahn wrote:
>>> JJ wrote:
>>>> On Mon, 25 Jun 2018 17:21:14 +0200, Christoph M. Becker wrote:
>>>>> Kidding aside: why would you manually encrypt the form submission,
>>>>> instead of relying on TLS?
>>>> Why ask me? Maybe he want more security.
>>>
>>> JFYI (as apparently you did not get the joke):
>>>
>>> Data encryption in and by client-side script code is *false* security –
>>> “security by obscurity”: It does _not_ increase security *at all* because
>>> *you serve* the used encryption algorithm to a potential attacker.
>>> […]
>>
>> You provide the attacker with no more information than they have when
>> you use TLS, as the encryption algorithm is just as know.
> 
> Incorrect; read again.
> 
> To use an example that you should be able to understand: Encryption by
> client-scripting that is like locking the door of my house, and pin a post-
> it note to the door that says “@Burglar: The key is below the mat.”, where
> the key actually is.
> 

Have the client and server setup a DH or other asymmetric key exchange 
to generate a secret key that can be used for a session of communication?

[toc] | [prev] | [next] | [standalone]

#35318

On 2018-06-27, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> Richard Damon wrote:
>> You provide the attacker with no more information than they have when
>> you use TLS, as the encryption algorithm is just as know.
>
> Incorrect; read again.
>
> To use an example that you should be able to understand: Encryption by 
> client-scripting that is like locking the door of my house, and pin a post-
> it note to the door that says “@Burglar: The key is below the mat.”, where 
> the key actually is.

You should look into this newfangled thing called "asymmetric encryption".

[toc] | [prev] | [next] | [standalone]

#35319

On 27.06.2018 at 15:29, Jon Ribbens wrote:

> On 2018-06-27, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>
>> Richard Damon wrote:
>>
>>> You provide the attacker with no more information than they have when
>>> you use TLS, as the encryption algorithm is just as know.
>>
>> Incorrect; read again.
>>
>> To use an example that you should be able to understand: Encryption by 
>> client-scripting that is like locking the door of my house, and pin a post-
>> it note to the door that says “@Burglar: The key is below the mat.”, where 
>> the key actually is.
> 
> You should look into this newfangled thing called "asymmetric encryption".

I'm afraid we're way off topic for c.l.js.  However, as I see it, you'd
have to deliver the *private* key to the client, which may not be the
best idea, anyway.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#35320

"Christoph M. Becker" <cmbecker69@arcor.de> writes:

> On 27.06.2018 at 15:29, Jon Ribbens wrote:
>
>> On 2018-06-27, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>>
>>> Richard Damon wrote:
>>>
>>>> You provide the attacker with no more information than they have when
>>>> you use TLS, as the encryption algorithm is just as know.
>>>
>>> Incorrect; read again.
>>>
>>> To use an example that you should be able to understand: Encryption by 
>>> client-scripting that is like locking the door of my house, and pin a post-
>>> it note to the door that says “@Burglar: The key is below the mat.”, where 
>>> the key actually is.
>> 
>> You should look into this newfangled thing called "asymmetric encryption".
>
> I'm afraid we're way off topic for c.l.js.  However, as I see it, you'd
> have to deliver the *private* key to the client, which may not be the
> best idea, anyway.

It's perfectly possible to do authentication over an insecure connection
by running cryptographic code in the client.  Maybe Thomas Lahn has some
narrow meaning in mind for his words, but if so he's not saying.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#35321

On Wednesday, 27 June 2018 17:00:13 UTC+2, Ben Bacarisse  wrote:
> "Christoph M. Becker" <cmbecker69@arcor.de> writes:
> > On 27.06.2018 at 15:29, Jon Ribbens wrote:
> >> On 2018-06-27, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
> >>> Richard Damon wrote:
> >>>
> >>>> You provide the attacker with no more information than they have when
> >>>> you use TLS, as the encryption algorithm is just as know.
> >>>
> >>> Incorrect; read again.
> >>>
> >>> To use an example that you should be able to understand: Encryption by 
> >>> client-scripting that is like locking the door of my house, and pin a post-
> >>> it note to the door that says “@Burglar: The key is below the mat.”, where 
> >>> the key actually is.
> >> 
> >> You should look into this newfangled thing called "asymmetric encryption".
> >
> > I'm afraid we're way off topic for c.l.js.  However, as I see it, you'd
> > have to deliver the *private* key to the client, which may not be the
> > best idea, anyway.
> 
> It's perfectly possible to do authentication over an insecure connection
> by running cryptographic code in the client.  Maybe Thomas Lahn has some
> narrow meaning in mind for his words, but if so he's not saying.

But the code on the client can be read by anyone, you just won't have any mean
to secure it: and it's not so much the algo per se, it's the keys and similar.

Can't you guys just do things by the book, start by learning from the expert,
instead of bullshitting your way around this world?  (I am criticising the
method.)

HTH,

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#35323

Julio Di Egidio <julio@diegidio.name> writes:

> On Wednesday, 27 June 2018 17:00:13 UTC+2, Ben Bacarisse  wrote:
>> "Christoph M. Becker" <cmbecker69@arcor.de> writes:
>> > On 27.06.2018 at 15:29, Jon Ribbens wrote:
>> >> On 2018-06-27, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> >>> Richard Damon wrote:
>> >>>
>> >>>> You provide the attacker with no more information than they have when
>> >>>> you use TLS, as the encryption algorithm is just as know.
>> >>>
>> >>> Incorrect; read again.
>> >>>
>> >>> To use an example that you should be able to understand: Encryption by 
>> >>> client-scripting that is like locking the door of my house, and pin a post-
>> >>> it note to the door that says “@Burglar: The key is below the mat.”, where 
>> >>> the key actually is.
>> >> 
>> >> You should look into this newfangled thing called "asymmetric encryption".
>> >
>> > I'm afraid we're way off topic for c.l.js.  However, as I see it, you'd
>> > have to deliver the *private* key to the client, which may not be the
>> > best idea, anyway.
>> 
>> It's perfectly possible to do authentication over an insecure connection
>> by running cryptographic code in the client.  Maybe Thomas Lahn has some
>> narrow meaning in mind for his words, but if so he's not saying.
>
> But the code on the client can be read by anyone, you just won't have any mean
> to secure it: and it's not so much the algo per se, it's the keys and
> similar.

The visibility of the algorithms and the other data does not prevent
client authentication.  Authentication over clear-text channels has been
done for decades.  How do you think TLS "bootstraps" the security in the
first place?

Anyway, this should not detract from the good advice to use HTTPS.  The
main problem of not using a secure connection that the user is
vulnerable to simple social engineering where an interloper replaces the
page with one that looks like the login page but POSTs the form, in the
clear, to wherever they like.

It does not matter that it's technically possible to make the
authentication safe because most users have no way of knowing that it's
safe.  You or I can have a look at the page source and see what's going
to happen when I click 'log in', but most people have to rely on the
feedback from the browser.  Users need to get used to the idea that all
log-ins (indeed, if possible, all web traffic) should be over HTTPS.

> Can't you guys just do things by the book, start by learning from the expert,
> instead of bullshitting your way around this world?

As it happens, I am an expert in this area (all-be-it a very minor one).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#35324

On Thursday, 28 June 2018 02:53:44 UTC+2, Ben Bacarisse  wrote:
> Julio Di Egidio <julio@diegidio.name> writes:
<snip>
> Users need to get used to the idea that all
> log-ins (indeed, if possible, all web traffic) should be over HTTPS.

No shit.

> > Can't you guys just do things by the book, start by learning from the expert,
> > instead of bullshitting your way around this world?
> 
> As it happens, I am an expert in this area (all-be-it a very minor one).

You have changed the subject, which was about encryption, not authentication.
And you cannot be an expert: security is an engineering, too...

That said, indeed you are wrong.  Read this for example (and follow the links,
and then read more):  <https://stackoverflow.com/a/7350936>

  << Basically, secure javascript does not exist. >>

Now, there is a web crypto api that could change some things: but, even
assuming that it's sound, it ain't generally supported yet.

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#35325

On 2018-06-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Julio Di Egidio <julio@diegidio.name> writes:
>> But the code on the client can be read by anyone, you just won't
>> have any mean to secure it: and it's not so much the algo per se,
>> it's the keys and similar.
>
> The visibility of the algorithms and the other data does not prevent
> client authentication.  Authentication over clear-text channels has been
> done for decades.  How do you think TLS "bootstraps" the security in the
> first place?

I wouldn't worry too much about Plonk Julio, he's highly clue-resistant.

> Anyway, this should not detract from the good advice to use HTTPS.

Absolutely correct. Using standard HTTPS will almost *always* be the
right thing to do (and conversely, rolling your own encryption will
almost *never* be sensible). I was just correcting the resident kook's
apparent assumption that anything implemented in ECMAScript must
necessarily be symmetric encryption.

[toc] | [prev] | [next] | [standalone]

#35326

On Thursday, 28 June 2018 11:17:50 UTC+2, Jon Ribbens  wrote:
> On 2018-06-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> > Julio Di Egidio <julio@diegidio.name> writes:
> >> But the code on the client can be read by anyone, you just won't
> >> have any mean to secure it: and it's not so much the algo per se,
> >> it's the keys and similar.
> >
> > The visibility of the algorithms and the other data does not prevent
> > client authentication.  Authentication over clear-text channels has been
> > done for decades.  How do you think TLS "bootstraps" the security in the
> > first place?
> 
> I wouldn't worry too much about Plonk Julio, he's highly clue-resistant.

A bit of ad hominem and total disregard for my reply, as proper from a vile
moron.  Then some more bullshit:

> > Anyway, this should not detract from the good advice to use HTTPS.
> 
> Absolutely correct. Using standard HTTPS will almost *always* be the
> right thing to do (and conversely, rolling your own encryption will
> almost *never* be sensible).

No shit.  Actually drop those almost, otherwise it's still wrong.

> I was just correcting the resident kook's
> apparent assumption that anything implemented in ECMAScript must
> necessarily be symmetric encryption.

The kook is you who think symmetric vs asymmetric makes any
difference re the problem of doing this stuff client-side.
The reason why TLS/HTTPS work in the browser is because the
browser does it, not the scripting...

EOD.

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#35322

On 6/27/2018 6:47 AM, Christoph M. Becker wrote:
> On 27.06.2018 at 15:29, Jon Ribbens wrote:
> 
>> On 2018-06-27, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>>
>>> Richard Damon wrote:
>>>
>>>> You provide the attacker with no more information than they have when
>>>> you use TLS, as the encryption algorithm is just as know.
>>>
>>> Incorrect; read again.
>>>
>>> To use an example that you should be able to understand: Encryption by
>>> client-scripting that is like locking the door of my house, and pin a post-
>>> it note to the door that says “@Burglar: The key is below the mat.”, where
>>> the key actually is.
>>
>> You should look into this newfangled thing called "asymmetric encryption".
> 
> I'm afraid we're way off topic for c.l.js.  However, as I see it, you'd
> have to deliver the *private* key to the client, which may not be the
> best idea, anyway.
> 

No. In asymmetric key exchange the secret key is NEVER sent across the 
wire. Instead the server and client generate the same secret key without 
showing it to anybody. Take a deep look at something along the lines of:

https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

See? There is no need to send the secret generated key across the wire.

[toc] | [prev] | [next] | [standalone]

#35327

On 27.06.2018 at 23:04, Chris M. Thomasson wrote:

> On 6/27/2018 6:47 AM, Christoph M. Becker wrote:
>
>> On 27.06.2018 at 15:29, Jon Ribbens wrote:
>>
>>> You should look into this newfangled thing called "asymmetric
>>> encryption".
>>
>> I'm afraid we're way off topic for c.l.js.  However, as I see it, you'd
>> have to deliver the *private* key to the client, which may not be the
>> best idea, anyway.
> 
> No. In asymmetric key exchange the secret key is NEVER sent across the
> wire. Instead the server and client generate the same secret key without
> showing it to anybody. Take a deep look at something along the lines of:
> 
> https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
> 
> See? There is no need to send the secret generated key across the wire.

Thanks.  I stand corrected.  Still, I can't see how this is actually
related to the OP.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#35328

On 6/28/2018 4:54 AM, Christoph M. Becker wrote:
> On 27.06.2018 at 23:04, Chris M. Thomasson wrote:
> 
>> On 6/27/2018 6:47 AM, Christoph M. Becker wrote:
>>
>>> On 27.06.2018 at 15:29, Jon Ribbens wrote:
>>>
>>>> You should look into this newfangled thing called "asymmetric
>>>> encryption".
>>>
>>> I'm afraid we're way off topic for c.l.js.  However, as I see it, you'd
>>> have to deliver the *private* key to the client, which may not be the
>>> best idea, anyway.
>>
>> No. In asymmetric key exchange the secret key is NEVER sent across the
>> wire. Instead the server and client generate the same secret key without
>> showing it to anybody. Take a deep look at something along the lines of:
>>
>> https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
>>
>> See? There is no need to send the secret generated key across the wire.
> 
> Thanks.  I stand corrected.  Still, I can't see how this is actually
> related to the OP.
> 

Sorry about that. I just pointed out a way where a server and client can 
create a secret key without exposing it to Eve.

Now, the primes that the client and server use should be hard to bust 
wrt the public data sent across the wire for any asymmetric key 
exchange. This can be a problem.

[toc] | [prev] | [next] | [standalone]

#35341

On 6/25/18 4:48 AM, bit-naughty@hotmail.com wrote:
>Hi,
>I have a Login box on my website, with a name and password field. When it's submitted, I want it to happen without a refresh (ie. the authentication), and I also want the form data to be ENCRYPTED between client and server (because of the password).
>
>Number 1) How do I submit? How do I get the form data into a format that "request.send" in the AJAX call will take? Do I have to extract the form data myself with "document.forms" and muck about with it somehow?
>and 2) How do I encrypt? Is putting a "https" in the "request.open("POST", https<blah blah>);" enough, or do I have to do something else?
>
>Thanks muchly for your help.


Not sure why the other responses went so off topic and into arguments...

It's generally assumed that if you are looking to perform secure
 communications you would use HTTPS. Standards groups pick the best
 algorithms for the job, browsers use and test commonly used ssl/tls
 libraries so you can trust the implementation of secure communications as
 much as one can.

As for the for the commonly repeated quote "you can't do encryption in
 Javascript" the issue is about authenticating the source of a message. When
 using HTTPS the server to browser communication path is secured well before
 any JS code is executed. If a MITM attack were to occur the browser would
 inform the user that communications were not secure. When you do not use
 HTTPS each component (html, css, js) and all data is loaded independently,
 each possible of being tampered with in transit. Once the JS  is loaded
 you've already been compromised.

So what reasons might you still want to encrypt form data in JS? If you want
 the destination of that data to not know what it is. Often sites that store
 data that is only used client side will encrypt it before sending it to the
 server for storage. This way if the server is compromised your data won't
 be. Only when the data is sent client side, and then is decrypted with the
 users password is it visible. Password mangers and bookmarking apps are two
 examples of cases where the user data is encrypted in JS before being sent
 to the server for storage.

If you choose to encrypt in JS for this reason...you must still use HTTPS. 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web