Re: Password managers

[Ryan Nowakowski]

On Thu, Nov 16, 2023 at 06:08:04AM +0100, Oliver Schode wrote:
> On Mon, 13 Nov 2023 21:58:17 -0500
>  wrote:
> >As it happens, pass(1) appeared to be precisely what I was looking for.
> >My original code stores all passwords in a single file, whereas pass
> >stores each password in a separate file. In addition, I don't need pass
> >in order to decode the password files. If pass every goes away or
> >disappears from the Debian repos, I can still fetch my passwords (and
> >associated data). Plus, it will insert any line in the password file
> >into the clipboard. And it's a terminal app. Yay.
> >
> 
> Good to see there's still an option for every liking. Turns out my
> expectations are not that far from yours, though gpg is a no-go for me
> (hence almost all in-repo managers) and bash/git magic all but out of
> the question for anyone also using mobile. 

There are several mobile apps that integrate well with pass(1).  I
use https://passwordstore.app/ for Android.

Re: Password managers

[Michel Verdier]

On 2023-11-16, Oliver Schode wrote:

> (hence almost all in-repo managers) and bash/git magic all but out of
> the question for anyone also using mobile.

I use bash and git on android with termux. Working easily with apt :)

Re: Password managers

[Oliver Schode]

On Mon, 13 Nov 2023 21:58:17 -0500
 wrote:

>As it happens, pass(1) appeared to be precisely what I was looking for.
>My original code stores all passwords in a single file, whereas pass
>stores each password in a separate file. In addition, I don't need pass
>in order to decode the password files. If pass every goes away or
>disappears from the Debian repos, I can still fetch my passwords (and
>associated data). Plus, it will insert any line in the password file
>into the clipboard. And it's a terminal app. Yay.
>

Good to see there's still an option for every liking. Turns out my
expectations are not that far from yours, though gpg is a no-go for me
(hence almost all in-repo managers) and bash/git magic all but out of
the question for anyone also using mobile. I know it's not workable for
everyone, but if your usage of oldschool passwords is still manageable,
already decreasing and/or you're using them only where you really have
to, going stateless is another clean, quick and unbloated option:

https://www.lesspass.com/
https://github.com/lesspass/lesspass

Debian has "gokey", perhaps the exception I could use otherwise, same
principle but apparently very bare-bones, cannot say more about that.
I've been using lesspass for years, it means I'm not saving anything,
anywhere. Nothing can be stolen, lost, destroyed or has to be synced.
Passwords are computed each time by way of "site", "login" and my
master password, they can still be changed of course if I have to. For
many people, however, that gets unwieldy real fast as you have to
remember not only all site/login combinations but also specifics like
length, excluded symbols and possibly counter. So before long many
would start populating some kind of database anyway, defeating the
whole concept. On the other hand you can use it on the CLI too, there's
a Python module, though not in Debian, and the Web interface is quite
handy. F-Droid even has a (very simple) app for Android. It's not a
recommendation for you, as one cannot save let alone annotate anything,
but maybe someone else is interested. I'ver never been a fan of
managers, don't like to save stuff in the browser(s) and the idea of
pulling in 100 MiB or half of the wacky Qt cosmos just in order to save
a few phrases makes my nose bleed.


Oliver

Re: Password managers

[Max Nikulin]

On 15/11/2023 15:40, Michel Verdier wrote:

On 2023-11-15, Max Nikulin wrote:


For Chromium it is better to have a password manager
(gnome-keyring/kwallet/keepassxc/etc.) with D-Bus interface. It needs
a key to encrypt passwords saved in browser and likely cookie store.
Encryption is not applied otherwise.

What about Firefox then? Does it work with password managers with a
D-Bus interface?


keepassxc has a plugin for firefox


Browser extension should be a significantly better option than using 
clipboard for passwords for various sites. (I hope, it is properly 
implemented.) I am unsure if it works for mozilla accounts since add-ons 
are not allowed to interact with some mozilla sites.


As to D-Bus Secret Storage API, Chrome has no master password dialog, it 
can use only user keyring. Firefox has its own dialog but does not 
support getting it through D-Bus. Both browsers have their own storages 
for site passwords. KeePassXC declares support of Secret Storage API, so 
it should be suitable for storing of Chrome master key. Certainly users 
may choose to keep their passwords for sites in KeePassXC, not in 
browser-specific storage.


Firefox stores cookies (and so authentication tokens for active logins) 
without encryption:

https://bugzilla.mozilla.org/show_bug.cgi?id=56788
and a number of duplicates.


Pass(1) sets a timer and removes the password from the clipboard after
that time has expired.


I am unsure if listening for clipboard change events is currently implemented
in browsers. Such feature defeats timeouts. Its fair use is clipboard managers
specifically for ChromeOS, but that might be usable on other platforms as
well.


don't know for pass, but keepassxc don't rely on managers and erase
the clipboard itself after its timeout


I mean clipboard sniffing

./clipnotify -s clipboard && xclip -selection clipboard -o |
   tee -a /tmp/pw.txt

where clipnotify is a tool to wait for clipboard changes:
https://github.com/cdown/clipnotify
The command above fetches clipboard content immediately when KeePassXC 
puts a password into clipboard. Timeout does not help.


In Wayland applications needs a permission to access clipboard.

In KDE klipper is enabled by default and clipboard history is saved to a 
file. There is a number of other clipboard managers.


For web pages there was intention to allow actions in response to 
changes of clipboard content:

https://w3c.github.io/clipboard-apis/#clipboard-event-clipboardchange

KeePassXC does not erase password immediately after clipboard content is 
obtained. However it would be rather minor improvement. Even if 
clipboard is cleared after first use, a sniffer may put content back to 
allow user to paste password.

Re: Password managers

[Michel Verdier]

On 2023-11-15, Max Nikulin wrote:

>>> For Chromium it is better to have a password manager
>>> (gnome-keyring/kwallet/keepassxc/etc.) with D-Bus interface. It needs
>>> a key to encrypt passwords saved in browser and likely cookie store.
>>> Encryption is not applied otherwise.
>> What about Firefox then? Does it work with password managers with a
>> D-Bus interface?

keepassxc has a plugin for firefox

>> Pass(1) sets a timer and removes the password from the clipboard after
>> that time has expired.
>
> I am unsure if listening for clipboard change events is currently implemented
> in browsers. Such feature defeats timeouts. Its fair use is clipboard managers
> specifically for ChromeOS, but that might be usable on other platforms as
> well.

don't know for pass, but keepassxc don't rely on managers and erase
the clipboard itself after its timeout

Re: Password managers

[Max Nikulin]

On 15/11/2023 03:05, Anssi Saari wrote:

Max Nikulin writes:


For Chromium it is better to have a password manager
(gnome-keyring/kwallet/keepassxc/etc.) with D-Bus interface. It needs
a key to encrypt passwords saved in browser and likely cookie store.
Encryption is not applied otherwise.


What about Firefox then? Does it work with password managers with a
D-Bus interface?


If you have passwords saved by Firefox or Thunderbird then you have to 
set master passwords in these applications. It is not integrated with 
user-wide key rings:


https://bugzilla.mozilla.org/show_bug.cgi?id=1586072
Password Manager using Secret Service (Open bug)

I am unsure it it affects cookies (that may contain long-lasting session 
credentials). Perhaps somebody may provide links clarifying it.


E.g. in Thunderbird internal password storage is a way to use gmail 
account while having JavaScript disabled. It breaks OAuth2 
authorization, so gmail application password (that is not supposed to be 
typed every time) has to be used. Certainly an external password manager 
is an alternative for passwords (but not for cookies).


On 15/11/2023 04:23, paulf wrote:

Pass(1) sets a timer and removes the password from the clipboard after
that time has expired.


I am unsure if listening for clipboard change events is currently 
implemented in browsers. Such feature defeats timeouts. Its fair use is 
clipboard managers specifically for ChromeOS, but that might be usable 
on other platforms as well.


Just a warning for those who use clipboard managers: I do not think that 
xclip, used by pass(1), allows to set e.g. 
application/x-kde-passwordManagerHint


https://bugs.kde.org/show_bug.cgi?id=156547
Passwords copied from kwalletmanager appear in klipper


Also worth noting that this system is in my home, behind a firewall,


Usual firewall does not protect against attacks through JavaScript 
executed in browsers, so having local network available. There are was 
an example of bricked NAS that were available for local networks only. 
Browsers may change security policy in respect to such requests, I am 
unsure concerning current state of affairs. In additional, collected 
data may be uploaded since outgoing HTTPS requests are not blocked.

Re: Password managers

