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

Groups > linux.debian.user > #194150 > unrolled thread

Password Manager opinions and recommendations

Back to article view | Back to linux.debian.user

Contents

  Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-25 18:00 +0200
    Re: Password Manager opinions and recommendations likcoras <likcoras@riseup.net> - 2018-03-25 18:40 +0200
      Re: Password Manager opinions and recommendations Ben Finney <bignose@debian.org> - 2018-03-26 00:10 +0200
    Re: Password Manager opinions and recommendations Brian <ad44@cityscape.co.uk> - 2018-03-25 19:50 +0200
      Re: Password Manager opinions and recommendations Roberto C. Sánchez <roberto@debian.org> - 2018-03-25 20:10 +0200
        Re: Password Manager opinions and recommendations Brian <ad44@cityscape.co.uk> - 2018-03-25 20:50 +0200
          Re: Password Manager opinions and recommendations Ángel <debian-user@debian.16bits.net> - 2018-03-25 23:20 +0200
            Re: Password Manager opinions and recommendations Brian <ad44@cityscape.co.uk> - 2018-03-26 21:40 +0200
              Re: Password Manager opinions and recommendations Mark Fletcher <mark27q1@gmail.com> - 2018-03-27 04:50 +0200
    Re: Password Manager opinions and recommendations Richard Hector <richard@walnut.gen.nz> - 2018-03-26 02:40 +0200
      Re: Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-26 04:00 +0200
        Re: Password Manager opinions and recommendations Brian <ad44@cityscape.co.uk> - 2018-03-26 22:00 +0200
          Re: Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-26 23:40 +0200
            Re: Password Manager opinions and recommendations Joe <joe@jretrading.com> - 2018-03-27 10:10 +0200
              Re: Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-27 14:50 +0200
                Re: Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-27 15:00 +0200
          Update: Re: Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-27 03:10 +0200
            Re: Update: Re: Password Manager opinions and recommendations Abdullah Ramazanoglu <ar018@yahoo.com> - 2018-03-27 03:40 +0200
            Re: Update: Re: Password Manager opinions and recommendations Kushal Kumaran <kushal@locationd.net> - 2018-03-27 07:00 +0200
              Re: Update: Re: Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-27 14:40 +0200
            Re: Update: Re: Password Manager opinions and recommendations Joe <joe@jretrading.com> - 2018-03-27 10:00 +0200
              Re: Update: Re: Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-27 14:50 +0200
            Re: Update: Re: Password Manager opinions and recommendations Brian <ad44@cityscape.co.uk> - 2018-03-27 13:20 +0200
              Re: Update: Re: Password Manager opinions and recommendations Richard Hector <richard@walnut.gen.nz> - 2018-03-28 04:30 +0200
                Re: Update: Re: Password Manager opinions and recommendations Brian <ad44@cityscape.co.uk> - 2018-03-28 12:40 +0200
            Re: Update: Re: Password Manager opinions and recommendations Tomaž Šolc <tomaz.solc@tablix.org> - 2018-03-30 14:00 +0200
              Re: Update: Re: Password Manager opinions and recommendations Curt <curty@free.fr> - 2018-03-30 14:50 +0200
                Re: Update: Re: Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-30 16:10 +0200
                  Re: Update: Re: Password Manager opinions and recommendations Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-03-31 01:00 +0200
              Storing "real" user data: was: Re: Update: Re: Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-30 16:00 +0200
                Re: Storing "real" user data: was: Re: Update: Re: Password Manager  opinions and recommendations Greg Wooledge <wooledg@eeg.ccf.org> - 2018-03-30 16:20 +0200
                Re: Storing "real" user data: was: Re: Update: Re: Password Manager  opinions and recommendations "der.hans" <deb-user@LuftHans.com> - 2018-03-30 20:20 +0200
      Re: Password Manager opinions and recommendations "der.hans" <deb-user@LuftHans.com> - 2018-03-30 10:50 +0200
        Re: Password Manager opinions and recommendations rhkramer@gmail.com - 2018-03-30 15:20 +0200
          Re: Password Manager opinions and recommendations "der.hans" <deb-user@LuftHans.com> - 2018-03-30 21:00 +0200
            Re: Password Manager opinions and recommendations Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> - 2018-03-31 03:50 +0200
              Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations) rhkramer@gmail.com - 2018-04-02 15:10 +0200
                Re: Chaniging focus: security ouitside a password manager (was: Re:  Password Manager opinions and recommendations) <tomas@tuxteam.de> - 2018-04-02 15:20 +0200
                  Re: Chaniging focus: security ouitside a password manager (was: Re: Password Manager opinions and recommendations) rhkramer@gmail.com - 2018-04-02 20:30 +0200
                Re: Chaniging focus: security ouitside a password manager (was: Re:  Password Manager opinions and recommendations) Roberto C. Sánchez <roberto@debian.org> - 2018-04-02 15:30 +0200
                Re: Chaniging focus: security ouitside a password manager likcoras <likcoras@riseup.net> - 2018-04-02 16:00 +0200
                Re: Chaniging focus: security ouitside a password manager Ben Finney <bignose@debian.org> - 2018-04-03 01:30 +0200
                Re: Chaniging focus: security ouitside a password manager (was: Re:  Password Manager opinions and recommendations) "der.hans" <deb-user@LuftHans.com> - 2018-04-03 02:10 +0200
                Re: Chaniging focus: security ouitside a password manager Richard Hector <richard@walnut.gen.nz> - 2018-04-03 08:00 +0200
                  Re: Chaniging focus: security ouitside a password manager rhkramer@gmail.com - 2018-04-03 13:50 +0200
                  Re: Chaniging focus: security ouitside a password manager Cindy-Sue Causey <butterflybytes@gmail.com> - 2018-04-03 18:30 +0200
                Re: Chaniging focus: security ouitside a password manager (was: Re:  Password Manager opinions and recommendations) Brian <ad44@cityscape.co.uk> - 2018-04-03 11:40 +0200
                Re: Chaniging focus: security ouitside a password manager (was: Re:  Password Manager opinions and recommendations) Brian <ad44@cityscape.co.uk> - 2018-04-03 21:10 +0200
    Re: Password Manager opinions and recommendations Abdullah Ramazanoglu <ar018@yahoo.com> - 2018-03-26 03:40 +0200
      Re: Password Manager opinions and recommendations Abdullah Ramazanoglu <ar018@yahoo.com> - 2018-03-26 04:20 +0200
        Re: Password Manager opinions and recommendations Ben Caradoc-Davies <ben@transient.nz> - 2018-03-26 05:10 +0200
    Re: Password Manager opinions and recommendations Ben Caradoc-Davies <ben@transient.nz> - 2018-03-26 04:00 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#194200 — Re: Update: Re: Password Manager opinions and recommendations

