I understand that a hash salt combination is the ideal way to store a users password. I also know that hashes are one way and not really possible to get the original plain text.
So, if one is to implement a "forgot password" function in a web application, what would be the best way to get to the original plain text password so we can send that back to the user?
Hopefully this isn't too ignorant of a question.
David
You don't. You can either change their password to a new (random) one and send that, or you send them a link that will let them access a page where they can enter a new password.
Related
I am using a custom Parse server hosted on Heroku.
My overall goal is for a unique PFUser to be created through someone clicking a button or a activation link in an email.
I have figured out how to send emails using Send Grid, however I have no idea how to make a custom button or link in the email that will execute some unique code.
My ideal work flow is:
User inputs unique username and password then clicks sign up
An email is sent to the users email with a button or a link
Once they click the button or link, somehow unique code is executed which signs up a new PFUser using the username and password that the user originally inputed.
I know how to do the first two steps, but have no idea how to execute the unique code from an email.
How is executing unique code from an email usually done? I have read something about tokens being used?
Could someone please outline for me how this process works and where I can go to learn all about executing unique code from emails?
Thanks, I appreciate all the help!
Code is never executed from email because it is a severe security risk.
To implement something like you're describing, you would send an email to the new user with a unique link to a web page like http://yoursite.com/confirmation/?id=some_unique_id_like_a_UUID
Then on you write the web page (at http://yoursite.com/confirmation/) to read that id value and then do the action that "signs up a new PFUser using the username and password that the user originally inputed."
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.
I just finished encrypting the passwords in my database using a salted sha1. Naturally I'll need to implement a forgot password link ( email as well ). I have make shift versions of those right now that are no good.
I am assuming due to the style of encryption, that I will need to prompt the user to reset their password.
I am just looking for the most secure way to do this. Any suggestions, or links to resources and tutorials, as well as what kinda of method I should use would be greatly appreciated.
thanks and good day.
Just to be clear, sha1, salted or cheesy onion flavour, is not encryption, it is called hashing. It's a one way function with unique output for unique. The idea of using a salted hash for passwords in your database is twofold:
The hash is a one way function, so nobody with access to the database can actually determine what those passwords are. Very good practise.
The salted part, assuming you're hashing the username+password+some junk, means that each username + password combination should be a unique hash. It makes dictionary attacks / shortcuts via precomputed hashes difficult, because most people don't have a dictionary of ninefingers:stackoverflow!!:{insertcommonwordhere} lying around. It doesn't stop them generating it, just makes it more inconvenient.
Now we've cleared that up, yes, if the user forgets their password, you can't email it to them because you can't reverse the hash. By design.
Instead, what you're looking to do is allow the user to securely reset their password. The simplest form of this is that, if the user enters their email address, you email them a link to your site including in its parameters a unique, use-once token valid for a short time window.
Other options? Generate them a password and email them that. The Uk Gov't Gateway here in the UK does something quite interesting: the web-page contains half the password, the email the other half. You need both to then log in again.
Now, the million-dollar question: is it secure? No. Nothing's secure. There is no 100% security. Ever. This particular method of storing passwords adds security because:
DBAs can't easily abuse their access to the user table;
Malicious requests that somehow select * from table users; can't easily read those passwords either.
But as soon as you rely on being able to email the user as a method of secure communication, you rely on:
Their email account being secure;
That their email is not being monitored.
The question then becomes - how secure do you really need to be? Implementing the email-out-a-reset-link solution will work for most cases because they're not high-value enough targets, really.
We have a very old client that is having problems trying to log in to a website. At the moment we think the user is not entering a correct username.
The site is in ASP does any one have any code that I could borrow that would be able to log and write down whats posted and then post that user name and password to the normal submit function.
Send the old client an email asking him what his username is. He'll probably mistype it in his reply the same way he mistypes it in the web form.
Give him a call, and tell him to spell out each letter/keystroke as he tries to log in.