Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #13053 > unrolled thread

Most secure way to reset a password via email link

Back to article view | Back to comp.lang.php

Contents

  Most secure way to reset a password via email link jvd_200089@yahoo.co.uk - 2014-03-05 05:02 -0800
    Re: Most secure way to reset a password via email link Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-05 08:49 -0500
    Re: Most secure way to reset a password via email link Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-05 14:56 +0000
      Re: Most secure way to reset a password via email link The Natural Philosopher <tnp@invalid.invalid> - 2014-03-05 15:35 +0000
        Re: Most secure way to reset a password via email link jvd_200089@yahoo.co.uk - 2014-03-05 07:54 -0800
          Re: Most secure way to reset a password via email link Gregor Kofler <usenet@gregorkofler.com> - 2014-03-05 17:34 +0100
            Re: Most secure way to reset a password via email link Arno Welzel <usenet@arnowelzel.de> - 2014-03-19 17:05 +0100
          Re: Most secure way to reset a password via email link Denis McMahon <denismfmcmahon@gmail.com> - 2014-03-05 19:51 +0000
            Re: Most secure way to reset a password via email link The Natural Philosopher <tnp@invalid.invalid> - 2014-03-05 21:47 +0000
      Re: Most secure way to reset a password via email link Christoph Michael Becker <cmbecker69@arcor.de> - 2014-03-05 17:29 +0100
    Re: Most secure way to reset a password via email link "J.O. Aho" <user@example.net> - 2014-03-05 18:53 +0100
      Re: Most secure way to reset a password via email link Chuck Anderson <cycletourist@invalid.invalid> - 2014-03-05 14:26 -0700
        Re: Most secure way to reset a password via email link "Peter H. Coffin" <hellsop@ninehells.com> - 2014-03-05 16:44 -0600
        Re: Most secure way to reset a password via email link Richard Yates <richard@yatesguitar.com> - 2014-03-05 15:51 -0800
          Re: Most secure way to reset a password via email link The Natural Philosopher <tnp@invalid.invalid> - 2014-03-06 00:12 +0000
            Re: Most secure way to reset a password via email link Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-03-06 11:30 +1100
              Re: Most secure way to reset a password via email link The Natural Philosopher <tnp@invalid.invalid> - 2014-03-06 00:58 +0000
                Re: Most secure way to reset a password via email link Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-03-06 13:38 +1100
                Re: Most secure way to reset a password via email link Arno Welzel <usenet@arnowelzel.de> - 2014-03-19 17:08 +0100
              Re: Most secure way to reset a password via email link Chuck Anderson <cycletourist@invalid.invalid> - 2014-03-05 21:13 -0700
                Re: Most secure way to reset a password via email link Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-03-06 16:17 +1100
                  Re: Most secure way to reset a password via email link Chuck Anderson <cycletourist@invalid.invalid> - 2014-03-06 22:53 -0700
        Re: Most secure way to reset a password via email link gordonb.9e9ri@burditt.org (Gordon Burditt) - 2014-03-29 01:28 -0500
    Re: Most secure way to reset a password via email link jnorth.au@example.com - 2014-03-06 13:58 +1100
      Re: Most secure way to reset a password via email link Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-06 03:32 +0000
        Re: Most secure way to reset a password via email link jnorth.au@example.com - 2014-03-07 12:41 +1100
          Re: Most secure way to reset a password via email link Chuck Anderson <cycletourist@invalid.invalid> - 2014-03-06 22:55 -0700
            Re: Most secure way to reset a password via email link jnorth.au@example.com - 2014-03-07 18:45 +1100
      Re: Most secure way to reset a password via email link jvd_200089@yahoo.co.uk - 2014-03-06 05:35 -0800
    Re: Most secure way to reset a password via email link Arno Welzel <usenet@arnowelzel.de> - 2014-03-19 17:01 +0100

Page 2 of 2 — ← Prev page 1 [2]

#13073

cycletourist@invalid.invalid says...

> >> have a file full of passwords and encrypt THAT with a secret key
> >
> > http://keepass.info/
> 
> I use Firefox and it does the same thing.

For non-web applications?

G

[toc] | [prev] | [next] | [standalone]

#13079

Geoff Muldoon wrote:
> cycletourist@invalid.invalid says...
>
>   
>>>> have a file full of passwords and encrypt THAT with a secret key
>>>>         
>>> http://keepass.info/
>>>       
>> I use Firefox and it does the same thing.
>>     
>
> For non-web applications?
>
> G
>   

Non-web passwords?

