Most secure way to reset a password via email link

[jvd_2...@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.

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.

[Jerry Stuckle]

Either choice is only as secure as the email.

Actually doing it will be dependent on your installation. Basically,
you need to create a password reset page; when the user requests a new
password, generate a random string (the longer the better) and store it
somewhere, i.e. in a database. Then email a link with the random string
as a parameter to the url.

When the user clicks on the link and accesses your reset page, get the
parameter from the url and process the request.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Ben Bacarisse]

jvd_2...@yahoo.co.uk writes:

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

This is reasonable provided the only thing that the user can do is log
in to a "change my password" page, and that makes it very similar in
complexity to the second option. It just makes it a tiny bit more fussy
for the user.

If the emailed password can be used as normal until the user changes it,
then this method is less secure than the second. An interloper will get
full access to the user's account until the users gets round to changing
the password -- often with no sign that anything is wrong.

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

In this case, an interloper can do only one thing: reset the password to
something of his or her choosing. They will get access, but the user
will almost certainly know of the compromise very soon. Small comfort
perhaps, but enough that this is the preferred method for most sites.

In short, either you make 1 and 2 virtually the same (in which case 1 is
actually a bit *more* complex) or 2 is slightly safer than 1.

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

I don't have anything I can show, but I would make one recommendation:
don't store passwords directly -- always hash them internally. That
way, an accidental or malicious release of the database (which just
seems to happen time and time again) won't reveal actual passwords.
Some effort (and you can make it significant effort) would be required
to recover the password from the hash. Also, users often re-use
passwords and you won't placate a user whose been told that their
favourite password is now out in the open by saying that they should not
have used it for more than one site -- no matter how true that is!

--
Ben.

[The Natural Philosopher]

On 05/03/14 14:56, Ben Bacarisse wrote:
> I would make one recommendation:
> don't store passwords directly -- always hash them internally. That
> way, an accidental or malicious release of the database (which just
> seems to happen time and time again) won't reveal actual passwords.
> Some effort (and you can make it significant effort) would be required
> to recover the password from the hash. Also, users often re-use
> passwords and you won't placate a user whose been told that their
> favourite password is now out in the open by saying that they should not
> have used it for more than one site -- no matter how true that is!

This is absolutely true and so trivial a matter to do: Unix/linux does
that with user passwords, so too does mysql, and php and mysql both
provide simple methods to generate a hash from a passwords that can be
compared with the stored value.

My final solution is like that.

Also cookies are reset EVERY TIME a user uses a 'secure page'.

So the valid cookie is constantly changing. That way two users with the
same identity will 'log each other out' and a stolen laptop with a
cookie stored in it from a previous sessions still wont access the
database..its no longer valid.Although stored passwords will of course..

Then always use https to avoid man in the middle attacks

Finally as proof against sysadmins, encrypt any sensitive data in the
database.

I use a second cookie which when combined with the first will elucidate
the key..of course the mechanism for doing that is sadly on the server,
and could be cracked, but stealing the database is not enough to reveal
the information. You also need the key generator.

AND then a valid pair of cookies. which the sysadmin normally wouldn't
have, since the cookies are generated on the fly by code..

obviously if he has the time to puzzle through the code, he can
duplicate the functionality..But its not a 5 minute 'steal the mysql files'

But the most compelling thing you must do when addressing security is
NOT use a hosted web server. Use a personally managed virtual private
server. You will need to go deep into the OS to adjust logging and send
warning emails and so on.

security is never complete. But making it hard and closing simpler
loopholes is the game.

Today, to steal a car, you need to get the owner to give you the keys.
It's not a 5 minute job at the kerbside.

Getting access to peoples' names and logins should be similar.



--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.

[jvd_2...@yahoo.co.uk]

On Wednesday, 5 March 2014 15:35:30 UTC, The Natural Philosopher wrote:
> Then always use https to avoid man in the middle attacks

Yes, email link will point to https:// but when using SSL what wrong with just redisplaying the password on the screen (after answer further security questions) because the data sent between server and client will by encrypted whereas an email to a standard pop3 email account won't be (or can you send SLL to a standard email)?

[Christoph Michael Becker]

Ben Bacarisse wrote:

> I don't have anything I can show, but I would make one recommendation:
> don't store passwords directly -- always hash them internally. That
> way, an accidental or malicious release of the database (which just
> seems to happen time and time again) won't reveal actual passwords.
> Some effort (and you can make it significant effort) would be required
> to recover the password from the hash. Also, users often re-use
> passwords and you won't placate a user whose been told that their
> favourite password is now out in the open by saying that they should not
> have used it for more than one site -- no matter how true that is!

OWASP regards password stored as plain text as vulnerability.[1]

[1] <https://www.owasp.org/index.php/Password_Plaintext_Storage>

--
Christoph M. Becker

[Gregor Kofler]

Am 05.03.2014 16:54, jvd_2...@yahoo.co.uk meinte:

