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 3 of 3 — ← Prev page 1 2 [3]

#194399 — Re: Chaniging focus: security ouitside a password manager

On 04/02/2018 10:07 PM, rhkramer@gmail.com wrote:
>    * during copy and paste operations, the plaintext password could remain on 
> the C&P "stack". thus making it vulnurable:  Some notes:

This is a semi-valid concern, depends on your usage patterns. For
example, some browsers may expose a JS API that allows sites to read
your clipboard. Adobe Flash has a similar feature, IIRC.

Also, other applications running on your desktop may be able to read the
clipboard contents as well, but that would require user privileges on
your machine. Take that into account when deciding whether this is
something you need to be worried about.

>       (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'm sure this is a relatively common feature in password manages. pass,
for example, has this feature. That's quite something, considering how
minimalistic it is compared to other, more fully-featured password
managers out there. It does just use xclip(1), though.

>From pass(1):

show [ --clip, -c ] pass-name
       Decrypt  and print a password named pass-name. If --clip
       or -c is  specified,  do  not  print  the  password  but
       instead  copy  the  first  line  to  the clipboard using
       xclip(1) and then restore the  clipboard  after  45  (or
       PASSWORD_STORE_CLIP_TIME) seconds.

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

pass also has this feature, suggesting it is a common feature to may
password managers. Through a third-party script (available in contrib/
on the git repo, or /usr/share/doc/pass/examples/dmenu/ after
installation on debian), this is possible. It basically just makes a
call to xdotool(1) and passes in the password to be typed. xdotool
handles the actual typing. As a plus, works even when sites decide to
block c&p. Obviously, you could use some other front-end, or write one
yourself.

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

As Tomás said, make sure your swap partition is encrypted, if you bother
with disk encryption. Even when not hibernating, if you start swapping,
you may be storing valuable information in there without you knowing.
It's usually a Bad Idea to have a plaintext swap but encrypted data
partitions.

Moreover, proper crypto code would probably make sure to remove keys
from memory as quickly as possible, as soon as they're no longer
necessary. No idea if GPG does this, though. Might be worth looking into.

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

#194425 — Re: Chaniging focus: security ouitside a password manager

rhkramer@gmail.com writes:

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

Yes, the Password Store tools do this (actively delete the content from
the clipboard, after a configurable timeout).

>       (2) another approach could be that a password manager provides a
> facility to write the password to a designated textbox […]

Another common approach, similar to that, is to have a web browser
plug-in which reads the same database.

Thanks to WebExt support in both Chromium and Firefox, we have the
Browserpass <URL:https://dannyvankooten.com/chrome-extension-for-pass/>
extension that allows using credentials directly from a Password Store
database.

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

I think you should move to the above model (tools like Password Store
that actively work to get the credentials out of the clipboard quickly)
as an immediate improvement first, and see how well that satisfies.

-- 
 \     “Don't be afraid of missing opportunities. Behind every failure |
  `\         is an opportunity somebody wishes they had missed.” —Jane |
_o__)                                          Wagner, via Lily Tomlin |
Ben Finney

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

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

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

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

moin moin,

> Just continuing to think (or maybe not think ;-) about password managers /
> password security, changing the focus slightly (I think) but keeping the same
> thread.
>
> I'm now thinking about the security (or vulnurability) of passwords during
> "normal" usage--I mean, I'm thinking about the times when a password, even
> though stored in a very secure manner (in a password manager or encrypted
> file(s) of some sort), the password is viewable in plain text, and thus, to a
> greater or lesser degree, vulnurable.
>
> The first two situations that come to mind include:
>
>   * during copy and paste operations, the plaintext password could remain on
> the C&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.

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

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

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

The auto-play feature might do what you want.

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

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

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

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

ciao,

der.hans

>   * during hibernation (or maybe suspend and resume): (I use neither at the
> present time, but, one stores the machine's state (including RAM) to disk, the
> other stores the (CPU) state to RAM while preserving the other contents of
> RAM.)  Hibernation could result in the plaintext of passwords being stored on
> disk while the power is off, making the plaintext passwords vulnurable if the
> machine is stolen.
>
> My current approach to passwords includes storing them in an encrypted file
> which is only ever decrypted to a RAMdisk, with the idea / intention that, if
> power is lost, or the machine is shutdown, the plaintext passwords would
> disappear from RAM (except to the extent that (iiuc) there are (NSA) ways to
> recover the contents of RAM if power is restored to the machine fairly
> quickly).  My assumption, without considering hibernation. was that the only
> remaining copy of the passwords would be in the encrypted files.
>
> Maybe my concern about these situations is unrealistic, but I want to consider
> it, so all comments are welcome.
>
> BTW, I can see that the Master Password approach might be the solution for
> most of the problem, unless I (or it) uses copy and paste to put passwords in
> a textbox.
>
>
>
>
>
> On Friday, March 30, 2018 09:44:18 PM Andrew McGlashan wrote:
>

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

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

#194430 — Re: Chaniging focus: security ouitside a password manager

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

On 03/04/18 01:07, rhkramer@gmail.com wrote:
> 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).

I'm not sure you actually need to be the NSA for that. Anything you can
plug in that can do DMA can probably do it - firewire is one option, but
for something with PCI(e) or other slots you could probably plug in a
special card (or maybe just a firewire card). I think the RAM will
persist for a few minutes at least.

Richard

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

#194440 — Re: Chaniging focus: security ouitside a password manager

On Tuesday, April 03, 2018 01:50:45 AM Richard Hector wrote:
> On 03/04/18 01:07, rhkramer@gmail.com wrote:
> > 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).
> 
> I'm not sure you actually need to be the NSA for that. Anything you can
> plug in that can do DMA can probably do it - firewire is one option, but
> for something with PCI(e) or other slots you could probably plug in a
> special card (or maybe just a firewire card). I think the RAM will
> persist for a few minutes at least.

Yes, I'm sure you're right--or at least for some number of seconds--I guess I 
could look up the refresh timing requirement for a modern RAM chip, that would 
probably give an order of magnitude figure, and with safety factors that are 
surely built in, that figure could be multiplied by two or more.

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

#194454 — Re: Chaniging focus: security ouitside a password manager

On 4/3/18, Richard Hector <richard@walnut.gen.nz> wrote:
> On 03/04/18 01:07, rhkramer@gmail.com wrote:
>> 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).
>
> I'm not sure you actually need to be the NSA for that. Anything you can
> plug in that can do DMA can probably do it - firewire is one option, but
> for something with PCI(e) or other slots you could probably plug in a
> special card (or maybe just a firewire card). I think the RAM will
> persist for a few minutes at least.


Speaking firsthand, for those worried that much about the possibility,
one thing is to add more than ample memory so that RAM has some place
to go quickly.

Just yesterday, my RAM was still *maxxed out* a half hour or so after
I logged back in from having been away from the computer. THAT was
because hardware memory was maxxed out k/t 320+ open (although not
active) browser tabs. It hadn't crossed my mind as to potential
negative consequences of RAM just hanging there until reading the
above.

Am working on my personal lack of enough (computer) memory issue, but
in the meantime, its glass half full side is that it shows what can
and does happen timely to what's being chatted here. Chalked it up on
the win side. :)

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

* runs with duct tape *

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

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

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

> Just continuing to think (or maybe not think ;-) about password managers /  
> password security, changing the focus slightly (I think) but keeping the same 
> thread.
> 
> I'm now thinking about the security (or vulnurability) of passwords during 
> "normal" usage--I mean, I'm thinking about the times when a password, even 
> though stored in a very secure manner (in a password manager or encrypted 
> file(s) of some sort), the password is viewable in plain text, and thus, to a 
> greater or lesser degree, vulnurable.
> 
> The first two situations that come to mind include:
> 
>    * during copy and paste operations, the plaintext password could remain on 
> the C&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.

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

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

-- 
Brian.

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

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

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

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

[...]

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

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

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

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

-- 
Brian.

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

#194164

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

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

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

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

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

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

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

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

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

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

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

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

Regards
-- 
Abdullah Ramazanoglu

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

#194167

On Mon, 26 Mar 2018 04:38:28 +0300 Abdullah Ramazanoglu said:

> I just copy-paste a password from that html table whenever I need it
> (it is open all the time in a background browser tab).

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

-- 
Abdullah Ramazanoglu

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

#194168

On 26/03/18 15:13, Abdullah Ramazanoglu wrote:
> Forgot to mention. For that (and other things) I use a separate dumb
> browser without any active content capabilities (Java, JS, plugins,
> etc.)

It is also worth mentioning:

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

Kind regards,

-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

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

#194165

On 26/03/18 04:52, rhkramer@gmail.com wrote:
> Here are some of what I think are my criteria for a password manager:
>     * encrypted storage on my own machines (no storage "in the cloud")
>     * ability to transfer to other devices, including Android tablets and
> phones
[...]
>     * a means to automatically generate secure passwords

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

Kind regards,


-- 
Ben Caradoc-Davies <ben@transient.nz>
Director
Transient Software Limited <https://transient.nz/>
New Zealand

[toc] | [prev] | [standalone]

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

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

csiph-web