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

Groups > comp.lang.php > #17054 > unrolled thread

HTTPS data in a form

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

Contents

  HTTPS data in a form bit-naughty@hotmail.com - 2016-09-15 21:45 -0700
    Re: HTTPS data in a form "J.O. Aho" <user@example.net> - 2016-09-16 07:52 +0200
    Re: HTTPS data in a form Arno Welzel <usenet@arnowelzel.de> - 2016-09-17 15:57 +0200
      Re: HTTPS data in a form Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-17 21:17 +0200
        Re: HTTPS data in a form Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-17 17:02 -0400
          Re: HTTPS data in a form "Peter H. Coffin" <hellsop@ninehells.com> - 2016-09-21 11:33 -0500
            Re: HTTPS data in a form Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-23 08:47 -0400
            Re: HTTPS data in a form Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-24 22:11 +0200
        Re: HTTPS data in a form Arno Welzel <usenet@arnowelzel.de> - 2016-09-19 21:36 +0200
          Re: HTTPS data in a form Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-19 23:28 +0200
            Re: HTTPS data in a form "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-09-19 23:44 +0200
              Re: HTTPS data in a form Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-19 23:57 +0200
                Re: HTTPS data in a form "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-09-20 19:00 +0200
            Re: HTTPS data in a form Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-19 21:00 -0400
            Re: HTTPS data in a form Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-09-20 05:59 +0000
              Re: HTTPS data in a form Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-20 15:40 +0200
                Re: HTTPS data in a form "J.O. Aho" <user@example.net> - 2016-09-20 18:39 +0200
                  Re: HTTPS data in a form Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-20 14:36 -0400
                Re: HTTPS data in a form Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2016-09-20 21:04 +0000
                  Re: HTTPS data in a form Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-24 21:58 +0200
                    Re: HTTPS data in a form Arno Welzel <usenet@arnowelzel.de> - 2016-09-26 19:43 +0200
                Re: HTTPS data in a form Arno Welzel <usenet@arnowelzel.de> - 2016-09-23 09:14 +0200
                  Re: HTTPS data in a form Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-24 22:00 +0200
                    Re: HTTPS data in a form Arno Welzel <usenet@arnowelzel.de> - 2016-09-26 19:44 +0200
            Re: HTTPS data in a form Arno Welzel <usenet@arnowelzel.de> - 2016-09-20 08:20 +0200
              Re: HTTPS data in a form Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-20 15:41 +0200
                Re: HTTPS data in a form Arno Welzel <usenet@arnowelzel.de> - 2016-09-23 09:02 +0200
                  Re: HTTPS data in a form Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-24 22:06 +0200
                    Re: HTTPS data in a form Arno Welzel <usenet@arnowelzel.de> - 2016-09-26 19:49 +0200
    Re: HTTPS data in a form Richard Damon <Richard@Damon-Family.org> - 2016-09-18 14:22 -0400
      Re: HTTPS data in a form Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-09-19 23:36 +0200
        Re: HTTPS data in a form Jerry Stuckle <jstucklex@attglobal.net> - 2016-09-19 21:03 -0400
    Re: HTTPS data in a form "Peter H. Coffin" <hellsop@ninehells.com> - 2016-09-21 11:29 -0500

Page 2 of 2 — ← Prev page 1 [2]

#17108

Thomas 'PointedEars' Lahn schrieb am 2016-09-24 um 21:58:

> Stefan Froehlich wrote:
> 
>> On Tue, 20 Sep 2016 15:40:04 Thomas 'PointedEars' Lahn wrote:
>>> Stefan Froehlich wrote:
>>>> On Mon, 19 Sep 2016 23:28:27 Thomas 'PointedEars' Lahn wrote:
>>>>> because the used encryption/hashing algorithm would have to reside
>>>>> on the client in the form of a client-side script *for every
>>>>> attacker plain to see* (obfuscation is _not_ protection).
>>>> If you use asymmetric encryption this would not be the big problem.
>>> Exposing the used encryption algorithm to a potential attacker is a
>>> security leak.
>>
>> No. Security by obscurity.
> 
> Utter nonsense.  It would only be “security by obscurity” if this was the 
> only consideration, e.g. the hashing algorithm were weak and one would 
> consider not telling about that to be the solution to the problem.
[...]

Do you know the Kerckhoffs's principle? It seems cryptography is not one
of your strengths.



