What way is the best way to hash a password? [duplicate] - php

This question already has answers here:
Secure hash and salt for PHP passwords
(14 answers)
Closed 9 years ago.
I'm working on a website that should be very safe for the users, so I need the hash the passwords. Usually I'm using the MD5, but I read that it doesn't safe anymore. So I tried PHPass, but then I read that it also has been cracked. So I tried password_hash() of PHP 5.5, but I use HostGator, and the PHP there is 5.4. Also I want to be able to add salt without knowing it (like time() * userid()), like in the password_hash().
The hash strength is very important to me because I want to be 100% sure that my users are safe. So is there a way that very safe and not something like SHA that will be hacked soon?

Use this library which provides forward compatibility with the password_* functions.
Example usage :
require_once("password.php"); // imports the library, assuming it's in the same directory as the current script
$password = "HelloStackOverflow"; // example password
$hash = password_hash($password, PASSWORD_BCRYPT); // here's the hash of the previous password
$hash = password_hash($password, PASSWORD_BCRYPT, array("cost" => 10)); // you can set the "complexity" of the hashing algorithm, it uses more CPU power but it'll be harder to crack, even though the default is already good enough
if (password_verify($password, $hash)) { // checking if a password is valid
/* Valid */
} else {
/* Invalid */
}

PHP comes with built-in hash algorithms such as MD5, SHA1 etc. However, from a security perspective, it's not recommended to use these functions to hash passwords as they can be easily broken via bruteforce attack using tools like Passwordpro.
It's better if you use salting as a way to secure your passwords. Below is an example :
$password = 'yourpassword';
$salt = 'randomstr!ng';
$password = md5($salt.$password);
An even better way of generating the salt is by hashing it first:
$password = 'yourpassword';
$salt = sha1(md5($password));
$password = md5($password.$salt);
The advantage is that this way the salt value is random and it changes for each password, making it nearly impossible to break.

Take a look at http://php.net/manual/de/function.crypt.php
You should consider using salts to prevent rainbow table attacks
You can find a tutorial here: http://www.yiiframework.com/wiki/425/use-crypt-for-password-storage/

I tink that the best thing is using a library to manage passwords.
If you cannot use php 5.5 you can try this library that works for php5.3+, have a look at this project:
http://rchouinard.github.io/phpass/

Related

best algorithm to store passwords in 2016

