Bcrypt is one way, you can't decrypt :/

Why? Why on earth would you want to do that? There is no reason for this. None. No excuse. This would be such a massive breach in security that is ridiculous to even think of for ANY reason.

If you have used Hash::make('password') you cannot reverse this process to turn the hash into the original password. This is the correct way to store passwords in your database for 99.9999% of all sensitive data.

However if you have used Crypt::encryptString('password'); you can get the cleartext version by Crypt::decryptString('encryptedstring');

For passwords where you never need to know the original password you should hash not encrypt but the are some edge cases where you do need to store sensitive data in your application that you need to be able to decrypt elsewhere in your application. For example a monitoring tool to uses the password to query a remote server. However if you do need the latter you need to ensure that you dont expose the decrypted values unintrntionally

Sounds like something very wrong is going on here. Like trying to program a site to get at personal data.

I still wish all developers had to pass an extensive (very extensive) background check if programming anything for U.S.

@cmdobueno & @jlrdw I know this is wrong but my concept is different. For better security... In a university there is a lots of student. everybody has a unique ID (provided by university). Now if they want to create login, anybody can create an account with anyones ID. Now my concept is, "the Admin will input the ID range. Based on that every ID will get individual random passwords.

Suppose Admin gives a range 101001 - 101010. now all the ID betweer this range will generate besides a random password will generate individually for that ID's.. Now the Student's will collect their Password's from admin for login. Then they login and will change their password latter...

Data Input: https://prnt.sc/lcbk2a

Database: https://prnt.sc/lcbkgm

@D9705996

This is my code for password Encryption:

function generateRandomString($characters) {
    $length = 6;
    $charactersLength = strlen($characters);
    $randomString = '';
    for ($i = 0; $i < $length; $i++) {
        $randomString. = $characters[rand(0, $charactersLength - 1)];
    }
    return bcrypt($randomString); //This will return encrypted password
}

You can use faker to generate a random password

use Illuminate\Support\Facades\Crypt;

public function generateEncryptedPasssword() {

   $faker = Faker\Factory::create();
   return Crypt::encryptString($faker->password);

}

You can then show the decrypted value using Crypt::decryptString('$2y$10...'); e.g. the value in your database.

I agree with all others that this is a bad idea as your passwords should hashed not encrypted. If a student changes their password the admin can still decrypt it with ease. If any student is able to bypass your "security" they could also decrypt all other students data. Do not underestimate the resourcefulness of students, they will try to break your system!

You really need to think about your registration process so you can automate the process with only the User having access to their account details and not the admin.

You do not need to do that.

Simply put, all you have to do is create their account, generate a random string and encrypt that for the password:

$password = Hash::make(str_rand(25));

Then when their account is created, you require them to reset their password. You are not granting security, you are making things far less secure. This is a horrific idea, and you will understand that once you get to a certain point.

But in all fairness... you can encrypt and decrypt using those words...

$password = encrypt($some_string);
$some_same_string = decrypt($password);

So you could use encrypt instead to do this... it would 'work' it is just not the right(tm) method...

Fun fact/note for you so you understand

$test1 = encrypt('a_word');
$test2 = encrypt('a_word');

$test != $test2;

These two variables WILL ALWAYS be different... just as a fun fact!

Then when their account is created, you require them to reset their password.

How does the User login to reset their password? The admin is generating multiple accounts in the backend. The one though I have is that stored the hashed password as you suggest but after fhe admin creates the accounts it displays the username and passwords that were used as a one time view that could be printed off and the individual authentication details can be provided to the allocated student as the physically register, which they then must change at login.

You do not need to login, this is why laravel has created signed urls.

This is one of those reasons for their existence. you would send this signed url directly to their email (just like the email verification). They they setup their new password, and life is wonderful.

Another thing I have done, before signed urls, is simple require them to reset their password, just send them a password reset url.