Yes, but how do you know it's me who's requesting my password to be resent?onion2k wrote: If the user uses a standard password across all their accounts then the chance of them having forgotten it is pretty small. Besides, I'd say that's more reason to send it to them: they might learn why that's such an incredibly bad idea.
MD5
Moderator: General Moderators
- stereofrog
- Forum Contributor
- Posts: 386
- Joined: Mon Dec 04, 2006 6:10 am
The process is very simple:stereofrog wrote:Yes, but how do you know it's me who's requesting my password to be resent?
1. The user loses their password, or a 'hacker' choses an account to try to hack.
2. The user clicks the "forgotten password" button.
3. An email is sent to the user's registered email address.
4. The email is read and some action is taken.
At point 3 you generate a method of logging in without knowledge of the existing password, be that a new password, a one-time password, or retrieving the old password, and you email it to the user's registered email address. Whatever the system of storing passwords you use this is a security issue if the user's email account has been compromised. There's no way around this. In order to allow legitimate users to generate a new login password or retrieve their old password you have to trust that their email account is secure or else you have no way to send them the new details.
Sending the user their old password means that users are less likely to forget their password over and over again, or worse to write it down so that they remember it, thus improving the quality of the experience using my websites. If they choose to use the same password on every website and their email address has been compromised then that's a shame, but it's really not my problem.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
To expand on this, I also use a challenge and response setup so that when the user enters their email address, they are presented with a challenge to respond to only if the email address checks out. In my systems, email addresses are always unique so there will always only be one challenge, and corresponding response, to each email address. Once the challenge is responded to correctly an email is generated to the registered email address. At the same time, the account is deactivated and will not reactivate until the user activates their account with the activation code in the email sent to them. A flag is also set that will require them to change their password on the next login and will not let them do anything until their password is changed.onion2k wrote:The process is very simple:stereofrog wrote:Yes, but how do you know it's me who's requesting my password to be resent?
1. The user loses their password, or a 'hacker' choses an account to try to hack.
2. The user clicks the "forgotten password" button.
3. An email is sent to the user's registered email address.
4. The email is read and some action is taken.
Can you please expand a bit more on this? What is the form of this challenge/response - is it like a secret question/answer?Everah wrote:To expand on this, I also use a challenge and response setup so that when the user enters their email address, they are presented with a challenge to respond to only if the email address checks out.
To the second part of the sentence - it's a long shot, but it seems like an interface to check for valid email addresses of your users :/
1. A local file disclosure vulnerability may errr disclose the key.onion2k wrote:AES is a US government standard for encrypting non-classified data. It's never been compromised using any direct attack (there's side channel attacks that work, but they're tricky and need 'live' access to the encryption process). It's more than secure enough for website passwords.
2. If you don't force the admin to choose a looooooooooooong key, it can be bruteforced with a known plaintext attack.
Temporary is definitely the keyword. Others in the thread have already elaborated on that.onion2k wrote:As for sending plain text passwords by email, so what? You have to email the user something that lets them access their account, be it a link, password, or temporary passkey.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
I keep between 8 and 12 generic questions in a database. They can be something like this:Mordred wrote:Can you please expand a bit more on this? What is the form of this challenge/response - is it like a secret question/answer?Everah wrote:To expand on this, I also use a challenge and response setup so that when the user enters their email address, they are presented with a challenge to respond to only if the email address checks out.
To the second part of the sentence - it's a long shot, but it seems like an interface to check for valid email addresses of your users :/
Code: Select all
+---------------+----------------------------------------+
|challenge_id | challenge_text |
+---------------+----------------------------------------+
|1 + What was your first pet's name |
+---------------+----------------------------------------+
|2 + What was the name of your first school |
+---------------+----------------------------------------+
|3 + What color was your first car |
+---------------+----------------------------------------+No. If the email address has been compromised then anything that lets the user log in, even with only a temporary password, is going to compromise the account. The nefarious hacker will change their password to a random word if they're forced to. The fact is you have to trust their registered email account if you're going to send them a password, activation link, whatever. If you trust their email account then there's no reason not to send them their existing password.Zu wrote:Seems like you are also forgetting that once someone receives a random password the first thing they tend to do is change it to their default password. Thus making the email password void.