Actually I read many post related to the algorithm for use like md5, sha1 and so on. But I am still not sure which one is the secure and the best one to use nowadays. I am beginner with web development and I am asking all of the best programmers around the world to teach and show me. I hope you guys can give me the choice and example for using it. Thank You
Incidentally: How to safely store your users' passwords in 2016.
Your choices are:
Argon2 (requires PHP 7.2 or a PHP extension)
Scrypt (requires PHP extension)
Bcrypt
If you really need to, also feel free to consider PBKDF2.
The old standby: Bcrypt
Given that you're a beginner, you should be writing your password validation like this:
// Creating your hashed password:
$hash = password_hash($userPassword, PASSWORD_DEFAULT);
// Checking a user-supplied password against a stored hash:
if (password_verify($userPassword, $hash)) {
// Login successful.
if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
// Recalculate a new password_hash() and overwrite the one we stored previously
}
}
Downside to bcrypt:
Passwords over 72 characters are truncated.
Passwords with a NUL byte will truncate.
A stop-gap that works around these limitations is built into Password Lock: It pre-hashes passwords with SHA384 then base64-encodes the raw hash before passing to PHP's password API.
First, create an encryption key and store it outside your document root. (Otherwise, a hacker can just steal the key.)
$newKey = \Defuse\Crypto\Key::createNewRandomKey();
file_put_contents(
'/outside/document/root/enckey.txt',
$newKey->saveToAsciiSafeString()
);
Now, you can use this key in conjunction with your passwords:
$key = Key::loadFromAsciiSafeString(
file_get_contents('/outside/document/root/enckey.txt')
);
// Hashing a password with PasswordLock:
$storeMe = PasswordLock::hashAndEncrypt($_POST['password'], $key);
// Verifying a password with PasswordLock:
if (PasswordLock::decryptAndVerify($_POST['password'], $storeMe, $key)) {
// Success!
}
You can now use Argon2 with password_hash() in PHP 7.2
The new standard: Argon2 (via Libsodium)
Unless you're on PHP 7.2 or higher, you'll need to install libsodium and the PHP extension to use Argon2. Password hashing is one of the features that is not provided by sodium_compat.
// Password hashing:
$hash_str = sodium_crypto_pwhash_str(
$password,
SODIUM_CRYPTO_PWHASH_OPSLIMIT_INTERACTIVE,
SODIUM_CRYPTO_PWHASH_MEMLIMIT_INTERACTIVE
);
// Password verification:
if (sodium_crypto_pwhash_str_verify($hash_str, $password)) {
// recommended: wipe the plaintext password from memory
sodium_memzero($password);
// Password was valid.
} else {
// recommended: wipe the plaintext password from memory
sodium_memzero($password);
// Password was invalid.
}
Intermediate: Scrypt
You'll need the scrypt extension which is available through PECL:
pecl install scrypt
echo "extension=scrypt.so" > /etc/php5/mods-available/scrypt.ini
php5enmod scrypt
Once that's installed, using it is fairly straightforward:
// Hashing:
$hash = \Password::hash($userProvidedPassword);
// Validation:
if (\Password::check($userProvidedPassword, $hash)) {
// Logged in successfully.
}
The only reason to really use scrypt is compatibility; at this point, go with either Argon2 or bcrypt.
Acceptable but not Great: PBKDF2
I highly recommend going with Defuse Security's cross-platform Password Hashing library if you need PBKDF2. (You should consider just using password_*, however!)
$hash = PasswordStorage::create_hash($password);
if (PasswordStorage::verify_password($password, $hash)) {
// Success
}
Any of the above choices are acceptable. Argon2 is probably the most secure, but it's not widely available in PHP yet. Anything absent from this list should be regarded with a healthy dose of skepticism.
Important is, that the algorithm offers a cost factor, which controls the necessary time to calculate a hash. The more time you can invest in calculating a single hash, the more expensive brute-forcing will become (e.g. 100 Giga MD5 per second vs 10 BCrypt per second).
Today recommended algorithms are BCrypt, PBKDF2 and SCrypt. The algorithm BCrypt is supported by PHP, a wrapper function takes care of the generation of a salt and is future proof.
// Hash a new password for storing in the database.
// The function automatically generates a cryptographically safe salt.
$hashToStoreInDb = password_hash($password, PASSWORD_DEFAULT);
// Check if the hash of the entered login password, matches the stored hash.
// The salt and the cost factor will be extracted from $existingHashFromDb.
$isPasswordCorrect = password_verify($password, $existingHashFromDb);

Using Md5 for password hash in Auth component of Cakephp 2.x

I have an existing website, built using CakePhp 1.3. In that website I have used MD5 algorithm for the password hash.
Now I want to upgrade my CakePhp version to 2.3.5, but I'm unable to use MD5 for the password hash.
I would like to know why I can't use MD5 in CakePhp 2.x. ?
Don't use md5 for passwords
md5 is not an appropriate hashing algorithm for hashing passwords, don't use it. There are many, many references which explain why - including the php manual:
Why are common hashing functions such as md5() and sha1() unsuitable for passwords?
Hashing algorithms such as MD5, SHA1 and SHA256 are designed to be very fast and efficient. With modern techniques and computer equipment, it has become trivial to "brute force" the output of these algorithms, in order to determine the original input.
Because of how quickly a modern computer can "reverse" these hashing algorithms, many security professionals strongly suggest against their use for password hashing.
How to change the default hash algorithm
You can change the default hashing algorithm using setHash, a recommended hash algorithm for passwords is blowfish:
Security::setHash('blowfish');
How to handle existing passwords
If you really want to, you can just change setHash to use md5.
But that's not a good idea.
Don't compromise the security of a new/updated application just to accommodate the poor security of the old one. Instead of using the same hash algoritm (and salt) as the previous application you can use logic such as the following (pseudo-ish code):
$username = $this->data['User']['username'];
$plainText = $this->data['User']['password'];
$user = current($this->User->findByUsername($username));
Security::setHash('blowfish');
$blowfished = Security::hash($plainText, 'blowfish', $user['password']);
if ($blowfished === $user['password']) {
return true; // user exists, password is correct
}
$oldSalt = Configure::read('configure.this');
$md5ed = Security::hash($plainText, 'md5', $oldSalt);
if ($md5ed === $user['password']) {
$this->User->id = $user['id'];
$blowfished = Security::hash($plainText);
$this->User->saveField('password', $blowfished);
return true; // user exists, password now updated to blowfish
}
return false; // user's password does not exist.
This kind of logic is not complex, and prevents the need to continue using a bad hash algorithm.
I do not recommend the use of this code in any scenario, ever. MD5 is a horrible hashing algorithm for security as it is too resource-light to discourage cracking. It also has known vulnerabilities. Use bcrypt or SHA-512.
To do this, you can edit AppController.php like this:
<?php
// AppController.php
public function beforeFilter()
{
Security::setHash('md5');
}
?>
However, this is not recommended as MD5 is a very poor password hashing algorithm. You're far better adding a function to allow users to login with existing md5 passwords, encouraging them to upgrade to the new hash, and not allowing any new users to set MD5 passwords.
If, instead you want to use a secure function like bcrypt, you can do the following:
<?php
// AppController.php
public function beforeFilter()
{
Security::setHash('blowfish');
}
?>
When comparing plaintext values to hashes, you have to pass the original hash as the salt value in order to retain cost parameters etc:
$newHash = Security::hash($newPassword, 'blowfish', $storedPassword);

