Welcome Guest, Not a member yet? Register   Sign In
Encryption
#1

Hi,

I have checked the code in Github, I realize you have built a lot of featured, but the Encryption is not built in. I expect it is built as soon as possible. Because, in basic site, we still need encrypt a lot of things like password, license, permission,...etc. Maybe, I have a little selfish for my project, but I think this feature is expected from a lot of fan.

Thanks!
Reply
#2

The module was written, but we could not get agreement on it, and it was withdrawn.
The module implemented needs CI7.2, with the libsodium bundled, to work as intended.
So, it is ready to roll - not sure if it will make it into the initial release or not.
Reply
#3

Hi, Thanks for information, I plan to build a project, and I love it is built with CI4, hope you get agreement on Encryption library.
Reply
#4

I think you may be confusing encryption with hashing. For many things, like the passwords you mentioned, you do NOT want to use encryption - you want to hash it, and PHP already has features baked in for that: password_hash, password_verify, etc.
Reply
#5

Hi, I have some example about the password.
- I need to storage a hosting(server) password, of course I want to show it to a client, so I need to encrypt it and storage it in the database, then decrypt to show it in front-end.
- I want to storage the password histories of the client, to compare it, that you know for some security reason I need decrypt it to compare.

I think you try to think about the simple sites,you'r right, they don't need to do like that. If you really don't agree on password encryption, I think I should look for another framework. And that is the weakness and lack of flexibility of the framwork you are trying to build.
Reply
#6

You could always use libsodium directly ... https://paragonie.com/book/pecl-libsodium
I could not find any other framework using it, so you might end up coming back to CI4 once our minimum PHP version hits 7.2 Undecided
Reply
#7

(This post was last modified: 01-23-2018, 09:20 PM by kilishan.)

I'm sorry you see it that way. I'm not sure what best practice would be for the first example, but for the second example you should still hash it. Hash the password you need to check, and then compare it (using password_hash) against the remaining history of passwords. Security best practices with anything password-like are to use a one-way hash so that it's impossible to decrypt it. That's not a personal opinion.

As Jim hinted at, we implemented a couple different tries at fixing the potential security edge cases but kept finding other security issues with. So, instead of releasing something with known security flaws, we opted against including it. Especially with 7.2 including libsodium out of the box and knowing it wouldn't be long before we could  include a wrapper on that. If you truly need encryption, you're encouraged to use libsodium for your project.

Oh - and NIST's current password guidelines no longer recommend comparing keeping your password against a history of passwords, or forcing repeated password changes, etc. I realize that many enterprise companies still want it, but I agree with NIST here that it causes more security holes than it patches up due to human psychology. I actually have to prepare an estimate for an existing client to implement the older composition, history, etc style security "upgrades" on his site. Not looking forward to it. Smile
Reply
#8

Yes, you'r right, thanks for your informations. But still hope you have a solution about the Encryption libary. I prefer use your interface, it will be clearly to show the code, someone else easy to read and look for a document.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB