I'm wondering how to use Hash::needsRehash() as I'm struggling to see using the documentation exactly what it's for.
if (Hash::needsRehash($hashed)) {
$hashed = Hash::make('plain-text');
}
What exactly causes Hash::needsRehash() to return true or false, does it return true if the hashed password is in another hash (such as MD5, SHA1 etc)?
In the case that your database is full of hashes in another algorithm and Hash::needsRehash() returns true, how would you rehash the users password so that it's they're up to date? You can't rely on the "login" password because it needs to be compared first to validate, right?
I guess maybe I'm overthinking things but I'm confused right now. Luckily my users passwords are using password_hash() anyway so shouldn't be a problem.
Hash::needsReHash() just calls php's built-in password_needs_rehash function. A helpful comment in the docs is:
// Check if a newer hashing algorithm is available
// or the cost has changed
if (password_needs_rehash($hash, PASSWORD_DEFAULT, $options)) {
So Hash::needsReHash() will return false if and only if hashing algorithm has changed (since you're not passing any options such as cost).
As for how and when to use this, you can only rehash a user's password when you have it -- e.g. when they're logging in. So during the login process, you check if their stored password's algorithm differs from your current algorithm, and if so, you replace their stored password hash with a new one.
This seems to be how to do it in Laravel 5.6
Put this in your LoginController:
protected function authenticated(Request $request, $user) {
if (Hash::needsRehash($user->password)) {
$user->password = Hash::make($request->password);
$user->save();
}
}
https://laravel.com/docs/5.6/hashing#basic-usage
The method returns true when PHP is updated and a new/better default algorithm was added or any other parameters changed. This lets you automatically take advantage of it without updating your code.
This method is used when a user is logging in as that is the only time you have access to the plain-text password. After confirming it is correct according to the old hash, you take the plain text password, rehash it, and put it back into the database for future use.
For a hypothetical example, lets say that right now the algorithm is md5() 10k times. In PHP7, it was updated to sha512() 15k times. If the hash is in the $count|$algo|$hash format, the method can tell when a hash is outdated. Since the old algorithm was not removed, you can still validate the password with old parameters before rehashing.
Note: obviously using md5()/sha512() is a bad idea. I'm just using them as examples.
Related
I created user and I gave him password 'secret'.
The hash that was generated by the registration process is
$10$TKh8H1.PfQx37YgCzwiKb.KjNyWgaHb9cbcoQgdIVFlYg7B77UdFm
I wanted to generate it in the code so I used Hash::make('secret') and I got:
$2y$10$Hnbg7DCp2VObns4cbr580uo9VTYgzJF2BSNSpA7S8BYjkAgfUlH.G
finally I used bcrypt('secret') and I got:
$2y$10$5g1bhkHB7kRk8SkM3yS/YOifsEesjZ31YeYnRlE.bxSBmZutVCuui
These are all different hashes, How can I generate one that would let me change password inside my code?
It's because bcrypt doesn't work as SHA-256, it uses a key that would change the result of the hash itself for the same string.
In Laravel, you can use Hash::check('plain-text', $hashedPassword) to check the password, but you will never have the same result for the same password. check here
You can use bcrypt(secret") and leave it at laravel and test it (everything is working).
It works as intended, bcrypt doesnt always generate the same hash. Laravels Hash::check() function will return true for any valid hash of the given password.
For mor informations, look here: https://stackoverflow.com/a/8468936/6622577
Bycrypt is a more secure password hashing algorithm. Unlike md5() or SHA1() bycrypt does not always generate the same hashed value for a specific string.
So when you are storing the hashed password in the database you will use
$password = bcrypt($input['password']);
Afterwards, when you wish to check at the time of login you simply set the plain-text password (As you might be getting it from user input) and run a function called Auth::attempt() to match the password.
$userdata = array(
'username' => $input['username'],
'password' => $input['password'],
);
if (Auth::attempt($userdata)) {
// Password matched
}
And if you want to explicitly check the plain-text password corresponding to its hash then use Hash::check() as below:
Hash::check('plain-text-password', 'hashed-password);
I am trying to use my stored passwords from Laravel 4 in a fresh Phalcon Installation. I have no idea whether this is possible and tried it this way in the SessionController of the Phalcon sample-apllication INVO:
#$password = sha1($password);
$password = password_hash($password, PASSWORD_BCRYPT);
Can I use another Hash-Algorythm in phalcon, that fits to Laravel 4 Passwords, or can I convert the hashes somehow?
You should be able to use laravel hashses - all you need to do is to check how Laravel is creating and checking them.
Check this code from BCryptHasher::make() and this for validating.
The problem is that in Laravel this algorithm is a bit different. First is obtaining user from database then checking if password is the same with password_verify. While in INVO you first hash the given password and then you search for a user with given email and hash - if it finds anything then it can log user. Below should do the trick knowing the $cost value from Laravel settings (class defaults to 10).
$password = password_hash($value, PASSWORD_BCRYPT, array('cost' => $cost));
Edit: while above would be true for SHA1 & similar. The INVO code should be changed to match the login algorithm in Laravel and BCrypt itself:
$user = Users::findFirst(array("email = :email: AND active='Y'", 'bind' => array('email' => $email));
if ($user != false && password_verify($user->password, $this->request->getPost('password'))) {
// login user
}
Laravel is using BCrypt for a reason - it is generally very good choice for hashing so you should stick to it.
Anyway you could write a password migration which will do upon each user successful login:
validate user password using old hashing algorithm
checks if User has migrated it's password (ie by checking some database field - or separated table)
hash given password with new algorithm
store new hash and update user table (with information that hash has been changed)
Which is rather complicated and should be needed only when migrating to "better" algorithm.
I'm currently going over my user registration code. The part I'm focusing on right now is the password hashing part.
What I do is get a static_salt from a config file, and use mt_rand() to generate a dynamic_salt. What I want to do is have this dynamic_salt stored in my database.
But if I pass the dynamic_salt() method to the create method in order to send it to the salt column of a table in my database it will just run the method again and create a different result from the one produced in my hashed() method.
What would be the best way to achieve what I'm trying to achieve, could you show me an example if possible?
public function create() {
$dbcolumn->password = $this->hashed();
$dbcolumn->salt = $this->dynamic_salt;
$this->db->insert('users', $dbcolumn);
}
public function dynamic_salt() {
$get_dynamic_salt = mt_rand();
return $get_dynamic_salt;
}
public function hashed() { //hashing method, that also makes
// sha1 and salt password
$static_salt = $this->config->item('encryption_key'); //grab static salt from config file
$dynamic_salt = $this->dynamic_salt();
$password = $this->encrypt->sha1($this->input->post('password')); //encrypt user password
$hashed = sha1($dynamic_salt . $password . $static_salt);
return $hashed;
}
I recommend that you don't use a dynamic salt, as it will reduce your applications flexibility and is likely not to work in it's current form.
The purpose of a salt is to prevent against dictionary attacks that someone could do if they obtained your user database. In that regard, a static salt is definitely a good idea to implement in your application.
Adding a dynamic salt to each user would mean that you will have to hit a datastore to retrieve the dynamic salt and the hashed version of the user's password, then you will have to perform the CPU intensive hash function (in your code, twice -- you are hashing a hash which is less secure and more likely to have collisions).
Having a simple known, static salt, and a hashed password will allow you to use key/value storage systems like memcache should you application grow. Store the userid as the key and the users hashed password as the value and you will have a lightening fast authentication system.
Try this:
public function dynamic_salt() {
if(!isset($this->dyn_salt))
$this->dyn_salt = mt_rand();
return $this->dyn_salt;
}
If the dyn_salt instance variable doesn't already exist, it will assign it the result of mt_rand(), else it will just return the previous value.
I'm using Zend_Auth with setCredentialTreatment to set the hash method and salt. I see all examples doing something like this, where the salt seems to be inserted as a text.
->setCredentialTreatment('SHA1(CONCAT(?,salt))'
but my salt is stored in the database. I could retrieve it first then use it in setCredentialTreatment but is there a way I could define it directly as a field name, so setCredentialTreatment would know to get it from that field? sort of like the way we define the field name for the username or password
->setCredentialColumn('password')
A side issue I'm having is that I'd like to use SHA512 not SHA1. Is this possible or is it not available? All the examples I see using SHA1.
I should say I'm fairly new to zend and am porting an existing application, so please go easy on me with the answers.
The example you've given does use the salt as stored in the database. It will work as long as the salt is stored in each row in a field called 'salt'. If the salt was not in the DB and in a PHP variable instead, the code would be something more like:
->setCredentialTreatment("SHA1(CONCAT(?, '$salt'))")
As for using SHA512, this might be a little trickier. Assuming you're using MySQL, SHA1() in this case is a MySQL function, and MySQL does not have a function for SHA512 as far as I can tell, and neither does PHP (edit: I was wrong about the latter, see comments). So you'll have to implement your own PHP SHA512 function, load the salt for the user out of the DB first, hash the result and not do anything to the variable in setCredentialTreatment.
As the other answer suggested you might want to write your own Zend_Auth_Adapter for this. An auth adapter is a class that handles authentication, presumably at the moment you're using Zend_Auth_Adapter_DbTable. You can find some more info about auth adapters in the manual: http://framework.zend.com/manual/en/zend.auth.introduction.html
Here's an example:
class My_Auth_Adapter extends Zend_Auth_Adapter_DbTable
{
public function authenticate()
{
// load salt for the given identity
$salt = $this->_zendDb->fetchOne("SELECT salt FROM {$this->_tableName} WHERE {$this->_identityColumn} = ?", $this->_identity);
if (!$salt) {
// return 'identity not found' error
return new Zend_Auth_Result(Zend_Auth_Result::FAILURE_IDENTITY_NOT_FOUND, $this->_identity);
}
// create the hash using the password and salt
$hash = ''; // SET THE PASSWORD HASH HERE USING $this->_credential and $salt
// replace credential with new hash
$this->_credential = $hash;
// Zend_Auth_Adapter_DbTable can do the rest now
return parent::authenticate();
}
}
You can write your own Zend_Auth_Adapter.
I am building my own small framework for my final year project at university and I am very confused about best practices here. I have read quiet a lot of articles and have a general idea but some clarification would be better.
I really like the new sodium extension in PHP But I am a bit confused.
I am creating a split token authentication thing both for long term persistent cookies and password resets.
I am using Libsodium as much as possible as it seems very secure, all be it new and not very well documented.
I am creating a split token like selector:validator.
What I want to do is basically use the selector to query the DB,
Then I want to either compare the two hashes VS Hash the plain text version from the cookie and then compare (But the latter means keeping a key somewhere which creates an issue)
I have heard across many articles especially with Paragone suggest that it is preferable to store the hashed version of a token in the Database and the plain version in the cookie or token.
Is there any real benefit of this?
I have created a simple Token class:
class SplitToken extends Token
{
protected $selector;
protected $validator;
function __construct($selector=14, $validator=18)
{
$this->selector = bin2hex(random_bytes($selector));
$this->validator = bin2hex(random_bytes($validator));
$this->key = random_bytes(SODIUM_CRYPTO_AUTH_KEYBYTES);
$this->tokenHash = sodium_crypto_auth($this->validator, $this->key);
}
public function Set()
{
$this->token = $this->selector.':'.$this->validator;
return $this;
}
public function Get()
{
return $this->token;
}
$sptoken = new SplitToken();
$token = $sptoken->set()->Get();
$dt = new DateTime('+ 2 months');
$expiry = $dt->getTimestamp();
//Gets bin2hex version of validator side of token for DB
$validatorHash = $token->GetValidatorHashHex();
$key = $token->GetKey();
//Store token In DB:
$query = "UPDATE Users SET Selector, Validator, Expiry
WHERE Selector = :Selector and Validator = :Validator and Expiry = :Expiry;
$stmt = $pdo->prepare($query);
$stmt->execute(
['Selector' => $token->GetSelector(),
'Validator' => $validatorHash,
'Expiry' => $expiry]);
Now that the temp token is in the DB. Now it is time to set the cookie (The same can apply to PW Reset with a different expiry of course.
Here I am getting confused and I have two options:
Option 1:
//Store the hexed version of selector:validator in the cookie (but not hashed)
setcookie('auth_token', $token, $expiry, '/', 'CONST_DOMAIN', true, true);
//Where do I store the key?
//So far I am using JSON fuNCTION which gets key from the folder where it is stored:
$storedKey = Key::GetFromVault('auth_token');
if(isset($_COOKIE['auth_token')){
$cookie = explode(':', $_COOKIE['auth_token'];
//Gets the User from the DB Where Selector = Selector
$user = DB::SelectUser($user);
//If User exists
if($user){
//*** Checks the Hash separate from the query to avoid timing attack ***
var_dump(sodium_crypto_auth_verify($user->Validator, $cookie[1], $storedKey);
}
}
Option 2:
Seems a bit simpler and cleaner because I am simply comparing two hashes and there is no need to worry about the key later but it means that I have to store the hashed version of the validator in the cookie:
$hashedToken = $token->GetSelector.':'.$token->GetValidatorHashHex();
setcookie('auth_token', $hashedToken, $expiry, '/', 'CONST_DOMAIN', true, true);
//Now On Request:
if(isset($_COOKIE['auth_token')){
$cookie = explode(':', $_COOKIE['auth_token'];
$user = DB::SelectUser($user);
if($user){
//Checks the Hash separate from the query to avoid timing attack
var_dump(hash_equals($user->Validator, $cookie[1]);
}
}
I know this probably sounds silly and it does not make much difference,
But In option 1 I am comparing a plain text token to a hashed version and comparing it with the sodium function
And with Option 2 I am comparing two hashes
If I compare the same two hashes with the sodium function it returns false and if I compare the plain text to the hashed with hash_equals even though the token before the hash is the same it returns false.
So basically:
1) Does this make much of a difference?
2) I would like to find a neat solution for Key storage and then store plain in the cookie but not sure how
Any advice would be greatly appreciated.
Happy to clarify my question
Thanks
It doesn't make any difference.
What sodium_crypto_auth_verify() does is compute the hash, and compare it with the provided one.
As long as the comparison is in constant time, there is no difference between this and doing it yourself.