[paulf]

On Tue, 14 Nov 2023 23:38:58 +0700
Max Nikulin  wrote:

> On 14/11/2023 09:58, paulf wrote:
> > 
> > As it happens, pass(1) appeared to be precisely what I was looking
> > for.
> [...]
> > Plus, it will insert any line in the password file
> > into the clipboard.
> 
> In general it is better to avoid secrets copied to the clipboard.
> Even JavaScript from a web page might read clipboard contents.
> (Browsers however restrict this ability requiring either user gesture
> or granting a permission in a popup dialog.)
> 

Pass(1) sets a timer and removes the password from the clipboard after
that time has expired.

Also worth noting that this system is in my home, behind a firewall, my
wife being the only other person with physical access to my computer.

Paul


-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Password managers

[Anssi Saari]

Max Nikulin  writes:

> For Chromium it is better to have a password manager
> (gnome-keyring/kwallet/keepassxc/etc.) with D-Bus interface. It needs
> a key to encrypt passwords saved in browser and likely cookie store. 
> Encryption is not applied otherwise.

What about Firefox then? Does it work with password managers with a
D-Bus interface?

Re: Password managers

[Max Nikulin]

On 14/11/2023 09:58, paulf wrote:


As it happens, pass(1) appeared to be precisely what I was looking for.

[...]

Plus, it will insert any line in the password file
into the clipboard.


In general it is better to avoid secrets copied to the clipboard. Even 
JavaScript from a web page might read clipboard contents. (Browsers 
however restrict this ability requiring either user gesture or granting 
a permission in a popup dialog.)


For Chromium it is better to have a password manager 
(gnome-keyring/kwallet/keepassxc/etc.) with D-Bus interface. It needs a 
key to encrypt passwords saved in browser and likely cookie store. 
Encryption is not applied otherwise.

Re: Password managers

[John Conover]

pa...@quillandmouse.com writes:
> On Thu, 09 Nov 2023 10:48:14 -0600
> John Hasler  wrote:
> 
> > Why does "accepted/popular" matter?
> 
> Not a great choice of words, perhaps. I was thinking in terms of those
> password managers which are written by others and included in the
> Debian repositories.
> 
> As it happens, pass(1) appeared to be precisely what I was looking for.
> My original code stores all passwords in a single file, whereas pass
> stores each password in a separate file. In addition, I don't need pass
> in order to decode the password files. If pass every goes away or
> disappears from the Debian repos, I can still fetch my passwords (and
> associated data). Plus, it will insert any line in the password file
> into the clipboard. And it's a terminal app. Yay.
> 
Hi Paul,

And pass(1) is an sh(1)/bash(1) script, making it expediently
configurable, with or without pass(1), as you say.

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: Password managers

[paulf]

On Thu, 09 Nov 2023 10:48:14 -0600
John Hasler  wrote:

> Why does "accepted/popular" matter?

Not a great choice of words, perhaps. I was thinking in terms of those
password managers which are written by others and included in the
Debian repositories.

As it happens, pass(1) appeared to be precisely what I was looking for.
My original code stores all passwords in a single file, whereas pass
stores each password in a separate file. In addition, I don't need pass
in order to decode the password files. If pass every goes away or
disappears from the Debian repos, I can still fetch my passwords (and
associated data). Plus, it will insert any line in the password file
into the clipboard. And it's a terminal app. Yay.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Password managers

[John Hasler]

Why does "accepted/popular" matter?
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Password managers

[Max Nikulin]

On 13/11/2023 21:29, Erwan David wrote:
That was a bad idea : lokking closer I see that kpcli does not support 
the latest keepass file format (v4)


Trying "apt search" I have noticed some python tool "secrets" having 
python3-pykeepass in its dependency. Does anybody use it (or at least 
have tried it)? My specific interest is recovery scenario when usually 
used (and tuned) system is not available, so minimal dependencies matter 
when a Live image is booted.


It seems KeePassXC implements secret.service D-Bus API. Can 
gnome-keyring/kwallet/KeePassXC be used instead of "native" application 
for particular desktop or actually there are various lock-ins (e.g. 
anything other than gnome-keyring is call to trouble in Gnome)?

Re: Password managers

[Erwan David]

Le 13/11/2023 à 15:11, Klaus Singvogel a écrit :

Erwan David wrote:

Note that you may have less dependencies with kpcli (a cli client for
keepass password files)

I always was peering at kpcli.

Do you have any experience switching between the CLI (kpcli) and the GUI 
(keepassxc) version frequently?

Is this flawless possible to switch from the one to the other and back, or is 
it something which can't easily to be done?

Thanks in advance.

Best regards,
Klaus.


That was a bad idea : lokking closer I see that kpcli does not support 
the latest keepass file format (v4)


--
Erwan David

Re: Password managers

[Klaus Singvogel]

Erwan David wrote:
> Note that you may have less dependencies with kpcli (a cli client for
> keepass password files)

I always was peering at kpcli.

Do you have any experience switching between the CLI (kpcli) and the GUI 
(keepassxc) version frequently?

Is this flawless possible to switch from the one to the other and back, or is 
it something which can't easily to be done?

Thanks in advance.

Best regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: Password managers

[Hans]

Am Sonntag, 12. November 2023, 18:23:20 CET schrieb Joe:
What about kwallet? Should run on other window managers than plasma5 as well.

Hans

Re: Password managers

[Joe]

On Sun, 12 Nov 2023 22:07:33 +0700
Max Nikulin  wrote:

> On 10/11/2023 01:48, Michael Kjörling wrote:
> > KeepassXC if you want a primarily GUI solution which also happens to
> > be open source. (There's also a command-line version keepassxc-cli
> > which can either be driven from the command line or used
> > interactively in a terminal session.)  
> 
> Having system booted from Debian Live image (assume some disaster),
> how many packaged have to be installed to get access to passwords
> stored by KeePassXC?
> 
As always, it depends on what you already have. Much of that enormous
list may already be there.

From a fairly large sid installation:

Install: libtspi1:amd64 (0.3.15-0.3, automatic), libzxcvbn0:amd64
(2.5+dfsg-1, automatic), keepassxc:amd64 (2.7.4+dfsg.1-2),
libbotan-2-19:amd64 (2.19.3+dfsg-1, automatic)

An alternative strategy is to keep the database backed up on a USB
device or uSD card etc. I do that anyway for laptop use, not
storing the database on the laptop itself. You could also install
PortableApps (and KeepassXC Portable) on the card, and have the
passwords available on any Windows machine without leaving anything
behind on that machine. Whatever you do, it's always a good idea to
copy the database to somewhere fairly safe whenever you update it.

Or there are other rescue-type distributions which have keepasxc, such
as Parted Magic. Knoppix has keepassx, but I'm not sure about file
compatibility with that fork.

-- 
Joe

Re: Password managers

[Erwan David]

Le 12/11/2023 à 16:53, Michael Kjörling a écrit :

On 12 Nov 2023 22:07 +0700, from maniku...@gmail.com (Max Nikulin):

Having system booted from Debian Live image (assume some disaster), how many
packaged have to be installed to get access to passwords stored by
KeePassXC?

I don't know about Debian Live images, but from an up-to-date install
of my _very_ minimal VM setup (Bookworm with only the standard and
ssh-server tasks installed), "apt-get install keepassxc" pulls in 142
packages totalling about 91 MB of downloads.

Many of those packages are fairly obviously generally GUI-related and
not directly related to KeepassXC specifically, so on a live image,
which already has a GUI, it would be much less.

Note that you may have less dependencies with kpcli (a cli client for 
keepass password files)

Re: Password managers

[Michael Kjörling]

On 12 Nov 2023 22:07 +0700, from maniku...@gmail.com (Max Nikulin):
> Having system booted from Debian Live image (assume some disaster), how many
> packaged have to be installed to get access to passwords stored by
> KeePassXC?

I don't know about Debian Live images, but from an up-to-date install
of my _very_ minimal VM setup (Bookworm with only the standard and
ssh-server tasks installed), "apt-get install keepassxc" pulls in 142
packages totalling about 91 MB of downloads.

Many of those packages are fairly obviously generally GUI-related and
not directly related to KeepassXC specifically, so on a live image,
which already has a GUI, it would be much less.

