How can we retrieve Kallithea admin user's Password, if forgotten it? The current setup is using its internal authentication plugin along with the default database SQLite. I can see the encrypted password in the database, but since it's encrypted, it's useless.
As the administrator is a normal user apart from its privileges, you can use Reset Password feature to regenerate (in the current stable release) or to change (in the forthcoming 0.3 release) its password. Even if you don't have email delivery configured, just check the logs — the password reset email is dumped there when there's no email delivery.
I think kallithea has no easy way of doing this, but when you use the original project ie. RhodeCode, there's a nice way to reset your account.
https://docs.rhodecode.com/RhodeCode-Enterprise/admin/reset-information.html#manually-reset-password
Related
How do I reset user password in app without sending email link using firebase in flutter?
If you've already established the user's identity by signing them in, you can update their password
Letting a user change the password of an account that they're not signed in to, would be a pretty big security risk though.
If you have another flow for password reset in mind, you can always update the password of any account through the Admin SDK, which can be used on trusted environments such as your development machine, a server that you control, or Cloud Functions/Cloud Run.
I'm looking for a way to make Moodle 2.9 include user passwords in the introductory e-mails it sends upon manual upload of CSV table with new user data.
So far it is sending introductory e-mails with text that is set up in the local_welcome plugin that is configurable via
Plugins/Local Plugins/Moodle welcome
This text contains fields such as [[username]], [[fullname]] which get replaced by the actual values, but no such field as [[password]].
I have tried including both [[password]] and {$a->newpassword} in the text but neither works, Moodle does not replace these strings with the actual password; these strings are sent verbatim instead. This happens irrespective of whether the passwords are uploaded via the CSV or generated.
So far I had no luck finding a solution to this on the web. The official help page on this function is unfortunately empty:
https://docs.moodle.org/29/en/admin/setting/local_welcome
Strangely enough, when I create just one user by hand in Moodle via
Users/Add a new user,
the e-mail it sends to the user is not that from plugin local_welcome. A string defined somewhere in the moodle php files is used. This contains string {$a->newpassword} and it works as expected; the user obtains both username and password.
How do I make bulk upload behave similarly? I'm looking for any doable way to make this work. If my question is not clear, please ask in the comments.
Sending plain password over email is not secure that's why Moodle prevent it.While uploading user record you can follow these steps,
enable Generate password and notify user.
or,
set your own password and enable Force password change.
It depends on configuration of bulk upload
Password field: (...) If omitted, a password will be generated for
each user (during the next Cron job) and welcome e-mails sent out.
https://docs.moodle.org/29/en/Upload_users#Fields_that_can_be_included
Just udate all existing users with the same password using csv file. Then use Moodle welcome to send bulk email with their different user name using [[username]] and then type the default password you chose in csv. And it is better to force change password after first login
I am trying to find the best practices for forgot password functionality via sending a link to reset password i.e. sending an email with a one time token to the registered user. The token will be stored in the database and when the user clicks the link, we check the token and allow the user to set a new password.
Best practices while designing forgot password function -
The token must be unpredictable, that's accomplished best with a
"really" random code which is not based upon a timestamp or values
like the user-id.
Like a password, the token should be hashed, before storing it in
the database. This makes them useless for an attacker, even if the
database is stolen.
The reset-link should preferably be short to avoid problems with
email clients, and contain only safe characters 0-9 A-Z a-z
(base62 encoded)
The token should have an expiration time within single-digit hours.
The token should be marked as used,after the user has
successfully set a new password.
When a user changes their password or requests another password
reset, expire all tokens already associated with their account.
These are some of the points I found. What can be other security issues that should be considered ?
Sources:
Secure password-reset function
Ycombinator News
A couple other practices I've seen:
Check user is on the same machine/browser/IP as the one where the reset password request was triggered (unless it was initiated by admin/system).
Rate-limit number of reset tokens that can be generated for an account.
It should also be noted that the best practice is usually to use an established library rather than inventing your own mechanism, as too many things can be overlooked.
I have the same question and found the OWASP Forgot Password Cheat Sheet.
Also few things that I would like to add:
Usually if user entered non existing email sites anyway shows message "pwd restoration link was sent". This is due to prevent hackers from determining that user with the email exists in system. But IMHO it's better to say user that email is not exists because usually it may not remember email used during registration.
It is better to add some additional personal question to user like a birthday date. If hacker stole user's email it makes harder to receive reset link. But since reset link may be sent to user by site admin the question with birthday must be on change password page which is opened by link.
Hackers may automatically send a lot of letters to some user. Some sites uses a CAPTCHA near email field to prevent this.
After successful changing of password all active sessions should be closed and user must be logged out. Thus even if hacker is logged in he will logged out.
It is a good idea to hash a restoration ticket like a password. Here should be used the same hashing algorithms like with password: Argon2, SCrypt, BCrypt.
After user restoration password it is good to mark it a possible fraud and for some time (like a week) do not allow to make some critical actions, like withdrawal money from account.
Also some sites are sending a letter to user that it's password was changed. They do this when user was logged normally changed it manually but maybe it is good to send the same latter when pwd was reseted.
User Administrator takes his password from "JIRA Internal Directory" (which means from database, as I understand). I know this password, but in some reasons I want to reset it. But in Administrator's profile there is no link "Set password".
All I found on the Internet - how to send password by e-mail (not to change it!) and view/change it's hash right in database by SQL query.
Is there any method that I overlooked?
Yes, go to Admin, System, General Config and change External User Management to off. Then put the internal directory at the top in the list of User Directories. Go to the admin's profile and click on Change Password. Then undo the previous steps
Many sites implement different methods and I am having a hard time deciding on which method would work best for my site.
My user profiles contain the following data:
username
password (in hash/digest form)
email
I'd like the password reset method to be secure, user-friendly, and efficient.
You should add two fields, reset_code and reset_expiry
This is the process for a secure password reset functionality.
User selects "Forgot password".
User prompted for email/username.
If valid, generates a GUID, and stores it in reset_code and also stores Now()+24 hours in reset_expiry in the database against that particular user.
Then it sends an email to the email address with a link to confirm the password reset. This email would contain a link to your website with the user's username AND reset_code embedded. (This stops a malicious user resetting a third parties password just by knowing their email)
Once the user clicks on the link in the email, they will be directed to your website.
Your website will validate that: the username and reset_code matches, and the current time hasn't exceeded the reset_expiry time.
If all is okay, we can complete the password reset. This can be done by either:
a) Onscreen a new randomly generated password
b) A new randomly generated password via email
c) The ability to enter a password of his/her own choosing
You should not store the passwords of your users, not even in encrypted form. You should only store the hash/digest necessary for authentication. Then, you can't "recover" the password (because you don't know it), you can just reset it, and/or give the user a temporary one-time password that allows him to set a new password.
Update: if you are doing the above, the standard procedure is to have a "require-password-reset" form. The user enters his id (typically his email) and a "token" (eg, a random string) is generated, stored in some table with some expiration date, and sent to his email along with a link to the "password-reset" form. In this form the token is checked, the user is allowed to enter a new password, and instructed to attempt a new login.
Update 2: A small privacy issue might arise: What should we do if the user id (email, user name, or whatever) entered in the request form does not exist in our database? To output a message "User does not exist. Check the id and retry." may be ok, but in some cases it would cause a privacy problem: anyone can check if other someone is registered in your database! If you want to avoid that, you must output the same message ("a mail has been sent with instructions...") even if the user wasnt found (and hence a mail was not actually sent).
Similar privacy issues advise to just output the message "login incorrect : bad user or password" when the user tries to login unsuccessfully - don't disclose if it was an incorrect user or password.
I agree with Leonbloy. Storing the password leads to trouble like the Gawker incident from a few weeks ago (1.5 million userid/pwd combinations were discovered and published).
You should, however, have a "reset password" function that e-mails the new password to the original e-mail address used to open the account.
There should be no provision for changing the e-mail address during the password reset. If the user doesn't have access to the old e-mail account anymore, too bad. Abandon the account and start over.
And use a good Captcha on the reset screen.