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 1 of 2  [1] 2  Next page →

#13053 — Most secure way to reset a password via email link

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.

[toc] | [next] | [standalone]

#13054

On 3/5/2014 8:02 AM, 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.
>

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
jstucklex@attglobal.net
==================

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

#13055

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

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

#13056

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.

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

#13057

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)?

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

#13059

Am 05.03.2014 16:54, jvd_200089@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

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

#13217

Am 05.03.2014 17:34, schrieb Gregor Kofler:
> Am 05.03.2014 16:54, jvd_200089@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.

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
http://arnowelzel.de
http://de-rec-fahrrad.de

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

#13061

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, denismfmcmahon@gmail.com

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

#13063

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


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

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

#13058

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

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

#13060

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

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

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

#13062

J.O. Aho wrote:
> On 05/03/14 14:02, jvd_200089@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
*****************************

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

#13064

On Wed, 05 Mar 2014 14:26:21 -0700, Chuck Anderson wrote:
> J.O. Aho wrote:
>> On 05/03/14 14:02, jvd_200089@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

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

#13065

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.

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

#13066

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


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

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

#13067

tnp@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/

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

#13068

On 06/03/14 00:30, Geoff Muldoon wrote:
> tnp@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..


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

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

#13069

In article <lf8h7j$nas$1@news.albasani.net>, tnp@invalid.invalid says...
> 
> On 06/03/14 00:30, Geoff Muldoon wrote:
> > tnp@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

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

#13218

Am 06.03.2014 01:58, schrieb The Natural Philosopher:
> On 06/03/14 00:30, Geoff Muldoon wrote:
>> tnp@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>


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

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

#13072

Geoff Muldoon wrote:
> tnp@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/
>   

I use Firefox and it does the same thing.

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web