> # apt-get -u install keepassxc
> [...]
> The following NEW packages will be installed:
>   adwaita-icon-theme at-spi2-common at-spi2-core dconf-gsettings-backend
>   dconf-service fontconfig fontconfig-config fonts-dejavu-core
>   fonts-font-awesome gsettings-desktop-schemas gtk-update-icon-cache
>   hicolor-icon-theme keepassxc libatk-bridge2.0-0 libatk1.0-0 libatspi2.0-0
>   libavahi-client3 libavahi-common-data libavahi-common3 libbotan-2-19
>   libcairo-gobject2 libcairo2 libcolord2 libcups2 libdatrie1 libdconf1
>   libdeflate0 libdouble-conversion3 libdrm-amdgpu1 libdrm-common libdrm-intel1
>   libdrm-nouveau2 libdrm-radeon1 libdrm2 libegl-mesa0 libegl1 libepoxy0
>   libevdev2 libfontconfig1 libfribidi0 libgbm1 libgdk-pixbuf-2.0-0
>   libgdk-pixbuf2.0-bin libgdk-pixbuf2.0-common libgl1 libgl1-mesa-dri
>   libglapi-mesa libglvnd0 libglx-mesa0 libglx0 libgraphite2-3 libgtk-3-0
>   libgtk-3-bin libgtk-3-common libgudev-1.0-0 libharfbuzz0b libice6
>   libinput-bin libinput10 libjbig0 libjpeg62-turbo liblcms2-2 liblerc4
>   libllvm15 libmd4c0 libminizip1 libmtdev1 libpango-1.0-0 libpangocairo-1.0-0
>   libpangoft2-1.0-0 libpciaccess0 libpcre2-16-0 libpcsclite1 libpixman-1-0
>   libqrencode4 libqt5concurrent5 libqt5core5a libqt5dbus5 libqt5gui5
>   libqt5network5 libqt5qml5 libqt5qmlmodels5 libqt5quick5 libqt5svg5
>   libqt5waylandclient5 libqt5waylandcompositor5 libqt5widgets5
>   libqt5x11extras5 librsvg2-2 librsvg2-common libsensors-config libsensors5
>   libsm6 libthai-data libthai0 libtiff6 libtspi1 libwacom-common libwacom9
>   libwayland-client0 libwayland-cursor0 libwayland-egl1 libwayland-server0
>   libwebp7 libx11-xcb1 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-icccm4
>   libxcb-image0 libxcb-keysyms1 libxcb-present0 libxcb-randr0
>   libxcb-render-util0 libxcb-render0 libxcb-shape0 libxcb-shm0 libxcb-sync1
>   libxcb-util1 libxcb-xfixes0 libxcb-xinerama0 libxcb-xinput0 libxcb-xkb1
>   libxcomposite1 libxcursor1 libxdamage1 libxfixes3 libxi6 libxinerama1
>   libxkbcommon-x11-0 libxkbcommon0 libxrandr2 libxrender1 libxshmfence1
>   libxtst6 libxxf86vm1 libz3-4 libzxcvbn0 qt5-gtk-platformtheme
>   qttranslations5-l10n qtwayland5 x11-common
> 0 upgraded, 142 newly installed, 0 to remove and 0 not upgraded.
> Need to get 90.9 MB of archives.
> After this operation, 379 MB of additional disk space will be used.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Password managers

[Max Nikulin]

On 10/11/2023 01:48, Michael Kjörling wrote:

KeepassXC if you want a primarily GUI solution which also happens to
be open source. (There's also a command-line version keepassxc-cli
which can either be driven from the command line or used interactively
in a terminal session.)


Having system booted from Debian Live image (assume some disaster), how 
many packaged have to be installed to get access to passwords stored by 
KeePassXC?

Re: Password managers

[Peter Hillier-Brook]

On 10/11/2023 10:32, Timothy M Butterworth wrote:



On Fri, Nov 10, 2023 at 5:25 AM Timothy M Butterworth 
> wrote:




On Fri, Nov 10, 2023 at 3:11 AM John Conover mailto:cono...@panix.com>> wrote:

John Darrah writes:
 > On Thu, 2023-11-09 at 16:03 -0800, pa...@quillandmouse.com
 wrote:
 > > Folks:
 > >
 > > Does anyone know of a password manager which will store a
variety of
 > > user-defined information for each login, and not store that
 > > information
 > > on the internet (and which is free as in beer)?
 > >
 >
 > Take a look at 'secrets' which is a Gnome native app. It uses a
 > database and key file compatible with Password Safe.


I have been looking for a password manager that was as simple and
easy to use as password manager and Secrets is definitely it. Thanks
so much for pointing out this program.


I spoke to soon Password Safe is now available for Linux. 
https://sourceforge.net/projects/passwordsafe/files/Linux/1.18.0/ 
 I 
used to run Password Safe in Wine. It is so good to see that it has been 
ported to linux.


The Linux port of PasswordSafe has been around for several years: I 
couldn't be without it!


Peter HB

Re: Password managers

[Eric S Fraga]

On Thursday,  9 Nov 2023 at 12:46, Todd Zullinger wrote:
> You may like pass[1].  It's a bash script which uses gpg, so
> it's somewhat familiar to what you've written in a sense.

+1

*and* it has an Emacs interface which is very easy to use.

-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-06-19) on Debian 12.0

Re: Password managers

[Timothy M Butterworth]

On Fri, Nov 10, 2023 at 5:25 AM Timothy M Butterworth <
timothy.m.butterwo...@gmail.com> wrote:

>
>
> On Fri, Nov 10, 2023 at 3:11 AM John Conover  wrote:
>
>> John Darrah writes:
>> > On Thu, 2023-11-09 at 16:03 -0800, pa...@quillandmouse.com wrote:
>> > > Folks:
>> > >
>> > > Does anyone know of a password manager which will store a variety of
>> > > user-defined information for each login, and not store that
>> > > information
>> > > on the internet (and which is free as in beer)?
>> > >
>> >
>> > Take a look at 'secrets' which is a Gnome native app. It uses a
>> > database and key file compatible with Password Safe.
>>
>
> I have been looking for a password manager that was as simple and easy to
> use as password manager and Secrets is definitely it. Thanks so much for
> pointing out this program.
>

I spoke to soon Password Safe is now available for Linux.
https://sourceforge.net/projects/passwordsafe/files/Linux/1.18.0/ I used to
run Password Safe in Wine. It is so good to see that it has been ported to
linux.


>
>>
>> Pass works well, too. http://www.passwordstore.org/.
>> Uses gpg encryption.
>>
>> John
>>
>> --
>>
>> John Conover, cono...@panix.com, http://www.johncon.com/
>>
>>
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
> ⠈⠳⣄⠀⠀
>


-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Password managers

[Timothy M Butterworth]

On Fri, Nov 10, 2023 at 3:11 AM John Conover  wrote:

> John Darrah writes:
> > On Thu, 2023-11-09 at 16:03 -0800, pa...@quillandmouse.com wrote:
> > > Folks:
> > >
> > > Does anyone know of a password manager which will store a variety of
> > > user-defined information for each login, and not store that
> > > information
> > > on the internet (and which is free as in beer)?
> > >
> >
> > Take a look at 'secrets' which is a Gnome native app. It uses a
> > database and key file compatible with Password Safe.
>

I have been looking for a password manager that was as simple and easy to
use as password manager and Secrets is definitely it. Thanks so much for
pointing out this program.



>
> Pass works well, too. http://www.passwordstore.org/.
> Uses gpg encryption.
>
> John
>
> --
>
> John Conover, cono...@panix.com, http://www.johncon.com/
>
>

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Password managers

[Minecraftchest1]

I can also recomend a Keepass compatible password manager. I am personally 
using the offical Keepass2 app over Mono, but KeePassXC has also worked well. I 
have been using Syncthing to sync it between my devices, include my Android 
smartphone. For Android, I have found KeepassDX and Keepass2Android to work 
well.

One nice thing about Keepass is that in addition to the freeform notes field, 
you can also have custom fields, as well as atrach files to each entry. There 
is also a number of plugins you can use with the offical app as well. 

Another option that should wotk for you is Vaultwarden. It is an open source, 
api compatible version of the Bitwarden server you can self-host in docker. You 
can use it with the offical Bitwarden (select change server at login if I 
recall correctly). It has all of the same features as the hosted version, and 
even uses the same web client.

On November 9, 2023 6:48:35 PM UTC, "Michael Kjörling" <2695bd53d...@ewoof.net> 
wrote:
>On 9 Nov 2023 11:05 -0500, from pa...@quillandmouse.com:
>> Does anyone know of a password manager which will store a variety of
>> user-defined information for each login, and not store that information
>> on the internet (and which is free as in beer)?
>
>KeepassXC if you want a primarily GUI solution which also happens to
>be open source. (There's also a command-line version keepassxc-cli
>which can either be driven from the command line or used interactively
>in a terminal session.)
>
>pass if you want something which mimics your homegrown solution.
>
>Any decent password manager should have a free-form notes field and I
>can confirm that KeepassXC 2.7.4 (which is the version currently
>packaged in Bookworm) searches in the notes field when I type into the
>search field in the GUI.
>
>-- 
>Michael Kjörling  https://michael.kjorling.se
>“Remember when, on the Internet, nobody cared that you were a dog?”
>

