Hi Steve,
I wanted to stay away from this thread, as I believe I've made my
opinion clear and there's not much more signal for me to add, but as
you've replied to me directly:
On 2/21/22 17:43, st...@tobtu.com wrote:
If crypt() is removed, you can still use password_verify() to verify all
On 21/02/2022 16:43, st...@tobtu.com wrote:
If crypt() is removed, you can still use password_verify() to verify all the
password hashes created by crypt(). The only thing you lose is creating those
bad password hashes. Which can be done in userland because most people aren't
changing their
On Mon, 21 Feb 2022 at 16:44, wrote:
> If crypt() is removed [...] The only thing you lose is creating those bad
> password hashes.
That's not exactly fair, as noted by Tim, `crypt()` can be used for other
software (e.g. Dovecot); and by Hans for modifying `/etc/shadow`.
While I would warn
If crypt() is removed, you can still use password_verify() to verify all the
password hashes created by crypt(). The only thing you lose is creating those
bad password hashes. Which can be done in userland because most people aren't
changing their passwords daily. So it will run that slow
On 21/02/2022 12:28, Jakub Zelenka wrote:
We can see
that there are some valid use case for using crypt directly and we can also
see that it's offered by other languages as well - e.g. Python:
https://docs.python.org/3/library/crypt.html .
I think this is quite an important point: if crypt()
>
> As mentioned elsewhere in the mail thread, `crypt()` is not designed for
> fast hashing, and is in fact slow by design.
>
What do you mean by slow? Are you aware that password_hash
and password_verify for bcrypt are just wrappers around crypt? Just to note
that by removing that, we would
fwiw i recall a real-world script modifying a linux system's /etc/passwd /
/etc/shadow using crypt() because password_hash() couldn't create
passwd/shadow-compatible hashes while crypt() could
On Mon, 21 Feb 2022 at 12:49, Marco Pivetta wrote:
> On Mon, Feb 21, 2022 at 12:39 PM Tim Düsterhus
On Mon, Feb 21, 2022 at 12:39 PM Tim Düsterhus wrote:
> Hi
>
> On 2/21/22 12:12, Marco Pivetta wrote:
> If it's not going to be removed, what's the point of annoying people
> with deprecation warnings (that they would patch out/silence anyway)?
>
> >>>
> >>> Probably to be removed
Hi
On 2/21/22 12:12, Marco Pivetta wrote:
If it's not going to be removed, what's the point of annoying people
with deprecation warnings (that they would patch out/silence anyway)?
Probably to be removed in `9.0` or `10.0`? Yes, it should be removed at
some point.
In contrast to other
On Mon, Feb 21, 2022 at 11:10 AM Tim Düsterhus wrote:
> Hi Marco
>
> On 2/21/22 10:15, Marco Pivetta wrote:
> >> If it's not going to be removed, what's the point of annoying people
> >> with deprecation warnings (that they would patch out/silence anyway)?
> >>
> >
> > Probably to be removed in
Hi Marco
On 2/21/22 10:15, Marco Pivetta wrote:
If it's not going to be removed, what's the point of annoying people
with deprecation warnings (that they would patch out/silence anyway)?
Probably to be removed in `9.0` or `10.0`? Yes, it should be removed at
some point.
In contrast to
On Mon, Feb 21, 2022 at 10:06 AM Stanislav Malyshev
wrote:
> Hi!
>
> > The RFC is about deprecation, not removal.
>
> If it's not going to be removed, what's the point of annoying people
> with deprecation warnings (that they would patch out/silence anyway)?
>
Probably to be removed in `9.0` or
Hi!
The RFC is about deprecation, not removal.
If it's not going to be removed, what's the point of annoying people
with deprecation warnings (that they would patch out/silence anyway)?
If we want to document which functions are recommended to be used in
which case, we have the manual for
I think it's a great idea to deprecate crypt(). I wouldn't want anyone to
use it in a new code. For legacy applications, we are giving them enough
time to upgrade their password storing policy. Also, it's not like we are
removing support for hashing in general from PHP, we are just deprecating a
On Sun, 20 Feb 2022, 14:17 Tim Düsterhus, wrote:
> Hi Steve,
>
> On 2/20/22 12:44, st...@tobtu.com wrote:
>
>
> > If that's the case, you may not know that password_verify() can verify
> all password hashes created by crypt(). The whole point of deprecating and
> finally removing crypt() is that
Hi Steve,
On 2/20/22 12:44, st...@tobtu.com wrote:
Also ~99% of implementations of crypt() that use sha256crypt and/or sha512crypt
password hashing algorithms are vulnerable to a long password DoS attack. Since
they don't know they need to limit the password length because the runtime is
> On 02/20/2022 1:10 AM Stanislav Malyshev wrote:
>
>
> 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
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
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
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
21 matches
Mail list logo