-- 
Arno Welzel
https://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#17091

Thomas 'PointedEars' Lahn schrieb am 2016-09-20 um 15:40:

> Stefan Froehlich wrote:
> 
>> On Mon, 19 Sep 2016 23:28:27 Thomas 'PointedEars' Lahn wrote:
>>> because the used encryption/hashing algorithm would have to reside
>>> on the client in the form of a client-side script *for every
>>> attacker plain to see* (obfuscation is _not_ protection).
>>
>> If you use asymmetric encryption this would not be the big problem.
> 
> Exposing the used encryption algorithm to a potential attacker is a security 
> leak.  It is a big problem in any case.

Well - according to
<https://www.ssllabs.com/ssltest/analyze.html?d=arnowelzel.de&s=85.214.147.94>
my server exposes which encryption algorithms are used for establishing
HTTPS connections.

Do I have a security problem?

And when using PGP to send an e-mail to someone it is very clear which
algorithm was used to encrypt the e-mail - because otherwise the
receiver doesn't know how to decrypt the content.

Also a security problem?


-- 
Arno Welzel
https://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#17100

Arno Welzel wrote:

> Well - according to
> 
<https://www.ssllabs.com/ssltest/analyze.html?d=arnowelzel.de&s=85.214.147.94>
> my server exposes which encryption algorithms are used for establishing
> HTTPS connections.
> 
> Do I have a security problem?
> 
> And when using PGP to send an e-mail to someone it is very clear which
> algorithm was used to encrypt the e-mail - because otherwise the
> receiver doesn't know how to decrypt the content.
> 
> Also a security problem?

Straw man.  The subject was *authentication*.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#17109

Thomas 'PointedEars' Lahn schrieb am 2016-09-24 um 22:00:

> Arno Welzel wrote:
> 
>> Well - according to
>>
> <https://www.ssllabs.com/ssltest/analyze.html?d=arnowelzel.de&s=85.214.147.94>
>> my server exposes which encryption algorithms are used for establishing
>> HTTPS connections.
>>
>> Do I have a security problem?
>>
>> And when using PGP to send an e-mail to someone it is very clear which
>> algorithm was used to encrypt the e-mail - because otherwise the
>> receiver doesn't know how to decrypt the content.
>>
>> Also a security problem?
> 
> Straw man.  The subject was *authentication*.

The subject was and is *encryption* - how to encrypt data in a login
form, so an attacker will not get the password. And there is no
differnce between using HTTPS which *known* cipher suites or sending a
password hash which was calculated with a *known* hashing algorithm.


-- 
Arno Welzel
https://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#17076

Thomas 'PointedEars' Lahn schrieb am 2016-09-19 um 23:28:

> Arno Welzel wrote:
> 
>> "If I have a form where there's a username and a password, and I'd like
>> only the *password* to be encrypted before being sent [...]"
> 
> OK, then the correct answer is that it is foolish to want that because the 
> used encryption/hashing algorithm would have to reside on the client in the 
> form of a client-side script *for every attacker plain to see* (obfuscation 
> is _not_ protection).

So what? One of the major principles in encryption is that the secret
has to be protected, not the algorithm.

If the attacker gains access to the client itself, even HTTPS does not
help - because then the attacker can easily read the password in plain
text before it is sent over the encrypted connection. The client itself
has to be secure and protected against attackers - otherwise it makes no
sense to think about protecting the transport.

> Checking a username/password then means comparing the hash of the provided 
> username/password against the stored hash(es) *server-side*.  The hash 
> should be computed using a strong hashing algorithm (so _not_ plain MD5 or 
> SHA1, but rather the likes of bcrypt [default for password_hash() since PHP 
> 5.5.0] and scrypt with a strong salt [using the default for password_hash() 
> is recommended as of PHP 7.0.0 as the “salt” option was deprecated]).

Well - the source code of bcrypt for JavaScript is available here:

<https://github.com/dcodeIO/bcrypt.js/blob/master/README.md>

Didn't you just say that it is a bad idea to have the source code for an
encryption method available? ;-)



-- 
Arno Welzel
https://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#17078

Arno Welzel wrote:

> Thomas 'PointedEars' Lahn schrieb am 2016-09-19 um 23:28:
> 
> […] One of the major principles in encryption is that the secret
> has to be protected, not the algorithm.

Utter nonsense.
 