Re: Password managers

[paulf]

On Fri, 10 Nov 2023 00:39:08 -0500
 wrote:

> On Thu, 9 Nov 2023 12:46:23 -0500
> Todd Zullinger  wrote:
> 
> > 
> > [1] https://www.passwordstore.org/
> > 
> 
> Excellent suggestion!
> 
> I can't get it to work properly, because there must be something
> fundamentally missing in my understanding of GPG, etc.
> 
> To initiate the store, you use the following command:
> 
> pass init 
> 
> If I feed this my master password for the "gpg-id", the .gpg-id file
> in the password store shows my master password in the clear. This
> can't be right. None of the docs explain what a "gpg-id" actually is.
> 
> I found some docs on Redhat's site where you could generate a gpg
> file:
> 
> gpg --full-generate-key
> 
> This asks a bunch of questions, and asks me for my master password. It
> generates a file: ~/.gnupg/pubring.kbx, and add a couple of hex
> strings in ~/.gnupg/private-keys-v1.d. Seems like I should be using
> one of those strings as my private key for gpg-id, but which one?
> 
> I'm really not sure what to give the init command for a gpg-id. Any
> help would be much appreciated.
> 
> Paul
> 

Sorry for the confusion. I figured it out. The gpg-id is the ID I used
when I set up the gpg key mentioned above. I was able to set up pass
and add password entries.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Password managers

[paulf]

On Thu, 9 Nov 2023 12:46:23 -0500
Todd Zullinger  wrote:

> Hi,
> 
> pa...@quillandmouse.com wrote:
> > I have a bash/GPG based password manager I wrote years ago, but I'd
> > like to use something more "accepted/popular". The problem I have
> > with the other password managers I've looked at is that you can
> > store a very limited amount of information for each "account". For
> > example, for one of my logins, I may have to store the answers to
> > three security questions, an account login, email address, the
> > actual password, and maybe the mobile phone number associated with
> > the login. I also object to my password information being stored
> > online by some password manager vendor.
> > 
> > Does anyone know of a password manager which will store a variety of
> > user-defined information for each login, and not store that
> > information on the internet (and which is free as in beer)?
> 
> You may like pass[1].  It's a bash script which uses gpg, so
> it's somewhat familiar to what you've written in a sense.
> 
> It supports random data via the --multiline (-m) option.
> 
> It's locally hosted (though you can use online syncing tools
> if you want).  There are a a good number of alternative
> clients for it as well, to suit various use cases or
> environments.
> 
> [1] https://www.passwordstore.org/
> 

Excellent suggestion!

I can't get it to work properly, because there must be something
fundamentally missing in my understanding of GPG, etc.

To initiate the store, you use the following command:

pass init 

If I feed this my master password for the "gpg-id", the .gpg-id file in
the password store shows my master password in the clear. This can't be
right. None of the docs explain what a "gpg-id" actually is.

I found some docs on Redhat's site where you could generate a gpg file:

gpg --full-generate-key

This asks a bunch of questions, and asks me for my master password. It
generates a file: ~/.gnupg/pubring.kbx, and add a couple of hex strings
in ~/.gnupg/private-keys-v1.d. Seems like I should be using one of
those strings as my private key for gpg-id, but which one?

I'm really not sure what to give the init command for a gpg-id. Any
help would be much appreciated.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Password managers

[der.hans]

Am 09. Nov, 2023 schwätzte der.hans so:

moin moin,

below I said KeePassXC doesn't have a way of syncing passwords with
another password database file. Tonight I was looking at KeePassXC SSH
integration documentation and I see there is a sharing option, KeeShare.

"KeeShare allows you to share a subset of your credentials with others and
vice versa."

In my example of my phone the others are myself and I :).

https://keepassxc.org/docs/KeePassXC_UserGuide#_database_sharing_with_keeshare

I will experiment and see if I can get sharing to work the way I want it
to.

ciao,

der.hans


Am 09. Nov, 2023 schwätzte pa...@quillandmouse.com so:

moin moin Paul,


Folks:

I have a bash/GPG based password manager I wrote years ago, but I'd
like to use something more "accepted/popular". The problem I have with
the other password managers I've looked at is that you can store a very
limited amount of information for each "account". For example, for
one of my logins, I may have to store the answers to three security
questions, an account login, email address, the actual password, and
maybe the mobile phone number associated with the login. I also object
to my password information being stored online by some password manager
vendor.

Does anyone know of a password manager which will store a variety of
user-defined information for each login, and not store that information
on the internet (and which is free as in beer)?


In KeePass-based projects like KeePassXC you can store the usual title,
username, password, URL and notes in the main screen/tab.

In the advanced tab you can store further key/value pairs. This works well
for storing random strings for security questions and answers.

The responses can been starred out like password entries are. There isn't
a keyboard shortcut to copy them, but there is a menu drop down, so you
can get the values without having to open the entry.

There's also an option to add attachments.

I say KeePass-based because KeePass was the original project. KeePassX was
a port of the windows KeePass project to Linux and other platforms.
KeePassXC is a more active, community developed fork of KeePassX. I've
been using the latter two for many, many years.

Thanks to the developers and packagers for the projects!

All 3 are using KeePass file formats. There are other packages that
understand the formats. F-Droid has several if you're wanting some of your
passwords on your phone. Because it's a common format you have some choice
into which tool you want to use. There are also some command line options.

The biggest lack I've seen for host-your-own is that there isn't a secure
way to do partial sync between password files. For instance, I don't need
all my passwords on my phone, so would like to have phone.kdbx with just
the few I need, but be able to sync with my everything.kdbx file if
changes are made in one or the other.

KeePassXC FAQ on file formats.

https://keepassxc.org/docs/#faq-format

ciao,

der.hans


Paul





--
#  https://www.SpiralArray.com   https://www.PhxLinux.org
#  It's up to the reader to make the book interesting.
#  An author has only the opportunity to make it uninteresting. - der.hans

Re: Password managers

[John Conover]

John Darrah writes:
> On Thu, 2023-11-09 at 16:03 -0800, pa...@quillandmouse.com wrote:
> > Folks:
> > 
> > Does anyone know of a password manager which will store a variety of
> > user-defined information for each login, and not store that
> > information
> > on the internet (and which is free as in beer)?
> > 
> 
> Take a look at 'secrets' which is a Gnome native app. It uses a
> database and key file compatible with Password Safe.
>

Pass works well, too. http://www.passwordstore.org/.
Uses gpg encryption.

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: Password managers

[John Darrah]

On Thu, 2023-11-09 at 16:03 -0800, pa...@quillandmouse.com wrote:
> Folks:
> 
> Does anyone know of a password manager which will store a variety of
> user-defined information for each login, and not store that
> information
> on the internet (and which is free as in beer)?
> 

Take a look at 'secrets' which is a Gnome native app. It uses a
database and key file compatible with Password Safe.

-- john

Re: Password managers

[der.hans]

Am 09. Nov, 2023 schwätzte pa...@quillandmouse.com so:

moin moin Paul,


Folks:

I have a bash/GPG based password manager I wrote years ago, but I'd
like to use something more "accepted/popular". The problem I have with
the other password managers I've looked at is that you can store a very
limited amount of information for each "account". For example, for
one of my logins, I may have to store the answers to three security
questions, an account login, email address, the actual password, and
maybe the mobile phone number associated with the login. I also object
to my password information being stored online by some password manager
vendor.

Does anyone know of a password manager which will store a variety of
user-defined information for each login, and not store that information
on the internet (and which is free as in beer)?


In KeePass-based projects like KeePassXC you can store the usual title,
username, password, URL and notes in the main screen/tab.

In the advanced tab you can store further key/value pairs. This works well
for storing random strings for security questions and answers.

The responses can been starred out like password entries are. There isn't
a keyboard shortcut to copy them, but there is a menu drop down, so you
can get the values without having to open the entry.

There's also an option to add attachments.

I say KeePass-based because KeePass was the original project. KeePassX was
a port of the windows KeePass project to Linux and other platforms.
KeePassXC is a more active, community developed fork of KeePassX. I've
been using the latter two for many, many years.

Thanks to the developers and packagers for the projects!

