Password Generation Library

[sarciszewski]

(I'm mostly creating this PR so Travis will run the tests. Cough.)

Features:

• Generate a random password

Other changes made by this PR:

• Added test cases

[narfbg]

I suppose you haven't looked at system/core/compat/ ... :)

[sarciszewski]

No, I somehow didn't notice this. I suppose I should nuke the PBKDF2 parts... would this be any good as just a solid "random strings for passwords" library?

[narfbg]

Yea, when I mentioned a password library earlier I was thinking more of a password generator library/helper with options for different types of passwords.
If it is to be named CI_Password, it should just wrap around the password_*() functions (although I'm not a fan of that, kind of ties you to the library's specifics while the functionality stays the same).

[sarciszewski]

Understood. What would be a good name for it then? CI_Password_generator?

[narfbg]

CI_Password_generator would be according to the styleguide.

Btw, take your time ... I didn't expect to see that in just a few hours. :)

[sarciszewski]

Okay, the tests are passing. At this point, I'd like to open the floor for criticism, review, suggestions, etc.

I'm also considering adding public funciton diceware($words) that would generate a diceware passphrase with a given number of words (minimum 5). However, this would require storing an array with 7776 elements somewhere-- either in configuration, a text file, or in the script itself. Anyone have thoughts on how to proceed with this? (Or, should we leave it alone?)

[narfbg]

You need to revert all changes to CI_Security - I've fixed the ctype_digit() issue (thanks for that one) and we already have hash_equals() (system/core/compat/hash.php) for constant time comparisons.

Also needs to comply with the styleguide ... stuff like TRUE vs true, where to put opening braces, etc.

On diceware() ... no, I don't think we should store such huge arrays anywhere within CI.

I'll leave inline comments on the patch for other details.

[narfbg]

If you'll be overwriting this, it shouldn't have 'default' in its name. :)

[narfbg]

Should also be a protected property.

[sarciszewski]

Uh oh, there's a merge conflict? Hmm.

[ivantcholakov]

Well?

[sarciszewski]

Squashed and resolved the merge conflict.

[narfbg]

We have hash_equals() in system/core/compat/, you don't need this. :)

[narfbg]

You deffinately need to rework this to match our styleguide, add a changelog message and documentation.

[narfbg]

Oddly, this is not a syntax error, but still erroneous. :)

Edit: And, um ... this test is kind of pointless. :)

[ircmaxell]

@ivantcholakov I wrote a blog post recently about that topic: Educate, Don't Mediate.

I think the rationale for replicating a security critical library in you code is flawed. If you don't have the skills to maintain such a library, then you're actively doing your user base harm by including it. Instead, educate the user base on how to do it properly.

The rest of the industry has adopted the component approach, because it has nothing but advantages once you get past the initial learning curve. And that learning curve is not that difficult.

You should be helping users over that learning curve. Not telling them they don't need to learn it because you'll just provide your own alternative.

At the moment all the code is CodeIgniter's only, it is some kind of tradition from the past.

Complacency kills. Not realizing that the past was flawed, and continuing it will actively harm people.

I could care less about the project and the direction that it takes. What I care about is the users who the project will take with them. They deserve to learn the better way, not just the historical one.

The same problem is about the supported PHP version, it is too late for changes.

It was too late for changes 4 years ago when PHP 5 was EOL. That's when it should have been done.

So you say "too late for changes". I say "Better late than never".

[narfbg]

Boy, that escalated quickly ...

@ircmaxell So, are you -1 on this because of the minimum version requirement or because you don't believe such a library should be a framework's part instead of a stand-alone component?

I can agree with the latter.

@sarciszewski It doesn't even come close to what the CI styleguide suggests.

[ivantcholakov]

@ircmaxell

"Educate, Don't Mediate" - Teaching is not my business, I serve my clients. CodeIgniter is not an educational toy, it serves business, it provides solutions. For mature people education is personal investment and personal responsibility.

"If you don't have the skills to maintain such a library, then you're actively doing your user base harm by including it." - I understand every line of the proposed code. When I wrote "qualified persons", I ment a good procedure, a formality. It is good code to be re-checked, but I see that you are reluctant to do so. Thank you very much for sharing your thoughts anyway.

[sarciszewski]

It doesn't even come close to what the CI styleguide suggests.

Oh. Is it a whitespace issue? A capitalization issue? I don't know what I'm overlooking.

[narfbg]

Well, it's a lot of stuff, that's why I said it doesn't come close. :) I'll leave some inline comments ...

[narfbg]

Spaces around the ! character.

We also always put curly braces on a new line.

[defuse]

FWIW I have a side-channel resistant PHP password generator here that you're free to draw inspiration from: https://github.com/defuse/php-passgen

[ircmaxell]

@narfbg The latter. The version discussion was a side-track (I still think it's incredibly important, as you can see from my recent blog post, but unrelated to this issue).

But I think fundamentally the component route is a far safer one, and strongly believe that we don't need duplicate functionality everywhere, especially in a security context.

[sarciszewski]

Okay, I'm going to close this PR and move the discussion towards incorporating an independent component in #3432

[ivantcholakov]

Personally I have no problem with this decision. But something must be done. I saw this https://github.com/bcit-ci/CodeIgniter/wiki/Random-Password-Generator

[ircmaxell]

@ivantcholakov completely fair. But to fix that, educate it. Fix the wiki post, educate users. Teach them. That's how you fix this in the long term...

[sarciszewski]

Eww, yeah. So...

• Should we fall back to php-passgen by @defuse?
• Is there a better alternative library to use?

[ivantcholakov]

@sarciszewski A long series of day-offs is comming, I feel uncomfortable to bother people.

[narfbg]

@sarciszewski I see nothing wrong in linking to either @defuse's or @ircmaxell's password-generating libraries.

However, I also think bundling a copy would be a mistake and I'd rather recommend them via documentation or on that wiki page.

[sarciszewski]

Makes sense to me.

[dmyers2004]

I would rather see these as composer packages. Since CI 3 has composer support already.
I think that we should leverage that much like we where trying with sparks.
Maybe a wiki section for "codeIgniter ready" composer packages or something?
You could add a single line to composer, grab the package, and start using it in 3 minutes (if you're a slow typer and connected over 56k)

[sarciszewski]

"I would rather see these as composer packages."

Sure, let's just encourage more developers to pipe data retrieved over a network to a scripting language interpreter!

(I'm working on making Composer do asymmetric signature verification, but until it's ready I don't recommend using Composer.)

[ircmaxell]

FWIW: composer requires 5.3.2... So isn't adding composer support raising your minimum? ;-)

[dmyers2004]

Good points.
Using composer with CodeIgniter 3 isn't "required" (therefore 5.3.2 isn't required) but it is already in CI 3. So perhaps a disclaimer in the manual?

http://www.codeigniter.com/userguide3/general/autoloader.html?highlight=composer

Perhaps a better approach would be to include "with composer" and "without composer" as part of your "CodeIgniter Ready" instructions? For those concerned about the security issues and/or have a version of PHP which is to old. You lose the autoloader but as long as it's 5.2.4 compatible you should still be able to attach and use it.

[ivantcholakov]

@sarciszewski

This password library should be published at GitHub, it is a well done job that is going to be lost. If you don't have the time, would you agree if I become a maintainer of this library under the MIT license on your name?