> On Wednesday, 5 March 2014 15:35:30 UTC, The Natural Philosopher wrote:
>> Then always use https to avoid man in the middle attacks
>
> Yes, email link will point to https:// but when using SSL what wrong with just redisplaying the password on the screen (after answer further security questions) because the data sent between server and client will by encrypted whereas an email to a standard pop3 email account won't be (or can you send SLL to a standard email)?

TLS will encrypt mails. Provided by practically all contemporary mail
servers and clients.

Gregor

[J.O. Aho]

On 05/03/14 14:02, jvd_2...@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.

Then the password is stored in plain text, even if the user who resets
the password is the owner of the account, someone who gets access to the
mail account will be able to get hold of the password (how many don't
keep those emails with passwords, just in case they would forget it).
There is also the risk of quite many being able to read the password
without access to the email account on it's way from the systems mail
system to the account owners mail account.

This is bad as Christoph already pointed with his link to OWASP.

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

Sure, but you could use those really stupid questions like "what was
your mother maiden name" to make it a bit more difficult to just hijack
when someone taken over someone else mail account.

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

You have the less risk of storing the password in plain text, no one at
your company will be able to get hold of account passwords and as the
user will for sure set a password and more likely to remember it.

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

I think you can manage to solve it by yourself, just sit down five
minutes and think where to store the random generated string which is
part of the url.


--

//Aho

[Denis McMahon]

On Wed, 05 Mar 2014 07:54:35 -0800, jvd_200089 wrote:

> On Wednesday, 5 March 2014 15:35:30 UTC, The Natural Philosopher wrote:

> Yes, email link will point to https:// but when using SSL what wrong
> with just redisplaying the password on the screen

FUCK THE HELL NO!

The ability to display the old password implies that you're either
storing it in the clear (this is worst possible practice) or using a
reversible hashing method (this is the second worst possible practice).

When a user sets a password, it should be one-way hashed[1], and the hash
stored. When a user tries to log in, apply the same one way hashing
function, and check the hash of the supplied password with the stored
hash of the original password.

Never ever ever ever store passwords in a manner that they can be
recovered, because when your database gets hacked (and the whole world
now knows you have a database of passwords waiting to be hacked that
might be stored in the clear) all your customers passwords will be
completely compromised almost immediately.

[1] Hashing includes salting.

--
Denis McMahon, denismf...@gmail.com

[Chuck Anderson]

J.O. Aho wrote:
> On 05/03/14 14:02, jvd_2...@yahoo.co.uk wrote:
>
>> 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.
>
> Sure, but you could use those really stupid questions like "what was
> your mother maiden name" to make it a bit more difficult to just
> hijack when someone taken over someone else mail account.

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?
If not, it's like giving away the keys to any other site where I use
that. If I pick a random question and supply a random answer, how do I
remember it?

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.

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.

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.

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

[The Natural Philosopher]

On 05/03/14 19:51, Denis McMahon wrote:
> On Wed, 05 Mar 2014 07:54:35 -0800, jvd_200089 wrote:
>
>> On Wednesday, 5 March 2014 15:35:30 UTC, The Natural Philosopher wrote:
>
>> Yes, email link will point to https:// but when using SSL what wrong
>> with just redisplaying the password on the screen
>
> FUCK THE HELL NO!

I never said that!!!

Please get the attributions right..

>
> The ability to display the old password implies that you're either
> storing it in the clear (this is worst possible practice) or using a
> reversible hashing method (this is the second worst possible practice).
>
> When a user sets a password, it should be one-way hashed[1], and the hash
> stored. When a user tries to log in, apply the same one way hashing
> function, and check the hash of the supplied password with the stored
> hash of the original password.
>
> Never ever ever ever store passwords in a manner that they can be
> recovered, because when your database gets hacked (and the whole world
> now knows you have a database of passwords waiting to be hacked that
> might be stored in the clear) all your customers passwords will be
> completely compromised almost immediately.
>
> [1] Hashing includes salting.
>


--

[Peter H. Coffin]

On Wed, 05 Mar 2014 14:26:21 -0700, Chuck Anderson wrote:
> J.O. Aho wrote:
>> On 05/03/14 14:02, jvd_2...@yahoo.co.uk wrote:
>>
>>> 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.
>>
>> Sure, but you could use those really stupid questions like "what was
>> your mother maiden name" to make it a bit more difficult to just
>> hijack when someone taken over someone else mail account.
>
> 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?
> If not, it's like giving away the keys to any other site where I use
> that. If I pick a random question and supply a random answer, how do I
> remember it?
>
> 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.

This is not primary authentication -- it's *typically* designed only to
limit the number of spurious passwords resets you could be deluged with.
Someone has to know enough about you to pass that hurdle to even send a
reset. My own sites use a delay mechanism; only one link to reset an
account password will be generated per day. Miss that link, you'll be
trying again tomorrow instead. (The link mailed is what starts the
invalidation/reset process. Merely having the reset link sent doesn't
affect the account at all, save setting a "reset link request date" that
must be in the past before a new reset link can be sent.)

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

