Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Stanislav Malyshev]

Hi!

On 2/19/22 6:03 PM, st...@tobtu.com wrote:

crypt() should be deprecate because it can be used to create bad password 
hashes:


I don't think it's a good reason for deprecating functions. A lot of 
functions, if used incorrectly, could produce bad results, it's not the 
reason to not use them correctly.



Since password_verify() and password_needs_rehash() already supports hashes 
created with crypt(), the only thing needed to do is remove crypt().


Removing it would cause serious BC issues with no practical gain.

--
Stas Malyshev
smalys...@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[steve]

hash() is for cryptographic hashes and checksums. crypt() only supports 
password hashing algorithms which should not be used as a cryptographic hash or 
checksum because they are purposefully slow.


> On 02/19/2022 7:16 PM Vasilii Shpilchin  wrote:
> 
>  
> Hashes are not for passwords only. For instance, hashes usually in use in
> sharding and to calculate checksums. I suggest to add a warning to the
> documentation, something like: if you need to hash a password, use
> password_hash().
> 
> Best regards,
> Vasilii.
> 
> On Sat, Feb 19, 2022, 8:03 PM  wrote:
> 
> > crypt() should be deprecate because it can be used to create bad password
> > hashes:
> >
> > * descrypt: 12 bits of salt is too small and it's ~100x faster to crack
> > than md5crypt. Which itself is too fast for password crackers (see
> > CVE-2012-3287).
> > * Extended DES: 24 bits of salt is too small.
> > * md5crypt is too fast for password crackers (see CVE-2012-3287).
> > * sha256crypt and sha512crypt are dangerous (see CVE-2016-20013).
> >
> > Since password_verify() and password_needs_rehash() already supports
> > hashes created with crypt(), the only thing needed to do is remove crypt().
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Vasilii Shpilchin]

Hashes are not for passwords only. For instance, hashes usually in use in
sharding and to calculate checksums. I suggest to add a warning to the
documentation, something like: if you need to hash a password, use
password_hash().

Best regards,
Vasilii.

On Sat, Feb 19, 2022, 8:03 PM  wrote:

> crypt() should be deprecate because it can be used to create bad password
> hashes:
>
> * descrypt: 12 bits of salt is too small and it's ~100x faster to crack
> than md5crypt. Which itself is too fast for password crackers (see
> CVE-2012-3287).
> * Extended DES: 24 bits of salt is too small.
> * md5crypt is too fast for password crackers (see CVE-2012-3287).
> * sha256crypt and sha512crypt are dangerous (see CVE-2016-20013).
>
> Since password_verify() and password_needs_rehash() already supports
> hashes created with crypt(), the only thing needed to do is remove crypt().
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] RFC proposal to deprecate crypt()

[steve]

crypt() should be deprecate because it can be used to create bad password 
hashes:

* descrypt: 12 bits of salt is too small and it's ~100x faster to crack than 
md5crypt. Which itself is too fast for password crackers (see CVE-2012-3287).
* Extended DES: 24 bits of salt is too small.
* md5crypt is too fast for password crackers (see CVE-2012-3287).
* sha256crypt and sha512crypt are dangerous (see CVE-2016-20013).

Since password_verify() and password_needs_rehash() already supports hashes 
created with crypt(), the only thing needed to do is remove crypt().

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP 7.4.28 Released!

[Jan Ehrhardt]

"Christoph M. Becker" in php.internals (Fri, 18 Feb 2022 16:26:20 +0100):
>On 18.02.2022 at 16:02, Jan Ehrhardt wrote:
>
>> Derick Rethans in php.internals (Thu, 17 Feb 2022 14:42:47 + (GMT)):
>>> The PHP development team announces the immediate availability of PHP
>>> 7.4.28. This is a security release.
>>
>>> Windows downloads:
>>
>> 7.4.28 is not there. 7.4.27 is there. And even 7.3.33 is still there.
>
>We're having some issues with the PHP 7.4 build VM.  I'm confident that
>the PHP 7.4.28 builds are available soonish.
>
>I'm going to remove the 7.3 downloads right away.

Please also move the 7.3.33 files to
https://windows.php.net/downloads/releases/archives/ 
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion

[Robert Landers]

Thanks! That’s all really useful information! Are we sure we want to change a 
language idiom though? The warning is useful (you can choose to ignore/suppress 
it or not) for most of us, that’ll result in better code. But it is a useful 
idiom.

Get Outlook for iOS

From: Rowan Tommins 
Sent: Friday, February 18, 2022 2:56:07 PM
To: internals@lists.php.net 
Subject: Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion

On 18/02/2022 12:31, Mark Randall wrote:
> I would claim that the unary operators behave slightly different, if
> it were a case of cooerce to zero, the behaviour of null++ and null--
> would be expected to be the same as operating on 0, but it's not.
>
> null++ is allowed, but null-- returns null, and its value afterwards
> is null.
>
> https://3v4l.org/Bnb2D


It is "--" that is the odd one out here, not "++". Every other
arithmetic operator in the language treats null as equivalent to 0.

As far as I can tell, the fact that "$a--" behaves differently from "$a
-= 1" is an implementation bug that's been around so long it's become
documented behaviour. I tried to propose changing it, but the reaction
degenerated into personal abuse, so I abandoned it.


>> If anything, it's the fact that $a++ is NOT a special case that means
>> it will be affected by this proposal.
>
> It is intended to be affected by this proposal.


I didn't say it wasn't intentional, I said it wasn't special; the exact
same behaviour applies to about a dozen operators which have to read the
current value before writing.

Concatenation, for instance, treats null as an empty string, so this
currently works (with a Warning) even if $message is undefined:

$message .= "Another thing happened\n";


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php