How do I update my security in my login script from MD5 to something more secure? [duplicate]

This question already has answers here:
How do you use bcrypt for hashing passwords in PHP? [duplicate]
(11 answers)
Closed 9 years ago.
I have a PHP login script with salt on the database, but in my register script I see:
$qry = "INSERT INTO accounts(username, firstname, lastname, password) " .
VALUES('$username','$fname','$lname','" . md5($_POST['password']) . "')";
and for the login:
$qry="SELECT * FROM accounts WHERE username='$username' AND password='" .
md5($_POST['password']) . "'";
Is there some code that can replace the MD5? Something more secure?
I've heard of SHA1 or something.
Short answer
Use bcrypt not md5 or sha1
Longer answer
Using the crypt() is hard. There is a new PHP password hashing API coming in PHP version 5.5, you can read about it here:
https://gist.github.com/nikic/3707231
It uses bcrypt and makes the whole process very easy. Of course php 5.5 isn't ready yet, so in the meantime there is a library to provide this new API right now:
https://github.com/ircmaxell/password_compat
Edit: See this thread for a much more thorough answer on the topic:
How do you use bcrypt for hashing passwords in PHP?
In consideration of #jszbody post, you should also update your password field to tell you want scheme you're using.
Where you have an MD5 hash now, you might have just "BAC232BC1334DE" or something.
When you go to SHA or whatever, you should change it to: "SHA:YOURSHAHASHHERE".
Because you can't change any of your existing passwords right now. This will make it more backward compatible, since now you can support both schemes.
Since you get the original password during login, you can dynamically upgrade your passwords in place as people login.
You get your user record, check the password. If there is no scheme, use MD5, and compare passwords. If they're correct (i.e. they can log in), you can update their old MD5 password to the new SHA password.
Also, it seems you are not salting your passwords. You must salt your passwords so that when Mary Sue uses "ilovekittens" for her password, and Big Jake Mahoney uses "ilovekittens" as his password, you don't get the same has for identical passwords.
You can store the salt in the password as well: "SHA:RANDOMSALTCHARACTERS:YOURSALTEDHASHHERE".
Salting is highly recommended. Unsalted, it pretty much doesn't matter a whole lot what scheme you use.
Try using the following class:
<?php
class PassHash {
// blowfish
private static $algo = '$2a';
// cost parameter
private static $cost = '$31';
// mainly for internal use
public static function unique_salt() {
return substr(sha1(mt_rand()),0,22);
}
// this will be used to generate a hash
public static function hash($password) {
return crypt($password,
self::$algo .
self::$cost .
'$' . self::unique_salt());
}
// this will be used to compare a password against a hash
public static function check_password($hash, $password) {
$full_salt = substr($hash, 0, 29);
$new_hash = crypt($password, $full_salt);
return ($hash == $new_hash);
}
}
?>
include it in your page with the following:
include_once('passhash.class.php');
Hash the password by:
PassHash::hash("test");
And check it with:
if (PassHash::check_password($databasepassword, $formpassword)){
// do stuff
}
This function uses Blowfish encryption. For more information on Blowfish goto PHP.net/crypt
Blowfish is considered the most effective yet most powerfull way of encrypting passwords. Do not use MD5 or SHA1 without using a salt!

