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 1 of 2  [1] 2  Next page →

#17054 — HTTPS data in a form

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.

[toc] | [next] | [standalone]

#17055

On 09/16/2016 06: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?

You need to use javascrip, which is off topic in the user group.


> I'm not really clear about HTTPS - if whatever it is is encrypted, then how is it decrypted later?

Encryption and decryption is done in the transport layer, your php will
not need any changes regards how it receives the post/get data.

You can read a short description in the following forum thread:
http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work


> 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?

Most mail servers will have the mail in plain text stored on the system
storage, regardless if the partition where the mail is located is
encrypted or not (encrypted partitions will only be unreadable when the
data is in rest, not mounted). If you use PGP, then your mail may be
encrypted and will be only decrypted when you read it in your mail client.


-- 

 //Aho

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

#17056

bit-naughty@hotmail.com schrieb am 2016-09-16 um 06:45:

> 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

There is no way for sending a password encrypted without using
JavaScript in the client side - and this is off-topic here, because this
group is about PHP and not JavaScript.

> 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?

What does this have to do with PHP?

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

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

#17057

Arno Welzel wrote:

> bit-naughty@hotmail.com schrieb am 2016-09-16 um 06:45:
>> 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
> 
> There is no way for sending a password encrypted without using
> JavaScript in the client side -

This is, of course, wrong.  If a form is sent to a resource that is only 
available via HTTPs, then all the form data is sent encrypted, including 
passwords.  Client-side JavaScript is not required for that.

>> 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?
> 
> What does this have to do with PHP?

Nothing, indeed.  PHP would only generate the HTML form.

-- 
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]

#17058

On 9/17/2016 3:17 PM, the well-known troll Thomas 'Pointed Head' Lahn wrote:
> Arno Welzel wrote:
> 
>> bit-naughty@hotmail.com schrieb am 2016-09-16 um 06:45:
>>> 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
>>
>> There is no way for sending a password encrypted without using
>> JavaScript in the client side -
> 
> This is, of course, wrong.  If a form is sent to a resource that is only 
> available via HTTPs, then all the form data is sent encrypted, including 
> passwords.  Client-side JavaScript is not required for that.
>

Once again you make a fool of yourself by replying without understanding
the question.

Arno is 100% correct in his statement - as related to the OPs question.
-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#17084

On Sat, 17 Sep 2016 17:02:25 -0400, Jerry Stuckle wrote:
> On 9/17/2016 3:17 PM, the well-known troll Thomas 'Pointed Head' Lahn wrote:
>> Arno Welzel wrote:
>> 
>>> bit-naughty@hotmail.com schrieb am 2016-09-16 um 06:45:
>>>> 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
>>>
>>> There is no way for sending a password encrypted without using
>>> JavaScript in the client side -
>> 
>> This is, of course, wrong.  If a form is sent to a resource that is only 
>> available via HTTPs, then all the form data is sent encrypted, including 
>> passwords.  Client-side JavaScript is not required for that.
>>
>
> Once again you make a fool of yourself by replying without understanding
> the question.
>
> Arno is 100% correct in his statement - as related to the OPs question.

In a moment of surreality, PointyHead has actually grasped the essential
PROBLEM and addressed that. Even though the OP was so confused as to be
asking the wrong question, which Arno answered most precisely as asked
but not as intended. OP is too confused as to what https is and the
nature of its role in forms and webpages as to be able to ask the right
thing.

-- 
18. I will not have a son. Although his laughably under-planned attempt
   to usurp power would easily fail, it would provide a fatal 
   distraction at a crucial point in time.
        --Peter Anspach's list of things to do as an Evil Overlord

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

#17092

On 9/21/2016 12:33 PM, Peter H. Coffin wrote:
> On Sat, 17 Sep 2016 17:02:25 -0400, Jerry Stuckle wrote:
>> On 9/17/2016 3:17 PM, the well-known troll Thomas 'Pointed Head' Lahn wrote:
>>> Arno Welzel wrote:
>>>
>>>> bit-naughty@hotmail.com schrieb am 2016-09-16 um 06:45:
>>>>> 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
>>>>
>>>> There is no way for sending a password encrypted without using
>>>> JavaScript in the client side -
>>>
>>> This is, of course, wrong.  If a form is sent to a resource that is only 
>>> available via HTTPs, then all the form data is sent encrypted, including 
>>> passwords.  Client-side JavaScript is not required for that.
>>>
>>
>> Once again you make a fool of yourself by replying without understanding
>> the question.
>>
>> Arno is 100% correct in his statement - as related to the OPs question.
> 
> In a moment of surreality, PointyHead has actually grasped the essential
> PROBLEM and addressed that. Even though the OP was so confused as to be
> asking the wrong question, which Arno answered most precisely as asked
> but not as intended. OP is too confused as to what https is and the
> nature of its role in forms and webpages as to be able to ask the right
> thing.
> 

No, he is not.  He claimed Arno's comment was wrong, and it is not.  And
maybe he *tried* to answer the question the OP *should have asked* - but
he failed in that respect, also.

This and other posts he's made in this thread shows he has no idea how
to properly secure a site.  He only knows a few words.

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

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

#17102

Peter H. Coffin wrote:

> In a moment of surreality, PointyHead […]

Score adjusted

-- 
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]

#17067

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