> If the attacker gains access to the client itself, even HTTPS does not
> help […]

Yes.  Non sequitur.
 
>> Checking a username/password then means comparing the hash of the
>> provided username/password against the stored hash(es) *server-side*. 
>> The hash should be computed using a strong hashing algorithm (so _not_
>> plain MD5 or SHA1, but rather the likes of bcrypt [default for
>> password_hash() since PHP 5.5.0] and scrypt with a strong salt [using the
>> default for password_hash() is recommended as of PHP 7.0.0 as the “salt”
>> option was deprecated]).
> 
> Well - the source code of bcrypt for JavaScript is available here:
> 
> <https://github.com/dcodeIO/bcrypt.js/blob/master/README.md>
> 
> Didn't you just say that it is a bad idea to have the source code for an
> encryption method available? ;-)

I said that it is a bad idea to expose the used encryption algorithm *on the 
client*.  Because then the attacker knows the algorithm already and it is 
easier for them to run an attack.

Also, you are having the common misconception that “JavaScript” means 
client-side and unprivileged code.  (Note that the first variant presented 
there is the one for Node.js.)

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#17090

Thomas 'PointedEars' Lahn schrieb am 2016-09-20 um 15:41:

> Arno Welzel wrote:
> 
>> Thomas 'PointedEars' Lahn schrieb am 2016-09-19 um 23:28:
>>
>> […] One of the major principles in encryption is that the secret
>> has to be protected, not the algorithm.
> 
> Utter nonsense.

No - best practice. Security by obscurity does not work.

[...]
>> Well - the source code of bcrypt for JavaScript is available here:
>>
>> <https://github.com/dcodeIO/bcrypt.js/blob/master/README.md>
>>
>> Didn't you just say that it is a bad idea to have the source code for an
>> encryption method available? ;-)
> 
> I said that it is a bad idea to expose the used encryption algorithm *on the 
> client*.  Because then the attacker knows the algorithm already and it is 
> easier for them to run an attack.

Which known attacks exist for bcrypt?

> Also, you are having the common misconception that “JavaScript” means 
> client-side and unprivileged code.  (Note that the first variant presented 
> there is the one for Node.js.)

In the context of this thread JavaScript means client side scripting.


-- 
Arno Welzel
https://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#17101

Arno Welzel wrote:

> Thomas 'PointedEars' Lahn schrieb am 2016-09-20 um 15:41:
>> Arno Welzel wrote:
>>> Thomas 'PointedEars' Lahn schrieb am 2016-09-19 um 23:28:
>>> […] One of the major principles in encryption is that the secret
>>> has to be protected, not the algorithm.
>> Utter nonsense.
> 
> No - best practice. Security by obscurity does not work.

*That* is _not_ “security by obscurity”.
 
> [...]
>>> Well - the source code of bcrypt for JavaScript is available here:
>>>
>>> <https://github.com/dcodeIO/bcrypt.js/blob/master/README.md>
>>>
>>> Didn't you just say that it is a bad idea to have the source code for an
>>> encryption method available? ;-)
>> I said that it is a bad idea to expose the used encryption algorithm *on
>> the client*.  Because then the attacker knows the algorithm already and
>> it is easier for them to run an attack.
> 
> Which known attacks exist for bcrypt?

Irrelevant.  But assuming that it is safe to expose an algorithm to an 
attacker because there are no *known* attacks is a far more incompetent 
approach than “security by obscurity”.
 
>> Also, you are having the common misconception that “JavaScript” means
>> client-side and unprivileged code.  (Note that the first variant
>> presented there is the one for Node.js.)
> 
> In the context of this thread JavaScript means client side scripting.

Then why are you referring, as a counter-argument, to an implementation that 
is not primarily intended for client-side scripting?

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#17110

Thomas 'PointedEars' Lahn schrieb am 2016-09-24 um 22:06:

> Arno Welzel wrote:
[...]
>> In the context of this thread JavaScript means client side scripting.
> 
> Then why are you referring, as a counter-argument, to an implementation that 
> is not primarily intended for client-side scripting?

Because it runs very well in browsers too and i referred to it to show
an *EXAMPLE* of an algorithm which can be used on the client side.

So what? You already explained that you don't recommend to implement a
new, unknown encryption method but you either don't know or don't
believe Kerckhoff.