-- 
*****************************
 Chuck Anderson • Boulder, CO
  http://cycletourist.com
 Turn Off, Tune Out, Drop In
*****************************

[toc] | [prev] | [next] | [standalone]

#13282

> Yes, ... I hate these challenge question schemes. I do not like being 
> forced to share things like my mother's maiden name - or other, perhaps, 
> private information with other people. Do they hash those answers, too? 

Don't give out personal information.  Lie.  Make it as blatant as
you want.  You might get fired for lying on a job application, but
I don't think the same applies to passwords and security questions.

I think it's best that your answer is something that no reasonable
person would give as an answer to the question if it wasn't a
security question.  Your mother's maiden name should be anything
but a name.  Your first child's birthday should not be a date.  Your
home town should not be a city, town, or village (at least not one
on Earth).  If you are sure you will never be asked for your password
over the phone or in person by a human, you could try a phrase
loaded with cusswords that will get you punched out if you said it
in person.

Some people think they can get away from forced disclosure of
passwords to the US government by making their password a confession
to a crime.  I doubt this will work.  It also involves more typing
than most people will put up with, and most systems won't let you
enter a pass-novel as a password.

> If not, it's like giving away the keys to any other site where I use 
> that. 

You should presume that anything you enter can be gotten in plaintext
by a technical employee at the site, regardless of how it's officially
stored.  A good explanation of SSL I've heard:  SSL allows you to
deliver your credit card number to the thief that owns the web site
securely so that he can rip you off before other thieves max out
your card.  Well, perhaps that's a bit harsh, but SSL will not
protect you from the owner/operator of the site you intend to send
data to.

Don't share passwords between different sites managed by different
companies.  Don't share passwords between your bank and Facebook,
or between work accounts and personal accounts.  I suppose a
rogue admin at a social networking site might have a good chance
of raiding customer bank accounts given the password, name, and
whatever useful personal information is put on the site.

> If I pick a random question and supply a random answer, how do I 
> remember it?

I have a few hundred personal passwords.  The first thing to realize
is that I *DON'T* need to keep 90% of them handy at all times.  For
most of them, it's fine if I have to go home to get the password
and use it from there.  Accessing your property tax account just
isn't urgent enough to require accessing it from an Internet cafe
unless you kept putting it off for a couple of months.

People usually do a pretty good job keeping their wallet secure,
even though they carry it around with them.  This is probably OK
except for keeping it secure from people you live with (spouses,
kids, parents).  Go ahead and write it down - it's much better than
having one or a few passwords you use for all sites.  It might be
a good idea to put passwords on one piece of paper and what they
are for on another.

If you can find a good phone app that stores your passwords encrypted
on the phone, that might work well.

> I noticed that my answer at one site can be mistyped slightly and still 
> pass. This would imply that they are saving this information in plain 
> text. Stupid is as stupid does.

Or perhaps worse, they chop it at N characters and then hash those.
N = 8 is sometimes found with Unix-style password hashing.

> I think this kind of thing (and requirements on password strength) 
> create a security problem of their own by forcing people to record this 
> information somewhere and then keep it handy.

I'm not sure that's such a bad thing.  It may present a problem if
you really need to keep this information secret from someone you
live with.

> To the OP - it has been said - do not store passwords in plain text or a 
> retrievable form. Use a one way hash. Any site that can "send me my 
> password if I forgot" is a big security risk.

Agreed.  However, beware if the hash of the password *becomes* the
password:  you can get access knowing the hash but not the password.


Someone came up with an interesting way of assigning unique numbers
to a device easily, and it might work for passwords also.  It costs
US $1 for each unique number.  To make a Facebook password, you
take a $1 bill and write "Facebook" on it.  The password is a
combination of the series year, and the serial number of the bill.
If you want to change your password, get another $1 bill and spend
the first one.  If you keep these bills in your wallet, just remember
not to spend them.  Also watch out for getting your own or someone
else's old passwords in change.

[toc] | [prev] | [next] | [standalone]

#13070

On Wed, 5 Mar 2014 05:02:50 -0800 (PST), jvd_200089@yahoo.co.uk wrote:

>When resetting a password:
>1) Emailing a new password that the user then logs in with and resets is the most simple method for non hashed passwords.
>
>2) The other way involves sending a link for them to click on that redirects them to the password reset page but unless their email is secure anyone could click that link. What is special about this 2nd way? because thats what how my boss wants it to work because there is not point doing it that way if it isn't  more secure than sending them a temporary new password.
>
>Also any source code examples for option 2 would be appreciated.