> Arno Welzel wrote:
> 
>> bit-naughty@hotmail.com schrieb am 2016-09-16 um 06:45:
>>> 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
>>
>> There is no way for sending a password encrypted without using
>> JavaScript in the client side -
> 
> This is, of course, wrong.  If a form is sent to a resource that is only 
> available via HTTPs, then all the form data is sent encrypted, including 
> passwords.  Client-side JavaScript is not required for that.

It seems you didn't understand or read the question. The OP asked how to
encrypt the password only in a form and not how to transmit everything
encrypted.

Just read what you quoted:

"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 [...]"



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

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

#17069

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).

Where passwords are involved, the form data – password *and* username –, 
SHOULD¹ be sent via an encrypted *connection* (HTTPS or, IOW, HTTP over a 
TLS-1.2-encrypted TCP connection; minimum cipher strength should be 256 
bits).  The password SHOULD NOT be stored on the server at all (and maybe 
not even the username verbatim), but only its checksum (“hash”) *that is 
computed by the server and SHOULD never leave the server*.  (Computing a 
hash is _not_ encryption.)

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]).

See also:

<https://www.owasp.org/index.php/Authentication_Cheat_Sheet> pp.
<https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet> pp.
<http://php.net/password_hash>

However, it is equally possible that the OP has a basic misconception about 
“password encryption”.  Hiding a password, e.g. by masking characters (e.g. 
using the HTML type="password" attribute), is _not_ “password encryption” 
either.

_________
¹  see RFC 2119 for the definitions of all-uppercase requirement levels
-- 
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]

#17071

On 19.09.2016 at 23:28, Thomas 'PointedEars' Lahn wrote:

> 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).

If the software running on the server would be OSS, the
encryption/hashing algorithm in use wouldn't be much harder to find, though.

-- 
Christoph M. Becker

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

#17072

Christoph M. Becker wrote:

> On 19.09.2016 at 23:28, Thomas 'PointedEars' Lahn wrote:
>> 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).
> 
> If the software running on the server would be OSS, the encryption/hashing
> algorithm in use wouldn't be much harder to find, though.

How did you get that idea?
 
-- 
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]

#17080

On 19.09.2016 at 23:57, Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
> 
>> If the software running on the server would be OSS, the encryption/hashing
>> algorithm in use wouldn't be much harder to find, though.
> 
> How did you get that idea?

I have to admit that my statement is most likely too general, but at
least some OSS running on a server can be probed to see which software
it is.  Bots are doing this, for instance, to check for WordPress (at
least a few years back I've noticed that in my server logs).

-- 
Christoph M. Becker

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

#17073

On 9/19/2016 5:28 PM, Thomas the well-know troll 'Pointed Head' Lahn wrote:
> 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).
>

No, the correct answer is not "that it is foolish".It is never proper to
tell someone asking a serious question that it is a foolish question.

But it is the type of answer I would expect from a pedantic troll like you.

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

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

#17075

On Mon, 19 Sep 2016 23:28:27 Thomas 'PointedEars' Lahn wrote:
> 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 [...]

Yes.

> 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.

On the other hand this takes quite an effort which could be easily
avoided by using HTTPS.

> However, it is equally possible that the OP has a basic misconception about 
> “password encryption”.

Quite likely, yes.

Bye,
  Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - mit der imaginären Extase bizarrer Gassen.
(Sloganizer)

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

#17077

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.
 
-- 
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]

#17079

On 09/20/2016 03:40 PM, 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.  It is a big problem in any case.

Not at all, just see how PGP works, you send you public key to people,
they encrypt the e-mail and send it to you, you can decrypt it with your
private key. Even if they have your public key, they will not be able to
generate your private key not use the public key to decrypt any messages
encrypted with it.

Most encryption is done with "exposed" algorithms, for example openssl
source code is free for grabs and most algorithms are anyway publicly
documented, so you will be able to build your own encryption/decryption
functionality.
No difference if you do it in javascript, c++, c# or your own created
language, seeing the code will not make people just able to decrypt
things, unless it's rot_13.


-- 

 //Aho

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

#17081

On 9/20/2016 12:39 PM, J.O. Aho wrote:
> On 09/20/2016 03:40 PM, 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.  It is a big problem in any case.
> 
> Not at all, just see how PGP works, you send you public key to people,
> they encrypt the e-mail and send it to you, you can decrypt it with your
> private key. Even if they have your public key, they will not be able to
> generate your private key not use the public key to decrypt any messages
> encrypted with it.
> 
> Most encryption is done with "exposed" algorithms, for example openssl
> source code is free for grabs and most algorithms are anyway publicly
> documented, so you will be able to build your own encryption/decryption
> functionality.
> No difference if you do it in javascript, c++, c# or your own created
> language, seeing the code will not make people just able to decrypt
> things, unless it's rot_13.
> 
> 

Do you know of any widely used computer algorithms which is NOT public?
Or any which are public which don't have some sample code available?

I know there are some manufacturer-specific algorithms, and some built
into ICs for specific situations, but nothing widely used in the
computer industry which aren't public.

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

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

#17082

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.

> It is a big problem in any case.

The problem in this case is somewhere else (as you and others did point out
already)

Bye,
  Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - Wer trägt heute schon Eulen nach Athen?
(Sloganizer)

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

#17099

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.

In general, telling an attacker anything about the used mechanisms makes it 
*easier for them to run an attack*.  So DO NOT do that.  *And do not stop 
there.*
 
>> It is a big problem in any case.
> 
> The problem in this case is somewhere else (as you and others did point
> out already)

There are several problems in this case, including this one.

-- 
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]

Page 1 of 2  [1] 2  Next page →

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

csiph-web