On Mon, 26 Mar 2018 21:02:48 -0400
rhkramer@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

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

#194210 — Re: Update: Re: Password Manager opinions and recommendations

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

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

#194208 — Re: Update: Re: Password Manager opinions and recommendations

On Mon 26 Mar 2018 at 21:02:48 -0400, rhkramer@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

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

#194230 — Re: Update: Re: Password Manager opinions and recommendations

[Multipart message — attachments visible in raw view] — view raw

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

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

#194233 — Re: Update: Re: Password Manager opinions and recommendations

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.

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

#194306 — Re: Update: Re: Password Manager opinions and recommendations

[Multipart message — attachments visible in raw view] — view raw

Hi

On 27. 03. 2018 03:02, rhkramer@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ž

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

#194307 — Re: Update: Re: Password Manager opinions and recommendations

On 2018-03-30, Tomaž Šolc <tomaz.solc@tablix.org> wrote:
>
> Hi
>
> On 27. 03. 2018 03:02, rhkramer@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

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

#194312 — Re: Update: Re: Password Manager opinions and recommendations

On Friday, March 30, 2018 08:44:53 AM Curt wrote:
> On 2018-03-30, Tomaž Šolc <tomaz.solc@tablix.org> wrote:
> > Hi
> > 
> > On 27. 03. 2018 03:02, rhkramer@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.

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

#194346 — Re: Update: Re: Password Manager opinions and recommendations

On 3/30/18, rhkramer@gmail.com <rhkramer@gmail.com> wrote:
> On Friday, March 30, 2018 08:44:53 AM Curt wrote:
>> On 2018-03-30, Tomaž Šolc <tomaz.solc@tablix.org> wrote:
>> > Hi
>> >
>> > On 27. 03. 2018 03:02, rhkramer@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 *

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

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

On Friday, March 30, 2018 07:54:03 AM Tomaž Šolc wrote:
> Hi
> 
> On 27. 03. 2018 03:02, rhkramer@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 /<user> (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" if you will some of those 
people and specs to get them changed.  (I think I was helpful in eventually 
getting some changes made to the FHS to make it clear that storing real user 
data in a place other than ~ acceptable.  (On the other hand, there were other 
people working in the same direction, so maybe I just eventually rode the 
groundswell ;-)

Anyway, these days, I store all my "real user data" in directories other than 
~, these include directories like /<user>01, /<user>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.

Thanks for allowing / prompting(?) me to reminisce!  Sorry for bending your 
ear^H^H^Heyes ;-)

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

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

On Fri, Mar 30, 2018 at 09:57:02AM -0400, rhkramer@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.

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

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

[Multipart message — attachments visible in raw view] — view raw

Am 30. Mar, 2018 schwätzte rhkramer@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, rhkramer@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 /<user> (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" if you will some of those
> people and specs to get them changed.  (I think I was helpful in eventually
> getting some changes made to the FHS to make it clear that storing real user
> data in a place other than ~ acceptable.  (On the other hand, there were other
> people working in the same direction, so maybe I just eventually rode the
> groundswell ;-)
>
> Anyway, these days, I store all my "real user data" in directories other than
> ~, these include directories like /<user>01, /<user>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.
>
> Thanks for allowing / prompting(?) me to reminisce!  Sorry for bending your
> ear^H^H^Heyes ;-)
>

-- 
#  https://www.LuftHans.com   https://www.PhxLinux.org
#  "I guess I should've agreed with my boss more often. Today I was replaced
#  by a bobblehead doll!" -- Randy Glasbergen, 13Mar2006

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

#194301

[Multipart message — attachments visible in raw view] — view raw

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

moin moin,

> On 26/03/18 04:52, rhkramer@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

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

#194309

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, rhkramer@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.

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

#194332

[Multipart message — attachments visible in raw view] — view raw

Am 30. Mar, 2018 schwätzte rhkramer@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, rhkramer@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

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

#194349

[Multipart message — attachments visible in raw view] — view raw

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

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

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

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&P "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:

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

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Apr 02, 2018 at 09:07:16AM -0400, rhkramer@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-----

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

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

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 tomas@tuxteam.de wrote:
> On Mon, Apr 02, 2018 at 09:07:16AM -0400, rhkramer@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

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

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

On Mon, Apr 02, 2018 at 09:07:16AM -0400, rhkramer@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&P "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

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web