Another method which you might want to consider is:
Sending an email stating that the next time they login they will need to reset their password.

In the database and the user table have a field that will indicate whether or not the password needs
to be reset.

If a reset is required then redirect them to the change password file.

This way their is no 'confidential' information being sent via email.

HTH

[toc] | [prev] | [next] | [standalone]

#13071

jnorth.au@example.com writes:

> On Wed, 5 Mar 2014 05:02:50 -0800 (PST), jvd_200089@yahoo.co.uk wrote:
>
>>When resetting a password:
>>1) Emailing a new password that the user then logs in with and resets
>>is the most simple method for non hashed passwords.
>>
>>2) The other way involves sending a link for them to click on that
>>redirects them to the password reset page but unless their email is
>>secure anyone could click that link. What is special about this 2nd
>>way? because thats what how my boss wants it to work because there is
>>not point doing it that way if it isn't more secure than sending them
>>a temporary new password.
>>
>>Also any source code examples for option 2 would be appreciated.
>
> Another method which you might want to consider is:
> Sending an email stating that the next time they login they will need
> to reset their password.
>
> In the database and the user table have a field that will indicate
> whether or not the password needs to be reset.
>
> If a reset is required then redirect them to the change password file.
>
> This way their is no 'confidential' information being sent via email.

I think the OP is talking about a situation where the user can't log in
any more and has requested a "reset".  If the user can't log in,
allowing them to change their password is not a safe option!

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#13078

On Thu, 06 Mar 2014 03:32:17 +0000, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

>jnorth.au@example.com writes:
>
>> On Wed, 5 Mar 2014 05:02:50 -0800 (PST), jvd_200089@yahoo.co.uk wrote:
>>
>>>When resetting a password:
>>>1) Emailing a new password that the user then logs in with and resets
>>>is the most simple method for non hashed passwords.
>>>
>>>2) The other way involves sending a link for them to click on that
>>>redirects them to the password reset page but unless their email is
>>>secure anyone could click that link. What is special about this 2nd
>>>way? because thats what how my boss wants it to work because there is
>>>not point doing it that way if it isn't more secure than sending them
>>>a temporary new password.
>>>
>>>Also any source code examples for option 2 would be appreciated.
>>
>> Another method which you might want to consider is:
>> Sending an email stating that the next time they login they will need
>> to reset their password.
>>
>> In the database and the user table have a field that will indicate
>> whether or not the password needs to be reset.
>>
>> If a reset is required then redirect them to the change password file.
>>
>> This way their is no 'confidential' information being sent via email.
>
>I think the OP is talking about a situation where the user can't log in
>any more and has requested a "reset".  If the user can't log in,
>allowing them to change their password is not a safe option!

I agree but the simple method of using only username/email and password is never going to be secure.
While the OP's second method is a bit more secure there are still problems. How do you know, with
any certainty that this is the person who is responding the the email?

Using email address as a username is not a good idea as these can be easily guessed.

To achieve more certainty of the person requesting a password reset would be to set up some
challenge questions (which the user set up when first registering). If they pass those then you are
probably dealing with the right person.

[toc] | [prev] | [next] | [standalone]

#13080

jnorth.au@example.com wrote:
> On Thu, 06 Mar 2014 03:32:17 +0000, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>   
>> jnorth.au@example.com writes:
>>
>>     
>>> On Wed, 5 Mar 2014 05:02:50 -0800 (PST), jvd_200089@yahoo.co.uk wrote:
>>>
>>>       
>>>> When resetting a password:
>>>> 1) Emailing a new password that the user then logs in with and resets
>>>> is the most simple method for non hashed passwords.
>>>>
>>>> 2) The other way involves sending a link for them to click on that
>>>> redirects them to the password reset page but unless their email is
>>>> secure anyone could click that link. What is special about this 2nd
>>>> way? because thats what how my boss wants it to work because there is
>>>> not point doing it that way if it isn't more secure than sending them
>>>> a temporary new password.
>>>>
>>>> Also any source code examples for option 2 would be appreciated.
>>>>         
>>> Another method which you might want to consider is:
>>> Sending an email stating that the next time they login they will need
>>> to reset their password.
>>>
>>> In the database and the user table have a field that will indicate
>>> whether or not the password needs to be reset.
>>>
>>> If a reset is required then redirect them to the change password file.
>>>
>>> This way their is no 'confidential' information being sent via email.
>>>       
>> I think the OP is talking about a situation where the user can't log in
>> any more and has requested a "reset".  If the user can't log in,
>> allowing them to change their password is not a safe option!
>>     
>
> I agree but the simple method of using only username/email and password is never going to be secure.
> While the OP's second method is a bit more secure there are still problems. How do you know, with
> any certainty that this is the person who is responding the the email?
>
> Using email address as a username is not a good idea as these can be easily guessed.
>
> To achieve more certainty of the person requesting a password reset would be to set up some
> challenge questions (which the user set up when first registering). If they pass those then you are
> probably dealing with the right person.
>   

