We are trying to build a web application using Laravel 5 and I'm wondering if it's possible to prevent the users from using the last 5 passwords.
We were thinking of creating a password history table where we save old passwords whenever a user register/reset password and then check the new password against the old ones in the ResetPasswordController.
Would this method work or we should write our own Auth classes ?
All you need to do is create the proper relationships a user would have for that passwords table.
Every time a user creates or changes a password run it against a the last 5 passwords for that user.
This can sometimes be annoying for users but large sites use it as a good safety feature. Good Luck!
Related
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.
Is there any way to login other users account for admin user ?
Currently authentication based on Meteor Accounts
I saw this post but didn't working at all now.
The feature is important for us because when user have problem in system then admin need to see it this by simulating user account.
Thanks in advance.
It seems you want to impersonate a user. This means that you want to have Meteor.userId (or this.userId depending on context) reflect the _id of a specific user both on the client and the server.
afaict the only way to do this is to login as the user. Presumably you don't want to ask the user for their password so you have a couple of choices:
Save their existing password, replace it (temporarily) with a password of your choosing, then after you're done impersonating their account, restore their existing password.
You probably don't want to ask the user for their password and you don't need to. All you need to do is set aside Meteor.user.findOne(userId).services.password.bcrypt, then reset the password to your temporary value, then restore the original bcrypt value later.
The downside is that the original user would not be able to login while you are logged-in. Plus it's really hacky.
Extend Meteor's Accounts package to provide impersonation capability in a more elegant manner.
You might also look at validateLoginAttempt. The docs are unclear as to whether a failed login attempt could be overridden with a successful one but if it could then that would provide another pathway to solve your problem.
Instead of logging in as the users, which requires their password and which is a total no-no, you may use rather alanning:roles and allow the admin to assign the role of any user in order to draw views based the user's role.
This requires a well designed role system.
As a plus you could then at least load the documents associated with the user who you want to support.
This requires a well designed document and data model.
But generally spoken you should rather focus on writing good tests (test driven development) for components as unit tests, integration tests and UI tests.
This will reduce the need to manually view the app as an end user a lot.
The most common end user problems can be reduced by creating a good knowledge base like a wiki or video tutorials.
Even if then an error occurs in the end user side, I would rather try to implement a well designed error log that allows users automatically create tickets on error which also include the error stack.
All the above methods are to be favored before logging in AS THE USER.
As #Jankpunkt has already mentioned alanning-roles I can add something you can use without installing any external package.
Just keep a type key in the profile object of the users collection. Then define some types like 1 for super-admin, 2 for admin, 3 for general etc. Then check the authorisation of particular action by checking the value of user.profile.type key.
Caveats: Make sure you are checking the type in server side. By default profile field is writable from the client end, so if you are putting type field in the profile object make sure that you are not allowing users to modify users collection in the client end.
Here is how to restrict client end update in users collection:
Meteor.users.deny({
update() { return true; }
});
Read more on roles and permissions here:
https://guide.meteor.com/accounts.html#roles-and-permissions
I would need a readout of joomlas user password in plain style to give special users the ability to send a mail in a custom module with login details like:
https://mydomain/login?user=testuser
password = testuserpassword
For that reason I need the plain passowrd out of the DB. Is there a way to show/read out password from joomla-db in plain style?
Thx in advanced!
Joomla saves the passwords in the database using a one way encryption mechanism, which means that you cannot know what the password is.
I am sure what you're doing can be done in a different method - if you want to login users automatically once they click on a link then you can have a different authentication plugin that will use a random, unique, one-time-use, and time-sensitive hash that will be associated with a Joomla user account.
You need to create a plugin with function after joomla user save
you need to store password in another table with user id and then you can use with sql query to get password.
This is a bad idea for the following reasons:
email is sent in plain text
email often is stored on several systems along the way to your mailbox
email often is stored on your computer in plain text or other unencrypted format
many copies may exist in many places, even after "deletion"
even encrypted email can be broken in to, given enough computing time
your account's security may have been compromised even before you read your email (changing the password will not help in this case)
However, you definitely can email the user their password upon initial registration by going to Global Configuration > Users and setting Send Password to "Yes" (default setting in Joomla 3.x).
If you are looking for a way to send this password after the registration event, as others have mentioned, you are out of luck. What Joomla! provides is a secure password reset functionality to reset a password to something the user can remember. This will be the best approach for you, as well.
Resources: Sending Passwords in Email, Stop Joomla Sending Passwords in Emails
Just need a little advice. I have a website based on CodeIgniter and using TankAuth and PHPass. I want to recode the website with another framework (Symfony 2).
Is there any way to allow user to log with their existing password or do I absolutely need to ask them to set a password again ?
Thank you very much :)
The best is to reset all the password and warn users through email or ask them to change the password with the new system.
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!!