I have been reading up on password encrypting, hashing etc.
I saw this fantastic response https://stackoverflow.com/a/6337021/2823458 and have a couple of questions:
First: Do I need to have access to my web server root to install compatibility libraries? (I assume I do but only have access to PHP 5.3.12 through my host and want to use $password_hash to hash using bcrypt). Which brings me to:
Second: If I have to be root on web server (not happening!) then would I just include Andrew's bcrypt class ad refer to it using (to quote):
$bcrypt = new Bcrypt(15);
$hash = $bcrypt->hash('password');
$isGood = $bcrypt->verify('password', $hash);
Obviously using my password variable in place of 'password'?
Clearly I'm pretty new to developing PHP and trying to ask the right people the right questions, If I'm miles off please point me in the right direction!
bcrypt is not available for PHP 5.3.x. You need to use the library from ex. https://github.com/ircmaxell/password_compat
You don't need to install anything on the server and you don't need to have root access.
Just install the package and start using the library :)
You can either use https://getcomposer.org (Dependency Manager for PHP) or just download and include it in your project.
When you upgrade your server to php 5.5 you can use crypt out of the box, as it has been implemented as part of the language.
Related
I have a question about encoding zip files with password, which is available from PHP v 7.2
When I am encoding ZIP with method
ZipArchive::setEncryptionName
There are argument method which can be:
ZipArchive::EM_AES_128
ZipArchive::EM_AES_192
ZipArchive::EM_AES_256
Can somebody tell me / explain which to use and why?
I am now using ZipArchive::EM_AES_256 because I am expecting that it is the most secure but my colleague is telling me that he cannot open it (his zip software is not even asking for password).
So is there one which will be working in all the cases? We have software which is used by a lot of people in my country and a lot of old people might get these ZIP files and it is required that they could be opened and that every zip file has a password.
Please consider that they might even use Windows XP etc.
As per your comment, Windows cannot decrypt AES-encrypted archives natively, not even in recent versions such as Windows 10 (see why).
PHP v8.0 adds "traditional pkware encryption" that will allow Windows users to work with files without 3rd party apps (7-Zip, etc).
For PHP v7.x, one needs to either rely on shell commands or use a library that supports ZipCrypto encryption algorithm (sometimes called "pkware" - as per the company that created the zip format). Several out of the most popular zip libraries on packagist use ext-zip, so they won't offer PKWARE encryption on PHP 7.x. However nelexa/zip doesn't and it supports pkware encryption.
My server host had php version 5.2.17. I am using a random token and used openssl_random_pseudo_bytes in my function.
openssl_random_pseudo_bytes( $length);
Trying to run this code from Scott's answer.
It is running well on my localhost with higher php version.
Other than upgrading my server php version. What is an alternative function for openssl_random_pseudo_bytes?
Update: Using mt_rand, rand or uniqid, how can I generate secure unique tokens?
As of now, I am using this line of code:
$token = md5(uniqid(rand(), true));
$thetoken = $token.$user_id;
Thank you for any help!
I am using 5.6 but have also been looking for ways to create secure and unique tokens as I am unable to get the openssl_random_pseudo_bytes function to work. I have run across paragonie's random_compat at github which should allow you to use random_bytes() and random_int() (both only available with PHP7). They do say it should be able to be used with older 5.x versions of PHP in theory, though they do suggest updating to a current stable version of php. https://github.com/paragonie/random_compat
Here is a link to another stack overflow answer that suggests using random_bytes() as $token = bin2hex(random_bytes($length));
best practice to generate random token for forgot password
And also the link i found suggesting paragonie's random_compat
https://akrabat.com/random_bytes-in-php-5-6-and-5-5/
https://paragonie.com/blog/2015/07/how-safely-generate-random-strings-and-integers-in-php
the Alternative way for openssl_random_pseudo_bytes(10) is something like this decbin(rand(0,1024)) in php 5.X
Is it possible to encrypt a PHP code file without installing php.in extensions?
I have a script of 5 php file and I want to create a copy to give away with the code protected. So they can access the script from the front-end but the back-end (code) is encrypted. I have found alot of software that allow encryption of php be but they all require installation of php.in extensions.
Is there anything embedded into Php 5.5 that would work similar to MD5 password encryption?
Is there anything embedded into Php 5.5 that would work similar to MD5
password encryption?
Simple answer: No.
Every encoder I have seen (e.g. http://www.ioncube.com/) uses some kind of php extension so your code will need a special enviroment to be executable.
There are some so called obfuscators (e.g. http://www.gaijin.at/olsphpobfuscator.php is free) out there that will not encrypt your code but rename variables and functions/methods so that your code will become much harder to read.
One thing to keep in mind is that debugging errors of encrypted/obfuscated code usually is much harder, even for the developer.
No because MD5 is a one-way hash, you can't reverse the string. The reasons these extensions exist are so that the code can be encrypted and decrypted so that PHP can execute it.
You might want to look at a similar question here: Best solution to protect PHP code without encryption
I just installed xampp, so i can test my website offline. Now i get numerous Undefined index or Undefined variable errors, which i know how to fix. Now logging in works online but with xampp it doesn't work. The code isn't wrong. I imported the database online to offline. I've pin pointed what is wrong but don't know how to solve it.
here is the code where i test if the login details are correct.
$Blowfish_Pre = '$2a$05$';
$Blowfish_End = '$';
$hashed_password = crypt($password, $Blowfish_Pre . $salt . $Blowfish_End);
//check to see if they match
if ($username==$dbusername&&$hashed_password==$dbpassword){
Offline the echoed $hashed_password for the account is $2a$05$CEDaiUETMOTuZ1tzSX1dW.1rmbYfiu1Hf6jnZyJ5DouQOIHEPwXiW
Online the echoed $hashed_password for the account is
$2J7rPSsTYb1Q
I've determined crypt is working differently online then it is offline? Why is this and how can i solve it?
crypt() uses different hash algorithm depending on what the system provides. Starting with PHP 5.3 it "contains its own implementation and will use that if the system lacks of support for one or more of the algorithms."
Your offline version does use blowfish as you can see at the start $2a$. Your online version does use some fallback.
See: http://php.net/manual/en/function.crypt.php
I am unable to comment..yet, so I place this answer in hope I can save some people some time.
I had the same question asked, and the chosen answer led me to the solution. But since it did not provide my ultimate solution, I thought I would share to save someone time.
My wamserver was PHP 5.38
my production server I found out was 5.2x
I simply asked them to upgrade me to the latest version, which was 5.4.22...and that solved the issue. The same code started kicking out 60 character hashes again.
So I would bet that if you have this same occurrence, upgrade the server acting up to the latest version of PHP or something over 5.3 and you should be good.
I think i'm losing my marbles here... I've got a problem on my web site where randomly it stops accepting logins. I've now been able to trace it to crypt() behaving very strangely.
In my database, i've got the crypted version of the users password - so let's say Og12345678.
When the user logs in, they enter their password, I read the salt out of the db and then crypt what they entered and compare - usually this works very well.
So i'm doing crypt($enteredPassword, $saltFromDb) - in this case, the salt would be Og of course. Normally for a given users password crypt works fine.
When things go wrong (and when they do it's a permanent change until I restart Apache) I found that crypt starts returning a DIFFERENT answer for the same input with the same salt.
It's consistent however, i.e. once the system has gone wrong crypt returns the wrong answer but it's always returning the same wrong answer. Repeated refreshes of the page show the same output. The same salt is also in evidence in the newly incorrect crypt result also, so it's not that the salt has gone missing somewhere.
If I then restart Apache and re-run the script without any changes at all, the results from crypt are then back to how they should be.
I appreciate it's not the latest PHP (5.2.8) but would value any views on this including whether it's a known bug fixed in a later version (upgrading PHP is not a happy task with lots of sites some of which still use unfortunate quirks that all need to be re-tested with each upgrade) - if it is a known fixed bug then obviously i'll get it all upgraded ASAP, beyond that it'll probably be easier to outsource the crypt externally since I only use it in one common place for my site.
Any input appreciated.
Matt Peddlesden
--- Update: 11 Mar 2011
Correction to comment previously given about operating system...
- Operating system is Windows Server 2008 SP1 64 bit. Apologies I should have double checked rather than assuming I could remember! Machine is a Dell 2950 8gb Ram, Xeon processors.
I am starting to think along the lines Krtek is suggesting - when the system has gone wonky, if I generate new crypt() (i.e a very simple example where i set a variable to a string, crypt it and then compare with the crypt) - all works great. When I restart the server, again it's all back to the previous calculations again. So I am definitely leaning towards something that is changing the algorithm used to calculate the crypt() result... any thoughts on what might cause this to happen? I printed out the values of the CRYPT_STD_DES etc and they don't change between restarts.
Anyone got any clues on what might cause this to happen?
Whatever it was seemed to happen twice in one day yesterday, most odd.
Thanks for the answers thus far.
--- Update: 16 Mar 2011
Just wanted to provide another update.
This is still happening, still no further understanding of why.
In case anyone comes across this in the future, I think my solution going forwards is going to be to do some nasty hack to push all the crypt() executions out to an external C# application and stop having to rely on PHP to do them. Something is going wrong somewhere and at this point the only solution I can see is to remove it from the equation entirely.
Of course if it still happens, that will be interesting to know too! :)
Thanks all.
Why are you reading the salt? And how are you getting the salt? Different algorithms use different methods for including the salt in the output.
Just use the whole output of the crypt function as the second argument:
$crypted='Og12345678';
if (crypt($_POST['password'], $crypted)==$crypted) {
....
And single pass DES? Really?
Last time I looked, the PHP crypt implementation would call the crypt() function provided by the system - so if it has broekn then its more likely to be your OS than PHP - but you didn't say what your OS is.
It might be the Suhosin PHP security patch affecting your crypt() function. It alters a lot of the encryption/random methods and may be the the cause of your problem.
Check a phpinfo() and see if 'suhosin' is anywhere on the page. If it's there, look into disabling some of it's features in the php config.
i had the same problem with crypt... I had that login-check working on 2 servers, but when i transfer it to the newest one it eventually stop working. I walk around it with md5 encryption as follows:
In register.php
$encrypted = md5($_POST["pass"]);
...
And then in login.php
$password = md5($_POST["password"]);
if ($password == $row["hash"])
{
// remember that user's now logged in by storing user's details in session
$_SESSION["id"] = $row["id"];
$_SESSION['username'] = $_POST['username'];
$_SESSION['logged'] = 'Yes';
// redirect to homepage
redirect("index.php");
}
I hope that helps :)
I faced the same problem. Since moving my vTigerCRM installation to local machine, user login with previously stored passwords started failing. It seems like crypt() is returning different hashes on different environments with the same arguments:
On local environment:
SYSTEM: Windows NT 6.1 build 7601 (Business Edition Service Pack 1) i586
PHP: 5.3.5
crypt('hello world','$1$ad0000000'):
$1$ad00000008tTFeywywdEQrAl9QzV.M1
On production environment:
SYSTEM: Linux 2.6.18-338.9.1.el5.lve0.8.32 #1 x86_64
PHP: 5.3.5
crypt('hello world','$1$ad0000000'):
$1$ad000000$8tTFeywywdEQrAl9QzV.M1