I need to send a mail to a umbraco user(member) with a password remind.
I work with umbraco.cms.businesslogic.member.Member class:
Member member = Member.GetMemberFromLoginName(userName);
string password = member.Password;
But when I look into this password apparently is a "coded"(crypted) password, not the "clear" one..
Is there a way to obtain a "clear" password ?
The passwords are hashed (and quite possibly salted) during account creation. The website doesn't know what the plaintext password is - it only can compare the hash (one-way cryptographic function, in theory irreversible) of what user inputed into password box with the stored hash.
The "forgot password" should verify owner of the account and send an e-mail with password reset link. Sending plaintext passwords emails is a huge security violation, as users often reuse their passwords on multiple sites, and gaining access to users email would expose password that can be tried on hundreds upon hundreds of different websites/systems.
Hopefully not.
It is very bad practice to store passwords in a way that allows for them to be recovered.
What you can do instead of "password reminder" is "password reset": Send them an email with a link that allows them to reset their password. Protected by some unique number that expires after a few hours and can only be used once.
Related
i want to decrease complexity of password for recovery password asp.net.for example if a user do the recovery, it send a random password only with numbers. not with complex characters!
and my second question is that can recovery password send old user password to his/her email again or not?
thank you
I would recommend setting it up so you DON't sent new passwords over mail to the user. Instead send a link to a generated URL that is valid for a specific time from which the user can set a new password. This way you get around a lot of security issues with sending passwords to users in their mail.
Sending the old password is realy bad practice and a huge security flaw in your system. Users normally reuse passwords. If anyone gets access to your database or pushes the users password recovery button your user is toost. So you have to save them as a hash with a salt. A way to let users change their password can be to send then a 1 time usable link where they can type a new password for your system.
A customer of ours complained about login password recovery using plain text password. The only workaround I know is auto-login with encripted username and passord in the query string.
What other options exist to increase the password recovery security?
Thanks.
You can send them a URL that lets them reset the password themselves.
You could create a database table that stores, at the very minimum, a user id and a hash value.
Send the user a link that includes the hash, and on the receiving page look up the associated information and allow the user to reset the password to the account. Which I'm hoping you store in the database as a hash value. Plain text passwords should never be stored or sent out.
Just be sure that the link either expires or is deactivated once the password is changed. Otherwise someone could visit that link whenever they want and change the password.
Along the same lines as Brandon's excellent answer, here is what we do:
Do not store passwords in plain text, or even a decryptable value. Always store passwords using a 1-way hashing algorithm. This means only the user can ever know what the plain-text password is.
When a user forgets their password, present them with a form where they enter their email address, and click submit.
When they submit their email address, create a table row with 2 major pieces: The first is a password reset token (we use a Guid for this). The token should be timestamped, so that you know when it was created, and when it expires (ours expire within 2 hours of submission). The second piece is a secret code that the user will have to enter in order to reset their password.
Send an email to the user, with a link to a page that will accept the token and secret code. When they click the link (or visit the page and enter the code manually), you can then present them with a page that lets them change their password without knowing its previous value.
Using a time-constrained token is a good idea, because if the user's email account is later compromised, the criminals can't use the email to reset the password -- assuming of course that the email account is not compromised within 2 hours of the password reset request.
I wouldn't send out the actual password of the account in plain text to the user's email address. The reason for this is because if someone hacked the users email address now they have their actual password. Most likely this password will be used for other systems as well.
The alternative is to send an encrypted querystring that links to that user and allow them to change their password based on some sort of security question or demographics you have specific to that user.
Facebook uses a matching of friends images to names. If you have their DOB and address you could use that (not that secure). Or you could set up specific security question and answers which would be better.
This question already has an answer here:
Closed 12 years ago.
Possible Duplicate:
sending to an email with contact form asp.net
How to send email from ASP.NET page using C# as for forget password, password will be automatically emailed to the alternate id. I need how is it possible to send email from ASP.NET page using C#.
There is no shortage of articles and tutorials on this.
Side note: Being able to email the user their password implies that you're storing their password in plain text. Please, please don't do that. Passwords should be stored in an encrypted form. If the user forgets their password, email them a temporary link for them to reset their password.
You could use the SmtpClient class to send an email in a .NET application.
What you are suggesting sounds like a security risk. It is inadvisable to send a password through email, since this assumes your are storing the plain text password somewhere. Since you should only know the salted hash of the password, you probably want to make the user reset their password instead.
I suppose if you still have some reason to send an email you can check out an extensive tutorial here to start. Seriously though, You can compromise all of your users security if you are not hashing there passwords, and even more so if you are emailing them out.
The short answer is, as stated above (+1'd btw), to use the SmtpClient class.
However, it's dangerous to go emailing passwords around. As a rule of thumb:
Don't send passwords in clear text
Don't store passwords in clear text
When storing a password (if you don't have some framework that does all this for you)
Create a salt
Append the salt to the password
Hash the resulting string
Store the salt and resulting hash
Discard the password
When authenticating, add the salt to
the newly provided password, hash the
resulting string, and compare to your
stored hash
If a user has forgotten their password, send that user an email containing a one-time use, time-sensitive (expires in 1 hour?), unique-link to reset his/her password. It's also a good practice to require the user to manually provide his/her account name or other identifying criteria on the password-reset form.
I store the customers passwords in DB using encryption.
When the customer edits his personal data (including the password) the passwords are shown as *****
How can i understand that the use change his password so write to DB without encrypted again and again.
I mean that the value in password field is the encrypted value. If dont change the password must update with the same value (or not update at all)
If user change password to 1234 I must encrypt the 1234 and write to DB the encrypted value
Thanks
Don't send the md5 hashed string from the DB back. Set up three fields:
Old password
New password
New password again
Then check if the first field after md5 hashing is equal to the stored one in the DB. If it is, hash the second field and store it. (Only if the second and third is equal)
You should require entering both old and new password when user wants to change it.
That way, you can encode the old password, check if the encoded value is the same as in the database. If it is the same, then the you should update the password in db with encoded new password. If it is not the same (or old password is empty) you do not update.
This helps you to distinguish between password change and settings-only change. You also gain a some level of security, as if someone have captured the session of your user, he cannot change his password without also capturing is original password.
A few points:
MD5 is a hashing algorithm, you will never be able to reverse the hash and that's the point.
Don't use MD5 as it has been cracked, use an SHA2+ Hash Algorithm (SHA256 for example)
Simply confirm the password with the "old password" by hashing the old password against the one in the database.
Another option is resetting the password, which will email their confirmed (hopefully) contact email with the new password.
If they're logged into the system already, you should not need to "confirm" the old password again.
Never send the hashed password back from the database, it is kind of defeating the purpose of what you are trying to accomplish.
I've have an asp.net web app, forms authentication, that's uses Hashed password type.
Will I run across any problems if I change the password type to Encrypted?
I see that, if I change to Encrypted, attempted password recovery for old hashed passwords fails gracefully, which is good. Are there any not so good things that might show up if I change.
If someone changes their password after I make the change to Encrypted the password type stays as Hashed. Is there any way to force it to store the new password as Encrypted instead?
if I change the password type to Encrypted?
Why?
Hashed is safer (password recovery: generate a new password and send that).
The only reason I can see to use encrypted is if the passwords are needed by the system itself (e.g. to authenticate to another system as the user).