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 crypt()...
Ya, didn't know that - my lib was based on the hash-functions (5.3).
But I understand nearly.
Perhaps I oversee something, but how do I know, if I could process it
with this version of crypt?
>> In my project I had really very good results, when I just throw
>> exceptions in the case that something goes wrong. This is the highly
>> visible sign for a bad developer, that he has made something wrong or
>
> 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.
Hum. I have arguments: developers tend to use the @-operator to
prevent disturbing error-messages. :)
Ok, serious: I don't like function where I cannot control what is
written to the logfiles.
For example: error messages in socket_open() can not be catched (its
quite difficult). But it's sometimes totally normal, that it will
fail. Think this is a design-failure in PHP, that it is so complicated
to catch the messages. But we go off-topic here.
> I think that halting execution if either function is called wrong is a bit
> drastic. Again, I understand why, but I think it's a bit overkill in this
> case...
Ok, it's a little bit too much and solves not the problem.
>> 3a) I would await a function "password_algos()" (like hash_algos()),
>> which returns me all available algorithms.
>>
>> The available algorithms should also be displayed in PHPINFO(). This
>> is because I need to check, if the current version has built it in.
>
>
> array(
> 'bcrypt' => PASSWORD_BCRYPT
> )
>
> I'll add that when I get a few minutes.
Maybe more informations?
array(
'bcrypt' => array(
'id' => PASSWORD_BCRYPT,
'default' => true,
'name' => "BCrypt"
'url' => "http://en.wikipedia.org/wiki/Bcrypt";,
'params' => array('cost','salt')
)
)
Not elegant, but something like that's what I mean with the
algo_info() .... self documention. see down...
> It's the standard crypt() format, which is available in almost every single
> programming language out there today. Which makes interoperability really
> easy.
>
> I would be very hesitant to invent our own format here, especially for the
> interoperability standpoint. There are standards that exist, and unless
> there's a *strong* reason not to use them, we should...
Sorry, just didn't know that. But was pure intention not to read too
much into the details.
Maybe something which should be documented carefully...
>> 3c) I think about changes. Password algorithms are a thing of changing
>> over time. So I would like to have a function like
>> "password_algo_info($algo)", which returns me as a developer a
>> detailed information about what this algorithm needs to work propper
> I'm not sure why this needs to be a function. Wouldn't the documentation on
> the internet be enough for this?
It's just an idea. Nothing really important, see above.
>> But to make it possible I suggest to have a function
>> "password_best_algo()" instead, which returns a name of
>> password_algos(). Why a function instead of a constant? You can add a
>> parameter "$version" to this function and in this case the function
>
> The password_best_algo() thought is intriguing, but I guess I don't see the
> changing constant to be a big deal. It's an informed choice the developer
> has to make, which is better than complicating the API by making it take 3
> or 4 function calls to hash a password (IMHO)...
I found no real need. Forget it. In an object-oriented context it
would make more sense.
>> 5. I added something like "is_password_hash()", to check, if a hash
>> has the right syntax (not semantic) to work with it. This prevents
>> internally also, that hashes with version 2 can work together with the
>> class for version 1.
>
> There's no need. password_get_info() could be used for it, and I'm not sure
> that there's even a valid use-case for such a function. Can you elaborate
> over why you would use such a function?
I do not quite completly understand the version/algorithm here. I
think about fast checks for millions of hashes.
Hm. In my class, the string had a defined format. If it hadn't that
format, it needs to be converted. This function was to check that very
fast without parsing it. But yours is implemented in C, not PHP... if
you can check 50000 per minute with password_get_info() I think it is
fast enough. :)
> password? If this is really an issue, please suggest a better prefix, as I
> can't think of one that's better without being cryptic...
Indeed, I have no better suggestions.
--
Greets Alex
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
