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.
Related
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!
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
I'm new to magento. Currently i'm creating a ecommerce webstore using magento. As you know magento will send a reset password link if anyone forgets his/her passwords. I want the system generated password has to be send to the users not as password resetlink.
Plz help me to achieve this....
Thanks in advance.
The current 2 step password reset feature was introduced in 1.6, so you could look at porting the password reset code from an older version of Magento into your site. We've looked at doing the opposite (back-porting the new method to older Magento sites) and it's do-able. The current method is much better from a security perspective, so while what you want is possible, it's probably not advisable.
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!!
I'm writing a very simple login system for a Rails app. I'm using RESTful authentication. It's a fairly conventional setup, where I'm sending the email and password to authenticate the user.
Here, I used REMEMBER ME?, if same user again wanna login then by using cookie, user can re-login. Now thing is like, I want to print email and password in its respective text-box. Email is inserted into the textbox but I am facing a problem to show password in text-field.
At the time of login, such condition is used
#person.password_hash == BCrypt::Engine.hash_secret(#password, #person.password_salt)
How can I get my password in text form?
[irony]Why are you even hashing them if you want to display it in text form?[/irony]
But to be serious: hashing is one way operation, you can't revert it.
http://en.wikipedia.org/wiki/Hash_function
Therefore you can't display user password (and btw - you shouldn't do it anyway, it's violation of the security principles).
When writing "remember me" feature, look at way devise is doing it: http://rubydoc.info/github/plataformatec/devise/master/Devise/Models/Rememberable If you want that feature to be really safe, there is some amount of work required to code it.
After a lot of searching the web, I found that BCrypt::Engine.hash_secret is one-way encryption of password. This means there is no way to reverse the process. So if you are trying to make password text from BCrypt::Engine.hash_secret, you cannot do it.