having multiple and same username but differ in their passwords is this possible in joomla?
if yes, how can I do that.
e.g
username | password
one 123
one 456
one 789
thanks
..
I think it's not possible to use same username with different password in Joomla.
Joomla!'s user model requires a unique identity (i.e. unique username per user).
This is a fundamental aspect of access control: 1 unique user identity for each user.
You could conceivably create an extension for Joomla! that would simulate what you're trying to achieve by making a unique identity from the combination of username and password. Of course, that would either have to prevent users from changing their password or provide a complex mechanism that made sure the hash of their new password didn't conflict with another user of the same username.
Of course rejecting such a password attempt would reveal the details of another users account access...
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.
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 developping an application with Spring MVC, and I want to add the security aspect to my authentication.
In my application I have the login and the password are registred in the database and any one who has access to it can see the login and the password clearly.
I want to have data encrypted in the database so that I will be sure that no one can use or divulgue them .
I've searched in the net but I found that there are some algorithms which may encrypt data such as md5 ,but the problem it's irreversible.
Could some body help me ?
I agree with Danny H, but wanted to address the other half of your question too: protecting the login (usually an email address). Most people ignore the need to protect it, but for website that want to maintain secrecy of their customers (not just Ashley Madison but also medical websites), then you'd want to add a layer of protection for the other data.
First, a reference on protecting the password: Secure Salted Password Hashing. Use either bcrypt, scrypt, PBKDF2, or argon2.
Now what about protecting the login? You can actually do a similar thing for protecting it, but you will need a fixed salt for it (for passwords, the salt must not be fixed!). Let's assume bcrypt is used for my example below.
Consider how the user would login: User enters his login id and password. System applies bcrypt to login id with fixed salt to look up user in database. From that, system gets the user's password salt, and system computes bcrypt on user provided password with salt to see if it matches hashed password in database. If so, user is granted access. Therefore, system granted access without storing the user’s login id in plaintext form in the database.
What about user forgetting password? No problem if the login id is the email address: the user enters login (email address) on forgot password page, system applies bcrypt with fixed salt on user entered email address to see if the user exists in database, and assuming yes, then emails the user a secret link for password reset. Within the database, we have to associate that secret link to this user to make sure he only resets his own password (not somebody else’s!).
What if the database is exposed? Anybody could determine if a specific user is in the database by computing bcrypt on that user’s email address and looking for a match in the database, but nobody is going to be able to reverse the entire collection of email addresses, which is a big improvement over the present situation.
I discussed this idea in a blog of mine more than 2 months ago, see: https://littlemaninmyhead.wordpress.com/2015/09/08/a-retrospective-on-ashely-madison-and-the-value-of-threat-modeling/
Why is it a problem that the encryption of passwords is irreversible?
When the user creates an account, salt and hash their password before saving. I prefer using bcrypt.
When the user logs in, you can use bcrypt's checkpw to compare the users credentials to the hashed ones saved in the db. Having them irreversible(undecryptable) ensures that if someone gains access to your db, they don't get all of your users passwords as well
I haven't used BCrypt with java before but I just glanced over this tutorial and it seemed like it may be a good starting place for you
Edit : Just realized he was using jBCrypt but the differences in the two should be very minimal
Edit2 : Here is a pretty good article on cracking passwords that are found in the database and a reason I recommend bcrypt and why you should use one-way encryption
MD5 is a hash function which is not reversible - it is not an encryption function. Hashes give the same output for a given input every time, that's why they work. Hashing would work in the scenario you described because the users who could see the hashes wouldn't know the original password - that said, it still sounds like a bad idea.
Ideally you would hash the passwords then encrypt the hash and other users wouldn't be able to see these values encrypted or not. That would be my suggestion, but if you choose only to encrypt the passwords RSA encryption would work just fine.
When user change his password, or admin changes any user password then it should not be same as his last 3 passwords.
How this validation can be done? I have installed password_policy module. But its not validating this constraint properly.
Can anybody tell me how to achieve this? I have installed phpass module too, is it effecting for this module?
Please help me to solve this problem.
According to the Password policy module page, it says that it supports:
History constraint (checks hashed password against a collection of users previous hashed passwords looking for recent duplicates)
So my first inclination would be that phpass is potentially influencing this. Is it possible to disable the phpass module to test this and confirm?
In fact, according to the Secure Password Hashes module page, it is using a different algorithm to store the user's password. Since Password policy is storing the history of the passwords as md5 hashes (in Drupal 6), this could cause issues if phpass did not take this into account.
Take a look at this related phpass module issue. You could also check the password_policy_history table and see if the history of password hashes for a given user matches up with the current password hash for that same user created by phpass.
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!!