All 3 are using KeePass file formats. There are other packages that
understand the formats. F-Droid has several if you're wanting some of your
passwords on your phone. Because it's a common format you have some choice
into which tool you want to use. There are also some command line options.

The biggest lack I've seen for host-your-own is that there isn't a secure
way to do partial sync between password files. For instance, I don't need
all my passwords on my phone, so would like to have phone.kdbx with just
the few I need, but be able to sync with my everything.kdbx file if
changes are made in one or the other.

KeePassXC FAQ on file formats.

https://keepassxc.org/docs/#faq-format

ciao,

der.hans


Paul


--
#  https://www.SpiralArray.com   https://www.PhxLinux.org
# "You want weapons? We're in a library! Books! The best weapons in the
# world! This room's the greatest arsenal we could have - arm yourselves!"
# -- the Doctor: Doctor Who, Tooth and Claw, 2006

Re: Password managers

[Michael Kjörling]

On 9 Nov 2023 11:05 -0500, from pa...@quillandmouse.com:
> Does anyone know of a password manager which will store a variety of
> user-defined information for each login, and not store that information
> on the internet (and which is free as in beer)?

KeepassXC if you want a primarily GUI solution which also happens to
be open source. (There's also a command-line version keepassxc-cli
which can either be driven from the command line or used interactively
in a terminal session.)

pass if you want something which mimics your homegrown solution.

Any decent password manager should have a free-form notes field and I
can confirm that KeepassXC 2.7.4 (which is the version currently
packaged in Bookworm) searches in the notes field when I type into the
search field in the GUI.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Password managers

[Todd Zullinger]

Hi,

pa...@quillandmouse.com wrote:
> I have a bash/GPG based password manager I wrote years ago, but I'd
> like to use something more "accepted/popular". The problem I have with
> the other password managers I've looked at is that you can store a very
> limited amount of information for each "account". For example, for
> one of my logins, I may have to store the answers to three security
> questions, an account login, email address, the actual password, and
> maybe the mobile phone number associated with the login. I also object
> to my password information being stored online by some password manager
> vendor.
> 
> Does anyone know of a password manager which will store a variety of
> user-defined information for each login, and not store that information
> on the internet (and which is free as in beer)?

You may like pass[1].  It's a bash script which uses gpg, so
it's somewhat familiar to what you've written in a sense.

It supports random data via the --multiline (-m) option.

It's locally hosted (though you can use online syncing tools
if you want).  There are a a good number of alternative
clients for it as well, to suit various use cases or
environments.

[1] https://www.passwordstore.org/

-- 
Todd


signature.asc
Description: PGP signature

Re: Password managers

[Pocket]

On 11/9/23 11:05, pa...@quillandmouse.com wrote:

Folks:

I have a bash/GPG based password manager I wrote years ago, but I'd
like to use something more "accepted/popular". The problem I have with
the other password managers I've looked at is that you can store a very
limited amount of information for each "account". For example, for
one of my logins, I may have to store the answers to three security
questions, an account login, email address, the actual password, and
maybe the mobile phone number associated with the login. I also object
to my password information being stored online by some password manager
vendor.

Does anyone know of a password manager which will store a variety of
user-defined information for each login, and not store that information
on the internet (and which is free as in beer)?

Paul


I use keepassxc.

It has an area that you can store information.
It is also cross platform.


--
It's not easy to be me

Re: Password managers

[Roberto C . Sánchez]

