Re: Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations)

[Brian]

On Mon 02 Apr 2018 at 09:07:16 -0400, rhkra...@gmail.com wrote:

> Just continuing to think (or maybe not think ;-) about password managers /  
> password security, changing the focus slightly (I think) but keeping the same 
> thread.
> 
> I'm now thinking about the security (or vulnurability) of passwords during 
> "normal" usage--I mean, I'm thinking about the times when a password, even 
> though stored in a very secure manner (in a password manager or encrypted 
> file(s) of some sort), the password is viewable in plain text, and thus, to a 
> greater or lesser degree, vulnurable.

[...]

Your concern is what can be scraped from the clipboard or from memory.
Does it really matter whether a password is inputted through copy and
paste or from  memory (your memory, that is) or via a password manager?
The keyboard or pointing device is still being used.

Secure storage is irrelevant. It's when you come to use it you expose
the password, whether it be by typing it in or through something which
manages passwords.

The solution is never to log in anywhere. :) Life without risk.

Just choose a password manager and stick with it or continue with what
you already do.

-- 
Brian.

Re: Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations)

[Brian]

On Mon 02 Apr 2018 at 09:07:16 -0400, rhkra...@gmail.com wrote:

> Just continuing to think (or maybe not think ;-) about password managers /  
> password security, changing the focus slightly (I think) but keeping the same 
> thread.
> 
> I'm now thinking about the security (or vulnurability) of passwords during 
> "normal" usage--I mean, I'm thinking about the times when a password, even 
> though stored in a very secure manner (in a password manager or encrypted 
> file(s) of some sort), the password is viewable in plain text, and thus, to a 
> greater or lesser degree, vulnurable.
> 
> The first two situations that come to mind include:
> 
>* during copy and paste operations, the plaintext password could remain on 
> the C "stack". thus making it vulnurable:  Some notes:
> 
>   (1) I've read about at least one password manager that, somehow, 
> deletes 
> the plaintext password from the copy and paste "stack" after a time delay--I 
> didn't make a note of which one that was.  
> 
>   (2) another approach could be that a password manager provides a 
> facility to write the password to a designated textbox without using the copy 
> and paste facility, thus, presumably, never putting the plaintext password on 
> the copy and paste "stack").
> 
>* during hibernation (or maybe suspend and resume): (I use neither at the 
> present time, but, one stores the machine's state (including RAM) to disk, 
> the 
> other stores the (CPU) state to RAM while preserving the other contents of 
> RAM.)  Hibernation could result in the plaintext of passwords being stored on 
> disk while the power is off, making the plaintext passwords vulnurable if the 
> machine is stolen.
> 
> My current approach to passwords includes storing them in an encrypted file 
> which is only ever decrypted to a RAMdisk, with the idea / intention that, if 
> power is lost, or the machine is shutdown, the plaintext passwords would 
> disappear from RAM (except to the extent that (iiuc) there are (NSA) ways to 
> recover the contents of RAM if power is restored to the machine fairly 
> quickly).  My assumption, without considering hibernation. was that the only 
> remaining copy of the passwords would be in the encrypted files. 
> 
> Maybe my concern about these situations is unrealistic, but I want to 
> consider 
> it, so all comments are welcome.
> 
> BTW, I can see that the Master Password approach might be the solution for 
> most of the problem, unless I (or it) uses copy and paste to put passwords in 
> a textbox.

If you are referring to masterpassword (masterpasswordapp) then copy
and paste is used here with a configurable timeout to input a password
to an application, and very useful it is too. Other password managers
also use the same technique.

AIUI, the clipboard is specific to my session. If there is another
application in the same session intent on reading the clipboard without
my knowledge, the length of the timeout doesn't really matter because a
microsecond would be sufficient for the master password to be obtained.
Of course, having such a password-reading entity on the machine would
mean I had lost control of the machine (maybe it does key-logging as
well) and would have a much bigger problem than deciding on the timeout
period.

-- 
Brian.

Re: Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations)

[der.hans]

Am 02. Apr, 2018 schwätzte rhkra...@gmail.com so:

moin moin,


Just continuing to think (or maybe not think ;-) about password managers /
password security, changing the focus slightly (I think) but keeping the same
thread.

I'm now thinking about the security (or vulnurability) of passwords during
"normal" usage--I mean, I'm thinking about the times when a password, even
though stored in a very secure manner (in a password manager or encrypted
file(s) of some sort), the password is viewable in plain text, and thus, to a
greater or lesser degree, vulnurable.

The first two situations that come to mind include:

  * during copy and paste operations, the plaintext password could remain on
the C "stack". thus making it vulnurable:  Some notes:

 (1) I've read about at least one password manager that, somehow, deletes
the plaintext password from the copy and paste "stack" after a time delay--I
didn't make a note of which one that was.


Clipboard expiration was the feature that got me to finally consider a
password manager rather than my roll-your-own gpg script.

As I understand it, the clipboard is told to delete the contents after a
given time. That time is configurable for the KeePassX tools. I believe it
defaults to 20 seconds. It doesn't work for extra fields, e.g. if you have
security answers, but does for the password. It would be nice if the
auto-expire fields were configurable. Maybe they are in KeePassXC. I need
to finally move to that fork.


 (2) another approach could be that a password manager provides a
facility to write the password to a designated textbox without using the copy
and paste facility, thus, presumably, never putting the plaintext password on
the copy and paste "stack").


The auto-play feature might do what you want.

Also, with KeePassXC a feature I have not yet reviewed allows the
browser to prompt KeePassXC for the credentials. KeePassXC will then ask
permission to provide them before answering the application. This also might
do what you want.

Note that in both cases the plain text password is still being
transferred. For the latter, I presume it's possible for an ssh-style
exchange, so the plain text password would be communicated over a secure
channel. As I said, I haven't yet looked at it.

In any case, it's definitely people more knowledgeable than me
implementing the security in the open with multiple people looking at the
work. In other words, way better than anything I can create on my own :).

There's probably a FAQ on how KeePassX protects data in memory.

ciao,

der.hans


  * during hibernation (or maybe suspend and resume): (I use neither at the
present time, but, one stores the machine's state (including RAM) to disk, the
other stores the (CPU) state to RAM while preserving the other contents of
RAM.)  Hibernation could result in the plaintext of passwords being stored on
disk while the power is off, making the plaintext passwords vulnurable if the
machine is stolen.

My current approach to passwords includes storing them in an encrypted file
which is only ever decrypted to a RAMdisk, with the idea / intention that, if
power is lost, or the machine is shutdown, the plaintext passwords would
disappear from RAM (except to the extent that (iiuc) there are (NSA) ways to
recover the contents of RAM if power is restored to the machine fairly
quickly).  My assumption, without considering hibernation. was that the only
remaining copy of the passwords would be in the encrypted files.

Maybe my concern about these situations is unrealistic, but I want to consider
it, so all comments are welcome.

BTW, I can see that the Master Password approach might be the solution for
most of the problem, unless I (or it) uses copy and paste to put passwords in
a textbox.





On Friday, March 30, 2018 09:44:18 PM Andrew McGlashan wrote:



--
#  https://www.LuftHans.com   https://www.PhxLinux.org
#  Knowledge is useless unless it's shared. - der.hans

Re: Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations)

[rhkramer]

Thanks to tomas, Roberto, and likcoras!  All good points!

I'm embarrassed to admit that I hadn't thought (at least to the best of my 
recent recollection) of the need to encrypt swap--that's something I'll want 
to deal with soon.


On Monday, April 02, 2018 09:15:08 AM to...@tuxteam.de wrote:
> On Mon, Apr 02, 2018 at 09:07:16AM -0400, rhkra...@gmail.com wrote:
> > Just continuing to think (or maybe not think ;-) about password managers
> > /
> 
> [...]
> 
> I don't know of the others (I never felt the need for a PW manager
> myself) but...
> 
> >* during hibernation (or maybe suspend and resume): (I use neither at
> >the
> > 
> > present time, but, one stores the machine's state (including RAM) to
> > disk, the other stores the (CPU) state to RAM while preserving the other
> > contents of RAM.)  Hibernation could result in the plaintext of
> > passwords being stored on disk while the power is off, making the
> > plaintext passwords vulnurable if the machine is stolen.
> 
> ...that would be why, should you suspend to disk and care about privacy,
> you'd put your swap onto an encrypted partition (not only passwords are
> vulnerable -- many things in RAM like unlocked private keys, session keys
> etc. are potential targets).
> 
> Cheers
> -- tomás

Re: Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations)

[Roberto C . Sánchez]

On Mon, Apr 02, 2018 at 09:07:16AM -0400, rhkra...@gmail.com wrote:
> 
> The first two situations that come to mind include:
> 
>* during copy and paste operations, the plaintext password could remain on 
> the C "stack". thus making it vulnurable:  Some notes:
> 
>   (1) I've read about at least one password manager that, somehow, 
> deletes 
> the plaintext password from the copy and paste "stack" after a time delay--I 
> didn't make a note of which one that was.  
> 
I use keepasssx and it has this feature. It is very handy, but very
occasionally frustrating, depending on the UI with which I am
interacting.

> 
>* during hibernation (or maybe suspend and resume): (I use neither at the 
> present time, but, one stores the machine's state (including RAM) to disk, 
> the 
> other stores the (CPU) state to RAM while preserving the other contents of 
> RAM.)  Hibernation could result in the plaintext of passwords being stored on 
> disk while the power is off, making the plaintext passwords vulnurable if the 
> machine is stolen.
> 
Using full disk encryption (or at a very minimum encrypted swap makes
this less of an issue.

Yet another issue that you did not mention but which, IMHO, is a far
more practical one (in the sense that it impacts us every single day yet
we tend to not be aware of it) is that every program to which you supply
your password must securely manage transferring the password into and
out of memory.

If you log in to a display manager, it must take your plaintext password
from a text box and transfer it to another layer of the OS. If you
provide a password to your web browser in an authentication dialog, the
browser must take that plaintext password and either produce a digest
(for digest-based authentication) or send it in the clear (e.g., over a
connection secured with SSL/TLS). It must necessarily reside in memory.

I use mutt and I either must store my passwords in plain text in
~/.muttrc or provide them to mutt when prompted. However, when providing
the password to mutt when prompted, the default for mutt is to remember
the password until the end of the session. It has to be stored
somewhere.

Now, the kernel provides facilities for storing sensitive information in
memory, protecting access to it, and preventing it from getting swapped
to disk. However, when you use the wide variety of applications that
take passwords as input, you necessarily trust that the developers are
using all the appropriate facilities to securely handle the password and
also to securely wipe it from memory. Some applications, I trust because
of their reputation or because they are high profile receive lots of
attention from security researchers (e.g., KeePassX, Firefox, Chromium,
etc.).

However, I have delved into the code of some random applications (the
one that stands out in my mind is an FTP client, though I do not recall
which one it was) that make me think that most applications that handle
passwords do so improperly and insecurely.

I hope I did not open yet another can of worms here for you :-)

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations)

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Apr 02, 2018 at 09:07:16AM -0400, rhkra...@gmail.com wrote:
> Just continuing to think (or maybe not think ;-) about password managers /  

