Hi Anthony,
On Tue, Jul 22, 2014 at 11:27 PM, Anthony Ferrara
wrote:
> > However, I don't mind at all to write RFC raising E_NOTICE for
> > password_hash()
> > with PASSWORD_BCRYPT.
>
> Awesome, thanks!
>
I'll write it later.
> Although cryptgraphic hash functions are supposed work cryptgraph
Yasuo,
> However, I don't mind at all to write RFC raising E_NOTICE for
> password_hash()
> with PASSWORD_BCRYPT.
Awesome, thanks!
> Although cryptgraphic hash functions are supposed work cryptgraphic way, but
> many of them are failing. This was in real world and I aware of the risk.
It's le
Hi Anthony,
I noticed I've made silly mistakes in previous reply. I've added little
more.
Even if I remove text formatting, gmail insists strange formatting. It may
be hard to read...
Please disregard old one and read this.
On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara
wrote:
>
> > E_NOTICE
Hi Yasuo,
On Tue, Jul 22, 2014 at 5:00 AM, Yasuo Ohgaki wrote:
> Hi Anthony,
>
> On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara
> wrote:
>
>> > E_NOTICE for password larger than 72 is mandatory. Current
>> password_hash()
>> > works without any sign of problem even if it may not be working as
Hi Anthony,
On Mon, Jul 21, 2014 at 11:32 PM, Anthony Ferrara
wrote:
> > E_NOTICE for password larger than 72 is mandatory. Current
> password_hash()
> > works without any sign of problem even if it may not be working as
> > authentication.
> > I'll add E_NOTICE as bug fix if there aren't any mo
Yasuo,
> E_NOTICE for password larger than 72 is mandatory. Current password_hash()
> works without any sign of problem even if it may not be working as
> authentication.
> I'll add E_NOTICE as bug fix if there aren't any more comments.
Could you please not.
I have asked you to draft an RFC to j
Hi all,
On Mon, Jul 21, 2014 at 3:17 PM, Yasuo Ohgaki wrote:
> In old days, crypt() was unusable securely. There are many
> users/developers that
> are used to have static slat. Code like below disables authentication
> completely.
>
> password_hash(hash('sha512', SOME_SECRET_SALT).$password, DE
Hi David,
On Mon, Jul 21, 2014 at 2:53 PM, David Muir wrote:
> Prehashing with sha512 means it is no longer blowfish. It is now a
> non-vetted DIY algorithm. The whole point of password_hash is to avoid this
> type of thing, and should be clearly discouraged in the documentation.
>
I agree. It'
On 21/07/2014, at 10:04 AM, Yasuo Ohgaki wrote:
> Hi Anthony,
>
> I want to finish and close this issue.
>
> On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki wrote:
>
>> Also, Deprecating crypt() without first discussing it (and having an
>>> RFC to vote on) is not cool (and has been reverted)
Hi Anthony,
I want to finish and close this issue.
On Sun, Jul 20, 2014 at 9:33 AM, Yasuo Ohgaki wrote:
> Also, Deprecating crypt() without first discussing it (and having an
>> RFC to vote on) is not cool (and has been reverted):
>>
>> http://svn.php.net/viewvc/phpdoc/en/trunk/reference/string
Hi Anthony,
On Sun, Jul 20, 2014 at 12:27 AM, Anthony Ferrara
wrote:
> > I'll suggest users to use SHA512 raw output as password to
> > remove 72 chars limitation if it is needed.
>
> Then you either misunderstood what I was saying, or completely ignored it.
>
SHA512 raw output may truncate byt
Yasuo
> I'll suggest users to use SHA512 raw output as password to
> remove 72 chars limitation if it is needed.
Then you either misunderstood what I was saying, or completely ignored it.
> Raising E_NOTICE for too long password for PASSWORD_BCRYPT
> makes sense. I'll add it later.
>
> https://b
Hi Anthony,
On Fri, Jul 18, 2014 at 6:56 AM, Anthony Ferrara
wrote:
> > Anthony, do you have suggestion for removing 72 char restriction of
> > PASSWORD_BCRYPT?
>
> My suggestion is to leave it there (it's no longer bcrypt if you do
> something to remove it). Here's a deeper explanation:
> http:
Yasuo
> Anthony, do you have suggestion for removing 72 char restriction of
> PASSWORD_BCRYPT?
My suggestion is to leave it there (it's no longer bcrypt if you do
something to remove it). Here's a deeper explanation:
http://stackoverflow.com/a/16597402/338665
Once scrypt (or yescrypt, or whateve
Hi all,
On Fri, Jul 18, 2014 at 4:38 AM, Anthony Ferrara
wrote:
> We internalized the algorithms in 5.3.2 at least partially because the
> system provided libraries were inconsistent at best (hence why many
> but not all 5.2 systems don't support bcrypt, it depended on the build
> of libcrypt yo
All,
Look at the issue, there's a line in there that is the crux of the issue:
> So problem isn't only in ROUNDS_MIN.
In fact, the overall algorithm changed.
Look at a quick example: http://3v4l.org/Eov3o
>From 5.3.2+ (when we pulled in our own implementation of crypt-sha256
and crypt-sha512,
On 16 July 2014 23:16, Tjerk Meesters wrote:
> On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki wrote:
>
>> Hi Tjerk,
>>
>> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters > > wrote:
>>
>>> Why should `password_verify()` work on a hash that wasn't generated with
>>> `password_hash()`? The fact tha
Hi Tjerk,
On Thu, Jul 17, 2014 at 3:16 PM, Tjerk Meesters
wrote:
> On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki wrote:
>
>> Hi Tjerk,
>>
>> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters <
>> tjerk.meest...@gmail.com> wrote:
>>
>>> Why should `password_verify()` work on a hash that wasn't g
On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki wrote:
> Hi Tjerk,
>
> On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters > wrote:
>
>> Why should `password_verify()` work on a hash that wasn't generated with
>> `password_hash()`? The fact that it uses `crypt()` internally should not
>> leak outsid
Hi Tjerk,
On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters
wrote:
> Why should `password_verify()` work on a hash that wasn't generated with
> `password_hash()`? The fact that it uses `crypt()` internally should not
> leak outside of its API, imho.
password_*() is designed as crypt() wrapper a
Hi,
On Thu, Jul 17, 2014 at 9:06 AM, Yasuo Ohgaki wrote:
> Hi Sara,
>
> On Thu, Jul 17, 2014 at 8:53 AM, Sara Golemon wrote:
>
> > At the risk of perhaps missing the point, wouldn't it be more useful
> > to encourage users in some way (perhaps through documentation only) to
> > use password_ha
Hi Sara,
On Thu, Jul 17, 2014 at 8:53 AM, Sara Golemon wrote:
> At the risk of perhaps missing the point, wouldn't it be more useful
> to encourage users in some way (perhaps through documentation only) to
> use password_hash()/password_verify() instead? It was designed with
> migration paths i
On Tue, Jul 15, 2014 at 5:46 PM, Yasuo Ohgaki wrote:
> crypt() has BC issue with older systems.
>
> https://bugs.php.net/bug.php?id=62372&edit=1
>
> The reason rounds became 1000 from 10 is hardcoded lower limit for newer
> PHPs.
> Generally speaking, developer should never use less than 1000 roun
Hi Andrea,
On Wed, Jul 16, 2014 at 10:47 AM, Andrea Faulds wrote:
> > This change was done while ago, so it would not worth the effort to relax
> > the requirement now. IMHO.
> >
> > We may add optional flag to relax the limitation, though.
> > I don't mind modifying crypt() or adding migration
On 16 Jul 2014, at 02:45, Yasuo Ohgaki wrote:
> This change was done while ago, so it would not worth the effort to relax
> the requirement now. IMHO.
>
> We may add optional flag to relax the limitation, though.
> I don't mind modifying crypt() or adding migration INI setting.
Yeah, that’s my
Hi Andrea,
On Wed, Jul 16, 2014 at 10:12 AM, Andrea Faulds wrote:
> > - Developer may use larger rounds and store updated hash when
> > user is authenticated with old PHP.
> > - Developer may ask users to reset password if password hash has
> > to fewer rounds than 1000 (i.e. outdated hash)
On 16 Jul 2014, at 01:46, Yasuo Ohgaki wrote:
> - Developer may use larger rounds and store updated hash when
> user is authenticated with old PHP.
> - Developer may ask users to reset password if password hash has
> to fewer rounds than 1000 (i.e. outdated hash) with new PHP.
Wait, doesn’t
27 matches
Mail list logo