On Thu, Nov 09, 2023 at 11:05:53AM -0500, pa...@quillandmouse.com wrote:
> Folks:
> 
> I have a bash/GPG based password manager I wrote years ago, but I'd
> like to use something more "accepted/popular". The problem I have with
> the other password managers I've looked at is that you can store a very
> limited amount of information for each "account". For example, for
> one of my logins, I may have to store the answers to three security
> questions, an account login, email address, the actual password, and
> maybe the mobile phone number associated with the login. I also object
> to my password information being stored online by some password manager
> vendor.
> 
> Does anyone know of a password manager which will store a variety of
> user-defined information for each login, and not store that information
> on the internet (and which is free as in beer)?
> 
KeePassXC (or KeePassX if you're still on buster).

Regards,

-Roberto

-- 
Roberto C. Sánchez

Password managers

[paulf]

Folks:

I have a bash/GPG based password manager I wrote years ago, but I'd
like to use something more "accepted/popular". The problem I have with
the other password managers I've looked at is that you can store a very
limited amount of information for each "account". For example, for
one of my logins, I may have to store the answers to three security
questions, an account login, email address, the actual password, and
maybe the mobile phone number associated with the login. I also object
to my password information being stored online by some password manager
vendor.

Does anyone know of a password manager which will store a variety of
user-defined information for each login, and not store that information
on the internet (and which is free as in beer)?

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Firefox Future and Config [WAS: Re: Password managers]

[Ansgar Burchardt]

"Garreau, Alexandre" writes:
> Wait, do you mean overriding password manager, and TreeStyleTabs will
> certainly and definitely stop to work?

TreeStyleTab is already ported to the new Web Extensions:
  https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/
It says "Compatible with Firefox 57+" right at the top besides the name.

Ansgar

Re: Firefox Future and Config [WAS: Re: Password managers [WAS: Re: when do I get a browsere that will do internet purchases?]]

[Garreau, Alexandre]

On 20/10/2017 at 18:22, The Wanderer wrote:
> (Please learn to quote properly. Failure to quote at all is arguably
> even worse than top-posting.)

Sorry, when I’m answering to all or the main part of a message
completely I find it clearer to try to begin answering with a sole mail,
but thank for the remind of the public convention

> simply because the stress of knowing that I'm going to be left behind
> anyway is not good for my psychological health.

I understand quite well :/ happens often for me…

> Plus, part of the reason why Mozilla has decided to drop XUL support
> (part and parcel of the WebExtensions move) is that they find that the
> work involved in maintaining it and keeping up further development based
> on it is unsustainable - and that's Mozilla, which if I'm not mistaken
> is a much larger and better-funded organization than Debian is.

Damn, Firefox is really that kind of gigantic never-stable software
that’s horrible for that kind of thing (recall me the concept forged by
some french librist about “liberator software”, complementar to the
“free software” concept but about sociomaterial constraints limiting
material freedom of the users), quite the opposite of software such as
TeX and their symbolic tangential versionning… Maybe it is even
intrinsic to the web…

Re: Firefox Future and Config [WAS: Re: Password managers [WAS: Re: when do I get a browsere that will do internet purchases?]]

[The Wanderer]

(Please learn to quote properly. Failure to quote at all is arguably
even worse than top-posting.)

On 2017-10-20 at 18:07, Garreau, Alexandre wrote:

> Wait, do you mean overriding password manager, and TreeStyleTabs
> will certainly and definitely stop to work?

I don't know about TreeStyleTabs. I recall hearing that a solution was
in place for at least some vertical-tabs extensions, but I have not been
following WebExtensions progress closely, simply because the stress of
knowing that I'm going to be left behind anyway is not good for my
psychological health.

The other I don't know about, but I wouldn't be terribly confident about
it. Check with the developers of the extension(s) you're concerned
about; if they'll be supported as WebExtensions, the developers will
probably already have made releases which include that support.

> Would it be realistic to find some way to make Debian maintain
> patches/a fork (or package GNU IceCat and work with them?

Not really. A proper fork of a project the size of Firefox is a MAJOR
project, particularly if you aren't going to be able to draw on
importing upstream's work anymore (because they're rewriting their base
to the point where the patches they write won't be applicable).

Plus, part of the reason why Mozilla has decided to drop XUL support
(part and parcel of the WebExtensions move) is that they find that the
work involved in maintaining it and keeping up further development based
on it is unsustainable - and that's Mozilla, which if I'm not mistaken
is a much larger and better-funded organization than Debian is.

It would not be completely impossible for a volunteer-basis organization
to come together and pick up the work and contribute funds to pay for
the infrastructure and so forth, but as it hasn't really happened in all
these years of Mozilla, the odds of it happening now aren't great either.

> why isn’t any fork packaged into Debian?

As I understand it, because that would mean having to support two very
similar codebases for security patches, which is double the work for the
security team and for relatively little return.

Beyond that, probably also people haven't been coming out of the
woodwork to volunteer to package them.

The former concern may be less significant in the future if Firefox
diverges far enough from the XUL codebase of the forks that there isn't
really much duplication, but even if so, that doesn't guarantee that the
security team will be willing to accept having both.

> ’cause Firefox isn’t known to be that cool for their decisions) that
> could still do that? Possibly still supporting XUL plus WebExtensions
> of course,

As above, this would quickly become unmaintainable in the absence of a
much larger outpouring of sustained, skilled volunteer effort than is
likely to occur.

Even if such a volunteer work were to get going, it would be better to
have it be independent of Debian, for a variety of reasons. (And basing
it on one of the existing forks would probably be a good idea, if only
because they probably already have some of that volunteer developer
base.)

> but also maybe some extended version of WebExtensions that allow this
> kind of stuff?

About the closest thing I can think of to this would be something akin
to what the recent Firefox versions have had: supporting both
WebExtensions and XUL extensions side-by-side, and also supporting
"hybrid" extensions (one type embedded inside the other) which can talk
to both APIs to some degree.

Firefox only supported those for transitional purposes, but it might not
be impossible to keep them around as a thing of their own - although the
effort required to do so, particularly long-term, would probably be
prohibitive.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Firefox Future and Config [WAS: Re: Password managers [WAS: Re: when do I get a browsere that will do internet purchases?]]

[Garreau, Alexandre]

Wait, do you mean overriding password manager, and TreeStyleTabs will
certainly and definitely stop to work?

Would it be realistic to find some way to make Debian maintain patches/a
fork (or package GNU IceCat and work with them? why isn’t any fork
packaged into Debian? ’cause Firefox isn’t known to be that cool for
their decisions) that could still do that? Possibly still supporting XUL
plus WebExtensions of course, but also maybe some extended version of
WebExtensions that allow this kind of stuff?

Re: Password managers [WAS: Re: when do I get a browsere that will do internet purchases?]

[The Wanderer]

On 2017-10-20 at 15:46, Garreau, Alexandre wrote:

> Maybe these extensions will be remade and repackaged with
> web-extensions then (afaik it’s a good move, yet breaking all the old
> apps forever is bad, they should re-integrate it after I while I’d
> personally prefer).
> 
> Waiting for this, XUL extensions I install through Debian on stable
> are perfectly working (maybe if they, dunno, keep easy for distros
> like debian to patch firefox in order to keep XUL support some time
> that’d help?), so that’s probably for a too recent, or even future,
> version that XUL doesn’t work anymore…

It will happen with Firefox 57, which I believe was just released, or
ESR 59, which is due out along with Firefox 59 - in other words, if I'm
not mistaken, probably in January.

Past that point, your only options are:

* Find (and/or make) an extension which does what you need in a way that
is compatible with WebExtensions. In some cases - most prominently,
anything that needs to modify the Firefox UI - this will not happen; the
Mozilla developers explicitly do not want to support doing that.

* Switch to one of the Firefox forks; Waterfox and Pale Moon are the two
best-spoken-of that I know of, and of course there's always still
Seamonkey (although that diverged far enough back that I'd be surprised
if many modern pre-WebExtensions Firefox extensions were still
compatible with it out-of-the-box).

* Stick with ESR52, avoiding upgrades, until some better solution
presents itself - however many years that takes.

For myself, unless Debian decides to start packaging one of the forks
which retains compatibility with the "long tail" of extensions, I will
be taking option three. (At least three of the addons which I consider
non-negotiably critical explicitly need to perform UI modification as
part of the features for which I want them, and at least two of them are
entirely unmaintained except by me.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Password managers [WAS: Re: when do I get a browsere that will do internet purchases?]

[Garreau, Alexandre]

Maybe these extensions will be remade and repackaged with web-extensions
then (afaik it’s a good move, yet breaking all the old apps forever is
bad, they should re-integrate it after I while I’d personally prefer).

Waiting for this, XUL extensions I install through Debian on stable are
perfectly working (maybe if they, dunno, keep easy for distros like
debian to patch firefox in order to keep XUL support some time that’d
help?), so that’s probably for a too recent, or even future, version
that XUL doesn’t work anymore…

Re: Password managers [WAS: Re: when do I get a browsere that will do internet purchases?]

[Jeremy Nicoll]

On Fri, 20 Oct 2017, at 02:27, Garreau, Alexandre wrote:

> I’d especially like to notice that there are the packages
> *xul-ext-gnome-keyring* and *xul-ext-kwallet5* which make both Firefox
> and Thunderbird use respectively GNOME and KDE’s password
> managers. That’s way more secure imho, and especially with the package
> xul-ext-pwdhash.

But haven't Mozilla, just phased-out xul support in Firefox, requiring
extensions to be written using the 'web-extensions' API?

https://developer.mozilla.org/en-US/Add-ons/WebExtensions

-- 
Jeremy Nicoll - my opinions are my own.

Re: Password managers [WAS: Re: when do I get a browsere that will do internet purchases?]

[Gene Heskett]

On Thursday 19 October 2017 21:27:07 Garreau, Alexandre wrote:

> On 19/10/2017 at 22:24, Peter Hillier-Brook wrote:
> > I had similar problems and switched to Chromium, however I would
> > never trust *any* browser to store passwords
>
> I don’t especially like or trust fully Firefox, but I wouldn’t trust
> Chromium more (yet my bank website too doesn’t work with firefox,
> that’s why I do everything from commandline with boobank (which does),
> yet once I used to use Chromium only for that).
>
> I’d especially like to notice that there are the packages
> *xul-ext-gnome-keyring* and *xul-ext-kwallet5* which make both Firefox
> and Thunderbird use respectively GNOME and KDE’s password
> managers. That’s way more secure imho, and especially with the package
> xul-ext-pwdhash.
>
> Waiting for the beautiful day where you’ll have only one passphrase to
> remember, update and type for both grub/libreboot, luks, PAM/login,
> password manager, and gpg-agent… Would that difficult to achieve?
> Would require intensive hack on packages grub, luks, shadow,
> Linux-PAM, Gnome-Keyring/KWallet and gnupg2 right?
>
> There are also the solution on allowing that unique passphrase per a
> usb token, a pgp card, or no passphrase at all (when you have memory
> problems and if you’re old and poor enough for example).
>
Don't mention age, cuz at 83 the word itself is discouraging.

> Makes computers way more accessible…


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: Password managers [WAS: Re: when do I get a browsere that will do internet purchases?]

[Ben Caradoc-Davies]

On 20/10/17 14:04, Roberto C. Sánchez wrote:

On Thu, Oct 19, 2017 at 10:24:55PM +0100, Peter Hillier-Brook wrote:

I had similar problems and switched to Chromium, however I would never
trust *any* browser to store passwords. Passwordsafe is my best friend,
especially since it was upgraded to run under Stretch.

+1
Though, I prefer KeePassX.


+1 for KeePassX on Debian and KeePassDroid on Android. Both use the same 
.kdbx format so databases can be synchronised with sftp (AndFTP on the 
Android side, but looking for open source recommendations).


Kind regards,

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

Password managers [WAS: Re: when do I get a browsere that will do internet purchases?]

[Garreau, Alexandre]

On 19/10/2017 at 22:24, Peter Hillier-Brook wrote:
> I had similar problems and switched to Chromium, however I would never
> trust *any* browser to store passwords

I don’t especially like or trust fully Firefox, but I wouldn’t trust
Chromium more (yet my bank website too doesn’t work with firefox, that’s
why I do everything from commandline with boobank (which does), yet once
I used to use Chromium only for that).

I’d especially like to notice that there are the packages
*xul-ext-gnome-keyring* and *xul-ext-kwallet5* which make both Firefox
and Thunderbird use respectively GNOME and KDE’s password
managers. That’s way more secure imho, and especially with the package
xul-ext-pwdhash.

Waiting for the beautiful day where you’ll have only one passphrase to
remember, update and type for both grub/libreboot, luks, PAM/login,
password manager, and gpg-agent… Would that difficult to achieve? Would
require intensive hack on packages grub, luks, shadow, Linux-PAM,
Gnome-Keyring/KWallet and gnupg2 right?

There are also the solution on allowing that unique passphrase per a
usb token, a pgp card, or no passphrase at all (when you have memory
problems and if you’re old and poor enough for example).

Makes computers way more accessible…

Password managers [WAS: Re: when do I get a browsere that will do internet purchases?]

[Roberto C . Sánchez]

On Thu, Oct 19, 2017 at 10:24:55PM +0100, Peter Hillier-Brook wrote:
> 
> I had similar problems and switched to Chromium, however I would never
> trust *any* browser to store passwords. Passwordsafe is my best friend,
> especially since it was upgraded to run under Stretch.

+1

Though, I prefer KeePassX.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: comparing password managers in Debian, synchronizing on multiple devices

[David Wright]

On Tue 25 Oct 2016 at 08:43:15 (+0200), deloptes wrote:
> Ben Finney wrote:
> 
> > I prefer integration to all applications on the desktop: i.e., the
> > program should simply place the passphrase in the clipboard, allowing me
> > to paste it into whatever form I visit. That covers the browser as well.
> 
> I've been using gpg since 2002 and never heard of PassStore or pass or
> whatever. But through all those years I used the kwallet and now tdewallet.
> Exactly because it is integrated into the system/desktop.
> 
> The idea to upload encrypted password on some cloud service is scary , but
> perhaps I am a bit old fashioned. Passwords are usually kept in a safe
> place. Especially private keys are not meant to be shared  so I did not
> understand what are you doing with your private gpg key? Do you have it
> printed on paper?
> 
> I think what you are describing is a bit of useless, but a summary of all
> password managers and storage systems is still pretty usefull. With my
> previous post I wanted to point out that completeness is what I would
> expect from a debian wiki article. You can save the filtering criteria for
> yourself. Let the people decide by providing information on the key
> features of each application.

Eh? Getting information on these packages is all too easy. What's more
difficult is mining people's knowledge of whether these key features
are beneficial, disadvantageous, a security risk, or just neutral,
nice to have.

I knew about pass: it contains the string "password manager" in its
description. Perhaps you missed it because it has no tags in the
Packages file, not one. Anyway, the full desciption reads:
"lightweight directory-based password manager
"Stores, retrieves, generates, and synchronizes passwords securely
 using gpg, pwgen, and git."

I can't see the point in just duplicating that information on a wiki
page. There's a list of possibilities at
https://wiki.archlinux.org/index.php/List_of_applications/Security#Password_managers
and you know that their websites will trumpet their key features.

But I can see the added value in running that information past
a set of criteria like "The database must be in a format already known
to be readable by other, mature, well-maintained software" to quote
just one. That sort of knowledge is what gets discussed here, and
a summary in one place would be very useful. It might look like
the sort of grid often seen in Wikipedia (though it might need a
lot of footnotes explaining why it passed/failed to come up to
scratch).

Cheers,
David.

Re: comparing password managers in Debian, synchronizing on multiple devices

[Ben Finney]

deloptes  writes:

> The idea to upload encrypted password on some cloud service is scary

Then don't upload it to a cloud service :-)

Instead, upload it to a specific host, one that you can make an informed
trust decision about.

> Passwords are usually kept in a safe place.

Yes. Do you consider encrypted files, that can only be unlocked by one's
private key, to be safe?

> Especially private keys are not meant to be shared  so I did not
> understand what are you doing with your private gpg key? Do you have
> it printed on paper?

The private key for unlocking the database stays on the device where I'm
using it. So yes, that means I need to be able to trust the device on
which I unlock my passphrase database.

That's entailed within the task: to access one's secret passphrases, one
must do that on a device one trusts with that task.


(Good sigmonster, have a cookie.)

-- 
 \ “Try adding “as long as you don't breach the terms of service – |
  `\  according to our sole judgement” to the end of any cloud |
_o__)  computing pitch.” —Simon Phipps, 2010-12-11 |
Ben Finney

Re: comparing password managers in Debian, synchronizing on multiple devices

[deloptes]

Ben Finney wrote:

> I prefer integration to all applications on the desktop: i.e., the
> program should simply place the passphrase in the clipboard, allowing me
> to paste it into whatever form I visit. That covers the browser as well.

I've been using gpg since 2002 and never heard of PassStore or pass or
whatever. But through all those years I used the kwallet and now tdewallet.
Exactly because it is integrated into the system/desktop.

The idea to upload encrypted password on some cloud service is scary , but
perhaps I am a bit old fashioned. Passwords are usually kept in a safe
place. Especially private keys are not meant to be shared  so I did not
understand what are you doing with your private gpg key? Do you have it
printed on paper?

I think what you are describing is a bit of useless, but a summary of all
password managers and storage systems is still pretty usefull. With my
previous post I wanted to point out that completeness is what I would
expect from a debian wiki article. You can save the filtering criteria for
yourself. Let the people decide by providing information on the key
features of each application.

regards

Re: comparing password managers in Debian, synchronizing on multiple devices

[William Satterthwaite]

I think a table; something like this would be prudent. I only know about
FPM2 as that is what I use, would be interesting in seeing a summary of
alternatives.

Password Manager
Supports snycing
Features
FPM2
No
Cipher: ACS-256
- Generates passwords up to 255 characters long, with options for
numbers, symbols and avoiding ambiguous characters (1 and I etc.)
- Password categories and filtering
- Search on typing
- Store addition reference information (url, notes, username)
- Password launchers
- Copy password to Primary selection or clipboard without showing it.
- Can use a key file
- Export/Import passwords to/from XML for moving between managers


About syncing, I use Mega.nz, because client side encryption, but some
inbuilt syncing system would be better, ideally peer to peer, so it
never leaves my devices.

On 25/10/16 06:44, deloptes wrote:
> Daniel Pocock wrote:
>
>>
>> On 24/10/16 13:05, Daniel Pocock wrote:
>>>
>>> There have been various discussions in here and in some derivative
>>> projects like Ubuntu about choosing and using password managers,
>>> especially the way to sync their password lists across multiple devices.
>>>
>>> Given the way we do things in Debian it is important not to depend on a
>>> service like Dropbox to sync the password files.
>>>
>>> Therefore, how are people choosing a password manager and solving this
>>> in practice?
>>>
>>> - which password managers have a built-in mechanism for synchronizing or
>>> merging password lists on multiple devices?
>>>
>>> - who is using some other mechanism such as Git or ownCloud to sync?
>>>
>>> I've made a list of some of the password managers in Debian:
>>>
>>> https://packages.qa.debian.org/a/assword.html
>>> https://packages.qa.debian.org/p/password-gorilla.html
>>> https://packages.qa.debian.org/p/password-store.html
>>> https://packages.qa.debian.org/r/revelation.html
>>> https://packages.qa.debian.org/k/keepass2.html
>>> https://packages.qa.debian.org/k/keepassx.html
>>> https://packages.qa.debian.org/k/kedpm.html
>>> https://packages.qa.debian.org/f/fpm2.html
>>> https://packages.qa.debian.org/c/cpm.html
>>> https://packages.qa.debian.org/p/passwordsafe.html
>>>
>>> There are quite a few and so it is hard for somebody to know the best
>>> place to start, maybe a comparison table in the wiki will be needed.
>> Wiki now created:
>>
>> https://wiki.debian.org/PasswordManagement
>>
>>
>>> Some other factors that come to mind for a comparison table:
>>>
>>> - support for PGP
>>> - support for other strong crypto (e.g. smartcard)
>>> - merging algorithm for multiple devices
>>> - multi-user / team capabilities
>>> - browser integration
>>>
>>> I notice that Tails chose to include KeePassX, although there is some
>>> uncertainty how it was selected:
>>>
>>> https://labs.riseup.net/code/issues/9231
>>>
>>> Can anybody comment on its history there?
>>>
> What about the wallet? In KDE4 and former KDE3 now Trinity Desktop we use
> the kwallet now tdewallet to store the passwords. I know gnome has also
> one, but I don't know it's name. I think each desktop has or should have a
> kind of integrated password manager. It is worth mentioning this.
>
> https://userbase.kde.org/KDE_Wallet_Manager
> https://utils.kde.org/projects/kwalletmanager/
> https://en.wikipedia.org/wiki/KWallet
>
> regards
>
>
>



signature.asc
Description: OpenPGP digital signature

Re: comparing password managers in Debian, synchronizing on multiple devices

[Ben Finney]

Daniel Pocock <dan...@pocock.pro> writes:

> Therefore, how are people choosing a password manager and solving this
> in practice?

A primary criterion for my data is: Avoid depending on a service I can't
quickly replicate elsewhere with all my data intact.

This tends strongly toward standard protocols, and services that are
published as free software.

So, for a password manager:

* The database must be in a format already known to be readable by
  other, mature, well-maintained software.

  (This disqualifies an application-specific storage format that might
  have been readable when I first checked but doesn't remain compatible
  over time.)

* The encryption must be immediately available to decrypt with standard
  tools, using keys in a standard format and available in an obvious
  place to use.

  (This disqualifies software that says it supports a standard
  encryption algorithm but its keys or encrypted data are not right
  there for me to try decrypting in a hurry with standard tools.)

* The synchronisation must default to, and encourage, standard
  widely-implemented file synchronisation systems.

  (This disqualifies software that has a non-default option for some
  protocol that most of the application's users don't use, therefore
  it's not as widely user-tested and more likely to be unreliable when I
  need it.)

* The synchronisation must default to, and encourage, choosing an
  independently-maintained hosting provider.

  (Similar to the above, if most people default to a single hosting
  provider then the federated hosting will not be nearly well tested
  enough to assure reliability in a pinch.)

* The synchronisation must easily and obviously allow a user to set up
  their own (or ask a skilled friend to set up) hosting, on at least an
  equal standing with other synchronisation methods.

For me, at present the best option is Password Store (a.k.a. ‘pass’).

> - which password managers have a built-in mechanism for synchronizing
> or merging password lists on multiple devices?

By setting a Git remote to a private hosted repository, all my devices
can sync the password database by Git push and pull.

> - who is using some other mechanism such as Git or ownCloud to sync?

Git is not an other method, it's built in to the application :-)

> Some other factors that come to mind for a comparison table:
>
> - support for PGP

Password Store uses standard OpenPGP, as implemented by GnuPG.

> - support for other strong crypto (e.g. smartcard)

Don't know about this.

> - merging algorithm for multiple devices

Password Store uses a separate encrypted file for each entry, so merges
are only a matter of managing a directory tree.

> - multi-user / team capabilities

I've seen discussion of this in the Password Store community; it usually
comes down to managing one's GnuPG keys.

Password Store allows the database to be encrypted to (i.e. unlockable
by any of) multiple GnuPG keys.

> - browser integration

I prefer integration to *all* applications on the desktop: i.e., the
program should simply place the passphrase in the clipboard, allowing me
to paste it into whatever form I visit. That covers the browser as well.

-- 
 \“But it is permissible to make a judgment after you have |
  `\examined the evidence. In some circles it is even encouraged.” |
_o__)—Carl Sagan, _The Burden of Skepticism_, 1987 |
Ben Finney

Re: comparing password managers in Debian, synchronizing on multiple devices

[deloptes]

Daniel Pocock wrote:

> 
> 
> On 24/10/16 13:05, Daniel Pocock wrote:
>> 
>> 
>> There have been various discussions in here and in some derivative
>> projects like Ubuntu about choosing and using password managers,
>> especially the way to sync their password lists across multiple devices.
>> 
>> Given the way we do things in Debian it is important not to depend on a
>> service like Dropbox to sync the password files.
>> 
>> Therefore, how are people choosing a password manager and solving this
>> in practice?
>> 
>> - which password managers have a built-in mechanism for synchronizing or
>> merging password lists on multiple devices?
>> 
>> - who is using some other mechanism such as Git or ownCloud to sync?
>> 
>> I've made a list of some of the password managers in Debian:
>> 
>> https://packages.qa.debian.org/a/assword.html
>> https://packages.qa.debian.org/p/password-gorilla.html
>> https://packages.qa.debian.org/p/password-store.html
>> https://packages.qa.debian.org/r/revelation.html
>> https://packages.qa.debian.org/k/keepass2.html
>> https://packages.qa.debian.org/k/keepassx.html
>> https://packages.qa.debian.org/k/kedpm.html
>> https://packages.qa.debian.org/f/fpm2.html
>> https://packages.qa.debian.org/c/cpm.html
>> https://packages.qa.debian.org/p/passwordsafe.html
>> 
>> There are quite a few and so it is hard for somebody to know the best
>> place to start, maybe a comparison table in the wiki will be needed.
> 
> Wiki now created:
> 
> https://wiki.debian.org/PasswordManagement
> 
> 
>> 
>> Some other factors that come to mind for a comparison table:
>> 
>> - support for PGP
>> - support for other strong crypto (e.g. smartcard)
>> - merging algorithm for multiple devices
>> - multi-user / team capabilities
>> - browser integration
>> 
>> I notice that Tails chose to include KeePassX, although there is some
>> uncertainty how it was selected:
>> 
>> https://labs.riseup.net/code/issues/9231
>> 
>> Can anybody comment on its history there?
>>

What about the wallet? In KDE4 and former KDE3 now Trinity Desktop we use
the kwallet now tdewallet to store the passwords. I know gnome has also
one, but I don't know it's name. I think each desktop has or should have a
kind of integrated password manager. It is worth mentioning this.

https://userbase.kde.org/KDE_Wallet_Manager
https://utils.kde.org/projects/kwalletmanager/
https://en.wikipedia.org/wiki/KWallet

regards

Re: comparing password managers in Debian, synchronizing on multiple devices

[Teemu Likonen]

Daniel Pocock [2016-10-24 13:05:28+02] wrote:

> Given the way we do things in Debian it is important not to depend on a
> service like Dropbox to sync the password files.
>
> Therefore, how are people choosing a password manager and solving this
> in practice?

I have used "pass" and liked it. It's a command-line tool, written in
Bash language, and it stores passwords as separate gpg-encrypted files
in ~/.password-store. .
Pass has a Git support but I have never used that. The basic usage is to
search for named password which can be copied to clipboard. The
clipboard is automatically cleared after 20 (or so, I don't remember).

There are a couple things in pass's user interface that I don't like so
I wrote my own Bash script which is compatible with pass's storage. I
have two Linux computers and I use Unison to sync password directory
(and many other files) between them.

-- 
/// Teemu Likonen   - .-..    //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///


signature.asc
Description: PGP signature

Re: comparing password managers in Debian, synchronizing on multiple devices

[Daniel Pocock]

On 24/10/16 13:05, Daniel Pocock wrote:
> 
> 
> There have been various discussions in here and in some derivative
> projects like Ubuntu about choosing and using password managers,
> especially the way to sync their password lists across multiple devices.
> 
> Given the way we do things in Debian it is important not to depend on a
> service like Dropbox to sync the password files.
> 
> Therefore, how are people choosing a password manager and solving this
> in practice?
> 
> - which password managers have a built-in mechanism for synchronizing or
> merging password lists on multiple devices?
> 
> - who is using some other mechanism such as Git or ownCloud to sync?
> 
> I've made a list of some of the password managers in Debian:
> 
> https://packages.qa.debian.org/a/assword.html
> https://packages.qa.debian.org/p/password-gorilla.html
> https://packages.qa.debian.org/p/password-store.html
> https://packages.qa.debian.org/r/revelation.html
> https://packages.qa.debian.org/k/keepass2.html
> https://packages.qa.debian.org/k/keepassx.html
> https://packages.qa.debian.org/k/kedpm.html
> https://packages.qa.debian.org/f/fpm2.html
> https://packages.qa.debian.org/c/cpm.html
> https://packages.qa.debian.org/p/passwordsafe.html
> 
> There are quite a few and so it is hard for somebody to know the best
> place to start, maybe a comparison table in the wiki will be needed.

Wiki now created:

https://wiki.debian.org/PasswordManagement


> 
> Some other factors that come to mind for a comparison table:
> 
> - support for PGP
> - support for other strong crypto (e.g. smartcard)
> - merging algorithm for multiple devices
> - multi-user / team capabilities
> - browser integration
> 
> I notice that Tails chose to include KeePassX, although there is some
> uncertainty how it was selected:
> 
> https://labs.riseup.net/code/issues/9231
> 
> Can anybody comment on its history there?
> 

comparing password managers in Debian, synchronizing on multiple devices

[Daniel Pocock]

There have been various discussions in here and in some derivative
projects like Ubuntu about choosing and using password managers,
especially the way to sync their password lists across multiple devices.

Given the way we do things in Debian it is important not to depend on a
service like Dropbox to sync the password files.

Therefore, how are people choosing a password manager and solving this
in practice?

- which password managers have a built-in mechanism for synchronizing or
merging password lists on multiple devices?

- who is using some other mechanism such as Git or ownCloud to sync?

I've made a list of some of the password managers in Debian:

https://packages.qa.debian.org/a/assword.html
https://packages.qa.debian.org/p/password-gorilla.html
https://packages.qa.debian.org/p/password-store.html
https://packages.qa.debian.org/r/revelation.html
https://packages.qa.debian.org/k/keepass2.html
https://packages.qa.debian.org/k/keepassx.html
https://packages.qa.debian.org/k/kedpm.html
https://packages.qa.debian.org/f/fpm2.html
https://packages.qa.debian.org/c/cpm.html
https://packages.qa.debian.org/p/passwordsafe.html

There are quite a few and so it is hard for somebody to know the best
place to start, maybe a comparison table in the wiki will be needed.

Some other factors that come to mind for a comparison table:

- support for PGP
- support for other strong crypto (e.g. smartcard)
- merging algorithm for multiple devices
- multi-user / team capabilities
- browser integration

I notice that Tails chose to include KeePassX, although there is some
uncertainty how it was selected:

https://labs.riseup.net/code/issues/9231

Can anybody comment on its history there?