On 31/07/12 22:20, Peter Lind wrote:
On 31 July 2012 22:02, Anthony Ferrara ircmax...@gmail.com wrote:
Peter,
On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 31 July 2012 18:21, Anthony Ferrara ircmax...@gmail.com wrote:
*snip*
Also, be aware that BCrypt only
2012/8/1 Ángel González keis...@gmail.com:
I'd go with the hashing. I'd would however produce a slightly different
prefix
than with bare bcrypt.
Like that. And I thought some about it. Currently, there is no real
need for that. And no one is hindered to implement his own
version-information
Also, be aware that BCrypt only uses the first 72 characters of the
password field. So if you use a hex encoded sha512 output, a good deal
of entropy would be lost (almost half of it)...
Good to know, do most hash algorithms have limitations on the # of chars as
input?
That would
On Tue Jul 31 12:21 PM, Anthony Ferrara wrote:
Jonathan,
Again, implementing something in the core that's not verified and
can't be implemented well by the vast majority of developers out
there.
Alright so I found some people supporting my claims:
On Thu Jul 12 02:34 PM, Anthony Ferrara wrote:
https://wiki.php.net/rfc/password_hash
-- password_hash()
password_hash_rfc(string $password, int $algo, array $options = array())
My personal opinion is the api should be:
password_hash(string $password, string $secret = '', array $options =
Say you have:
define('MY_HASHING_SECRET', 'hhtrg54~%$%4long'); $password =
'1234';
password_hash_rfc($password . MY_HASHING_SECRET,
PASSWORD_METHOD_BCRYPT); password_hash($password, MY_HASHING_SECRET);
Note here that in both cases we let crypt() generate a random salt that
is
Jonathan,
On Tue, Jul 31, 2012 at 8:32 AM, Jonathan Bond-Caron jbo...@openmv.comwrote:
On Thu Jul 12 02:34 PM, Anthony Ferrara wrote:
https://wiki.php.net/rfc/password_hash
-- password_hash()
password_hash_rfc(string $password, int $algo, array $options = array())
My personal
RFC:
https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper
Thanks, I missed it...
I strongly disagree with this, the 'pepper' IMHO is a best practice for web
applications.
I prefer to live with the idea that an attacker may comprise some
database(s) in the 'cloud' but
On Tue, Jul 31, 2012 at 4:28 PM, Jonathan Bond-Caron jbo...@openmv.com wrote:
Thanks, I missed it...
I strongly disagree with this, the 'pepper' IMHO is a best practice for web
applications.
I prefer to live with the idea that an attacker may comprise some
database(s) in the 'cloud' but not
On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron jbo...@openmv.comwrote:
RFC:
https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper
Thanks, I missed it...
I strongly disagree with this, the 'pepper' IMHO is a best practice for web
applications.
Again, I have
On Tue Jul 31 10:54 AM, Anthony Ferrara wrote:
On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron HYPERLINK
I strongly disagree with this, the 'pepper' IMHO is a best practice
for web applications.
Again, I have not seen this being said by any security or cryptography
expert.
Jonathan,
On Tue, Jul 31, 2012 at 12:01 PM, Jonathan Bond-Caron jbo...@openmv.comwrote:
On Tue Jul 31 10:54 AM, Anthony Ferrara wrote:
On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron HYPERLINK
I strongly disagree with this, the 'pepper' IMHO is a best practice
for web
On 31/07/12 18:21, Anthony Ferrara wrote:
Jonathan,
On Tue, Jul 31, 2012 at 12:01 PM, Jonathan Bond-Caron
jbo...@openmv.comwrote:
Sure managing keys properly can be hard, simple cases:
$secret = MY_KEY;
$secret = file_get_contents('/security/key.pem');
Actually, that's not properly
On 31 July 2012 18:21, Anthony Ferrara ircmax...@gmail.com wrote:
*snip*
Also, be aware that BCrypt only uses the first 72 characters of the
password field. So if you use a hex encoded sha512 output, a good deal of
entropy would be lost (almost half of it)...
Seeing as the hashing function
Peter,
On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 31 July 2012 18:21, Anthony Ferrara ircmax...@gmail.com wrote:
*snip*
Also, be aware that BCrypt only uses the first 72 characters of the
password field. So if you use a hex encoded sha512 output, a
On 31 July 2012 22:02, Anthony Ferrara ircmax...@gmail.com wrote:
Peter,
On Tue, Jul 31, 2012 at 3:46 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 31 July 2012 18:21, Anthony Ferrara ircmax...@gmail.com wrote:
*snip*
Also, be aware that BCrypt only uses the first 72 characters of
On Sun, Jul 15, 2012 at 6:21 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 07/15/2012 06:03 PM, Anthony Ferrara wrote:
Additionally, DateTime is a class in core. Do any functions throw
exceptions?
Nope, and note that if you call those same DateTime functions
procedurally they don't use
On Mon, Jul 16, 2012 at 8:04 AM, Galen Wright-Watson ww.ga...@gmail.com wrote:
What about an approach like PDO, where the password functions would
generate errors by default, but could be configured to throw exceptions?
The ugliest aspects of this idea are the requirement for another function
Hi Anthony,
Sorry, I'm really off topic here. What I suggest here is just to think
about new ways to make PHP more secure - and I think how to work with
errors is an important thing in this case.
It's here, because the password-rfc is just a good example for
security. :) It's not critic to the
We shouldn't neuter the language because some stupid people might do
stupid people. Use appropriate error handling, not inappropriate error
handling because it might catch someone out who has a poorly
configured server.
On 16 July 2012 14:40, Alex Aulbach alex.aulb...@gmail.com wrote:
Hi
2012/7/16 Galen Wright-Watson ww.ga...@gmail.com:
What about an approach like PDO, where the password functions would
generate errors by default, but could be configured to throw exceptions?
I think it makes things more complicated instead of less. For security
simpleness is important.
--
Nikita,
On Mon, Jul 16, 2012 at 5:30 AM, Nikita Popov nikita@gmail.com wrote:
On Mon, Jul 16, 2012 at 8:04 AM, Galen Wright-Watson ww.ga...@gmail.com
wrote:
What about an approach like PDO, where the password functions would
generate errors by default, but could be configured to throw
PHP6 may have exceptions everywhere, but for the moment, do things
like other functions. E_WARNING.
On 16 July 2012 15:05, Anthony Ferrara ircmax...@gmail.com wrote:
Nikita,
On Mon, Jul 16, 2012 at 5:30 AM, Nikita Popov nikita@gmail.com wrote:
On Mon, Jul 16, 2012 at 8:04 AM, Galen
2012/7/16 Andrew Faulds ajf...@googlemail.com:
We shouldn't neuter the language because some stupid people might do
stupid people. Use appropriate error handling, not inappropriate error
handling because it might catch someone out who has a poorly
configured server.
I think it's not
On 16/07/12 08:04, Galen Wright-Watson wrote:
What about an approach like PDO, where the password functions would
generate errors by default, but could be configured to throw exceptions?
The ugliest aspects of this idea are the requirement for another function
(password_set_option?) and hidden
2012/7/14 Andrew Faulds ajf...@googlemail.com:
Well... if people have poorly configured servers spitting out debug
info in production mode, I don't think it is our problem. It is
theirs.
Do you want to make it secure or do you want to discuss?
--
Greetings Alex Aulbach
--
PHP Internals -
Hi Anthony:
I want exceptions here too. But PHP doesn't use exceptions in its standard
library (aside from SPL)
DateTime uses exceptions.
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
On 15/07/12 22:07, Alex Aulbach wrote:
2012/7/14 Andrew Faulds ajf...@googlemail.com:
Well... if people have poorly configured servers spitting out debug
info in production mode, I don't think it is our problem. It is
theirs.
Do you want to make it secure or do you want to discuss?
Seems
Ok. I think, I go too much off topic. Sorry.
But I want to repeat
- we never know in which context the program will run. And good
security means, thait it shouldn't care, in which context it runs.
- everything, which can go wrong will go wrong (Murphy); if there is
any chance to make it wrong,
Alex,
On Sun, Jul 15, 2012 at 7:19 PM, Alex Aulbach alex.aulb...@gmail.comwrote:
Ok. I think, I go too much off topic. Sorry.
But I want to repeat
- we never know in which context the program will run. And good
security means, thait it shouldn't care, in which context it runs.
Could you
Hi Anthony:
But I agree with your larger point. The only problem with it is that it
would take an engine wide shift to do.
How does using exceptions in this new extension require an engine wide
shift? DateTime already uses exceptions, no problem.
Thanks,
--Dan
--
T H E A N A L Y S I S
Daniel,
On Sun, Jul 15, 2012 at 8:20 PM, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Anthony:
But I agree with your larger point. The only problem with it is that it
would take an engine wide shift to do.
How does using exceptions in this new extension require an engine
On 07/15/2012 06:03 PM, Anthony Ferrara wrote:
Additionally, DateTime is a class in core. Do any functions throw
exceptions?
Nope, and note that if you call those same DateTime functions
procedurally they don't use exceptions. So yes, changing PHP to start
throwing exceptions from
On 13/07/12 12:28, Ryan McCue wrote:
Somewhat off-topic, but is there a reason why not? It seems to me that
introducing a new API without using PHP's best method of error handling
(IMHO) is a little silly.
I don't really trust exception throwing near password-managing functions.
Consider the
2012/7/13 Ángel González keis...@gmail.com:
The codebase does no global exception handling (because it doesn't throw
exceptions itself),
and also nobody configured the server not to show errors/exceptions
(some say it was
purposely setup to show them).
password_verify() errors if the
Anthony Ferrara wrote:
I want exceptions here too. But PHP doesn't use exceptions in its standard
library (aside from SPL), and I'm not sure this is a compelling enough case
to implement the first... I could be swayed, but I'm not sure the rest of
the team would.
Somewhat off-topic, but is
2012/7/12 Anthony Ferrara ircmax...@gmail.com:
Hello all,
Since the discussion has died down around the concept, I have updated the
RFC and moved it into Proposed (under discussion) status.
I have updated the RFC to include a section on discussion points containing
points that I know were
On Thu, Jul 12, 2012 at 7:24 PM, Alex Aulbach alex.aulb...@gmail.com wrote:
1. The resulting string should have a version information. For example
the first char. the example hash will look like
1$2y$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi,
instead of
2012/7/12 Nikita Popov nikita@gmail.com:
On Thu, Jul 12, 2012 at 7:24 PM, Alex Aulbach alex.aulb...@gmail.com wrote:
1. The resulting string should have a version information. For example
the first char. the example hash will look like
Hi!
https://wiki.php.net/rfc/password_hash
Looks good. The only question I have is for password_make_salt() - do we
need the user to specify length? I think length is defined by the
algorithm in the most cases. Maybe convert it to password_make_salt(int
$salt_type = PASSWORD_SALT_BCRYPT, int
Stas,
https://wiki.php.net/rfc/password_hash
Looks good. The only question I have is for password_make_salt() - do we
need the user to specify length? I think length is defined by the
algorithm in the most cases. Maybe convert it to password_make_salt(int
$salt_type = PASSWORD_SALT_BCRYPT,
Alex,
First off, thanks for such a thorough reply!!! Comments are inline.
1. The resulting string should have a version information. For example
the first char. the example hash will look like
1$2y$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi,
instead of
2012/7/12 Anthony Ferrara ircmax...@gmail.com:
That's what $2y$ is for. It's a standard crypt() prefix algorithm
identifier. For example you can use $1$ for md5, $5$ for sha256 and $6$ for
sha512 algorithms. In the future, if new algorithms are added, it would be
added as a new prefix for
43 matches
Mail list logo