Go ahead and write it down. It's more secure these days to record
passwords only you have access to than it is to NOT record whatever
handful of memorable passwords, even combined with some kind of "mental
hash".

--
60. My five-year-old child advisor will also be asked to decipher any
code I am thinking of using. If he breaks the code in under 30
seconds, it will not be used. Note: this also applies to passwords.
--Peter Anspach's list of things to do as an Evil Overlord

[Richard Yates]

On Wed, 05 Mar 2014 14:26:21 -0700, Chuck Anderson

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

Yes!!! The standard recommendations to users about passwords are
simply contradictory or impossible to follow. Based on my brief
experience dealing with others' passwords I believe that, with a few
exceptions, everybody either writes them down or uses the same one in
multiple places.

Personally I confess that I do both.

There's gotta be a better way.

[The Natural Philosopher]

have a file full of passwords and encrypt THAT with a secret key

[Geoff Muldoon]

t...@invalid.invalid says...

>
> On 05/03/14 23:51, Richard Yates wrote:
> > On Wed, 05 Mar 2014 14:26:21 -0700, Chuck Anderson
> >> 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.
> >
> > Yes!!! The standard recommendations to users about passwords are
> > simply contradictory or impossible to follow. Based on my brief
> > experience dealing with others' passwords I believe that, with a few
> > exceptions, everybody either writes them down or uses the same one in
> > multiple places.
> >
> > Personally I confess that I do both.
> >
> > There's gotta be a better way.
> >
> have a file full of passwords and encrypt THAT with a secret key

http://keepass.info/

[The Natural Philosopher]

Assuming you are daft enough to run windows..

[Geoff Muldoon]

In article <lf8h7j$nas$1...@news.albasani.net>, t...@invalid.invalid says...

>
> On 06/03/14 00:30, Geoff Muldoon wrote:
> > t...@invalid.invalid says...
> >>
> >> On 05/03/14 23:51, Richard Yates wrote:
> >>> On Wed, 05 Mar 2014 14:26:21 -0700, Chuck Anderson
> >>>> 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.
> >>>
> >>> Yes!!! The standard recommendations to users about passwords are
> >>> simply contradictory or impossible to follow. Based on my brief
> >>> experience dealing with others' passwords I believe that, with a few
> >>> exceptions, everybody either writes them down or uses the same one in
> >>> multiple places.
> >>>
> >>> Personally I confess that I do both.
> >>>
> >>> There's gotta be a better way.
> >>>
> >> have a file full of passwords and encrypt THAT with a secret key
> >
> > http://keepass.info/
> >
> Assuming you are daft enough to run windows..

"Note that KeePass 2.x runs under Linux / Mac OS X, too; see Running
KeePass under Mono."

RTFM

[jnor...@example.com]

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

[Ben Bacarisse]

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.

[Chuck Anderson]

I use Firefox and it does the same thing.

[Geoff Muldoon]

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

[jvd_2...@yahoo.co.uk]

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.

[jnor...@example.com]

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.

[Chuck Anderson]

Non-web passwords?

[Chuck Anderson]

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

[jnor...@example.com]

Only for the intellectually challenged.

[Arno Welzel]

Am 05.03.2014 14:02, schrieb jvd_2...@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

[Arno Welzel]

TLS will not encrypt mails. TLS is "Transport Layer Security" - it will
only encrypt the connection between the client and the server. But there
is no guarantee that this applies to all smarthots on the way from your
server to the clients (ISP) server.

Mail encryption would be nice - but so far I don't know any service who
offers to use a public PGP key or S/MIME certificate to send encrypted
mails to their customers.

[Arno Welzel]

Am 06.03.2014 01:58, schrieb The Natural Philosopher:
> On 06/03/14 00:30, Geoff Muldoon wrote:
>> t...@invalid.invalid says...
>>>
>>> On 05/03/14 23:51, Richard Yates wrote:
>>>> On Wed, 05 Mar 2014 14:26:21 -0700, Chuck Anderson
>>>>> 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.
>>>>
>>>> Yes!!! The standard recommendations to users about passwords are
>>>> simply contradictory or impossible to follow. Based on my brief
>>>> experience dealing with others' passwords I believe that, with a few
>>>> exceptions, everybody either writes them down or uses the same one in
>>>> multiple places.
>>>>
>>>> Personally I confess that I do both.
>>>>
>>>> There's gotta be a better way.
>>>>
>>> have a file full of passwords and encrypt THAT with a secret key
>>
>> http://keepass.info/
>>
> Assuming you are daft enough to run windows..

Keepass is open source and also available for many other platforms:

<http://keepass.info/download.html>

[Gordon Burditt]

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