-- 
Arno Welzel
https://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

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

#17059

On 9/16/16 12:45 AM, bit-naughty@hotmail.com wrote:
> If I have a form where there's a username and a password, and I'd like only the *password* to be encrypted before being sent to the server, NOT the username, how do I code the form HTML?
> I'm not really clear about HTTPS - if whatever it is is encrypted, then how is it decrypted later? Like, if my mail is being viewed over a HTTPS connection, then there must be a way to decrypt it, right, otherwise I wouldn't be able to see it....? What is it that's stored on the server side exactly?
>
>
> Thanks.
>

Perhaps you don't understand how HTTPS works. With HTTPS, on setting up 
the connection, both sides send an encryption key to the other side 
(that only they know the decryption key) so the whole link is 
transferred as encrypted data. It isn't just some 'data' in the contents 
being transferred being encrypted, but the whole packet.

To the application layer, this is all transparent, as the data the 
application gets from the socket has been decrypted.

If you don't want to use HTTPS, but normal HTTP, then as others have 
said, you would need some client side code, likely javascript, to 
encrypt the field before being sent. One warning, unless you are REAL 
careful in how you do this, it may just add a false sense of security, 
as you are still totally susceptible to man-in-the-middle attacks and 
unless you are really careful to salt the login page, and make sure the 
salt matches, someone eves dropping can still just return the same 
encrypted password to get access.

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

#17070

Richard Damon wrote:

> If you don't want to use HTTPS, but normal HTTP, then as others have
> said, you would need some client side code, likely javascript, to
> encrypt the field before being sent. One warning, unless you are REAL
> careful in how you do this, it may just add a false sense of security,

They are *definitely* “[adding] a false sense of security” if they do this.

> as you are still totally susceptible to man-in-the-middle attacks 

If they do this, MITM attacks are the least of their problems.  *Everybody* 
can brute-force their way in because they are literally *handed the keys*.

> and unless you are really careful to salt the login page, and make sure
                                       ^^^^^^^^^^^^^^^^^^^
> the salt matches, someone eves dropping can still just return the same
> encrypted password to get access.

ROTFL.  You have no clue what you are talking about.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#17074

On 9/19/2016 5:36 PM, Thomas the famous troll 'Pointed Head' Lahn wrote:
> Richard Damon wrote:
> 
>> If you don't want to use HTTPS, but normal HTTP, then as others have
>> said, you would need some client side code, likely javascript, to
>> encrypt the field before being sent. One warning, unless you are REAL
>> careful in how you do this, it may just add a false sense of security,
> 
> They are *definitely* “[adding] a false sense of security” if they do this.
> 
>> as you are still totally susceptible to man-in-the-middle attacks 
> 
> If they do this, MITM attacks are the least of their problems.  *Everybody* 
> can brute-force their way in because they are literally *handed the keys*.
> 
>> and unless you are really careful to salt the login page, and make sure
>                                        ^^^^^^^^^^^^^^^^^^^
>> the salt matches, someone eves dropping can still just return the same
>> encrypted password to get access.
> 
> ROTFL.  You have no clue what you are talking about.
> 

Nope, he is perfectly correct.  If each time a login page is sent a new
salt is created, then MTTM attacks fail.

It is not Richard who has no clue.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#17083

On Thu, 15 Sep 2016 21:45:45 -0700 (PDT), bit-naughty@hotmail.com wrote:

> If I have a form where there's a username and a password, and I'd like
> only the *password* to be encrypted before being sent to the server,
> NOT the username, how do I code the form HTML?

html and https have essentially nothing to do with each other. html is
the poem and https is whether it's being read over radio broadcast,
television, or cell phone.

> I'm not really clear about HTTPS - if whatever it is is encrypted,
> then how is it decrypted later? Like, if my mail is being viewed over
> a HTTPS connection, then there must be a way to decrypt it, right,
> otherwise I wouldn't be able to see it....? What is it that's stored
> on the server side exactly?

The webserver takes care of all the decryption and encryption necessary.
By the time you get to see it, you're dealing with it only in
unencrypted form. HTTPS only protects data from being spied on IN
TRANSIT between the browser on a user's computer and the webserver.

-- 
28. My pet monster will be kept in a secure cage from which it cannot 
   escape and into which I could not accidentally stumble.
        --Peter Anspach's list of things to do as an Evil Overlord

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web