[...]

I don't know of the others (I never felt the need for a PW manager
myself) but...

>* during hibernation (or maybe suspend and resume): (I use neither at the 
> present time, but, one stores the machine's state (including RAM) to disk, 
> the 
> other stores the (CPU) state to RAM while preserving the other contents of 
> RAM.)  Hibernation could result in the plaintext of passwords being stored on 
> disk while the power is off, making the plaintext passwords vulnurable if the 
> machine is stolen.

...that would be why, should you suspend to disk and care about privacy,
you'd put your swap onto an encrypted partition (not only passwords are
vulnerable -- many things in RAM like unlocked private keys, session keys
etc. are potential targets).

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrCLNwACgkQBcgs9XrR2kYOOACePFCCOvj4GdwrZ2izKq9rO2cF
/2sAn11O8aeEMHFvsNO/buej8yWfVmpP
=WHsE
-END PGP SIGNATURE-

Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations)

[rhkramer]

Just continuing to think (or maybe not think ;-) about password managers /  
password security, changing the focus slightly (I think) but keeping the same 
thread.

I'm now thinking about the security (or vulnurability) of passwords during 
"normal" usage--I mean, I'm thinking about the times when a password, even 
though stored in a very secure manner (in a password manager or encrypted 
file(s) of some sort), the password is viewable in plain text, and thus, to a 
greater or lesser degree, vulnurable.

The first two situations that come to mind include:

   * during copy and paste operations, the plaintext password could remain on 
the C "stack". thus making it vulnurable:  Some notes:

  (1) I've read about at least one password manager that, somehow, deletes 
the plaintext password from the copy and paste "stack" after a time delay--I 
didn't make a note of which one that was.  

  (2) another approach could be that a password manager provides a 
facility to write the password to a designated textbox without using the copy 
and paste facility, thus, presumably, never putting the plaintext password on 
the copy and paste "stack").

   * during hibernation (or maybe suspend and resume): (I use neither at the 
present time, but, one stores the machine's state (including RAM) to disk, the 
other stores the (CPU) state to RAM while preserving the other contents of 
RAM.)  Hibernation could result in the plaintext of passwords being stored on 
disk while the power is off, making the plaintext passwords vulnurable if the 
machine is stolen.

My current approach to passwords includes storing them in an encrypted file 
which is only ever decrypted to a RAMdisk, with the idea / intention that, if 
power is lost, or the machine is shutdown, the plaintext passwords would 
disappear from RAM (except to the extent that (iiuc) there are (NSA) ways to 
recover the contents of RAM if power is restored to the machine fairly 
quickly).  My assumption, without considering hibernation. was that the only 
remaining copy of the passwords would be in the encrypted files. 

Maybe my concern about these situations is unrealistic, but I want to consider 
it, so all comments are welcome.

BTW, I can see that the Master Password approach might be the solution for 
most of the problem, unless I (or it) uses copy and paste to put passwords in 
a textbox.





On Friday, March 30, 2018 09:44:18 PM Andrew McGlashan wrote:

Re: Storing "real" user data: was: Re: Update: Re: Password Manager opinions and recommendations

[David Wright]

On Fri 30 Mar 2018 at 12:15:18 (-0400), rhkra...@gmail.com wrote:
> On Friday, March 30, 2018 11:17:32 AM Eduardo M KALINOWSKI wrote:
> > There's ~/.config
> > (https://www.freedesktop.org/software/systemd/man/file-hierarchy.html#~/.co
> > nfig) . Many apps use it, but still the majority uses ~ directly (and
> > probably allways will).
> 
> And now to comment on the above (again)--yes, true, but even if they all used 
> ~/.config, that wouldn't really satisfy me.

But this should convince you that your "vice versa" is a dead duck:
you can only attempt to move people's personal information and leave
the configuration side to evolve as it is doing. I suppose the
creation of ~/{Desktop,Documents,Public,Templates,…} is a step in that
direction.

Cheers, David.

Re: Password Manager opinions and recommendations

[Andrew McGlashan]

On 31/03/18 05:57, der.hans wrote:
> Captcha is still annoying and needs an "I am a cyborg" option.

Cloudfare is an issue, I'm growing to hate it as much as Google, perhaps
more.

CF relies upon Google for captcha, why can't they use and create their own?

I would prefer a captcha from DDG, at least they could better respect my
privacy.

The fact that Google sees every captcha going through CF is bad enough,
but CF is also posing privacy risk themselves as far as I am concerned.

Why the world thinks they need the "protection" of CF is beyond me, the
world is relying far too much on external services when they should be
getting their own house in order if they have the funds and avoid using
any and all 3rd party resources as much as possible (including CDNs).

Kind Regards
AndrewM




signature.asc
Description: OpenPGP digital signature

Re: Update: Re: Password Manager opinions and recommendations

[Cindy-Sue Causey]

On 3/30/18, rhkra...@gmail.com  wrote:
> On Friday, March 30, 2018 08:44:53 AM Curt wrote:
>> On 2018-03-30, Tomaž Šolc  wrote:
>> > Hi
>> >
>> > On 27. 03. 2018 03:02, rhkra...@gmail.com wrote:
>> >> I have what might be called a "religious" aversion to storing what
>> >> I=20
>> >> consider "real" user data in /home.
>> >
>> > I'm curious. Why do you have this aversion and where do you store
>> > "real"
>> > user data?
>> >
>> > This is the first time I've heard about not storing user data in /home.
>> > I thought that's the whole point of /home.
>>
>> Security through obscurity (rather than vice versa).
>
> Well, just for the record, that's not how I'd describe it (but, on further
> thought), that could be a valid alternate / additional description.


I've thought about it on occasion (/home versus anywhere else for
certain user data). I always console myself with.. well-l-l-l, it's
password protected, and that's why I go through the repetitious "pain"
of entering a password ~20 or more times a day every day even as a
private user..

Except that I also know how easily I can access anything I need if
I've mangled a partition or something e.g. made it unbootable yet
I can still snag absolutely anything I need off of it..

That [devil's advocacy] is notoriously a personal *ah-haaa* moment
regarding all of the extensive encryption related discussions here on
this list.. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with duct tape *

Re: Password Manager opinions and recommendations

[der.hans]

Am 30. Mar, 2018 schwätzte rhkra...@gmail.com so:

moin moin,


As I sometimes (often?) do, just commenting on a few points:

On Friday, March 30, 2018 04:39:05 AM der.hans wrote:

Am 26. Mar, 2018 schwätzte Richard Hector so:

On 26/03/18 04:52, rhkra...@gmail.com wrote:



We can add character set requirements and most sites now allow 30+
characters, so they at least look random.


Good point, I hadn't really thought that one through--I thought maybe I'd
generate an intentionally longer password and then just delete unallowable
characters.  (Or maybe the "right size" password and then substitute (random)
allowable characters for the unallowable characters.

I'm not sure what that would do to the cryptographic security if the
passwords.


They should still be fine provided they're long. I sometimes change out
characters.

When I run into password limitations on a site I add notes to the KeePassX
entry, e.g. "max pw length=15" or "doesn't allow % and &". For the latter,
I would change % and & in the randomly generated passwords to some other
non-alnum. That's one of the few occasions that I see passwords for
anything other than system logins.

Also, KeePassX can generate random word groups, ala correct horse battery
staple.

https://xkcd.com/936/

The following article has more info about password generation with
KeePassXC.

https://www.darkreading.com/endpoint/heartbleed-a-password-manager-reality-check/d/d-id/1204549?


   * a means to automatically update passwords on the target websites
   (to

facilitate regular / frequent password changes)--this is probably a
stretch--I mean something that would work its way through the various
screens and prompts to change a password with a minimum of manual
intervention by me


Difficult. That would have to be scripted for each website etc, wouldn't
it?


Many of the KeePass* tools support auto-type which will send a sequence to
the browser. The sequence can use the default pattern or be customized.

I believe one of the commercial, proprietary tools offers to change all
your passwords for you and uses a JavaScript client to do so, so perhaps
there's already a model to replicate.


Hmm, if anybody can shed more light on that, I'd be interested--not sure I
could make use of it in any quick fashion, but, if it exists, I'd like to
learn more about it.


Lastpass has some auto-change functionality. Turns out it's only for
specific sites. I recall claims during the Heartbleed reaction that they
could change all the passwords. Probably me mis-remembering, but they make
other bogus claims ( securely sharing passwords where the recipient can't
see that password ), so I might be remembering correctly.

Lastpass did add a feature to automagically check a site for Heartbleed before
authenticating. That was awesome.

https://helpdesk.lastpass.com/generating-a-password/#h2

Still, we could build templates for different sites with URL and auto-type
script for password changes.

Captcha is still annoying and needs an "I am a cyborg" option.

ciao,

der.hans


I don't use auto-type, so haven't investigated beyond seeing that it's
there. I have had multiple people report that it works well for them.


--
#  https://www.LuftHans.com   https://www.PhxLinux.org
# "I came to open source for the tech, but I stay for the people."
# -- Richard Gaskin, 2016Jan25

Re: Storing "real" user data: was: Re: Update: Re: Password Manager opinions and recommendations

[der.hans]

Am 30. Mar, 2018 schwätzte rhkra...@gmail.com so:

moin moin,

I tend to keep my created data in ~/local/, so ~/local/bin/, ~/local/etc/,
~/local/sandbox/, ~/local/data/, etc.

I then link some of the dotfiles I want to preserve into ~/local/etc/, e.g.
.mozilla, .screenrc and .vim.

I haven't been dilligent enough to force ~/Desktop/ and ~/Documents/ to be
softlinks into ~/local/, so I don't have experience as to whether or not
that would freak tools out.

Some desktop environments helpfully rename those directories when I
switch languages, so I'm certain there would be some issues with the
automagically created directories.

I still back up all of ~/, but I take advantage of ~/local/ for syncing
systems.

ciao,

der.hans


On Friday, March 30, 2018 07:54:03 AM Tomaž Šolc wrote:

Hi

On 27. 03. 2018 03:02, rhkra...@gmail.com wrote:

I have what might be called a "religious" aversion to storing what I
consider "real" user data in /home.


I'm curious. Why do you have this aversion and where do you store "real"
user data?

This is the first time I've heard about not storing user data in /home.
I thought that's the whole point of /home.


Well, it's my religion, and afaik, I have no (or maybe few?) disciples)--or
maybe I should not call them disciples but--what would the word be--
independent "prophets").

Also, it's been a while since I developed that "religion" (I shouldn't call it
a religion, I mean no disrespect to real religions).

