I need to debug some user issues which can only be debugged by actually being the user. Is there a way I can impersonate a user without knowing their password? I'd rather not have to reset their password in the DB as that will lose the original one.
Related
We have a working a custom credential provider,
and a working way to change password when user is logged in.
We are trying to handle the use-case of changing password when the
password is known as expired.
We managed to get the status in ReportResult:
STATUS_PASSWORD_MUST_CHANGE we save that the password must change.
Windows display a message to say, the user need to change his password,
but when clicking on OK, it fallback to logon screen, not our CPUS_CHANGE_PASSWORD scenario.
We have tried to force this scenario when enumerating credentials, but still, the LOGON UI is still drawn instead of the CPUS_CHANGE_PASSWORD one.
How can we do to redraw the UI with the correct Scenario after clicking on OK?
Thanks
I am working on a Laravel project. I need to be able to create a user, mark that user with a number for their 'plan_id', and then invite them to log in and change their password. Currently, I am creating a user, adding the 'plan_id', and setting the password to a generic term like 'password'. I don't have info like their SSN or DOB that I could set it to initially.
While this does work, I don't know that it follows best practices. The only other thing I can think of is setting up another table that matches up the user's email address to the 'plan_id'. I don't want to do this because it makes it possible that the user accidentally signs up with another email and can't figure out why their portal is not working.
It doesn't sound like a great idea to set all new passwords to "password". It looks like your application is creating users, then letting each user know they have an account, as opposed to the user initiating this process. This would mean that you can't have the user pick a password.
Consider not creating a password at all, but sending an email to each new user containing a link to your system with a unique key that you store in the database user record. The user could then access the system, and it would ask them to pick an email and password to be registered with. You could have the keys expire after a number of days.
The easiest way to do this would be to generate a completely random password for the user and then email them a password reset link. The potential pitfall of this is that password reset links expire, by default after 1 hour though you can change it in config/auth.php.
In my database 15 users are have their login and password. If any user change their password then we don't know the users current password. I want to save the password of each users that admin have the only permission to view.If any user changed their password, then admin can know their password, because if we want to login with particular user then it results wrong password.
or
when I login to odoo there is no option to save the password, the username is restore but I want to keep the password automatically fill in the field, does anybody know how to do it?
Thanks........
It's not a good idea to save a password unencrypted in your database.
I'd suggest to take a look at the auth_admin_passkey module.
This would give you the possibility to login at all useraccounts with the admin password.
If you really want to save the new password you could override the write method from res.users and check for the field "password". this way you could save the password to your desired field before it gets encrypted.
I'm using the MVC forms log in which works ok, but I need to call a data service which requires the same Username and Password combination from within a controller.
Using HttpContext.User.Identity.Name I can get the name, but what about the password? Is there any way to retrieve this after the user has already logged in?
First of all, you shouldn't be storing passwords in your application. Membership provider doesn't store the password in clear-text anywhere. All you have in database is salted hash. There is no way to obtain user's password after they logged in.
You would need to get the password from the Login action or create a custom MembershipProvider.
But consider changing the design if possible so you don't have to keep clear-text passwords. Once the user has been authenticated you know who it is, and lower layers in your application can trust upper layers with passing the authenticated principal to them. Otherwise why would they trust with passing correct username/password pair?
Currently I am developing an application with 3 roles: 1 for customers, 1 for the company employees and another one for a Super Admin.
Is it a good practice to allow Super Admin users to see/edit the users' passwords through the UI? Or should it only be modified directly through the DB?
UPDATE: I am using asp.net membership provider and MySQL. Therefore, there is a table in the DB called my_aspnet_membership which stores two fields: Password and PasswordKey. The field PasswordKey seems to be the encrypted password. However, the Password field is stored in plain text. So, can anyone tell me why this is designed in this way if it is not a good practice? Thank you all for your responses!
UPDATE: For those who asked if it really stores the password in two different fields:
Your password should not be stored un encrypted inside your database and as such, shouldn't be visible to users of the UI nor the database.
As for whether it should be modifyable, sure.
In this case the password should be re-generated through user or administrator request. Again, this should be encrypted in the database. My preference would be to auto generate the new password for the user rather than have an administrator type it themselves.
Given this, the only way to change the password directly in the database would be to encrypt it first before insertion. It's quicker to do this through an UI that deals with the encrypting.
UPDATE
In answer to your update, you should specify in your web.config that the password format be hashed:
<providers>
<add [...]
passwordFormat="Hashed"
/>
</providers>
as outlined here:
http://msdn.microsoft.com/en-us/library/ff648345.aspx
There is never a reason to allow someone to see a password they do not own, under any circumstance.
Update for the OP Update: Of course I have no way to know why your DB was designed like this. Thinking optimistically, it contains the plain password so that if a user forgets their password it can be mailed to them -- a bad excuse, but an unfortunately common one. A better alternative is to have the system mail them a freshly generated temporary password -- one which works only to allow setting of a permanent password (and does not destroy the current password until the change occurs).
No user should be allowed to see the Plaintext password of any other user whatsoever. The password must be encrypted atleast if not hashed even in the database.
You MAY allow the super admin to change any user's password, but allowing him to see it in plaintext is taboo.
EDIT: Are you absolutely certain the password field stores the password in plaintext, while there exists another passwordkey field? Because, it sounds similar to a 'salt' mechanism to me. Where, the password is first encrypted with one key, and then re-encrypted with the passwordkey field.
EDIT 2: I am now almost absolutely certain that your database is using a salted password. Salted passwords are often used to increase the security level of the database. For more information on salt, check this.
You should always save passwords encrypted. Therefore you don't have any possibility to show the superadmin the password of another user.
You should never ever store password as is in any database. Always use a hash function to save the password.
You should save all passwords encrypted in DB.. Not in plaintext!!