On a blog of mine, a user asked me if I could tell him his password from that account, which happens to be the same password he used on multiple accounts, on an email which was deactived - the point is he needs that specific password.
Since the only option in the Wordpress Dashboard is to change the password, I had to look in phpmyadmin, under wp_users table at his password. The things is, the password is encrypted unde wordpress's unique encoding hash, phpass I believe, since it starts with $P$B. If it was 2008 again and wordpress would've used MD5 to enconde password in sql tables, it would have been easier.
From my knowledge I know that phpass pasword can't be decrypted, naturally, since it's a one-way encryption method. The only way would be to bruteforce it, which is out of the question.
And then, I thought about resending the user an e-mail containing the password. I searched the plugins page and found one named: 'Re-send Welcome e-mail' which still resets it eventualy.
I think that this method is plausable, because, if I change the password in the wp_users table with another one encoded in phpass, he can login with the new one, so Wordpress somehow verifies it by encoding or decoding it, or by enconding it and comparing the hash of the password entered with the one already present in the wp_users table, under that user's row.
Is there a plugin available or a turn-around to this situations? I overthinked the whole situation and now I'm out of solutions which are in my league of knowledge.
The whole idea of hashing is that you can't read the password. So no, you can't resend or retrieve the password from a hashed string besides trying bruteforce.
http://en.wikipedia.org/wiki/Cryptographic_hash_function
Related
I'm using the FOSUserBundle on a Symfony project, and I would like to know if, when a user changes his password, I can have access to his former password. The one he's supposed to enter in the "current password" field.
I have a system of encryption on my project, and it's partially based on the user's password, that's why I need it, to update the user's encryption settings.
I created a listener when the user changes his password but I don't know how to get his former password. Or current password, whatever.
Thank you for your help !
Short answer: NO. If user won't give you his current password by typing it in form it's impossible to guess his password.
Only option to have access to current user's password is when password is stored in database in plain text which is rather not the case.
The way passwords are stored in db usually is by using hashing function which are designed to be impossible to invert - you are able to hash your password but you can't unhash it.
In theory you could try to use Rainbow tables but it's not something you could use in regular way on every passwprd change because it's very CPU heavy.
encrypt the new password.
compare the hash of the new password and the hash password in the database.
I modified register usercontrol with my custom fields. In this control it doesn't have password field. I am generating password randomly with Membership.GeneratePassowrd() method. I am sending email to the user after registering using Membership.Getuser(username).GetPassword() method.Every thing is fine when i kept the PassowrdFormat=Clear in web.config file. Now i want to change to passwordFormat=Hashed. But if i use the passwordFormat as Hased then it is unable to retrieve the password. Bottom line is i want to send the password to the user which is hashed one. What is the workaround for this one. I am searching in google, but no suitable answers were found. It would be great full if any one give your helping hand.
I followed these link1, link2 but didn't give any solution.
As far as I am aware it's not possible to derive the plain text password from the hashed password stored in the database. If you need to send the plain text password via e-mail then you will need to keep track of it separately.
Depending on how your code is written it could just be as straightforward as saving the result of Membership.GeneratePassword() to a string variable and ensuring you send that in the e-mail and not any password values retrieved from the database.
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'm migrating an application from ColdFusion to ASP.Net MVC and have a little problem I cannot seem to get my head around. The original application stores user's passwords in a MD5 hash format with no salt in the database. I'm using the ASP.Net membership store and would like to allow for as seamless a transition for the existing users as possible. Here's the possibilities I was thinking of...
1) Since I cannot decrypt the values of their current passwords, I was thinking of storing this old password in a table, checking against it on login... if it's not empty and their password matches, I prompt them to update their password, which would then set the password properly in the asp.net membership table and wipe out their old password, never to be checked again.
2) Users login with their email, not their screen name, so I was thinking of resetting everyone's password to their screen name and forcing them to change it after first login. The only problem is that I'm not sure I can update their password via SQL without the current password. Executing the aspnet_Membership_SetPassword proc doesn't appear to encrypt the password in its own.
What you say?
I've used a variant of #1 in a live application. It worked great, users never noticed the change as far as I was aware.
A couple of refinements:
You don't need to prompt them to update their password; they provided you the cleartext to log in (and you know it's the correct cleartext since it hashed correctly), so just go ahead and set that as their password.
Make sure you clear the legacy password hash if they use the password reset functionality.
I would under no circumstances use option 2; it's wildly insecure.
One other thing -- it is possible to set a password without knowing their current one, it just requires two steps.
Reset the user's password. You now know the reset password.
Use the newly reset password to set the password to a known value.
I had a similar situation recently- An old application of mine used a salted MD5 and I very much wanted to upgrade without affecting my users. What I ended up doing was wrapping the original hash in a better hash and then re-salting it to mitigate the loss of resolution.
For example my initial hash was MD5(pass + salt)
I upgraded everything to SHA256(MD5(pass+salt) +salt) - that way my app is secure and I never needed to find out the original passwords or reset anything.
Once your new authentication process is in place simply run an update script over all existing users in the DB. It is a little bit of a pain but is essentially seamless for you users.
--
Bah- I apologize, this isn't really tailored to ASP.net membership as I'm using a custom auth class on my application. I still think it is one of the more sound methods for performing the upgrade, but i'm not sure of the ASP.net membership specifics.
Option 2 is a pretty big security risk. If anyone knows the email of a screen name can log hijack that account before the rightful owner logs in. Knowing or guessing the email of most popular site users (ie. most tempting ones to hijack) may be more prevalent than you think.