On Fri, Apr 23, 2021 at 2:41 PM Niklas Keller wrote:
> People might remember the approach incorrectly or have a similar idea
> themselves and make mistakes in their own version of such code.
>
>
While I agree in principle that this is possibly true and a good
justification for adding guard rails,
On Fri, Apr 23, 2021 at 2:56 PM Kamil Tekiela wrote:
> We can also consider switching the default to Argon2id.
> As Scott says the NUL byte truncation is not a bug in PHP, but a bug in
> the algorithm. I don't know the exact specification but maybe we should
> leave the current implementation as
We can also consider switching the default to Argon2id.
As Scott says the NUL byte truncation is not a bug in PHP, but a bug in the
algorithm. I don't know the exact specification but maybe we should leave
the current implementation as is?
Sara Golemon schrieb am Fr., 23. Apr. 2021, 00:21:
> On Thu, Apr 22, 2021 at 3:27 PM Niklas Keller wrote:
> >> Do you have a link to places where frameworks are doing this? I built a
> >> contrived example which I think summarizes the behavior you described
> here:
> >> https://3v4l.org/6tunp
>
On Thu, Apr 22, 2021 at 3:27 PM Niklas Keller wrote:
>> Do you have a link to places where frameworks are doing this? I built a
>> contrived example which I think summarizes the behavior you described
here:
>> https://3v4l.org/6tunp
>
> I have links to a library / blog post:
>
> https://github.co
Sara Golemon schrieb am Do., 22. Apr. 2021, 17:27:
> On Thu, Apr 22, 2021 at 12:58 AM Niklas Keller wrote:
> > Thank you for your work. I think this is a really good safety check to
> have. I'd however go a step further and also throw on NUL in
> password_verify.
> >
> > You seem to assume that
On Thu, Apr 22, 2021 at 11:04 AM Kamil Tekiela wrote:
>
> I don't like throwing exceptions for pretty much the same reasons as
Nikita described.
> This is a rather limited attack vector. It depends either on the user
going out of their way
> to make their password vulnerable or on the developer in
I don't like throwing exceptions for pretty much the same reasons as Nikita
described. This is a rather limited attack vector. It depends either on the
user going out of their way to make their password vulnerable or on the
developer introducing the vulnerability with the use of another function
ma
On Thu, Apr 22, 2021 at 12:58 AM Niklas Keller wrote:
> Thank you for your work. I think this is a really good safety check to
have. I'd however go a step further and also throw on NUL in
password_verify.
>
> You seem to assume that NUL bytes as input come from the end user, but I
think it's more
On Thu, Apr 22, 2021 at 3:06 AM Nikita Popov wrote:
> I don't think this is a good idea.
>
Fair, and that objection alone is enough to merit going RFC if I decide to
proceed with this.
> This adds an error condition that is based on the input string, which is
generally user-provided.
> As there i
On Thu, Apr 22, 2021 at 3:20 AM Claude Pache wrote:
> Also, the warning message you introduced contains “... this hash should
be regenerated using ...”.
> There is already a dedicated function for conveying that information in a
coder-friendly way,
> namely `password_needs_rehash()`: let’s use tha
> Le 22 avr. 2021 à 03:47, Sara Golemon a écrit :
>
> I have this notion that we've discussed this before, I'm certain I knew
> that bcrypt wasn't binary safe, but someone reminded me that
> password_hash() could be called with null bytes in the password itself and
> that is just SCREAMING to
On Thu, Apr 22, 2021 at 3:48 AM Sara Golemon wrote:
> I have this notion that we've discussed this before, I'm certain I knew
> that bcrypt wasn't binary safe, but someone reminded me that
> password_hash() could be called with null bytes in the password itself and
> that is just SCREAMING to hav
Sara Golemon schrieb am Do., 22. Apr. 2021, 03:47:
> I have this notion that we've discussed this before, I'm certain I knew
> that bcrypt wasn't binary safe, but someone reminded me that
> password_hash() could be called with null bytes in the password itself and
> that is just SCREAMING to have
I have this notion that we've discussed this before, I'm certain I knew
that bcrypt wasn't binary safe, but someone reminded me that
password_hash() could be called with null bytes in the password itself and
that is just SCREAMING to have some safety-rails put on IMO.
So I've thrown together https
15 matches
Mail list logo
