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.
Related
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 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.
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
I think I may have found a bug in PHP's crypt() function under Windows.
However: I recognize that it's probably my fault. PHP is used by millions and worked on by thousands; my code is used by tens and worked on by me. (This argument is best explained on Coding Horror.)
So I'm asking for help: show me my fault. I've been trying to find it for a few days now, with no luck.
The setup
I'm using a Windows server installation with Apache 2.2.14 (Win32) and PHP 5.3.2. My development box runs Windows XP Professional; the 'production' server (this is an intranet setup) runs Windows Storage Server 2003. The problem happens on both.
I don't see anything in php.ini related to crypt(), but will happily answer questions about my config.
The problem
Several scripts in my PHP app occasionally hang: the page sits there on 'waiting for localhost' and never finishes. Each of these scripts uses crypt to hash a user's password before storing it in the database, or, in the case of the login page, to hash the entered password before comparing it to the version stored in the database.
Since the login page is the simplest, I focused on it for testing. I repeatedly logged in, and found that it would hang maybe 4 out of 10 times.
As an experiment, I changed the login page to use the plain text password and changed my password in the database to its plain text version. The page stopped hanging.
I saw that PHP's latest version lists this bugfix:
Fixed bug #51059 (crypt crashes when
invalid salt are [sic] given).
So I created a very simple test script, as follows, using the same salt given in an official example:
$foo = crypt('rasmuslerdorf','r1');
echo $foo;
This page, too, will hang, if I reload it like crazy. I only see it hanging in Chrome, but regardless of browser, the effect on Apache is the same.
Effect on Apache
When these pages hang, Apache's server-status page (which I explained here, regarding a different problem) increments the number of requests being processed and decrements the number of idle workers. The requests being processed almost all have a status of 'Sending Reply,' though sometimes for a moment they will show either 'Reading request' or 'keepalive (read).'
Eventually, Apache may crash. When it does, the Windows crash report looks like this:
szAppName: httpd.exe
szAppVer: 2.2.14.0
szModName: php5ts.dll
szModVer: 5.3.1.0 // OK, this report was before I upgraded to PHP 5.3.2,
// but that didn't fix it
offset: 00a2615
Is it my fault?
I'm tempted to file a bug report to PHP on this. The argument against it is, as stated above, that bugs are nearly always my fault.
However, my argument in favor of 'it's PHP's fault' is:
I'm using Windows, whereas most servers use Linux (I don't get to choose this), so the chances are greater that I've found an edge case
There was recently a bug with crypt(), so maybe it still has issues
I have made the simplest test case I can, and I still have the problem
Can anyone duplicate this? Can you suggest where I've gone wrong? Should I file the bug after all?
Thanks in advance for any help you may give.
The bugs 51059 (only about passing invalid inputs) or 50947 (not the same code, 5.3 has new algorithms and features implemented in php, on all platforms) are not related to this problem.
However http://bugs.php.net/bug.php?id=51424 is. I already posted a partial patch there, but it solves most of the possible locks but it is indeed not sufficient. A full fix will be present in the next 5.3 release.
By the way, it is not windows specific but about the threaded SAPI (windows apache 2.2 for example).
This question has now been viewed 128 times and upvoted 9 times. The only answer I've received says it's a bug, and points to one in the PHP bug database. I don't think it's exactly the same one, but it does seem to validate my diagnosis.
Therefore, with some hesitation, I have filed a bug report:
Bug #51666 - Using crypt() makes Apache hang or crash
Thanks to everyone who has looked at this with me - even if you didn't reply, just knowing that others were considering this with me, and not telling me I'm crazy, has been helpful.
Yes. It's a known bug,
http://bugs.php.net/bug.php?id=50947
You can simulate the crypt() result using mcrypt. If you can change your password hash, you should really use hash_hmac(), which is more secure and we have no issues with it On Apache. No experiences on Windows though.