Now I'm trying to "remember out loud" (which is sort of like thinking out
loud, only trying to remember rather than think ;-)

One of the first disappointing encounters I had with ~ was when I did something
like intentionally delete it--this could have been back around 2000 or 2001.
I completely forgot (or maybe I hadn't yet learned that there is a lot of stuff
stored in ~ as hidden files.

It (the stuff stored as hidden files) is what I now call "user configuration
data" as opposed to what I call "real user data", which I define as files I've
created or intentionally captured / stored--things like text documents,
letters, spreadsheets, code I may have written, music files, videos, photos,
...--in short, things I [probably | may ] want to keep "forever" (for example,
stuff I want to carry along when I upgrade to a new computer or OS).

When I upgrade to a new computer or OS, I don't necessarily want to carry my
"user configuration data" along--it may be irrelevant or even counter
productive in the new OS.  (To be sure, sometimes the case is just the
opposite--I figured out some configuration that I prefer and I want to carry
that along to the new OS (assuming it will work in the new OS).

In fact, I may be misremembering my first disappointing counter with ~: I may
have done just the opposite of what I described like copy ~ (with my "real
user data" to a new OS and got all of the "user configuration data" along with
the "real user data" which caused some problems with the new OS.

Some asides:

  * that was back in the day when I was first considering my move to LInux--
what I did in those days (with a spare computer) was attempt to install a
LInux distro--if it installed, I then tried it out for anywhere from a few
houirs to maybe a few days or weeks--when I found something I didn't like I'd
try the next distro.  (In those days I found lots of Linux distros, some from
a LUG I belonged to.)

  * in those early days, I may have made both mistakes--that is: carrying
along the "user configuration data" with my "real user data" when I really
didn't want to, and accidentally wiping out my "real user data" when I really
just wanted to wipe out the "user configuration data".

Anyway, to me it was a problem (and I considered it a design mistake) to
combine the two types of data in one directory, and even more so, having one
of the types of data as hidden files / directories so it was too easy (for me)
to forget about it.

So, anyway, after various fits and starts (which included corresponding with
various mailing lists about the problem or ways to get around it), I
considered two solutions each involving moving one of the types of data out of
~.

It became easier to move my "real user data" out of ~. so I created a new (and
eventually more than one) top level directory which I named / (e.g.,
/bill) to store my real user data.

Some of the related problems that I had to overcome included:

  * many applications that I was aware of at the time defaulted to storing
their "real user data" files in ~.  (I.e., if I created a text file with some
useful content, many applications stored that in ~ by default, and some didn't
even have a reasonable way of specifying a different directory (iirc--or, at
least, I couldn't find that reasonable way).  So I had to find different
applications that allowed me to specify where to store the files, and, in some
cases, contacted the authors / maintainers of such software asking them to
provide such a reasonable way.

  IIRC, lots of these things became 

Re: Storing "real" user data: was: Re: Update: Re: Password Manager opinions and recommendations

[rhkramer]

On Friday, March 30, 2018 11:17:32 AM Eduardo M KALINOWSKI wrote:
> There's ~/.config
> (https://www.freedesktop.org/software/systemd/man/file-hierarchy.html#~/.co
> nfig) . Many apps use it, but still the majority uses ~ directly (and
> probably allways will).

And now to comment on the above (again)--yes, true, but even if they all used 
~/.config, that wouldn't really satisfy me.

Re: Storing "real" user data: was: Re: Update: Re: Password Manager opinions and recommendations

[rhkramer]

On Friday, March 30, 2018 11:17:32 AM Eduardo M KALINOWSKI wrote:
> There's ~/.config
> (https://www.freedesktop.org/software/systemd/man/file-hierarchy.html#~/.co
> nfig) . Many apps use it, but still the majority uses ~ directly (and
> probably allways will).

True, but I mainly wanted to comment on your sig--I'm sure that's true:

We'll know that rock is dead when you have to get a degree to work in it.

Re: Storing "real" user data: was: Re: Update: Re: Password Manager opinions and recommendations

[Eduardo M KALINOWSKI]

On 30-03-2018 11:47, rhkra...@gmail.com wrote:
> * with that in mind, some of my proposals to various people (including
> the
> FHS) included things like creating a new directory, then keeping one named 
> /home and naming the new one either something like /data (for real user data, 
> and keeping the configuation data in /home, or vice versa--keeping the real 
> user data in /home and creating a new top level directory named maybe 
> something like /config for user configuration data.
There's ~/.config
(https://www.freedesktop.org/software/systemd/man/file-hierarchy.html#~/.config)
. Many apps use it, but still the majority uses ~ directly (and probably
allways will).

-- 
We'll know that rock is dead when you have to get a degree to work in it.

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Storing "real" user data: was: Re: Update: Re: Password Manager opinions and recommendations

[rhkramer]

On Friday, March 30, 2018 09:57:02 AM rhkra...@gmail.com wrote:
> Anyway, these days, I store all my "real user data" in directories other
> than ~, these include directories like /01, /02, (e.g.,
> /bob01, /bob02, /back01, back02), and I have no fear / reluctance to
> create other such top level directories when I feel a need to.  (On the
> other hand, most of my real user data is under directories like (e.g.,)
> /bob01, e.g., /bob01/photos, /bob01/documents, ...
> 
> The one thing I still don't like is that the "user configuration data" is
> stored as hidden files in ~.  I configure any file manager or similar
> software that I use to show hidden files.

Just one (or two) additional thoughts:

   * I can somewhat understand the use of /home for both types of data back in 
the days when a *nix system had many users--having all of the personalized 
data under one directory (/home) made many tasks easier for the admins (e.g., 
they only had to backup one directory to preserve all user data.

   * with that in mind, some of my proposals to various people (including the 
FHS) included things like creating a new directory, then keeping one named 
/home and naming the new one either something like /data (for real user data, 
and keeping the configuation data in /home, or vice versa--keeping the real 
user data in /home and creating a new top level directory named maybe 
something like /config for user configuration data.

Re: Storing "real" user data: was: Re: Update: Re: Password Manager opinions and recommendations

[Greg Wooledge]

On Fri, Mar 30, 2018 at 09:57:02AM -0400, rhkra...@gmail.com wrote:
> It (the stuff stored as hidden files) is what I now call "user configuration 
> data" as opposed to what I call "real user data", which I define as files 
> I've 
> created or intentionally captured / stored--things like text documents, 
> letters, spreadsheets, code I may have written, music files, videos, photos, 
> ...--in short, things I [probably | may ] want to keep "forever" (for 
> example, 
> stuff I want to carry along when I upgrade to a new computer or OS).

For me, everything in /home is equally valuable, and is preserved forever
to the best of my ability, across all system replacements.  Regardless
of whether it was created by a program, or by a human, or a team effort
between the two.

Re: Update: Re: Password Manager opinions and recommendations

[rhkramer]

On Friday, March 30, 2018 08:44:53 AM Curt wrote:
> On 2018-03-30, Tomaž Šolc  wrote:
> > Hi
> > 
> > On 27. 03. 2018 03:02, rhkra...@gmail.com wrote:
> >> I have what might be called a "religious" aversion to storing what I=20
> >> consider "real" user data in /home.
> > 
> > I'm curious. Why do you have this aversion and where do you store "real"
> > user data?
> > 
> > This is the first time I've heard about not storing user data in /home.
> > I thought that's the whole point of /home.
> 
> Security through obscurity (rather than vice versa).

Well, just for the record, that's not how I'd describe it (but, on further 
thought), that could be a valid alternate / additional description.

Storing "real" user data: was: Re: Update: Re: Password Manager opinions and recommendations

[rhkramer]

On Friday, March 30, 2018 07:54:03 AM Tomaž Šolc wrote:
> Hi
> 
> On 27. 03. 2018 03:02, rhkra...@gmail.com wrote:
> > I have what might be called a "religious" aversion to storing what I
> > consider "real" user data in /home.
> 
> I'm curious. Why do you have this aversion and where do you store "real"
> user data?
> 
> This is the first time I've heard about not storing user data in /home.
> I thought that's the whole point of /home.

Well, it's my religion, and afaik, I have no (or maybe few?) disciples)--or 
maybe I should not call them disciples but--what would the word be--
independent "prophets").

Also, it's been a while since I developed that "religion" (I shouldn't call it 
a religion, I mean no disrespect to real religions).

Now I'm trying to "remember out loud" (which is sort of like thinking out 
loud, only trying to remember rather than think ;-)

One of the first disappointing encounters I had with ~ was when I did something 
like intentionally delete it--this could have been back around 2000 or 2001.  
I completely forgot (or maybe I hadn't yet learned that there is a lot of stuff 
stored in ~ as hidden files.  

It (the stuff stored as hidden files) is what I now call "user configuration 
data" as opposed to what I call "real user data", which I define as files I've 
created or intentionally captured / stored--things like text documents, 
letters, spreadsheets, code I may have written, music files, videos, photos, 
...--in short, things I [probably | may ] want to keep "forever" (for example, 
stuff I want to carry along when I upgrade to a new computer or OS).

When I upgrade to a new computer or OS, I don't necessarily want to carry my 
"user configuration data" along--it may be irrelevant or even counter 
productive in the new OS.  (To be sure, sometimes the case is just the 
opposite--I figured out some configuration that I prefer and I want to carry 
that along to the new OS (assuming it will work in the new OS).

In fact, I may be misremembering my first disappointing counter with ~: I may 
have done just the opposite of what I described like copy ~ (with my "real 
user data" to a new OS and got all of the "user configuration data" along with 
the "real user data" which caused some problems with the new OS.

Some asides:

   * that was back in the day when I was first considering my move to LInux--
what I did in those days (with a spare computer) was attempt to install a 
LInux distro--if it installed, I then tried it out for anywhere from a few 
houirs to maybe a few days or weeks--when I found something I didn't like I'd 
try the next distro.  (In those days I found lots of Linux distros, some from 
a LUG I belonged to.)

   * in those early days, I may have made both mistakes--that is: carrying 
along the "user configuration data" with my "real user data" when I really 
didn't want to, and accidentally wiping out my "real user data" when I really 
just wanted to wipe out the "user configuration data".

Anyway, to me it was a problem (and I considered it a design mistake) to 
combine the two types of data in one directory, and even more so, having one 
of the types of data as hidden files / directories so it was too easy (for me) 
to forget about it.

So, anyway, after various fits and starts (which included corresponding with 
various mailing lists about the problem or ways to get around it), I 
considered two solutions each involving moving one of the types of data out of 
~.

It became easier to move my "real user data" out of ~. so I created a new (and 
eventually more than one) top level directory which I named / (e.g., 
/bill) to store my real user data.

Some of the related problems that I had to overcome included:

   * many applications that I was aware of at the time defaulted to storing 
their "real user data" files in ~.  (I.e., if I created a text file with some 
useful content, many applications stored that in ~ by default, and some didn't 
even have a reasonable way of specifying a different directory (iirc--or, at 
least, I couldn't find that reasonable way).  So I had to find different 
applications that allowed me to specify where to store the files, and, in some 
cases, contacted the authors / maintainers of such software asking them to 
provide such a reasonable way.  

   IIRC, lots of these things became easier when I started using a GUI vs. the 
command line, but maybe the early GUIs had the same problem (of defaulting to 
store "real user data" in ~.

   * some of the people I corresponded with seemed to have no concept of what 
I meant by real user data, and it took me a while to find ways to make it clear 
to them.  (Some of them seemed to just consider what I call "user configuration 
data" as the only user data--the only thing that concerned them.)

   * the people and specifications that "controlled" *nix seemed to think it 
was perfectly fine to combine both types of data in one directory, with one 
type hidden.  I spent considerable time "lobbying" 

Re: Password Manager opinions and recommendations

[rhkramer]

As I sometimes (often?) do, just commenting on a few points:

On Friday, March 30, 2018 04:39:05 AM der.hans wrote:
> Am 26. Mar, 2018 schwätzte Richard Hector so:
> > On 26/03/18 04:52, rhkra...@gmail.com wrote:

> We can add character set requirements and most sites now allow 30+
> characters, so they at least look random.

Good point, I hadn't really thought that one through--I thought maybe I'd 
generate an intentionally longer password and then just delete unallowable 
characters.  (Or maybe the "right size" password and then substitute (random) 
allowable characters for the unallowable characters.

I'm not sure what that would do to the cryptographic security if the 
passwords.
 
> >>* a means to automatically update passwords on the target websites
> >>(to
> >> 
> >> facilitate regular / frequent password changes)--this is probably a
> >> stretch--I mean something that would work its way through the various
> >> screens and prompts to change a password with a minimum of manual
> >> intervention by me
> > 
> > Difficult. That would have to be scripted for each website etc, wouldn't
> > it?
> 
> Many of the KeePass* tools support auto-type which will send a sequence to
> the browser. The sequence can use the default pattern or be customized.
> 
> I believe one of the commercial, proprietary tools offers to change all
> your passwords for you and uses a JavaScript client to do so, so perhaps
> there's already a model to replicate.

Hmm, if anybody can shed more light on that, I'd be interested--not sure I 
could make use of it in any quick fashion, but, if it exists, I'd like to 
learn more about it.
 
> I don't use auto-type, so haven't investigated beyond seeing that it's
> there. I have had multiple people report that it works well for them.

Re: Update: Re: Password Manager opinions and recommendations

[Curt]

On 2018-03-30, Tomaž Šolc  wrote:
>
> Hi
>
> On 27. 03. 2018 03:02, rhkra...@gmail.com wrote:
>> I have what might be called a "religious" aversion to storing what I=20
>> consider "real" user data in /home.
>
> I'm curious. Why do you have this aversion and where do you store "real"
> user data?
>
> This is the first time I've heard about not storing user data in /home.
> I thought that's the whole point of /home.
>

Security through obscurity (rather than vice versa).

-- 
Poor juvenile solutions, explaining nothing. No need then for caution,
we may reason on to our heart’s content, the fog won’t lift. --Samuel Beckett

Re: Update: Re: Password Manager opinions and recommendations

[Tomaž Šolc]

Hi

On 27. 03. 2018 03:02, rhkra...@gmail.com wrote:
> I have what might be called a "religious" aversion to storing what I 
> consider "real" user data in /home.

I'm curious. Why do you have this aversion and where do you store "real"
user data?

This is the first time I've heard about not storing user data in /home.
I thought that's the whole point of /home.

Best regards
Tomaž



signature.asc
Description: OpenPGP digital signature

Re: Password Manager opinions and recommendations

[der.hans]

Am 26. Mar, 2018 schwätzte Richard Hector so:

moin moin,


On 26/03/18 04:52, rhkra...@gmail.com wrote:

I started reading up on password managers in order to consider using one.


I use the keepass family - KeePassX on Debian, KeePassDroid on Android.
I believe Windows and Mac versions are available as well.


KeePassX and KeePassDroid are also what I use and regularly recommend. I
even have a talk essentially wrapped around using KeePassX to store all
the unique, random stuff I recommend ( username, password, subaddress for
email, security questions and answers, birthdate, etc. ).

I gave the talk at SCaLE a couple weeks ago and someone pointed out
KeePassXC, which I had not run into. It's KeePassX with more people
participating and has added some excellent features. For instance, you can
get a random string from anywhere in the UI, not just when generating a
password. It can also sync passwords with multiple files.

The person who brought it up during my presentation also mentioned that it
has ssh-agent integration. I have not yet looked at that.

https://keepassxc.org/

https://packages.debian.org/sid/keepassxc


   * encrypted storage on my own machines (no storage "in the cloud")


Yes


   * ability to transfer to other devices, including Android tablets and
phones--either all the passwords or just one for some special logon on a
machine I don't normally use.  Currently I do almost everything (that requires
a password) on one of my desktop computers.  I have a laptop that I use very
occasionally.  Occasionally I've had to go to a library (or similar) to use a
Windows machine.  I do have an Android tablet and phone, and, in general, I
don't use that for confidential type stuff (no banking, for example), but that
could change if either I feel very secure or in some sort of extreme
emergency.


I sync my database to my own NextCloud instance - in my case it's on a
VPS, which I guess is 'in the cloud', but I manage it myself. There are
NextCloud clients for all the above platforms as well.


   * (a repeat of part of the previous bullet) a means to easily take an
individual password to another machine for occasional use of another machine


I use multiple files as not every device needs access to all of my data.

Until now I've kept passwords in sync by hand. I'm looking forward to 
moving to KeePassXC and being able to sync via the password manager. 
Initial testing looks good.



Not that I know of. But it's on my phone, which goes where I go. That
does mean I sometimes have to view the password and type it in, which is
a pain for a 16-character password full of symbols ...


KeePassDroid puts the username and password into dropdowns from the alerts
menu making for easy copy and paste without needing to know what they are.


   * a means to recover all the passwords if the password manager becomes
defunct (and this also implies backup and restore capabilities)


It's free software, so you can keep copies of it. It can export to XML
(IIRC) too.


KeePassX is one of many tools that uses the KeePass2.x file format, so
multiple projects have to cease to exist for a long time before the files
can no longer be read.

I believe you can use the command line interface to export to XML, so you
might be able to pipe that into GPG for universal backups.


   * a means to automatically generate secure passwords


Yes. Well, I assume they're secure; I'm no cryptographer.


We can add character set requirements and most sites now allow 30+
characters, so they at least look random.


   * a means to automatically update passwords on the target websites (to
facilitate regular / frequent password changes)--this is probably a stretch--I
mean something that would work its way through the various screens and prompts
to change a password with a minimum of manual intervention by me


Difficult. That would have to be scripted for each website etc, wouldn't it?


Many of the KeePass* tools support auto-type which will send a sequence to
the browser. The sequence can use the default pattern or be customized.

I believe one of the commercial, proprietary tools offers to change all
your passwords for you and uses a JavaScript client to do so, so perhaps
there's already a model to replicate.

I don't use auto-type, so haven't investigated beyond seeing that it's
there. I have had multiple people report that it works well for them.

ciao,

der.hans
--
#  https://www.LuftHans.com   https://www.PhxLinux.org
#  I'm not anti-social, I'm pro-individual. - der.hans

Re: Update: Re: Password Manager opinions and recommendations

[Brian]

On Wed 28 Mar 2018 at 15:27:44 +1300, Richard Hector wrote:

> On 28/03/18 00:19, Brian wrote:
> > I eventually settled on masterpasswordapp
> > because the re-creation aspect appealed to me, it was actively
> > maintained, the author's well-thought arguments were convincing
> > and (insofar as I could judge) it is secure.
> > 
> > But it did take some time to come to a decision and both the other
> > two you have been recommended were on my list. The last thing you
> > want to be doing is changing a password manager every few months,
> 
> That's one of the disadvantages of masterpasswordapp, as far as I can

Not quite the point I was trying to make but it is a good one anyway.

> see: If you have to change one password, whether because the site owner
> says so or it's genuinely been compromised, then masterpasswordapp won't
> let you do that, right? Based on your name, the sitename, and your
> master password, there is only one true password. So to change a
> password, you'd have to change one of those factors. You probably can't
> change the site name, changing your own name is inconvenient, and
> changing the master password changes all your other passwords as well.

At http://masterpasswordapp.com/algorithm.html there is a list of
items a user is expected to remember. Four are used to generate the
master password and one of those is the site's password counter. In
the event of a forced site password change the counter is increased
from its default value of 1 to generate a new password for the site
without changing the master password.

Incidentally, the four items above are not secrets. I use the CLI
version of the app with a script so need to remember the master
password only. Also, the site name and full name can be anything
you like, provided you can remember what they are (not that the
app's author recommends this).

-- 
Brian.

Re: Update: Re: Password Manager opinions and recommendations

[Richard Hector]

On 28/03/18 00:19, Brian wrote:
> I eventually settled on masterpasswordapp
> because the re-creation aspect appealed to me, it was actively
> maintained, the author's well-thought arguments were convincing
> and (insofar as I could judge) it is secure.
> 
> But it did take some time to come to a decision and both the other
> two you have been recommended were on my list. The last thing you
> want to be doing is changing a password manager every few months,

That's one of the disadvantages of masterpasswordapp, as far as I can
see: If you have to change one password, whether because the site owner
says so or it's genuinely been compromised, then masterpasswordapp won't
let you do that, right? Based on your name, the sitename, and your
master password, there is only one true password. So to change a
password, you'd have to change one of those factors. You probably can't
change the site name, changing your own name is inconvenient, and
changing the master password changes all your other passwords as well.

Richard




signature.asc
Description: OpenPGP digital signature

Re: Password Manager opinions and recommendations

[rhkramer]

On Tuesday, March 27, 2018 08:47:10 AM rhkra...@gmail.com wrote:
> On Tuesday, March 27, 2018 04:08:07 AM Joe wrote:
> > On Mon, 26 Mar 2018 17:38:33 -0400
> > 
> > rhkra...@gmail.com wrote:
> > > > > Yes, at least I think so, unless there is some standard for how
> > > > > to handle passwords (including changing them) on websites.  I
> > > > > suspect that there isn't. There may be some commonality in
> > > > > websites generated by a common website "generator" (one of those
> > > > > packages that help you create a website--I think they exist, but
> > > > > I've never used one--maybe Drupal is an example?
> > > > 
> > > > The standard exists. You change your password via the website. Then
> > > > you inform your password manager of the change.
> > > 
> > > Ok, but that's not the kind of standard I was hoping for--I was
> > > hoping for a (standard) programmatic way of changing the password on
> > > a website, which, being programmatic, could be initiated by the
> > > password manager.
> > 
> > Unless such a thing is a library function in JavaScript, then no
> > commercial website will contain it...
> > 
> > More seriously, I doubt that such a thing exists, it would be like the
> > backdoor in OpenSSL, an absolutely disastrous idea. Websites tend to
> > store password data (sometimes in plain text!) insecurely enough as it
> > is.
> 
> Good point, although I'd expect such a function to require authentication,
> presumably by entering the old password.
> 

Hmm, but on further (but little thought), I still would like such a function, 
maybe it could work something like this:

When you login to a site that requires authentication / a password (and you've 
fulfilled the captcha or equal), you could get a prompt something like: "Would 
you like to change the password?  (Maybe mentioning how old the password is, 
or how many times you've logged in using it).  If you answer yes to the 
prompt, the password manager starts a programmatic dialog to change the 
password, including entering the password, but (perhaps optionally, via a per 
site setting in your password manager) it requires additional authentication 
(from / with the site, not with password manager) which may include--well, 
something, maybe another captcha.  And it would only work on https:// pages or 
under similar encryption.



> > Also, many websites where security is a big issue do try to ensure that
> > logins can't be made by computer.
> 
> Oh, yeah, Captchas (and such)--how could I forget about those...

Re: Password Manager opinions and recommendations

[rhkramer]

On Tuesday, March 27, 2018 04:08:07 AM Joe wrote:
> On Mon, 26 Mar 2018 17:38:33 -0400
> 
> rhkra...@gmail.com wrote:
> > > > Yes, at least I think so, unless there is some standard for how
> > > > to handle passwords (including changing them) on websites.  I
> > > > suspect that there isn't. There may be some commonality in
> > > > websites generated by a common website "generator" (one of those
> > > > packages that help you create a website--I think they exist, but
> > > > I've never used one--maybe Drupal is an example?
> > > 
> > > The standard exists. You change your password via the website. Then
> > > you inform your password manager of the change.
> > 
> > Ok, but that's not the kind of standard I was hoping for--I was
> > hoping for a (standard) programmatic way of changing the password on
> > a website, which, being programmatic, could be initiated by the
> > password manager.
> 
> Unless such a thing is a library function in JavaScript, then no
> commercial website will contain it...
> 
> More seriously, I doubt that such a thing exists, it would be like the
> backdoor in OpenSSL, an absolutely disastrous idea. Websites tend to
> store password data (sometimes in plain text!) insecurely enough as it
> is.
> 

Good point, although I'd expect such a function to require authentication, 
presumably by entering the old password.

> Also, many websites where security is a big issue do try to ensure that
> logins can't be made by computer.

Oh, yeah, Captchas (and such)--how could I forget about those...

Re: Update: Re: Password Manager opinions and recommendations

[rhkramer]

On Tuesday, March 27, 2018 03:57:24 AM Joe wrote:
> Something I haven't seen mentioned: KeePassX does a kind of poor man's
> two-factor authentication, allowing the use of both a password and an
> arbitrary file in its encryption. So it's possible to store the file on
> your computer(s) and carry the database itself on a USB key, meaning
> that if either is lost or stolen, there is a bit less urgency in
> changing all of your passwords. A couple of offline backups of both, of
> course, should also be kept.

Thanks!  Yes that's a nice feature--a lot to think about, and an important (as 
Brian pointed out) / hopefully one time decision to make.

I may not do much more until after tax season (April 16, this year).

Re: Update: Re: Password Manager opinions and recommendations

[rhkramer]

On Tuesday, March 27, 2018 12:56:24 AM Kushal Kumaran wrote:
> Set the PASSWORD_STORE_DIR environment variable to point to your
> location of choice.  This is mentioned in the "Environment Variables"
> section of the pass(1) manpage.

Thanks! I missed that.

Re: Update: Re: Password Manager opinions and recommendations

[Brian]

On Mon 26 Mar 2018 at 21:02:48 -0400, rhkra...@gmail.com wrote:

> Thanks to all who replied! 
> 
> I thought I'd summarize where I am:
> 
> I like three of the suggestions (from what I've seen / investigated 
> (slightly) 
> so far, but with some comments:
> 
>* pass: appeals to me a lot--the one problem for me (for which I believe 
> I've found the solution) is that it stores the encrypted password files in my 
> /home.  I have what might be called a "religious" aversion to storing what I 
> consider "real" user data in /home.  I've looked at the source code, and I 
> see 
> where $HOME is used to create that directory.  If I use pass, I will, at the 
> very least, modify that in my own copy, but also write to the author and 
> suggest that he allow a command line parameter (or config file) change the 
> location of the directory.
> 
>* I like the approach that http://masterpasswordapp.com/ takes to create 
> passwords and, iiuc, recreate them each time they are needed rather than 
> storing them anywhere.  I'll read up a little more on that.
> 
>* I haven't spent much time on keepass--maybe in the next day or so
> 
>* I also like the approach suggested by Abdullah Ramazanoglu (and the 
> somewhat similar Diceware), but I almost didn't find the emails from 
> Abdullah--
> for some reason my email client did not receive them--I've done a search of 
> all the local email files (on my computer) (including trash, which I have not 
> emptied in the last several days), and I've searched the Google email spam, 
> trash, and all folders.  I'll be digging into this and possibly seek help in 
> a 
> new thread.

Not so long ago we had this message on -user:

  https://lists.debian.org/debian-user/2017/08/msg01260.html

During the course of the conversation I changed my mind on the
usefulness of my password policy and, like you, investigated
password managers. I eventually settled on masterpasswordapp
because the re-creation aspect appealed to me, it was actively
maintained, the author's well-thought arguments were convincing
and (insofar as I could judge) it is secure.

But it did take some time to come to a decision and both the other
two you have been recommended were on my list. The last thing you
want to be doing is changing a password manager every few months,
so it is worthwhile taking the time to explore them in your use
context.

Unfortunately, masterpasswordapp is not in Debian but it is not
difficult to build.

-- 
Brian.
 appealed

Re: Password Manager opinions and recommendations

[Joe]

On Mon, 26 Mar 2018 17:38:33 -0400
rhkra...@gmail.com wrote:

>
> > > 
> > > Yes, at least I think so, unless there is some standard for how
> > > to handle passwords (including changing them) on websites.  I
> > > suspect that there isn't. There may be some commonality in
> > > websites generated by a common website "generator" (one of those
> > > packages that help you create a website--I think they exist, but
> > > I've never used one--maybe Drupal is an example?  
> > 
> > The standard exists. You change your password via the website. Then
> > you inform your password manager of the change.  
> 
> Ok, but that's not the kind of standard I was hoping for--I was
> hoping for a (standard) programmatic way of changing the password on
> a website, which, being programmatic, could be initiated by the
> password manager.
> 

Unless such a thing is a library function in JavaScript, then no
commercial website will contain it...

More seriously, I doubt that such a thing exists, it would be like the
backdoor in OpenSSL, an absolutely disastrous idea. Websites tend to
store password data (sometimes in plain text!) insecurely enough as it
is. 

Also, many websites where security is a big issue do try to ensure that
logins can't be made by computer.

-- 
Joe

Re: Update: Re: Password Manager opinions and recommendations

[Joe]

On Mon, 26 Mar 2018 21:02:48 -0400
rhkra...@gmail.com wrote:

> Thanks to all who replied! 
> 
> I thought I'd summarize where I am:
> 
> I like three of the suggestions (from what I've seen / investigated
> (slightly) so far, but with some comments:
> 
>* pass: appeals to me a lot--the one problem for me (for which I
> believe I've found the solution) is that it stores the encrypted
> password files in my /home.  I have what might be called a
> "religious" aversion to storing what I consider "real" user data
> in /home.  I've looked at the source code, and I see where $HOME is
> used to create that directory.  If I use pass, I will, at the very
> least, modify that in my own copy, but also write to the author and
> suggest that he allow a command line parameter (or config file)
> change the location of the directory.
> 
>* I like the approach that http://masterpasswordapp.com/ takes to
> create passwords and, iiuc, recreate them each time they are needed
> rather than storing them anywhere.  I'll read up a little more on
> that.
> 
>* I haven't spent much time on keepass--maybe in the next day or so
> 
>* I also like the approach suggested by Abdullah Ramazanoglu (and
> the somewhat similar Diceware), but I almost didn't find the emails
> from Abdullah-- for some reason my email client did not receive
> them--I've done a search of all the local email files (on my
> computer) (including trash, which I have not emptied in the last
> several days), and I've searched the Google email spam, trash, and
> all folders.  I'll be digging into this and possibly seek help in a
> new thread.
> 

Something I haven't seen mentioned: KeePassX does a kind of poor man's
two-factor authentication, allowing the use of both a password and an
arbitrary file in its encryption. So it's possible to store the file on
your computer(s) and carry the database itself on a USB key, meaning
that if either is lost or stolen, there is a bit less urgency in
changing all of your passwords. A couple of offline backups of both, of
course, should also be kept.

-- 
Joe

Re: Update: Re: Password Manager opinions and recommendations

[Kushal Kumaran]

rhkra...@gmail.com writes:

> Thanks to all who replied! 
>
> I thought I'd summarize where I am:
>
> I like three of the suggestions (from what I've seen / investigated 
> (slightly) 
> so far, but with some comments:
>
>* pass: appeals to me a lot--the one problem for me (for which I believe 
> I've found the solution) is that it stores the encrypted password files in my 
> /home.  I have what might be called a "religious" aversion to storing what I 
> consider "real" user data in /home.  I've looked at the source code, and I 
> see 
> where $HOME is used to create that directory.  If I use pass, I will, at the 
> very least, modify that in my own copy, but also write to the author and 
> suggest that he allow a command line parameter (or config file) change the 
> location of the directory.
>

Set the PASSWORD_STORE_DIR environment variable to point to your
location of choice.  This is mentioned in the "Environment Variables"
section of the pass(1) manpage.

One thing I like about pass is its ability to encrypt using multiple
keys.  This lets me use the repository both on my computer and my phone
without the private keys leaving either device.

>* I like the approach that http://masterpasswordapp.com/ takes to create 
> passwords and, iiuc, recreate them each time they are needed rather than 
> storing them anywhere.  I'll read up a little more on that.
>
>* I haven't spent much time on keepass--maybe in the next day or so
>
>* I also like the approach suggested by Abdullah Ramazanoglu (and the 
> somewhat similar Diceware), but I almost didn't find the emails from 
> Abdullah--
> for some reason my email client did not receive them--I've done a search of 
> all the local email files (on my computer) (including trash, which I have not 
> emptied in the last several days), and I've searched the Google email spam, 
> trash, and all folders.  I'll be digging into this and possibly seek help in 
> a 
> new thread.

-- 
regards,
kushal

Re: Password Manager opinions and recommendations

[Mark Fletcher]

On Mon, Mar 26, 2018 at 08:34:28PM +0100, Brian wrote:
> On Sun 25 Mar 2018 at 22:43:26 +0200, Ángel wrote:
> 
> > On 2018-03-25 at 19:47 +0100, Brian wrote:
> > > 1 day after the breach your data had been compromised. Changing your
> > > password 10 days later on in your 1 month cycle doesn't seem to me to
> > > be reactive security. Better than nothing, I suppose, but closing the
> > > door after etc.
> > > 
> > > In any case, your 20 character, high entropy password was your ultimate
> > > defence. (Not unless Yahoo! didn't hash).
> > 
> > 
> > Sure. If someone stole your password, be that by compromising and
> > injecting a password-stealing javascript server side, due to a sslstrip
> > you didn't notice on that free wifi, perhaps just someone looking at the
> > keys you pressed when entering your password, etc. the data you had up
> > to that point in that service should be considered compromised.
> > 
> > However, if the password was changed N days/months later, as part of a
> > periodic password change, that would mean that data processed after that
> > date would no longer be in risk, whereas otherwise the account would
> > continue being accessible by the bad actors for years (assuming that you
> > are not using a pattern that removes the benefit or rotating the
> > password!).
> 
> I would be more accepting of this argument if it fitted with real world
> examples in other fields. Nobody offers the advice to change the locks
> on your front door or your car at regular intervals. But the computer
> security business has conjured up the "what if" argument to counteract
> commensense.
> 
It's pretty difficult to steal someone's keys without them realising it 
has happened. In contrast, password compromise happens without the 
victim's knowledge all the time.

Mark

Re: Update: Re: Password Manager opinions and recommendations

[Abdullah Ramazanoglu]

On Mon, 26 Mar 2018 21:02:48 -0400 rhkra...@gmail.com said:

> Thanks to all who replied! 

You are welcome. :)

>* I also like the approach suggested by Abdullah Ramazanoglu (and
> the somewhat similar Diceware), but I almost didn't find the emails
> from Abdullah-- for some reason my email client did not receive
> them--I've done a search of all the local email files (on my
> computer) (including trash, which I have not emptied in the last
> several days), and I've searched the Google email spam, trash, and
> all folders.  I'll be digging into this and possibly seek help in a
> new thread.

That maybe because I am not subscribed to the mailing list?

I use a news (nntp) client and read/post messages through an nntp server
- mailing list gateway (gmane.org) However, my posts to news server
nntp.gmane.org are forwarded to the mailing list by Gmane (and vice
versa) and then distributed by lists.debian.org mailing list manager to
everyone subscribed, so you should have received them (not directly
from me, but) from the mailing list.

Or I might have possibly misunderstood the actual problem.

Regards
-- 
Abdullah Ramazanoglu

Update: Re: Password Manager opinions and recommendations

[rhkramer]

Thanks to all who replied! 

I thought I'd summarize where I am:

I like three of the suggestions (from what I've seen / investigated (slightly) 
so far, but with some comments:

   * pass: appeals to me a lot--the one problem for me (for which I believe 
I've found the solution) is that it stores the encrypted password files in my 
/home.  I have what might be called a "religious" aversion to storing what I 
consider "real" user data in /home.  I've looked at the source code, and I see 
where $HOME is used to create that directory.  If I use pass, I will, at the 
very least, modify that in my own copy, but also write to the author and 
suggest that he allow a command line parameter (or config file) change the 
location of the directory.

   * I like the approach that http://masterpasswordapp.com/ takes to create 
passwords and, iiuc, recreate them each time they are needed rather than 
storing them anywhere.  I'll read up a little more on that.

   * I haven't spent much time on keepass--maybe in the next day or so

   * I also like the approach suggested by Abdullah Ramazanoglu (and the 
somewhat similar Diceware), but I almost didn't find the emails from Abdullah--
for some reason my email client did not receive them--I've done a search of 
all the local email files (on my computer) (including trash, which I have not 
emptied in the last several days), and I've searched the Google email spam, 
trash, and all folders.  I'll be digging into this and possibly seek help in a 
new thread.

Re: Password Manager opinions and recommendations

[rhkramer]

On Monday, March 26, 2018 03:49:38 PM Brian wrote:
> On Sun 25 Mar 2018 at 21:54:22 -0400, rhkra...@gmail.com wrote:
> >  > at some time in the future>
> > 
> > On Sunday, March 25, 2018 08:38:25 PM Richard Hector wrote:
> > > On 26/03/18 04:52, rhkra...@gmail.com wrote:
> > > >* a means to automatically update passwords on the target websites
> > > >(to
> > > > 
> > > > facilitate regular / frequent password changes)--this is probably a
> > > > stretch--I mean something that would work its way through the various
> > > > screens and prompts to change a password with a minimum of manual
> > > > intervention by me
> > > 
> > > Difficult. That would have to be scripted for each website etc,
> > > wouldn't it?
> > 
> > Yes, at least I think so, unless there is some standard for how to handle
> > passwords (including changing them) on websites.  I suspect that there
> > isn't. There may be some commonality in websites generated by a common
> > website "generator" (one of those packages that help you create a
> > website--I think they exist, but I've never used one--maybe Drupal is an
> > example?
> 
> The standard exists. You change your password via the website. Then you
> inform your password manager of the change.

Ok, but that's not the kind of standard I was hoping for--I was hoping for a 
(standard) programmatic way of changing the password on a website, which, 
being programmatic, could be initiated by the password manager.

Re: Password Manager opinions and recommendations

[Brian]

On Sun 25 Mar 2018 at 21:54:22 -0400, rhkra...@gmail.com wrote:

>  some time in the future>
> 
> On Sunday, March 25, 2018 08:38:25 PM Richard Hector wrote:
> > On 26/03/18 04:52, rhkra...@gmail.com wrote:
> > >* a means to automatically update passwords on the target websites (to
> > > 
> > > facilitate regular / frequent password changes)--this is probably a
> > > stretch--I mean something that would work its way through the various
> > > screens and prompts to change a password with a minimum of manual
> > > intervention by me
> > 
> > Difficult. That would have to be scripted for each website etc, wouldn't
> > it?
> 
> Yes, at least I think so, unless there is some standard for how to handle 
> passwords (including changing them) on websites.  I suspect that there isn't. 
>  
> There may be some commonality in websites generated by a common website 
> "generator" (one of those packages that help you create a website--I think 
> they exist, but I've never used one--maybe Drupal is an example?

The standard exists. You change your password via the website. Then you
inform your password manager of the change.

-- 
Brian.

Re: Password Manager opinions and recommendations

[Brian]

On Sun 25 Mar 2018 at 22:43:26 +0200, Ángel wrote:

> On 2018-03-25 at 19:47 +0100, Brian wrote:
> > 1 day after the breach your data had been compromised. Changing your
> > password 10 days later on in your 1 month cycle doesn't seem to me to
> > be reactive security. Better than nothing, I suppose, but closing the
> > door after etc.
> > 
> > In any case, your 20 character, high entropy password was your ultimate
> > defence. (Not unless Yahoo! didn't hash).
> 
> 
> Sure. If someone stole your password, be that by compromising and
> injecting a password-stealing javascript server side, due to a sslstrip
> you didn't notice on that free wifi, perhaps just someone looking at the
> keys you pressed when entering your password, etc. the data you had up
> to that point in that service should be considered compromised.
> 
> However, if the password was changed N days/months later, as part of a
> periodic password change, that would mean that data processed after that
> date would no longer be in risk, whereas otherwise the account would
> continue being accessible by the bad actors for years (assuming that you
> are not using a pattern that removes the benefit or rotating the
> password!).

I would be more accepting of this argument if it fitted with real world
examples in other fields. Nobody offers the advice to change the locks
on your front door or your car at regular intervals. But the computer
security business has conjured up the "what if" argument to counteract
commensense.

-- 
Brian.

Re: Password Manager opinions and recommendations

[Ben Caradoc-Davies]

On 26/03/18 15:13, Abdullah Ramazanoglu wrote:

Forgot to mention. For that (and other things) I use a separate dumb
browser without any active content capabilities (Java, JS, plugins,
etc.)


It is also worth mentioning:

Firefox Master Password System Has Been Poorly Secured for the Past 9 Years
https://www.bleepingcomputer.com/news/security/firefox-master-password-system-has-been-poorly-secured-for-the-past-9-years/

Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Password Manager opinions and recommendations

[Ben Caradoc-Davies]

On 26/03/18 04:52, rhkra...@gmail.com wrote:

Here are some of what I think are my criteria for a password manager:
* encrypted storage on my own machines (no storage "in the cloud")
* ability to transfer to other devices, including Android tablets and
phones

[...]

* a means to automatically generate secure passwords


I use and recommend keepassx on Debian and KeePassDroid on Android. I 
copy the .kdbx (KeePass 2.x file format) file between platforms with 
sftp, not using cloud storage. Both implementations include password 
generation and so I think tick your three boxes above.


Kind regards,


--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: Password Manager opinions and recommendations

[rhkramer]

On Sunday, March 25, 2018 08:38:25 PM Richard Hector wrote:
> On 26/03/18 04:52, rhkra...@gmail.com wrote:
> >* a means to automatically update passwords on the target websites (to
> > 
> > facilitate regular / frequent password changes)--this is probably a
> > stretch--I mean something that would work its way through the various
> > screens and prompts to change a password with a minimum of manual
> > intervention by me
> 
> Difficult. That would have to be scripted for each website etc, wouldn't
> it?

Yes, at least I think so, unless there is some standard for how to handle 
passwords (including changing them) on websites.  I suspect that there isn't.  
There may be some commonality in websites generated by a common website 
"generator" (one of those packages that help you create a website--I think 
they exist, but I've never used one--maybe Drupal is an example?

Re: Password Manager opinions and recommendations

[Abdullah Ramazanoglu]

On Sun, 25 Mar 2018 11:52:13 -0400 rhkra...@gmail.com said:

> I started reading up on password managers in order to consider using
> one.  
> 
> Up until now, I've made up passwords myself, and stored them in an
> encrypted file.  Some of the drawbacks include: 
> 
>* I keep the passwords on the short side
>* I don't change the passwords as often as I should
>* I sometimes use the same password on more than one site
> 
> All of the above because it is not convenient enough for me to do
> better.

A redacted and grouped output of "apt-cache search password manager" on
Buster:

"pass" family:
pass - lightweight directory-based password manager
qtpass - GUI for password manager pass
pass-extension-otp - pass extension for managing one-time-password
tokens webext-browserpass - web extension for the password manager pass

"kwalletmanager" family:
kwalletmanager - secure password wallet manager
xul-ext-kwallet5 - kwallet integration for firefox

"passwordsafe":
passwordsafe - Simple & Secure Password Management
passwordsafe-common - architecture independent files for Password Safe

"keepass" family:
keepassx - Cross Platform Password Manager
keepassxc - Cross Platform Password Manager
kpcli - command line interface to KeePassX password manager databases
(I don't know the difference between keepassx and keepassxc - their
detailed description is ditto word for word.)

"keepass" continued:
keepass2 - Password manager
keepass2-doc - Password manager - Documentation
(seems to be an offspring of keepass family)

Others:
cpm - Curses based password manager using PGP-encryption
gringotts - secure password and data storage manager
impass - Simple and secure password management and retrieval system
xul-ext-password-editor - edit password manager entries in Mozilla
applications password-gorilla - cross-platform password manager
pypass - lightweight directory-based password manager in python

> My head is just not "into" reading about password managers--it just
> seems to be too boring to really get into, so, I thought I'd try
> posting here to get opinions and recommendations from the list.  (I
> am continuing my effort to read--maybe I'll get a renewed burst of
> enthusiasm after I send this ;-)

For me, I use none of the above. I generate a hundred or so random
alphanumeric strings and save them in a plain text file as an "instant
password source". I then consume them one by one whenever I need a new
password. I keep all my actual passwords with other relevant info in an
html file (a huge table) and keep them all in a high-security
environment. I just copy-paste a password from that html table whenever
I need it (it is open all the time in a background browser tab). Never
share that file between devices. That means I concentrate all my
security sensitive procedures on a single machine.

I do KISS. The more it is "featureful" (aka complicated) the more there
is a chance of password leak (bugs, momentary carelessness, more attack
vectors, etc.)

Regards
-- 
Abdullah Ramazanoglu

Re: Password Manager opinions and recommendations

[Richard Hector]

On 26/03/18 04:52, rhkra...@gmail.com wrote:
> I started reading up on password managers in order to consider using one.

I use the keepass family - KeePassX on Debian, KeePassDroid on Android.
I believe Windows and Mac versions are available as well.

>* encrypted storage on my own machines (no storage "in the cloud")

Yes

>* ability to transfer to other devices, including Android tablets and 
> phones--either all the passwords or just one for some special logon on a 
> machine I don't normally use.  Currently I do almost everything (that 
> requires 
> a password) on one of my desktop computers.  I have a laptop that I use very 
> occasionally.  Occasionally I've had to go to a library (or similar) to use a 
> Windows machine.  I do have an Android tablet and phone, and, in general, I 
> don't use that for confidential type stuff (no banking, for example), but 
> that 
> could change if either I feel very secure or in some sort of extreme 
> emergency.

I sync my database to my own NextCloud instance - in my case it's on a
VPS, which I guess is 'in the cloud', but I manage it myself. There are
NextCloud clients for all the above platforms as well.

>* (a repeat of part of the previous bullet) a means to easily take an 
> individual password to another machine for occasional use of another machine

Not that I know of. But it's on my phone, which goes where I go. That
does mean I sometimes have to view the password and type it in, which is
a pain for a 16-character password full of symbols ...

>* a means to recover all the passwords if the password manager becomes 
> defunct (and this also implies backup and restore capabilities)

It's free software, so you can keep copies of it. It can export to XML
(IIRC) too.

>* a means to automatically generate secure passwords

Yes. Well, I assume they're secure; I'm no cryptographer.

>* a means to automatically update passwords on the target websites (to 
> facilitate regular / frequent password changes)--this is probably a 
> stretch--I 
> mean something that would work its way through the various screens and 
> prompts 
> to change a password with a minimum of manual intervention by me

Difficult. That would have to be scripted for each website etc, wouldn't it?

Richard



signature.asc
Description: OpenPGP digital signature

Re: Password Manager opinions and recommendations

[Ben Finney]

likcoras  writes:

> I think pass (https://www.passwordstore.org/) meets most of your
> requirements. It's a glorified shell script that calls gpg under the
> hood to create passwords that are stored locally (under
> ~/.password-store).

I concur with the recommendation for Password Store, in this case.
(that link again, ).
Someone who has been manually handling their password database should be
right at home with the Password Store system.

> - It does not have a network component.

Password Store uses Git to store the entries, and Git natively allows
distribution of the repository via SSH or HTTPS (and others, of course).

> - You can transfer individual password files, decrypt them yourself
> with gpg, etc.

This is very important! Our password data is too crucial to be locked
into a custom data format needing a specific tool. Password Store avoids
this by using only standard, general-purpose tools.

> - Very straightforward to decrypt with a simple shell script.
> - Uses pwgen to generate passwords, if requested. You can customize
> generation a bit (no special characters, etc.)

For more useful passphrases I can recommend Diceware or ‘xkcdpass’
. That's a separate tool
though, Password Store does not yet integrate with it.

> - It does not handle automatic password updates.

True. This could be implemented in a custom client though.

Which raises another advantage of Password Store: it is a description of
a password manager *without* specifying the client. There are many
clients that work with this system, as can be seen at the website.



So I use the ‘pass’ command-line client on some machines, QtPass desktop
client on others, and the Android app (available from the F-Droid app
store )
to carry them with me.

-- 
 \  “Isn't it enough to see that a garden is beautiful without |
  `\  having to believe that there are fairies at the bottom of it |
_o__) too?” —Douglas Adams |
Ben Finney

Re: Password Manager opinions and recommendations

[Ángel]

On 2018-03-25 at 19:47 +0100, Brian wrote:
> 1 day after the breach your data had been compromised. Changing your
> password 10 days later on in your 1 month cycle doesn't seem to me to
> be reactive security. Better than nothing, I suppose, but closing the
> door after etc.
> 
> In any case, your 20 character, high entropy password was your ultimate
> defence. (Not unless Yahoo! didn't hash).


Sure. If someone stole your password, be that by compromising and
injecting a password-stealing javascript server side, due to a sslstrip
you didn't notice on that free wifi, perhaps just someone looking at the
keys you pressed when entering your password, etc. the data you had up
to that point in that service should be considered compromised.

However, if the password was changed N days/months later, as part of a
periodic password change, that would mean that data processed after that
date would no longer be in risk, whereas otherwise the account would
continue being accessible by the bad actors for years (assuming that you
are not using a pattern that removes the benefit or rotating the
password!).

Regards

Re: Password Manager opinions and recommendations

[Brian]

On Sun 25 Mar 2018 at 14:06:53 -0400, Roberto C. Sánchez wrote:

> On Sun, Mar 25, 2018 at 06:48:15PM +0100, Brian wrote:
> > On Sun 25 Mar 2018 at 11:52:13 -0400, rhkra...@gmail.com wrote:
> > 
> > The PIN for my credit card has only four digits.
> > 
> > >* I don't change the passwords as often as I should
> > 
> > There isn't and never has been a need to do this. Passwords don't
> > deteriorate with age.
> > 
> I disagree. Forced password changes are annoying and counterproductive,

Those two attributes may be a consequence of forced password changes but
are not sufficient to advocate or not advocate such a strategey.

> but there is an argument to be made for users periodically changing
> their passwords. The Yahoo! data breach, for example, did not become
> publically known until long after the breach. Even then, the scope
> continued to expand as additional related breaches were discovered that
> had taken place even earlier.

1 day after the breach your data had been compromised. Changing your
password 10 days later on in your 1 month cycle doesn't seem to me to
be reactive security. Better than nothing, I suppose, but closing the
door after etc.

In any case, your 20 character, high entropy password was your ultimate
defence. (Not unless Yahoo! didn't hash).

> There are some sites which force me to change my password periodically
> and find them annoying because the passwords do not protect anything
> important enough to warrant that. On the other hand, there are some
> sites where I regularly change my password to guard against a hacker
> gaining continuing access to my account/data following a breach.

If I had so little confidence in the password hashing procedures at the
site I might do the same. My problem would then come down to predicting
when a likely breach would occur.

-- 
Brian.


> 
> While you are right that passwords do not deteriorate, they do get
> compromised. The last few years have shown that it happens with rather
> shocking regularity.
> 
> Regards,
> 
> -Roberto
> 
> -- 
> Roberto C. Sánchez
> 

Re: Password Manager opinions and recommendations

[Roberto C . Sánchez]

On Sun, Mar 25, 2018 at 06:48:15PM +0100, Brian wrote:
> On Sun 25 Mar 2018 at 11:52:13 -0400, rhkra...@gmail.com wrote:
> 
> The PIN for my credit card has only four digits.
> 
> >* I don't change the passwords as often as I should
> 
> There isn't and never has been a need to do this. Passwords don't
> deteriorate with age.
> 
I disagree. Forced password changes are annoying and counterproductive,
but there is an argument to be made for users periodically changing
their passwords. The Yahoo! data breach, for example, did not become
publically known until long after the breach. Even then, the scope
continued to expand as additional related breaches were discovered that
had taken place even earlier.

There are some sites which force me to change my password periodically
and find them annoying because the passwords do not protect anything
important enough to warrant that. On the other hand, there are some
sites where I regularly change my password to guard against a hacker
gaining continuing access to my account/data following a breach.

While you are right that passwords do not deteriorate, they do get
compromised. The last few years have shown that it happens with rather
shocking regularity.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Password Manager opinions and recommendations

[Brian]

On Sun 25 Mar 2018 at 11:52:13 -0400, rhkra...@gmail.com wrote:

> I started reading up on password managers in order to consider using one.  
> 
> Up until now, I've made up passwords myself, and stored them in an encrypted 
> file.  Some of the drawbacks include: 
> 
>* I keep the passwords on the short side

The PIN for my credit card has only four digits.

>* I don't change the passwords as often as I should

There isn't and never has been a need to do this. Passwords don't
deteriorate with age.

>* I sometimes use the same password on more than one site

Tut, tut.

> All of the above because it is not convenient enough for me to do better.
> 
> My head is just not "into" reading about password managers--it just seems to 
> be too boring to really get into, so, I thought I'd try posting here to get 
> opinions and recommendations from the list.  (I am continuing my effort to 
> read--maybe I'll get a renewed burst of enthusiasm after I send this ;-)
> 
> Here are some of what I think are my criteria for a password manager:
> 
>* encrypted storage on my own machines (no storage "in the cloud")

Definitely done by

 http://masterpasswordapp.com/

It is designed that way.

>* ability to transfer to other devices, including Android tablets and 
> phones--either all the passwords or just one for some special logon on a 
> machine I don't normally use.  Currently I do almost everything (that 
> requires 
> a password) on one of my desktop computers.  I have a laptop that I use very 
> occasionally.  Occasionally I've had to go to a library (or similar) to use a 
> Windows machine.  I do have an Android tablet and phone, and, in general, I 
> don't use that for confidential type stuff (no banking, for example), but 
> that 
> could change if either I feel very secure or in some sort of extreme 
> emergency.

I don't use such such exotic devices but see how

 http://masterpasswordapp.com/

suits.

>* (a repeat of part of the previous bullet) a means to easily take an 
> individual password to another machine for occasional use of another machine 

 http://masterpasswordapp.com/

has only one password; you can take it anywhere you want.

>* a means to recover all the passwords if the password manager becomes 
> defunct (and this also implies backup and restore capabilities)

Not too sure about this but, provided you have the app, you have the
ability to (re)generate all your passwords.

>* a means to automatically generate secure passwords

That's

 http://masterpasswordapp.com/

>* a means to automatically update passwords on the target websites (to 
> facilitate regular / frequent password changes)--this is probably a 
> stretch--I 
> mean something that would work its way through the various screens and 
> prompts 
> to change a password with a minimum of manual intervention by me

See above. A waste time.

> As an alternative to a password manager, I may create my own memorizable 
> password generator "algorithm" that I can mostly use "in my head".  For 
> instance, it could be something like this:

Don't bother.

 http://masterpasswordapp.com/

got there before you. And does it better than you and I could ever do.

>* think up a multiword phrase, possibly with a mnemonic connection to the 
> target website (or, have a means to extract them from a book, e.g., the 3rd 
> sentence of the 5th chapter of War and Peace--or maybe the first sentence in 
> the book that contains the word bank would become the passphrase for my bank).
>* have a consistent substitution algorithm, which might do things like 
> this:
>   * capitalize the nth letter of each word (or the nth letter of the 
> first 
> word, the (n+1)th letter of the 2nd word, ...
>   * substitute (or insert) a punctuation mark for (like above) the mth 
> letter of each word (or the mth letter of the first word, the (m+1)th letter 
> of 
> the 2nd word, ... --the puntuation might be selected in, for example, 
> keyboard 
> order (or reverse keyboard order) across the numeric keys (e.g., !@#$%^&*() 
> (although maybe some of those might be invalid in (some?) passwords)
>   * some other similar generation rules
> 
> Obviously, having "published" these ideas, my actual implementation will be 
> somewhat different ;-)   

masterpasswordapp is a deterministic password generator. Such things
sometimes get a bad press. In this case, much of the criticism is
unjustified. Documentation and support for it is excellent.

-- 
Brian. (Who doesn't have any commercial connection with
masterpasswordapp.com/)

Re: Password Manager opinions and recommendations

[likcoras]

On 03/26/2018 12:52 AM, rhkra...@gmail.com wrote:
> I started reading up on password managers in order to consider using one.  

Good! Welcome aboard.

> Here are some of what I think are my criteria for a password manager:
> 
>* encrypted storage on my own machines (no storage "in the cloud")
>* ability to transfer to other devices, including Android tablets and 
> phones--either all the passwords or just one for some special logon on a 
> machine I don't normally use.  Currently I do almost everything (that 
> requires 
> a password) on one of my desktop computers.  I have a laptop that I use very 
> occasionally.  Occasionally I've had to go to a library (or similar) to use a 
> Windows machine.  I do have an Android tablet and phone, and, in general, I 
> don't use that for confidential type stuff (no banking, for example), but 
> that 
> could change if either I feel very secure or in some sort of extreme 
> emergency.
>* (a repeat of part of the previous bullet) a means to easily take an 
> individual password to another machine for occasional use of another machine 
>* a means to recover all the passwords if the password manager becomes 
> defunct (and this also implies backup and restore capabilities)
>* a means to automatically generate secure passwords
>* a means to automatically update passwords on the target websites (to 
> facilitate regular / frequent password changes)--this is probably a 
> stretch--I 
> mean something that would work its way through the various screens and 
> prompts 
> to change a password with a minimum of manual intervention by me
> 

I think pass (https://www.passwordstore.org/) meets most of your
requirements. It's a glorified shell script that calls gpg under the
hood to create passwords that are stored locally (under ~/.password-store).

- It does not have a network component.
- You can transfer individual password files, decrypt them yourself with
gpg, etc.
- Very straightforward to decrypt with a simple shell script.
- Uses pwgen to generate passwords, if requested. You can customize
generation a bit (no special characters, etc.)
- It does not handle automatic password updates.

It would also be trivial to modify the script to use some other password
generator, and of course you can input your own passwords.

The pass package in Debian also includes the passmenu utility, which
uses dmenu to automatically type in your password for you. I highly
recommend you use this or some other frontend, as copy-pasting passwords
becomes a chore. Let the password manager type it out for you!

That is one disadvantage of pass, though. It does not have a built-in
frontend, so it requires you to install some other piece if you want to
use it more efficiently.

Also note, if you decide to use passmenu, I think there was some bug
where it did not properly escape text when typing it in for you. Not
sure if it was patched or if the bug is still open. If it gives you
trouble, just grab the latest version from the pass git repository.

> As an alternative to a password manager, I may create my own memorizable 
> password generator "algorithm" that I can mostly use "in my head".  For 
> instance, it could be something like this:
>* think up a multiword phrase, possibly with a mnemonic connection to the 
> target website (or, have a means to extract them from a book, e.g., the 3rd 
> sentence of the 5th chapter of War and Peace--or maybe the first sentence in 
> the book that contains the word bank would become the passphrase for my bank).
>* have a consistent substitution algorithm, which might do things like 
> this:
>   * capitalize the nth letter of each word (or the nth letter of the 
> first 
> word, the (n+1)th letter of the 2nd word, ...
>   * substitute (or insert) a punctuation mark for (like above) the mth 
> letter of each word (or the mth letter of the first word, the (m+1)th letter 
> of 
> the 2nd word, ... --the puntuation might be selected in, for example, 
> keyboard 
> order (or reverse keyboard order) across the numeric keys (e.g., !@#$%^&*() 
> (although maybe some of those might be invalid in (some?) passwords)
>   * some other similar generation rules
> 
> Obviously, having "published" these ideas, my actual implementation will be 
> somewhat different ;-)   

About that, I would suggest you just use diceware
(http://world.std.com/%7Ereinhold/diceware.html). The page includes
instructions on adding special characters/etc to increase
entropy/satisfy dumb requirements.

The reason for this is that you are guaranteed  a certain amount of
entropy even if your method of generating passwords is revealed, even if
they know which wordlist that you use.

Something like what you describe might possibly be safer, but you can't
really quantify how much security you would be giving up by omitting
some step, or how worried you should be about having some of the steps
revealed by accident or by other, more nefarious means. Don't take