Encrypt password before storing in database?

I have a password being passed from my iPhone app to the database via a php script, user.php.
The variable $pass is populated by the following:
$pass = str_replace("'", "", $_REQUEST['pass']);
How can I encrypt this before it's inserted into my database? I've read a little about the different techniques, but looking for the best way to manage this.
Thanks to everyone.
While the answer below is technically still correct, php has new recommendations with regards to the hashing algorithms to use. Their recommendation, as of php >= 5.5.0, is to use the password_hash and password_verify functions to hash and verify hashed passwords . As an added benefit, these functions automatically include an individualized salt as part of the returned hash, so you don't need to worry about that explicitly.
If you don't care about retrieving the actual password's value (from the database encrypted value), you can run a one-way hash algorithm on it (such as sha1). This function will return a specific length string (hash) which cannot be used to find the original string (theoretically). It is possible that two different strings could create the same hash (called a collision) but this shouldn't be a problem with passwords.
Example:
$pass = sha1($_REQUEST['pass']);
One thing, to make it a little more secure is to add a salt to the hash and run the hash function again. This makes it more difficult to generate a password hash maliciously since the salt value is handled server-side only.
Example:
$pass = sha1(sha1($_REQUEST['pass']).sha1("mySalt#$#(%"));
Use php's crypt library. Md5 is not encryption, it is hashing.
Also, salt your passwords. Why?
This answer
Another good answer
First, you should create a random user salt. Then you should store that and the password hash in the database.
$salt = md5(unique_id().mt_rand().microtime());
$pass = sha1($salt.$_REQUEST['pass']);
and save the $salt and $pass in the database. Then when they go to login you look up their row and check the hash:
$user = query('SELECT * FROM `user` WHERE username = ?', array($_REQUEST['username']));
if($user)
{
// If the password they give maches
if($user->pass === sha1($user->salt. $_REQUEST['pass']))
{
// login
}
else
{
// bad password
}
}
else
{
// user not found
}
Creating a user salt for each account insures rainbow tables are useless and anyone that broken into your server would have to brute-force each password.
Use crypt with some salt. Such as
$user = strip_tags(substr($_REQUEST['user'],0,32));
$plain_pw = strip_tags(substr($_REQUEST['pass'],0,32));
$password = crypt(md5($plain_pw),md5($user));
as on http://www.ibm.com/developerworks/opensource/library/os-php-encrypt/
Most basic: Hash it with MD5 or SHA1
$newpass = md5($_REQUEST['pass']);
or
$newpass = sha1($_REQUEST['pass']);
Recently I started storing the username hashed as well, so login attempts are secure using only hashed data for comparisons.
You can "salt" the hashes with extra data so if they are compromised, it's value cannot be found (try googling some simple hashed words).. i.e. use a site-wide string just to alter the standard hash like md5("mySiteSalt!!" . $_REQUEST['pass']); or something more advanced.
You should use SHA1 to hash your passwords for storage in the database. It's the simplest, yet most effective way to store passwords:
$password = sha1($password);
It's also exceptionally safe. Though the integrity of it is beginning to creep, it's rather easy to upgrade this function to SHA-256 (which is incredibly secure).
To find out why md5, sha1 and their speedy friends might not be a good idea, you should read the post Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes by Thomas Ptacek. The gist:
Finally, we learned that if we want to
store passwords securely we have three
reasonable options: PHK’s MD5 scheme,
Provos-Maziere’s Bcrypt scheme, and
SRP. We learned that the correct
choice is Bcrypt.
Note: it's PHK, not php.

How can I store my users' passwords safely?

