Login with plain-text instead of hashed password

I want that every user should have a password as a plain text

Why?

Steps:

1- GOTO: App\Http\Controllers\Auth\LoginController 2- Add:

protected function attemptLogin(Request $request)
{
    $user = \App\User::where('email', $request->email)
        ->where('password', $request->password)->first();
        
    return $user ? \Auth::login($user) : false;
}   

That's all

Oh no @abdk2r. No, just no.

Client whish to see the password of all users if the password is hashed then it will not be understandable by the client or any human being. The problem of hashing is, it cannot be reversed into plain text so that's why password as a plain text is a requirement

That is not "the problem" of hashing, that's exactly the POINT of hashing. There shouldn't be a need for your client to see or understand the plain text passwords of your users.

Please walk away from this project as fast as you can.

The problem of hashing is, it cannot be reversed into plain text so that's why password as a plain text is a requirement

Euhm that is not the problem of hashing, that is the beauty of hashing... You should ask why they want to see the password of the users. There is no reason for that. Unless the whole goal of your project is to steal passwords of course...

Client whish to see the password of all users if the password is hashed then it will not be understandable by the client or any human being. The problem of hashing is, it cannot be reversed into plain text so that's why password as a plain text is a requirement

Read that back to yourself, and then ask why a hashed password is preferred..

There are other strategies for dealing with forgotten passwords; or an admin logging in as another user etc

@tykus do you have any better option then please suggest me

do you have any better option then please suggest me

Yes, use hashed passwords.

Why does the client need to know its users' passwords?

Also, if you could let me know what application/site this is, so I know to avoid it

Use the things that are implemented in Laravel.

If you forget your password you get sent an email, click on a link and create a new password.

@click he is the admin so it's up to him that he wants to watch the password or not. Why should I force him not to watch the password of students and teachers :D

If you have any solution then please tell me.

We just gave you the solutions! He can see and control the data in the database anyway so why would he need the passwords? It's nothing more than a security risk. How do you think password leaks happen? Exactly because of this!

@afrasiyabhaider .... please tell me you are joking.

A password is something private for the user. There should be no reason for anyone, in any circumstance to "watch" passwords. Why does somebody wants to do that for legitimate reasons?

The only solution is to hash the passwords.

he is the admin so it's up to him that he wants to watch the password or not

You are abdicating all responsibility for security of the system you are building. In fact, it is arguably unethical to knowingly store plain text passwords for your users.

I've got a solution now, guide me if I am wrong.

Admin has to enter the roll number/ teacher id, so initially, the roll number will be set as the password for student and teacher id will be set as a password for teacher and these things will be hashed and stored in the password column of teacher and student.

Should I go with this or you guys have some better option?

@abdk2r @tykus @click @

Why not either of (i) generate a random single use password and email it to the user directly, or (ii) build an invitation system?

If the password is saved with a random number then how teacher/student will get their password if the password is stored with Hashing?

No invitation system is not in the requirement

email it to the user directly

ok any other suggestion?

Send them an email with their password could be a solution indeed. Another solution without too much work is to generate a "forget password" url for each user. And send them this link. Than you know for sure that they change their password.

Having default passwords that can easily be guessed like student numbers or names it not a good idea because it is easy to get into the system of your classmate if you know his number.

@afrasiyabhaider Passwords should not be viewable. Under any circumstance.

Why should I force him not to watch the password of students and teachers :D

Storing passwords in plaintext introduces two major attack vectors:

1. If the database is compromised, an attacker now has all of the passwords in your application.
2. People use the same password for multiple services. If the password from one service is discovered, then an attacker can try that password on other services: social media, online banking, etc. Not good.

Admin has to enter the roll number/ teacher id, so initially, the roll number will be set as the password for student and teacher id will be set as a password for teacher and these things will be hashed and stored in the password column of teacher and student.

Not good enough. A roll number is easily found. Especially if they follow some form of pattern (i.e. incrementing: 1000, 1001, 1002, ...). So there is nothing stopping someone logging in with another roll number.

You really need to have a bit of pride in yourself and tell your client that you will not compromise security because they say so. If they ask you to do something illegal are you just going to do it because they told you to? In fact, I imagine storing sensitive information (such as passwords) is illegal in some jurisdictions as you have a duty of care to take as many precautions as possible when it comes to security. Because it will you that will get sued if the application you build is compromised. Especially when dealing with a sector such as education and holding details of children.

@martinbean you are right then what should be the initial password set by the admin while registering the student and teacher?

Why should the admin set the password manually?

Because admin is registering students and teachers so admin is responsible to assign an initial password.

The application can do that (much better).

@afrasiyabhaider Generate a password, send that password to the user:

// Generate a random, 20-character password
$password = Str::random(20);

// Create a user account
$user = User::create([
    'name' => $request->input('name'),
    'email' => $request->input('email'),
    'password' => Hash::make($password),
]);

// Send new user their password
Mail::to($user)->send(new AccountCreated($password));

The only person setting a password for an account should be the owner of that account. Not an admin and not a developer.

Why would you want to do that. Kindly advice your clients against such action, Don't ever store password in a plain text. What you can do hash the password, but while user is registering, send the password in a plain text to user's email.but password in your db must be hashed

Replying to this as it's relevant to something I've come across today in a discussion. Like most things in development, "it depends".

I'm about to start work on a small project where a teacher creates x number of logins for a student. The username for the student is auto-generated along with the password. There is no identifiable data on the user model, not even an email address.

The teacher will print out the username and password for the student and they'll be given that at the start of term. The login just gives them access to a resource. The teacher would be responsible for resetting any password manually.

Happy to be given an alternative in this case...

@1stevengrant you could do the exact same with hashed passwords. The fact that someone creates the passwords manually or uploads it via CSV is not related to the question if a password should be hashed or not. It should always be hashed.

Even for small projects there should not be a reason to not hash the passwords these days. It is really simple todo and it prevents accidentally storing passwords of users not hashed.