Isn't "what's your email address?" the equivalent of a challenge question?

-- 
*****************************
 Chuck Anderson • Boulder, CO
  http://cycletourist.com
 Turn Off, Tune Out, Drop In
*****************************

[toc] | [prev] | [next] | [standalone]

#13081

On Thu, 06 Mar 2014 22:55:50 -0700, Chuck Anderson <cycletourist@invalid.invalid> wrote:

>jnorth.au@example.com wrote:
>> On Thu, 06 Mar 2014 03:32:17 +0000, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>   
>>> jnorth.au@example.com writes:
>>>
>>>     
>>>> On Wed, 5 Mar 2014 05:02:50 -0800 (PST), jvd_200089@yahoo.co.uk wrote:
>>>>
>>>>       
>>>>> When resetting a password:
>>>>> 1) Emailing a new password that the user then logs in with and resets
>>>>> is the most simple method for non hashed passwords.
>>>>>
>>>>> 2) The other way involves sending a link for them to click on that
>>>>> redirects them to the password reset page but unless their email is
>>>>> secure anyone could click that link. What is special about this 2nd
>>>>> way? because thats what how my boss wants it to work because there is
>>>>> not point doing it that way if it isn't more secure than sending them
>>>>> a temporary new password.
>>>>>
>>>>> Also any source code examples for option 2 would be appreciated.
>>>>>         
>>>> Another method which you might want to consider is:
>>>> Sending an email stating that the next time they login they will need
>>>> to reset their password.
>>>>
>>>> In the database and the user table have a field that will indicate
>>>> whether or not the password needs to be reset.
>>>>
>>>> If a reset is required then redirect them to the change password file.
>>>>
>>>> This way their is no 'confidential' information being sent via email.
>>>>       
>>> I think the OP is talking about a situation where the user can't log in
>>> any more and has requested a "reset".  If the user can't log in,
>>> allowing them to change their password is not a safe option!
>>>     
>>
>> I agree but the simple method of using only username/email and password is never going to be secure.
>> While the OP's second method is a bit more secure there are still problems. How do you know, with
>> any certainty that this is the person who is responding the the email?
>>
>> Using email address as a username is not a good idea as these can be easily guessed.
>>
>> To achieve more certainty of the person requesting a password reset would be to set up some
>> challenge questions (which the user set up when first registering). If they pass those then you are
>> probably dealing with the right person.
>>   
>
>Isn't "what's your email address?" the equivalent of a challenge question?

Only for the intellectually challenged.

[toc] | [prev] | [next] | [standalone]

#13075

On Thursday, 6 March 2014 02:58:01 UTC, jnor...@example.com  wrote:

> Another method which you might want to consider is:
> 
> Sending an email stating that the next time they login they will need to reset their password.

The main purpose of the password reset option is incase someone loses their password in which case they cannot log in.

[toc] | [prev] | [next] | [standalone]

#13216

Am 05.03.2014 14:02, schrieb jvd_200089@yahoo.co.uk:

> When resetting a password:
> 
> 1) Emailing a new password that the user then logs in with and resets
> is the most simple method for non hashed passwords.

Even for hashed ones, since it is always possible to generate a password
to send and the hash for it on the server.

> 2) The other way involves sending a link for them to click on that
> redirects them to the password reset page but unless their email is
> secure anyone could click that link. What is special about this 2nd
> way? because thats what how my boss wants it to work because there is
> not point doing it that way if it isn't  more secure than sending
> them a temporary new password.

There is no difference between the two ways concerning security.

*Every* e-mail is not secure as long as the transmission is not
encrypted. It doesn't matter if the mail contains a new password or a
link. If the attacker gets access to the mail and also knows the account
associated with, he will get access to the account.

> Also any source code examples for option 2 would be appreciated.

I don't have code - just the way to do it:

Set a flag in the user account that it is "locked" and the user must set
a new password and can not use the old one any longer. Then send an
e-mail with the URL where the user can enter a new password.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.php

csiph-web