How much more safe is this than plain MD5? I've just started looking into password security. I'm pretty new to PHP.
$salt = 'csdnfgksdgojnmfnb';
$password = md5($salt.$_POST['password']);
$result = mysql_query("SELECT id FROM users
WHERE username = '".mysql_real_escape_string($_POST['username'])."'
AND password = '$password'");
if (mysql_num_rows($result) < 1) {
/* Access denied */
echo "The username or password you entered is incorrect.";
}
else {
$_SESSION['id'] = mysql_result($result, 0, 'id');
#header("Location: ./");
echo "Hello $_SESSION[id]!";
}
The easiest way to get your password storage scheme secure is by using a standard library.
Because security tends to be a lot more complicated and with more invisible screw up possibilities than most programmers could tackle alone, using a standard library is almost always easiest and most secure (if not the only) available option.
The new PHP password API (5.5.0+)
If you are using PHP version 5.5.0 or newer, you can use the new simplified password hashing API
Example of code using PHP's password API:
<?php
// $hash is what you would store in your database
$hash = password_hash($_POST['password'], PASSWORD_DEFAULT, ['cost' => 12]);
// $hash would be the $hash (above) stored in your database for this user
$checked = password_verify($_POST['password'], $hash);
if ($checked) {
echo 'password correct';
} else {
echo 'wrong credentials';
}
(In case you are still using legacy 5.3.7 or newer you can install ircmaxell/password_compat to have access to the build-in functions)
Improving upon salted hashes: add pepper
If you want extra security, the security folks now (2017) recommend adding a 'pepper' to the (automatically) salted password hashes.
There is a simple, drop in class that securely implements this pattern, I recommend:
Netsilik/PepperedPasswords
(github).
It comes with a MIT License, so you can use it however you want, even in proprietary projects.
Example of code using Netsilik/PepperedPasswords:
<?php
use Netsilik/Lib/PepperedPasswords;
// Some long, random, binary string, encoded as hexadecimal; stored in your configuration (NOT in your Database, as that would defeat the entire purpose of the pepper).
$config['pepper'] = hex2bin('012345679ABCDEF012345679ABCDEF012345679ABCDEF012345679ABCDEF');
$hasher = new PepperedPasswords($config['pepper']);
// $hash is what you would store in your database
$hash = $hasher->hash($_POST['password']);
// $hash would be the $hash (above) stored in your database for this user
$checked = $hasher->verify($_POST['password'], $hash);
if ($checked) {
echo 'password correct';
} else {
echo 'wrong credentials';
}
The OLD standard library
Please note: you should not be needing this anymore! This is only here for historical purposes.
Take a look at: Portable PHP password hashing framework: phpass and make sure you use the CRYPT_BLOWFISH algorithm if at all possible.
Example of code using phpass (v0.2):
<?php
require('PasswordHash.php');
$pwdHasher = new PasswordHash(8, FALSE);
// $hash is what you would store in your database
$hash = $pwdHasher->HashPassword( $password );
// $hash would be the $hash (above) stored in your database for this user
$checked = $pwdHasher->CheckPassword($password, $hash);
if ($checked) {
echo 'password correct';
} else {
echo 'wrong credentials';
}
PHPass has been implemented in some quite well known projects:
phpBB3
WordPress 2.5+ as well as bbPress
the Drupal 7 release, (module available for Drupal 5 & 6)
others
The good thing is that you do not need to worry about the details, those details have been programmed by people with experience and reviewed by many folks on the internet.
For more information on password storage schemes, read Jeff`s blog post: You're Probably Storing Passwords Incorrectly
Whatever you do if you go for the 'I'll do it myself, thank you' approach, do not use MD5 or SHA1 anymore. They are nice hashing algorithm, but considered broken for security purposes.
Currently, using crypt, with CRYPT_BLOWFISH is the best practice.
CRYPT_BLOWFISH in PHP is an implementation of the Bcrypt hash. Bcrypt is based on the Blowfish block cipher, making use of it's expensive key setup to slow the algorithm down.
Your users will be much safer if you used parameterized queries instead of concatenating SQL statements. And the salt should be unique for each user and should be stored along with the password hash.
A better way would be for each user to have a unique salt.
The benefit of having a salt is that it makes it harder for an attacker to pre-generate the MD5 signature of every dictionary word. But if an attacker learns that you have a fixed salt, they could then pre-generate the MD5 signature of every dictionary word prefixed by your fixed salt.
A better way is each time a user changes their password, your system generate a random salt and store that salt along with the user record. It makes it a bit more expensive to check the password (since you need to look up the salt before you can generate the MD5 signature) but it makes it much more difficult for an attacker to pre-generate MD5's.
With PHP 5.5 (what I describe is available to even earlier versions, see below) around the corner I'd like to suggest to use its new, built-in solution: password_hash() and password_verify(). It provides several options in order to achieve the level of password security you need (for example by specifying a "cost" parameter through the $options array)
<?php
var_dump(password_hash("my-secret-password", PASSWORD_DEFAULT));
$options = array(
'cost' => 7, // this is the number of rounds for bcrypt
// 'salt' => 'TphfsM82o1uEKlfP9vf1f', // you could specify a salt but it is not recommended
);
var_dump(password_hash("my-secret-password", PASSWORD_BCRYPT, $options));
?>
will return
string(60) "$2y$10$w2LxXdIcqJpD6idFTNn.eeZbKesdu5y41ksL22iI8C4/6EweI7OK."
string(60) "$2y$07$TphfsM82o1uEKlfP9vf1fOKohBqGVXOJEmnUtQu7Y1UMft1R4D3d."
As you might see, the string contains the salt as well as the cost that was specified in the options. It also contains the algorithm used.
Therefore, when checking the password (for example when the user logs in), when using the complimentary password_verify() function it will extract the necessary crypto parameters from the password hash itself.
When not specifying a salt, the generated password hash will be different upon every call of password_hash() because the salt is generated randomly. Therefore comparing a previous hash with a newly generated one will fail, even for a correct password.
Verifying works like this:
var_dump(password_verify("my-secret-password", '$2y$10$BjHJbMCNWIJq7xiAeyFaHOGaO0jjNoE11e0YAer6Zu01OZHN/gk6K'));
var_dump(password_verify("wrong-password", '$2y$10$BjHJbMCNWIJq7xiAeyFaHOGaO0jjNoE11e0YAer6Zu01OZHN/gk6K'));
var_dump(password_verify("my-secret-password", '$2y$07$TphfsM82o1uEKlfP9vf1fOKohBqGVXOJEmnUtQu7Y1UMft1R4D3d.'));
var_dump(password_verify("wrong-password", '$2y$07$TphfsM82o1uEKlfP9vf1fOKohBqGVXOJEmnUtQu7Y1UMft1R4D3d.'));
I hope that providing these built-in functions will soon provide better password security in case of data theft, as it reduces the amount of thought the programmer has to put into a proper implementation.
There is a small library (one PHP file) that will give you PHP 5.5's password_hash in PHP 5.3.7+: https://github.com/ircmaxell/password_compat
That's fine with me. Mr Atwood wrote about the strength of MD5 against rainbow tables, and basically with a long salt like that you're sitting pretty (though some random punctuation/numbers, it could improve it).
You could also look at SHA-1, which seems to be getting more popular these days.
I want to add:
Don't limit users passwords by length
For compatibility with old systems often set a limit for the maximum length of the password. This is a bad security policy: if you set restriction, set it only for the minimum length of passwords.
Don't send user passwords via email
For recovering a forgotten password you should send the address by which user can change the password.
Update the hashes of users passwords
The password hash may be out of date (parameters of the algorithm may be updated). By using the function password_needs_rehash() you can check it out.
Here's a PHP + CouchDB.apache.org login system that doesn't store plaintext passwords.
According to the advice that I've read, it should be totally secure.
CMS login code : https://github.com/nicerapp/nicerapp/blob/24ff0ca317b28c1d91aee66041320976a6d76da7/nicerapp/boot.php#L56
calls
https://github.com/nicerapp/nicerapp/blob/24ff0ca317b28c1d91aee66041320976a6d76da7/nicerapp/functions.php#L171
app(s) specific business code :
https://github.com/nicerapp/nicerapp/blob/24ff0ca317b28c1d91aee66041320976a6d76da7/nicerapp/ajax_login.php#L87
calls
https://github.com/nicerapp/nicerapp/blob/24ff0ca317b28c1d91aee66041320976a6d76da7/nicerapp/functions.php#L230
which in turn calls :
https://github.com/nicerapp/nicerapp/blob/2d479b3e22dce9e7073525481b775f1bf7389634/nicerapp/apps/nicer.app/webmail/recrypt.php#L2
and to edit the webmail app config data into the database :
https://github.com/nicerapp/nicerapp/blob/main/nicerapp/apps/nicer.app/webmail/ajax_editConfig.php

Categories