Page 2 of 2

Posted: Tue Mar 20, 2007 7:15 pm
by stereofrog
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.
Yes, but how do you know it's me who's requesting my password to be resent?

Posted: Tue Mar 20, 2007 8:15 pm
by onion2k
stereofrog wrote:Yes, but how do you know it's me who's requesting my password to be resent?
The process is very simple:

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.

Posted: Tue Mar 20, 2007 10:31 pm
by RobertGonzalez
onion2k wrote:
stereofrog wrote:Yes, but how do you know it's me who's requesting my password to be resent?
The process is very simple:

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.
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.

Reply

Posted: Wed Mar 21, 2007 5:04 am
by user___
Thank you guys.

Posted: Wed Mar 21, 2007 9:54 am
by Mordred
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.
Can you please expand a bit more on this? What is the form of this challenge/response - is it like a secret question/answer?
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 :/
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.
1. A local file disclosure vulnerability may errr disclose the key.
2. If you don't force the admin to choose a looooooooooooong key, it can be bruteforced with a known plaintext attack.
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.
Temporary is definitely the keyword. Others in the thread have already elaborated on that.

Posted: Wed Mar 21, 2007 9:58 am
by Zu
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.

Posted: Wed Mar 21, 2007 10:26 am
by RobertGonzalez
Mordred wrote:
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.
Can you please expand a bit more on this? What is the form of this challenge/response - is it like a secret question/answer?
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 :/
I keep between 8 and 12 generic questions in a database. They can be something like this:

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          |
+---------------+----------------------------------------+
The user, when signing up selects a challenge from the list and adds their answer. The challenge id is stored in their row of the user table along with the response. If the email address they present is found in the database, the challenge is brought back from the that search. They have to answer that challenge with their response that is in the database. If that passes, they are deactivated, sent an email with an activation code, a new temporary password and instructions on how to get back in.

Posted: Wed Mar 21, 2007 11:14 am
by onion2k
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.
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.