Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Nate Bargmann]

Well, it appears like most things in life this one was self inflicted.
🤬

Yesterday I was working on another project and to verify something was
occurring the 'strace' utility was recommended.  It dawned on me that
this could help me get a clue as to what was happening to the
gnome-keyring-daemon.  Using strace attached to the PID of the daemon
after a reboot showed it was getting the SIGTERM signal at exactly the
top of the hour.  What?!!

After seeing this twice this morning I recalled that I have a cron entry
to kill the 'rec' program.  This was to break up audio files into hourly
segments when recording an amateur radio event.  This was the cron
command:

# Rotate sound recorder files
00 * * * * /usr/bin/pkill -f rec > /dev/null 2> /dev/null

On a hunch I commented that line and Voila! the daemon ran through the
next hour change and is still running as expected.  The man page states
that the '-f' option matches against the full command line, not just the
process name.  So, looking at the gnome-keyring-daemon command line:

   1857 ?SLsl   0:00 /usr/bin/gnome-keyring-daemon --foreground 
--components=pkcs11,secrets --control-directory=/run/user/1000/keyring

I see that the 'rec' in 'directory' provided the match!  Confirmed with
pgrep:

$ pgrep -f rec
1857

It looks like the solution for the future will be to change the cron
line to:

00 * * * * /usr/bin/pkill -f /usr/bin/rec > /dev/null 2> /dev/null

When I want to use it next in order to protect other processes.

I certainly hope this is resolved.  OTOH, it forced me to recall a
number of passwords!  🤣

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Nate Bargmann]

* On 2023 14 Aug 21:29 -0500, Max Nikulin wrote:
> On 14/08/2023 07:30, Nate Bargmann wrote:
> > Now, while typing this email all keyring PIDs have vanished!
> 
> It may be a way to minimize RAM usage.

I don't think so.  It has been persistent in the past in Buster and
Bullseye with GNOME and is persistent on the laptop which is also
running Bookworm and GNOME.  On this desktop it will rather reliably
shutdown/crash about exactly an hour after logging in with no other
desktop activity, i.e. not opening browsers or other apps.

> The agent may be a socket-activated
> process.
>
> systemctl --user list-sockets

The lists are virtually identical between the laptop:

$ systemctl --user list-sockets
LISTEN   UNITACTIVATES  
 
/run/user/1000/bus   dbus.socket 
dbus.service
/run/user/1000/gcr/ssh   gcr-ssh-agent.socket
gcr-ssh-agent.service
/run/user/1000/gnupg/S.dirmngr   dirmngr.socket  
dirmngr.service
/run/user/1000/gnupg/S.gpg-agent gpg-agent.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.browser gpg-agent-browser.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.extra   gpg-agent-extra.socket  
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.ssh gpg-agent-ssh.socket
gpg-agent.service
/run/user/1000/keyring/control   gnome-keyring-daemon.socket 
gnome-keyring-daemon.service
/run/user/1000/pipewire-0pipewire.socket 
pipewire.service
/run/user/1000/pk-debconf-socket pk-debconf-helper.socket
pk-debconf-helper.service
/run/user/1000/pulse/native  pipewire-pulse.socket   
pipewire-pulse.service

11 sockets listed.
Pass --all to see loaded but inactive sockets, too.

and the desktop:

$ systemctl --user list-sockets
LISTENUNITACTIVATES 
  
/run/user/1000/busdbus.socket 
dbus.service
/run/user/1000/gcr/sshgcr-ssh-agent.socket
gcr-ssh-agent.service
/run/user/1000/gnupg/S.dirmngrdirmngr.socket  
dirmngr.service
/run/user/1000/gnupg/S.gpg-agent  gpg-agent.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.browser  gpg-agent-browser.socket
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.extragpg-agent-extra.socket  
gpg-agent.service
/run/user/1000/gnupg/S.gpg-agent.ssh  gpg-agent-ssh.socket
gpg-agent.service
/run/user/1000/keyring/controlgnome-keyring-daemon.socket 
gnome-keyring-daemon.service
/run/user/1000/pipewire-0 pipewire.socket 
pipewire.service
/run/user/1000/pk-debconf-socket  pk-debconf-helper.socket
pk-debconf-helper.service
/run/user/1000/pulse/native   pipewire-pulse.socket   
pipewire-pulse.service
/run/user/1000/snapd-session-agent.socket snapd.session-agent.socket  
snapd.session-agent.service

12 sockets listed.
Pass --all to see loaded but inactive sockets, too.

On the desktop gnome-keyring-daemon has not been running for several hours.

> Check owner of $SSH_AUTH_SOCK using ss or lsof. It may give some clue what
> is really happening in your case.

On both systems that environment variable is:

$ echo $SSH_AUTH_SOCK
/run/user/1000/keyring/ssh

> I suggest you to add "f" option to "ps" to see process tree. It may help to
> find details concerning starting of particular agent.

At this point I know the agent will be working normally when I first log
into gnome-shell.  This has been a reliable way to get it started. I
posted to the GNOME discourse about this and was advised to open
separate issues in the keyring Gitlab repository.  They are:

https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/135
"gnome-keyring-daemon shutting down on Debian 12 shortly after logging
into GNOME Shell "

https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/136
"gnome-keyring-daemon fails to restart properly on Debian 12 "

Last night I did some testing with gdb and put my results in issue #135.
In this case the daemon crashed when I logged out of another system,
well short of the hour it will run if left idle.

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Max Nikulin]

On 14/08/2023 07:30, Nate Bargmann wrote:

I have been using the GNOME keyring applet to manage the SSH public key
passwords I use as it prompts to save passwords and then lets me SSH to
other hosts without out a password prompt.


I do not know how it is arranged in Gnome, but I hope my observations 
still might be helpful.



systems on my LAN and was greeted with a password prompt for the
corresponding public key


To be precise, it is the passphrase do decrypt your *private* key. A 
public key may be known to anybody. Private key is a secret that allows 
to prove that you have it without disclosing of this private key. 
Encryption using a passphrase is a means to mitigate consequences if the 
private key is stolen.


An ssh agent opens a socket and exposes its location through an 
environment variable (perhaps using "systemctl set-environment", but I 
am not sure). Try


env | grep SSH

There are multiple implementations of SSH agents: openssh, gpg, 
keepassxc(?), perhaps gnome has more (seahorse? I am unsure concerning 
the role of secrets service). It may happen that in your case multiple 
instances are running:


/usr/lib/systemd/user/ssh-agent.service
/usr/lib/systemd/user/gpg-agent-ssh.socket
/etc/X11/Xsession.d/90x11-common_ssh-agent

GUI prompt may be just a proxy to an actual ssh agent. It just listens 
its socket and displaying a password prompt on demand and passing other 
messages literally.



Now, while typing this email all keyring PIDs have vanished!


It may be a way to minimize RAM usage. The agent may be a 
socket-activated process.


systemctl --user list-sockets

Check owner of $SSH_AUTH_SOCK using ss or lsof. It may give some clue 
what is really happening in your case.


I suggest you to add "f" option to "ps" to see process tree. It may help 
to find details concerning starting of particular agent.


   ps xwwf

P.S. At certain moment gnome designers decided that password prompt must 
be a modal dialog completely blocking interaction with any other 
applications (including 3rd party password manager). For me it was 
another reason to avoid gnome. I am aware that X11 protocol allows to 
sniff keyboard events and a measure against it is grabbing input. 
However I believe mouse still may be a way to call an external password 
manager. After all, there are may be an option to temporary suspend 
keyboard grabbing. I learned about multiple ways to start a ssh agent 
during initialization of user session when I was trying to figure out 
which way GUI prompt is implemented and if a more flexible dialog could 
be used instead.

Upgrade to Bookworm, now GNOME keyring dies--no access to stored SSH key passwords

[Nate Bargmann]

I now have two desktop systems running Bookworm with GNOME.  The laptop
was upgraded last month and I upgraded the desktop this afternoon.  I
have been using the GNOME keyring applet to manage the SSH public key
passwords I use as it prompts to save passwords and then lets me SSH to
other hosts without out a password prompt.

Some time after the upgrade I wanted to SSH into one of the other
systems on my LAN and was greeted with a password prompt for the
corresponding public key that had prior been managed by the keyring
applet.  I noted differences in the running processes between the laptop
where the keyring applet is still working and the desktop where it was
not.

On an off-chance I cold booted this system and found the keyring applet
was working as expected so I went on doing other things for a while.
Then I tried again and was prompted for the public key's password.
Uggh.

Right after rebooting the process list looked like this which mirrors
the laptop:

$ ps ax -u nate | grep "agent\|keyring"
   2037 ?SLsl   0:00 /usr/bin/gnome-keyring-daemon --foreground 
--components=pkcs11,secrets --control-directory=/run/user/1000/keyring
   2151 ?Ssl0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?Ss 0:00 ssh-agent -D -a /run/user/1000/openssh_agent
   3802 ?S  0:00 /usr/bin/ssh-agent -D -a 
/run/user/1000/keyring/.ssh
   3922 pts/0S+ 0:00 grep --color=auto agent\|keyring

When I began this mail things looked like this:

$ ps ax -u nate | grep "agent\|keyring"
   2151 ?Ssl0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?Ss 0:00 ssh-agent -D -a /run/user/1000/openssh_agent
  12324 ?Sl 0:00 /usr/bin/gnome-keyring-daemon --start --foreground 
--components=secrets
  12325 ?Ssl0:00 /usr/bin/gnome-keyring-daemon --foreground 
--components=pkcs11,secrets --control-directory=/run/user/1000/keyring
  19308 pts/0S+ 0:00 grep --color=auto agent\|keyring

It appears to me that gnome-keyring-daemon has been restarted for some reason.
As a result PIDs 2037 and 3802 are terminated and also
/run/user/1000/keyring/.ssh is no longer present along with the pkcs11 and ssh
files in the same directory.

I don't see anything out of the ordinary, in fact, these packages are
the same on the desktop and laptop systems:

debian-archive-keyring/stable,stable,now 2023.3 all [installed,automatic]
fasttrack-archive-keyring/stable,stable,now 2020.12.19 all [installed]
gnome-keyring-pkcs11/stable,now 42.1-1+b2 amd64 [installed,automatic]
gnome-keyring/stable,now 42.1-1+b2 amd64 [installed,automatic]
gpg-agent/stable,now 2.2.40-1.1 amd64 [installed,automatic]
libpam-gnome-keyring/stable,now 42.1-1+b2 amd64 [installed,automatic]
libpolkit-agent-1-0/stable,now 122-3 amd64 [installed,automatic]

Now, while typing this email all keyring PIDs have vanished!

$ ps ax -u nate | grep "agent\|keyring"
   2151 ?Ssl0:00 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
   2157 ?Ss 0:00 ssh-agent -D -a /run/user/1000/openssh_agent
  22418 pts/0S+ 0:00 grep --color=auto agent\|keyring

I am flummoxed.

TIA

- Nate

-- 
"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819



signature.asc
Description: PGP signature

Re: Passwords

[Jeffrey Walton]

On Tue, Jan 17, 2023 at 3:55 AM DdB
 wrote:
>
> Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> > вт, 17 янв. 2023 г. в 11:01, David :
> >> Looking on the internet it says the passwords are stored in /etc/passwd
> >> and /etc/shadow
> >
> >  In /etc/shadow only password's hashes, some data, one-way calculated
> > from password string.
> >
> >> The password string in /etc/shadow looks as if it's encoded, how can I
> >> read this string?
> >
> > You can't.
> Everyone (and their friend) seem to know, how to work around this, which
> apparently is common debian knowledge (which is nice).
>
> But somehow, i feel there could be more caring about avoiding to teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list? - I doubt it.

There's nothing extraordinary in the answers to recover a lost
password. Reiterating them here does not provide additional advantage
to an attacker.

If you don't have physical security on your machine, then you are
already pwn'd. You may not realize it yet, but it's already game over.

Jeff

Re: Passwords

[gene heskett]

On 1/17/23 01:01, David wrote:

Morning All,

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

David.

.
TBH, you can't, its a one way hash, add a "single" to the grub boot line 
which should give you a text shell, from which you can set a new root 
pw. Make it hard for the hackers, minimum 20 characters, every character 
you add, multiplies the effort they have to use to find it.


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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

Re: Passwords

[Joe]

On Tue, 17 Jan 2023 15:02:03 +0100
steve  wrote:

> Le 17-01-2023, à 08:07:02 -0500, Greg Wooledge a écrit :
> 
>
> >
> >If you went in via a Live CD, and mounted the Debian root partition,
> >the next step is to chroot into the Debian root partition.  Then you
> >can run "passwd root" in the chroot shell.  Then exit from the shell,
> >and unmount the Debian partition.  
> 
> chroot can be tricky for newcommers…
> 

No harder than the easy first bit of an installation (i.e. language,
keyboard etc.)

About two or three minutes gets you to the point where you can select a
root drive and chroot into it, all the mounting details handled for you.

-- 
Joe

Re: Passwords

[DdB]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

thx everyone for sharing your point of view(s).
I am enjoying that food-for-thought and reconsidering ...

Am 17.01.2023 um 15:05 schrieb to...@tuxteam.de:
>> chroot can be tricky for newcommers…
> That's why passwd is nice to us and has the -R option :)
Whoa! nice one, much easier, in fact.
Much appreciated hint. Thank you
DdB

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEumgd33HMGU/Wk4ZRe3aiXLdoWD0FAmPGu1wACgkQe3aiXLdo
WD1vkBAAifiu2NoiTxD0nWV+zrX0KW8bIcop3VTAyajepFHY8T9FPh78Ol5D7fp8
2WpJYtX5FTchQz/i/Qy5n+yc1gkHP4A0MVpz/3OYJ/dXJ29l6b7rSNY9KDkAa7gB
VkO1COHKe6Oo459IwmsBNhmT49ZzlYj91d0LU3nB71pWKOw/iYVbCjtTZqmpVaGd
amQXGYr/xolDkYrj5RkzE9ReN5q1f8hLGQ4kDSYQqLVKj8+9Qz353KoYcxI1TTFu
NQcybsLQ/KAEHYcEV9o0LxiuPXWPC+tczgXicO6TGcP2LNQ+tvS9fb8IrmD1T49w
zwOAZoePr/eqfXUkfA6yKycTB1OHO2dltQ5CDoVPusIm3MuwfNhSDTJtSzYGdcde
4suGr1r3axHM2dTr/ivXQrxDPvcYcRWWKjXPilxS4MPrLIsAP6BK5xOpFSll7Rka
BSgw67dGLbyGT+ugVjqLm2lzPrc72KWEaFKTm6LLgqfTPynAikiHb4XOY9T6K5iH
f0PznG6xdTn5QA+18dVXRoWr3lLiFroJWHplV6sb+uNlHDuoPazvHLyJZ9vAWiL8
xHaxuaPpgRXSDYjRt7i5EXJCurfAFzhTGSmpOGE/k9IXQ5qdMD9v5xAX6tP2CFEJ
vkrd5dvXkoCO+8dl2jL85WXffLlE44Qp7KM4k5Rx4xFFQpILWbI=
=eIKP
-END PGP SIGNATURE-

Re: Passwords

[tomas]

On Tue, Jan 17, 2023 at 03:30:32PM +0100, steve wrote:
> Le 17-01-2023, à 15:05:37 +0100, to...@tuxteam.de a écrit :
> 
> > > chroot can be tricky for newcommers…
> > 
> > That's why passwd is nice to us and has the -R option :)
> 
> Thanks Tomas, didn't know that option. Will go to bed a bit less stupid
> tonight :-)

Alas, as far as I'm concerned, I fear I'm leaking at least as much
wisdom as I try to fill from the top :-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Passwords

[steve]

Le 17-01-2023, à 15:05:37 +0100, to...@tuxteam.de a écrit :


chroot can be tricky for newcommers…


That's why passwd is nice to us and has the -R option :)


Thanks Tomas, didn't know that option. Will go to bed a bit less stupid
tonight :-)

Re: Passwords

[tomas]

On Tue, Jan 17, 2023 at 03:02:03PM +0100, steve wrote:
> Le 17-01-2023, à 08:07:02 -0500, Greg Wooledge a écrit :
> 
> > On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:
> > > Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :

> > If you went in via a Live CD, and mounted the Debian root partition,
> > the next step is to chroot into the Debian root partition [...]

> chroot can be tricky for newcommers…

That's why passwd is nice to us and has the -R option :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Passwords

[steve]

Le 17-01-2023, à 08:07:02 -0500, Greg Wooledge a écrit :


On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:

Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :

> On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:
> > Easier would be to delete the second field in /etc/shadow for root, so there
> > won't be anymore root password (it's empty). You can then create one with 
the
> > 'passwd' command.
>
> If you can edit the /etc/shadow file, you're already root, which means
> you can simply run "passwd root" to set a new password.  You will not
> be prompted for the old password, so there's no need to clear the old
> password hash preemptively.

You're right if you're editing the file in the OS, but not if you have
accessed data from a live-cd, which was what I was thinking. Sorry.


If you went in via a Live CD, and mounted the Debian root partition,
the next step is to chroot into the Debian root partition.  Then you
can run "passwd root" in the chroot shell.  Then exit from the shell,
and unmount the Debian partition.


chroot can be tricky for newcommers…


Of course, your way (which I'm assuming is "mount the Debian root
partition, edit the /debian/etc/shadow file to clear the hash, unmount
it, reboot into Debian, login as root with no password, and run "passwd")
also works, but it's a bit more effort.


Sure but it's pretty straightforward and simple to understand.

Anyway, thanks for the other options, always good to have a refresh :)

Re: Passwords

[Greg Wooledge]

On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:
> Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :
> 
> > On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:
> > > Easier would be to delete the second field in /etc/shadow for root, so 
> > > there
> > > won't be anymore root password (it's empty). You can then create one with 
> > > the
> > > 'passwd' command.
> > 
> > If you can edit the /etc/shadow file, you're already root, which means
> > you can simply run "passwd root" to set a new password.  You will not
> > be prompted for the old password, so there's no need to clear the old
> > password hash preemptively.
> 
> You're right if you're editing the file in the OS, but not if you have
> accessed data from a live-cd, which was what I was thinking. Sorry.

If you went in via a Live CD, and mounted the Debian root partition,
the next step is to chroot into the Debian root partition.  Then you
can run "passwd root" in the chroot shell.  Then exit from the shell,
and unmount the Debian partition.

Of course, your way (which I'm assuming is "mount the Debian root
partition, edit the /debian/etc/shadow file to clear the hash, unmount
it, reboot into Debian, login as root with no password, and run "passwd")
also works, but it's a bit more effort.

Re: Passwords

[tomas]

On Tue, Jan 17, 2023 at 01:53:33PM +0100, steve wrote:
> Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :
> 
> > On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:
> > > Easier would be to delete the second field in /etc/shadow for root, so 
> > > there
> > > won't be anymore root password (it's empty). You can then create one with 
> > > the
> > > 'passwd' command.
> > 
> > If you can edit the /etc/shadow file, you're already root, which means
> > you can simply run "passwd root" to set a new password.  You will not
> > be prompted for the old password, so there's no need to clear the old
> > password hash preemptively.
> 
> You're right if you're editing the file in the OS, but not if you have
> accessed data from a live-cd, which was what I was thinking. Sorry.

Or mounted the disk externally on another system.

Still there's the -R (chroot) option for passwd(1) as an alternative
for those cases. But editing is definitely a valid option (esp. if
you are dealing with an OS you suspect format compatibility problems
because of its age or some such).

There is more than... and so on :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Passwords

[steve]

Le 17-01-2023, à 07:19:04 -0500, Greg Wooledge a écrit :


On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:

Easier would be to delete the second field in /etc/shadow for root, so there
won't be anymore root password (it's empty). You can then create one with the
'passwd' command.


If you can edit the /etc/shadow file, you're already root, which means
you can simply run "passwd root" to set a new password.  You will not
be prompted for the old password, so there's no need to clear the old
password hash preemptively.


You're right if you're editing the file in the OS, but not if you have
accessed data from a live-cd, which was what I was thinking. Sorry.

Re: Passwords

[Greg Wooledge]

On Tue, Jan 17, 2023 at 09:36:03AM +0100, steve wrote:
> Easier would be to delete the second field in /etc/shadow for root, so there
> won't be anymore root password (it's empty). You can then create one with the
> 'passwd' command.

If you can edit the /etc/shadow file, you're already root, which means
you can simply run "passwd root" to set a new password.  You will not
be prompted for the old password, so there's no need to clear the old
password hash preemptively.

Re: Passwords

[Greg Wooledge]

On Tue, Jan 17, 2023 at 07:38:28AM +0100, Toni Mas Soler wrote:
> You don't need  a live-usb/cd.
> If your boot system is grub you only have to change command to exec=/bin/bash
> 
> Once you are in your system you can change root password and others.

For the record, the kernel parameter you wanted was "init=/bin/bash".

Re: Passwords

[Jude DaShiell]

pass phrase length and complexity.  At least 16 characters; Starts and
ends with a letter, has two symbols, two numbers two upper-case two
lower-case.  Nothing found in dictionaries in pass phrase no keyboard
walking, no recognizeable keyboard patterns may work for a few seconds.



Jude  "There are four boxes to be used in
defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Tue, 17 Jan 2023, daven...@tuxfamily.org wrote:

> Hello
>
> On 2023-01-17 09:51, DdB wrote:
> > Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> >> ??, 17 ???. 2023 ?. ? 11:01, David :
> >>> Looking on the internet it says the passwords are stored in /etc/passwd
> >>> and /etc/shadow
> >>
> >> In /etc/shadow only password's hashes, some data, one-way calculated
> >> from password string.
> >>
> >>> The password string in /etc/shadow looks as if it's encoded, how can I
> >>> read this string?
> >>
> >> You can't.
> > Everyone (and their friend) seem to know, how to work around this, which
> > apparently is common debian knowledge (which is nice).
> >
> > But somehow, i feel there could be more caring about avoiding to teach
> > future hackers by accident. Is this kind of lesson appropriate for a
> > users list? - I doubt it.
> >
> > just my 2 cents
> > DdB
>
>
> It's not hacking. It's typical administration system stuff. A required
> knowledge so you don't end up locked out of your own system in non-encypted
> installation. It requires physical access to the computer, so applicable from
> distance as you need to either
> - remove then mount the hard drive on another machine.
> - boot from a live USB.
> - boot into GRUB's rescue-shell.
>
> But if you're worried about physical access to your computer (as a laptop than
> can be easily stolen, or left in hotel room, or whatever), an account password
> isn't going to protect your data or from someone alter your password /install
> fishy stuff?
>
> In such case, you need to protect your system by encrypt it. And not just
> encrypt /home as the files you need to protect in order to protect the system
> from password tampering are NOT in /home. Debian installer has an option to
> encrypt the system quite easily, you just need time for the initial
> installation is it spends an good amount of writing random data (m?re or less
> acceptable duration depending on your disk speed and CPU performance). And
> re-ecrypt it when needed/when algorithmes get broken and new better ones
> become the new recommended standard/if your decryption passphrase is known by
> someone else/whatever.
>
> But it only makes sense of your decryption key has a long complex passphase.
> An easily brute-forceable or guessable password for disk encryption defeats
> the very own purpose of disk encryption. It basically means if you forget the
> passphrase, you're pretty much screwed until you either remembrer it, or
> reinstall and reconfigure everything. so you need to have backup [1] in secure
> place.
>
> ---
> 1. But again, backups are required anyway, encrypted installs or not. Storage
> support do fail and/or get stolen. Never trust a single storage device. Or a
> "cloud" backup bullshit. Cloud being nothing else than someone's else computer
> who can do whatever they want on it, kick users whenever they please or abuse
> personal data for profit if they want to (whether they do it in a "legal" or
> semi-legal way or not doesn't matter. As they have the technical means to do
> so and users have no means to check what's going on [2]. Including when data
> is "encrypted" IF encryption and decryption happens on their systems).
> 2. It's already hard enough to know what's going on on one's own computer, let
> alone distant systems managed by someone else?
>
>
>

Re: Passwords

[Timothy M Butterworth]

On Tue, Jan 17, 2023 at 1:01 AM David  wrote:

> Morning All,
>
> I have forgotten my password to a Debian PC using an SD stick as it's
> main drive.
>
> Looking on the internet it says the passwords are stored in /etc/passwd
> and /etc/shadow
>
> The password string in /etc/shadow looks as if it's encoded, how can I
> read this string?
>
> David.
>
>
Do you have a root account? If so then log in as root and run `passwd
 `

If you do not have root then you can login using single user mode and set a
root password.
https://devconnected.com/single-user-mode-secure-boot-on-ubuntu-debian/

Tim

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

Re: Passwords

[tomas]

On Tue, Jan 17, 2023 at 09:51:46AM +0100, DdB wrote:

[...]

> Everyone (and their friend) seem to know, how to work around this, which
> apparently is common debian knowledge (which is nice).
> 
> But somehow, i feel there could be more caring about avoiding to teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list? - I doubt it.

You don't improve security by keeping knowledge secret.

On the contraty, only knowing what's possible you can make your
system more secure.

Please, don't advocate for knowledge being reserved to a closed
cast of "priests". Arguably, we're here for making knowledge
available to all.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Passwords

[davenull]

Hello

On 2023-01-17 09:51, DdB wrote:

Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:

вт, 17 янв. 2023 г. в 11:01, David :
Looking on the internet it says the passwords are stored in 
/etc/passwd

and /etc/shadow


 In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can 
I

read this string?


You can't.
Everyone (and their friend) seem to know, how to work around this, 
which

apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

just my 2 cents
DdB



It's not hacking. It's typical administration system stuff. A required 
knowledge so you don't end up locked out of your own system in 
non-encypted installation. It requires physical access to the computer, 
so applicable from distance as you need to either

- remove then mount the hard drive on another machine.
- boot from a live USB.
- boot into GRUB's rescue-shell.

But if you're worried about physical access to your computer (as a 
laptop than can be easily stolen, or left in hotel room, or whatever), 
an account password isn't going to protect your data or from someone 
alter your password /install fishy stuff…


In such case, you need to protect your system by encrypt it. And not 
just encrypt /home as the files you need to protect in order to protect 
the system from password tampering are NOT in /home. Debian installer 
has an option to encrypt the system quite easily, you just need time for 
the initial installation is it spends an good amount of writing random 
data (mère or less acceptable duration depending on your disk speed and 
CPU performance). And re-ecrypt it when needed/when algorithmes get 
broken and new better ones become the new recommended standard/if your 
decryption passphrase is known by someone else/whatever.


But it only makes sense of your decryption key has a long complex 
passphase. An easily brute-forceable or guessable password for disk 
encryption defeats the very own purpose of disk encryption. It basically 
means if you forget the passphrase, you're pretty much screwed until you 
either remembrer it, or reinstall and reconfigure everything. so you 
need to have backup [1] in secure place.


---
1. But again, backups are required anyway, encrypted installs or not. 
Storage support do fail and/or get stolen. Never trust a single storage 
device. Or a "cloud" backup bullshit. Cloud being nothing else than 
someone's else computer who can do whatever they want on it, kick users 
whenever they please or abuse personal data for profit if they want to 
(whether they do it in a "legal" or semi-legal way or not doesn't 
matter. As they have the technical means to do so and users have no 
means to check what's going on [2]. Including when data is "encrypted" 
IF encryption and decryption happens on their systems).
2. It's already hard enough to know what's going on on one's own 
computer, let alone distant systems managed by someone else…

Re: Passwords

[Bastien Durel]

Le mardi 17 janvier 2023 à 09:51 +0100, DdB a écrit :
> Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> Everyone (and their friend) seem to know, how to work around this,
> which
> apparently is common debian knowledge (which is nice).
> 
> But somehow, i feel there could be more caring about avoiding to
> teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list? - I doubt it.

Local user is king. They can change boot-loader, extract disks to put
them in another computer ... Not only Debian-related, much computer-
related ^^

To prevent that, you should encrypt your disks, so no-one can mount
them and change your passwords/read your data. (But you won't recover
for lostt passphrase, then ;))

Regards,

-- 
Bastien

Re: Passwords

[Joe]

On Tue, 17 Jan 2023 09:51:46 +0100
DdB  wrote:

> Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> > вт, 17 янв. 2023 г. в 11:01, David :  
> >> Looking on the internet it says the passwords are stored in
> >> /etc/passwd and /etc/shadow  
> > 
> >  In /etc/shadow only password's hashes, some data, one-way
> > calculated from password string.
> >   
> >> The password string in /etc/shadow looks as if it's encoded, how
> >> can I read this string?  
> > 
> > You can't.  
> Everyone (and their friend) seem to know, how to work around this,
> which apparently is common debian knowledge (which is nice).

It's common Internet knowledge generally. Google will find you a
method, and will also find you a utility to fix a lost password in
Windows, if you can trust it.
> 
> But somehow, i feel there could be more caring about avoiding to teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list? - I doubt it.
>

First rule of security: keep your computer physically secure. If it's
portable, encrypt it, if it isn't, generally don't, because encryption
really is impossible to recover if the key is lost. My laptop isn't
encrypted, but all significant data is stored in a VeraCrypt volume. I
don't care if the machine is booted by a thief, because I'll never see
it again, and I have backup copies of the data.

-- 
Joe

Re: Passwords

[David]

On Tue, 2023-01-17 at 09:51 +0100, DdB wrote:
> Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> > вт, 17 янв. 2023 г. в 11:01, David :
> > > Looking on the internet it says the passwords are stored in
> > > /etc/passwd
> > > and /etc/shadow
> > 
> >  In /etc/shadow only password's hashes, some data, one-way
> > calculated
> > from password string.
> > 
> > > The password string in /etc/shadow looks as if it's encoded, how
> > > can I
> > > read this string?
> > 
> > You can't.
> Everyone (and their friend) seem to know, how to work around this,
> which
> apparently is common debian knowledge (which is nice).
> 
> But somehow, i feel there could be more caring about avoiding to
> teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list? - I doubt it.

For this sort of `cracking', there would need to be direct access to
the machine. It would involve house breaking after having discerned the
address in the other country the target resided in, and travelling
there.
Cheers!

Re: Passwords

[davenull]

Hello

On 2023-01-17 08:58, Tim Woodall wrote:

On Tue, 17 Jan 2023, Stanislav Vlasov wrote:


??, 17 ???. 2023 ?. ? 11:01, David :


I have forgotten my password to a Debian PC using an SD stick as it's
main drive.


Looking on the internet it says the passwords are stored in 
/etc/passwd

and /etc/shadow


In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

The password string in /etc/shadow looks as if it's encoded, how can 
I

read this string?


You can't.
But you can set new password, if you boot from live-usb/live-cd, mount
your system to dir and run `chroot dir && passwd $user`



One other thing you can do if you don't have a quick and easy way to
boot is to manually replace the hash in /etc/shadow with one that you 
do

know the password for. (This might be the case, for example, where the
USB stick is for booting ARM but all your other machines are x86, 
mount,

change password, umount is much quicker than trying to work out how to
live boot a headless arm system...)


No, don't do that. It's requires to do more steps manually and might 
lead to less security. And you need to make sure to use you use 
cryptographic salt. crypt, the utility used to set passwords stored in 
/etc/shadow, use salts. There is just to many things you could do wrong, 
especially if you use a different tool to henerate the password and 
trust it default settings.


For instance, you might choose (or use by default) the "wrong" 
encryption when you generate the password, which might by less secure 
than the default one. For instance, I just realised after readding this 
thread and checking, Debian 11 now uses yescrypt ($y$ prefix, see 
crypt(5) man entry: `man 5 crypt`). If I replaced the hash manually, I 
would probably used an older encryption algo without realizing it…


You're better off editing /etc/shadow and remove instead of replacing 
the second field, which is the hash with it's encryption identifier 
prefix ($*$) of the salted password. Then boot and log into your 
now-passwordless user account, then set a password again, as you would 
normally normally, using `passwd` command.


IMPORTANT NOTE: Not sure if you need to edit /etc/passwd to remove the 
second field as well, the "x" that indicated a hidden/hashed password is 
used/expected, before rebooting to re-set your password. Last time I did 
that, multiples "debian-stable-versions ago", I remove it "just in case" 
as it doesn't cost anything whether it's necessary or not.




This is something I did in ancient times when most systems still used
crypt and the system I was having problems with was the only one (so
far) that had been converted to use SHA? hashes. I replaced root's 
hash,

which I'd forgotten with that of my user account, which I did know.

And if you don't have any hashes that you know the password for then 
ask

here, someone can generate one for you - or see this thread:

https://unix.stackexchange.com/questions/81240/manually-generate-password-for-etc-shadow

Obviously manually editing these files isn't something to be done
without care. I always have backups so worst case is "restore from
backup" and not "I've lost everything"

Re: Passwords

[Alexander V. Makartsev]

On 17.01.2023 13:51, DdB wrote:

Everyone (and their friend) seem to know, how to work around this, which
apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.
This is not hacking. How to reset password on your computer is the is 
most basic system administration knowledge everyone should know.
This information is described in system administration manual and mostly 
applies for any Linux-based system.


Since it is so easy to reset user password on a computer you have 
physical access to, and it doesn't matter if OS is Windows or Linux-based,
so making your user password so long and complex, to the point it could 
be forgotten, is so not necessary.
Even 4-6 digit password is enough to secure access to local user account 
and impossible to forget.


Long and complex passwords are only necessary for non-local user 
accounts, e.g. Web-sites, e-Mail accounts, or any accounts exposed to 
the Internet.


--
With kindest regards, Alexander.

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

Re: Passwords

[Tixy]

On Tue, 2023-01-17 at 09:51 +0100, DdB wrote:
> 
> But somehow, i feel there could be more caring about avoiding to teach
> future hackers by accident. Is this kind of lesson appropriate for a
> users list?

Yes. It's a common occurrence, and trivial to deal with - if you have
physical access to the computer or disk. And if you have such access 
then that password isn't actually protecting anything you couldn't do
without the password.

If you google "linux forgotten root password" then you will find these
techniques are explained all over the web, e.g. Redhat's site, Arch
wiki etc.

-- 
Tixy

 

Re: Passwords

[DdB]

Am 17.01.2023 um 07:14 schrieb Stanislav Vlasov:
> вт, 17 янв. 2023 г. в 11:01, David :
>> Looking on the internet it says the passwords are stored in /etc/passwd
>> and /etc/shadow
> 
>  In /etc/shadow only password's hashes, some data, one-way calculated
> from password string.
> 
>> The password string in /etc/shadow looks as if it's encoded, how can I
>> read this string?
> 
> You can't.
Everyone (and their friend) seem to know, how to work around this, which
apparently is common debian knowledge (which is nice).

But somehow, i feel there could be more caring about avoiding to teach
future hackers by accident. Is this kind of lesson appropriate for a
users list? - I doubt it.

just my 2 cents
DdB

Re: Passwords

[steve]

Le 17-01-2023, à 07:58:40 +, Tim Woodall a écrit :



One other thing you can do if you don't have a quick and easy way to
boot is to manually replace the hash in /etc/shadow with one that you do
know the password for. (This might be the case, for example, where the
USB stick is for booting ARM but all your other machines are x86, mount,
change password, umount is much quicker than trying to work out how to
live boot a headless arm system...)


Easier would be to delete the second field in /etc/shadow for root, so there
won't be anymore root password (it's empty). You can then create one with the
'passwd' command.

Re: Passwords

[Tim Woodall]

On Tue, 17 Jan 2023, Stanislav Vlasov wrote:


??, 17 ???. 2023 ?. ? 11:01, David :


I have forgotten my password to a Debian PC using an SD stick as it's
main drive.



Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow


In /etc/shadow only password's hashes, some data, one-way calculated
from password string.


The password string in /etc/shadow looks as if it's encoded, how can I
read this string?


You can't.
But you can set new password, if you boot from live-usb/live-cd, mount
your system to dir and run `chroot dir && passwd $user`



One other thing you can do if you don't have a quick and easy way to
boot is to manually replace the hash in /etc/shadow with one that you do
know the password for. (This might be the case, for example, where the
USB stick is for booting ARM but all your other machines are x86, mount,
change password, umount is much quicker than trying to work out how to
live boot a headless arm system...)

This is something I did in ancient times when most systems still used
crypt and the system I was having problems with was the only one (so
far) that had been converted to use SHA? hashes. I replaced root's hash,
which I'd forgotten with that of my user account, which I did know.

And if you don't have any hashes that you know the password for then ask
here, someone can generate one for you - or see this thread:

https://unix.stackexchange.com/questions/81240/manually-generate-password-for-etc-shadow

Obviously manually editing these files isn't something to be done
without care. I always have backups so worst case is "restore from
backup" and not "I've lost everything"

Re: Passwords

[Jude DaShiell]

futureproofing could include encrypting passwords then logging those on
paper in encrypted form.  Just remember where you keep that log and
remember your encryption for recovery if you forget your password again.
Us totally blind people not only have braille as an encryption technique
but other forms of writing we can use in braille for additional
encryption.



Jude  "There are four boxes to be used in
defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)

.

On Tue, 17 Jan 2023, Stanislav Vlasov wrote:

> ??, 17 ???. 2023 ?. ? 11:01, David :
>
> > I have forgotten my password to a Debian PC using an SD stick as it's
> > main drive.
>
> > Looking on the internet it says the passwords are stored in /etc/passwd
> > and /etc/shadow
>
>  In /etc/shadow only password's hashes, some data, one-way calculated
> from password string.
>
> > The password string in /etc/shadow looks as if it's encoded, how can I
> > read this string?
>
> You can't.
> But you can set new password, if you boot from live-usb/live-cd, mount
> your system to dir and run `chroot dir && passwd $user`
>
>

Re: Passwords

[Toni Mas Soler]

You don't need  a live-usb/cd.
If your boot system is grub you only have to change command to exec=/bin/bash

Once you are in your system you can change root password and others.


Toni Mas

Missatge de Stanislav Vlasov  del dia dt., 17
de gen. 2023 a les 7:15:
>
> вт, 17 янв. 2023 г. в 11:01, David :
>
> > I have forgotten my password to a Debian PC using an SD stick as it's
> > main drive.
>
> > Looking on the internet it says the passwords are stored in /etc/passwd
> > and /etc/shadow
>
>  In /etc/shadow only password's hashes, some data, one-way calculated
> from password string.
>
> > The password string in /etc/shadow looks as if it's encoded, how can I
> > read this string?
>
> You can't.
> But you can set new password, if you boot from live-usb/live-cd, mount
> your system to dir and run `chroot dir && passwd $user`
>
> --
> Stanislav
>

Re: Passwords

[Stanislav Vlasov]

вт, 17 янв. 2023 г. в 11:01, David :

> I have forgotten my password to a Debian PC using an SD stick as it's
> main drive.

> Looking on the internet it says the passwords are stored in /etc/passwd
> and /etc/shadow

 In /etc/shadow only password's hashes, some data, one-way calculated
from password string.

> The password string in /etc/shadow looks as if it's encoded, how can I
> read this string?

You can't.
But you can set new password, if you boot from live-usb/live-cd, mount
your system to dir and run `chroot dir && passwd $user`

-- 
Stanislav

Passwords

[David]

Morning All,

I have forgotten my password to a Debian PC using an SD stick as it's
main drive.

Looking on the internet it says the passwords are stored in /etc/passwd
and /etc/shadow

The password string in /etc/shadow looks as if it's encoded, how can I
read this string?

David.

Re: Help! Thunderbird lost my passwords

[Alexander V. Makartsev]

On 04.08.2021 05:03, Douglas McGarrett wrote:



On 7/19/21 1:15 AM, Alexander V. Makartsev wrote:

On 19.07.2021 05:13, w...@mgssub.com wrote:

I installed tbird 78.12.0 (64-bit)
 and it can't find my email passwords. I have browsed signons.sqlite
 and the passwords seem to be there in the middle of the db. I have 
tried to install a prior version of tbird but dpkg has thwarted 
those efforts so far! Any other ideas suggestions would be appreciated!


Many TIA!
Dennis
If you didn't setup "Master Password" in ThunderBird, you can try 
"Mail PassView" utility from NirSoft. [1]

It works with WINE.
If password database files were not corrupted somehow, it will show 
stored accounts and passwords from TB profile.



[1] https://www.nirsoft.net/utils/mailpv.html
I recently downloaded and installed T/B after having lost the use of 
it a couple of months ago when it refused
to recognize my password or any new one. Now it is working, and I hope 
it continues. At any rate, I did not see
anything about a Master Password. What is it, and where is it, and 
should I need it?

--doug
I've never had any issues with T/B, but I've seen complains from other 
people multiple times about password-related problems.
Which could be explained by not so smooth automatic migration from old 
password storage database format to a new one.
I usually delay updates installation for T/B and other business-critical 
software by a few weeks or so, and that could be the reason I've avoided 
said issues so far.


Passwords and account information in T/B (and other Mozilla software?) 
are stored in an reversible-encrypted state by default.
So, for an example, if T/B profile and password DB files were stolen by 
malware they could be decrypted effortlessly using forensic utilities, 
like "Mail PassView".
A "Master password" feature protects password DB files by adding 
additional layer of encryption, which could be decrypted only if you use 
a master password.
So, in the same scenario I've described above, even if badguys will 
steal a profile files with password DB files, they won't be able to 
decrypt them easily without master password and will have to use 
time-consuming "bruteforce" techniques to get it.


The only inconvenience of master password feature, once you enable it, 
you will have to enter it each time you launch a T/B session and every 
time you will want to see saved passwords in plain text.
The ordinary EMail functions, like sending and receiving, won't be 
affected by it.


--
With kindest regards, Alexander.

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

Re: Help! Thunderbird lost my passwords

[Jude DaShiell]

All passwords need to be written and secured.  First by being part of a
book or being in a specific place in a hard copy file.  Second, encrypted
before written down.  For anyone to be able to use any of those passwords
even if found they'd have to know the encryption system you used.

Re: Help! Thunderbird lost my passwords

[Keith Bainbridge]

On 4/8/21 10:03, Douglas McGarrett wrote:

a Master Password. What is it, and where is it, and should I need it?



go: edit|preferences|privacy& Security

and on my screen 'Passwords' is close to the bottom before you start
scrolling

--
All the best

Keith Bainbridge

keith.bainbridge.3...@gmail.com
0447 667 468

Re: Help! Thunderbird lost my passwords

[Douglas McGarrett]

On 7/19/21 1:15 AM, Alexander V. Makartsev wrote:

On 19.07.2021 05:13, w...@mgssub.com wrote:

I installed tbird 78.12.0 (64-bit)
 and it can't find my email passwords. I have browsed signons.sqlite
 and the passwords seem to be there in the middle of the db. I have 
tried to install a prior version of tbird but dpkg has thwarted those 
efforts so far! Any other ideas suggestions would be appreciated!


Many TIA!
Dennis
If you didn't setup "Master Password" in ThunderBird, you can try 
"Mail PassView" utility from NirSoft. [1]

It works with WINE.
If password database files were not corrupted somehow, it will show 
stored accounts and passwords from TB profile.



[1] https://www.nirsoft.net/utils/mailpv.html
I recently downloaded and installed T/B after having lost the use of it 
a couple of months ago when it refused
to recognize my password or any new one. Now it is working, and I hope 
it continues. At any rate, I did not see
anything about a Master Password. What is it, and where is it, and 
should I need it?

--doug

Re: Help! Thunderbird lost my passwords

[Alexander V. Makartsev]

On 19.07.2021 05:13, w...@mgssub.com wrote:

I installed tbird 78.12.0 (64-bit)
 and it can't find my email passwords. I have browsed signons.sqlite
 and the passwords seem to be there in the middle of the db. I have 
tried to install a prior version of tbird but dpkg has thwarted those 
efforts so far! Any other ideas suggestions would be appreciated!


Many TIA!
Dennis
If you didn't setup "Master Password" in ThunderBird, you can try "Mail 
PassView" utility from NirSoft. [1]

It works with WINE.
If password database files were not corrupted somehow, it will show 
stored accounts and passwords from TB profile.



[1] https://www.nirsoft.net/utils/mailpv.html

--
With kindest regards, Alexander.

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

Help! Thunderbird lost my passwords

[wix]

I installed tbird 78.12.0 (64-bit) and it can't find my email passwords. I have browsed signons.sqlite and the passwords seem to be there in the middle of the db. I have tried to install a prior version of tbird but dpkg has thwarted those efforts so far! Any other ideas suggestions would be appreciated!Many TIA!Dennis

chromium browser lost stored passwords after upgrade from Stretch to Buster

[Tapio Lehtonen]

I upgraded on 25th May office computer Debian Stretch to Buster. Home
directory comes from NFS server. Chromium browser now longer has the stored
passwords available.

Other browsers, Firefox and Google Chrome, do have the passwords still.

Where did chromium browser on Stretch store the passwords? It is
not ~/.config/chromium/Default/Login Data, I restored from old backups but
on none of the backed up files does the logins -table contain any entries.

Does it matter if chromium is started with parameters %U -incognito

Re: Discussion about backup passwords for LUKS encrypted filesystems before revising wiki

[David Christensen]

On 2020-12-24 10:06, rhkra...@gmail.com wrote:


On Tuesday, December 22, 2020 07:20:39 PM David Christensen wrote:

Thank you for offering to improve Debian documentation.  :-)


You're welcome, but I wasn't making a general offer to improve documentation,
just to fix something that I thought was misleading.


One fix is still an improvement.  :-)



... I
need to setup a few encrypted partitions for backup of some encrypted data
(currently backed up in only one place, on the same computer).  So I have an
interest in (better) learning how to set up LUKS partitions (without regard to
LVM).  


I have several such "encrypted backup media" drives.  The following are 
from my notes when I prepared one:


1.  Wipe drive:

# dd if=/dev/zero of=/dev/disk/by-id/ata-ST3000DM001-***redacted*** bs=4M

2.  Create GPT partition scheme:

# parted /dev/disk/by-id/ata-ST3000DM001-***redacted*** mklabel gpt

3.  Create one partition using almost all of the available space:

# parted /dev/disk/by-id/ata-ST3000DM001-***redacted*** mkpart primary 
0% 100%


4.  Create a LUKS container:

# cryptsetup luksFormat 
/dev/disk/by-id/ata-ST3000DM001-***redacted***-part1


WARNING!

This will overwrite data on 
/dev/disk/by-id/ata-ST3000DM001-***redacted***-part1 irrevocably.


Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:

5.  Open the LUKS container:

# cryptsetup luksOpen 
/dev/disk/by-id/ata-ST3000DM001-***redacted***-part1 i3000a_crypt

Enter passphrase for /dev/disk/by-id/ata-ST3000DM001-***redacted***-part1:

6.  Create an ext4 filesystem:

# mkfs.ext4 /dev/mapper/i3000a_crypt
mke2fs 1.42.5 (29-Jul-2012)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
183148544 inodes, 732565760 blocks
36628288 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
22357 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968,
10240, 214990848, 51200, 550731776, 644972544

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

7.  Create a mount point:

# mkdir /mnt/i3000a

8.  Mount the filesystem:

# mount /dev/mapper/i3000a_crypt /mnt/i3000a



But, I've also been curious about LVM (without much intention of using
it) -- when I started skimming the LVM wiki page and found the stuff on LUKS I
decided that would be worth reading in view of my first interest (LUKS).



Further / farther aside: The secondary interest in LVM was sparked by some
clues in the ongoing thread(s) on debian-user that pointed to (or lead me to)
some gotchas that, if I were to start using LVM I'd want to be very aware of
(for instance, that adding a partition to an LVM wipes out any data on that
partition.


I have used MD and LUKS on Linux in the past.  Now I prefer OpenZFS (on 
FreeBSD).  But, that is a long story.  Learn LUKS and backups on Linux 
first.




As I was reading parts of that wiki page again (again in the LUKS section) I
started to realize that (to me) the more important thing (rather than creating
backup passwords) is creating a backup of the LUKS header.  I guess that is
what you are suggesting.  


Yes.



So, while "Backup passwords" -> "Step" ->
2.1 and "Restore password" -> 1.1 may describe useful system
administration procedures, these subsections have conceptual and
technical issues.


... I don't know
what they are -- I might be interested in learning what they are, but not sure
I'm interested in rewriting the document to reflect them more correctly.



Yeah, I guess I can see that perhaps some of the discussion of LUKS on this
page could / should be moved to a page specifically on LUKS, or as you mention
below, to a wiki page on BackupAndRecovery.  Again, I'm probably not ready to
do that (although to a certain extent I do enjoy writing and spend too much
time doing (or trying) to do it.


Do your homework, ask good questions, read the answers, and implement 
solutions that work for you.  Accept that you will make mistakes, so be 
prepared with good backups.  Eventually, you'll learn what you need to know.



If and when you feel comfortable contributing to the Debian Wiki, etc., 
then please do so.



David

Re: Discussion about backup passwords for LUKS encrypted filesystems before revising wiki

[rhkramer]

Note: Initially sent to David off list, he asked me to reply to the list.

David,

Thanks for your response!

I'm replying privately intentionally for various reasons -- I may summarize 
some of this on list at some point.

On Tuesday, December 22, 2020 07:20:39 PM David Christensen wrote:
> Thank you for offering to improve Debian documentation.  :-)

You're welcome, but I wasn't making a general offer to improve documentation, 
just to fix something that I thought was misleading.

And, I have a little trouble understanding what you are suggesting.  Keep 
reading.

Aside: Maybe I should explain why I was reading (some of) that wiki page: I 
need to setup a few encrypted partitions for backup of some encrypted data 
(currently backed up in only one place, on the same computer).  So I have an 
interest in (better) learning how to set up LUKS partitions (without regard to 
LVM).  But, I've also been curious about LVM (without much intention of using 
it) -- when I started skimming the LVM wiki page and found the stuff on LUKS I 
decided that would be worth reading in view of my first interest (LUKS).

Further / farther aside: The secondary interest in LVM was sparked by some 
clues in the ongoing thread(s) on debian-user that pointed to (or lead me to) 
some gotchas that, if I were to start using LVM I'd want to be very aware of 
(for instance, that adding a partition to an LVM wipes out any data on that 
partition.

> I agree that the content of "LVM" Debian Wiki page "Encrypted LVM"
> section could use some improvement.
> 
> 
> AIUI backing up aLinux Unified Key Setup (LUKS) header will save a copy
> of the metadata for a LUKS volume, which includes secure hashes of the
> passphrases (and/or keys) used to access the contents (such as a Linux
> Volume Manager (LVM) volume).  

As I was reading parts of that wiki page again (again in the LUKS section) I 
started to realize that (to me) the more important thing (rather than creating 
backup passwords) is creating a backup of the LUKS header.  I guess that is 
what you are suggesting.  (Again, I might, or might not revise the wiki to say 
that, if that is your point.  If that is not your point, I need some 
amplification.)

> So, while "Backup passwords" -> "Step" ->
> 2.1 and "Restore password" -> 1.1 may describe useful system
> administration procedures, these subsections have conceptual and
> technical issues.

Well, except for the one discussed previous to this sentence, I don't know 
what they are -- I might be interested in learning what they are, but not sure 
I'm interested in rewriting the document to reflect them more correctly.

 > The subjects of multiple passphrases and/or keys for encrypted items
> (volumes, filesystems, directories, files, etc.) and disaster
> preparedness/ recovery of encrypted volumes and/or containers are
> related, but different.  Regarding the first subject and LUKS, I would
> expect the first to appear on a wiki page for "LUKS" (which does not
> appear to exist).  

Yeah, I guess I can see that perhaps some of the discussion of LUKS on this 
page could / should be moved to a page specifically on LUKS, or as you mention 
below, to a wiki page on BackupAndRecovery.  Again, I'm probably not ready to 
do that (although to a certain extent I do enjoy writing and spend too much 
time doing (or trying) to do it.

> The latter subject for LUKS could be a useful
> addition to the "BackupAndRecovery" wiki page:
> 
>  https://wiki.debian.org/BackupAndRecovery
> 
> 
> David

Re: Discussion about backup passwords for LUKS encrypted filesystems before revising wiki

[Andrei POPESCU]

On Ma, 22 dec 20, 12:11:19, rhkra...@gmail.com wrote:
> 
>* or if: "you simply forget your password" -- it seems unlikely that 
> you'll 
> forget the "normal" password (the one you most often use) but remember a 
> backup password (although maybe you'd use something really easy to remember 
> (for you), and hope that because you don't normally use it, it is less 
> exposed 
> and less likely to be captured somehow)

Or you create a very secure backup password and keep it in a safe 
(place), possibly even remote. 

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Discussion about backup passwords for LUKS encrypted filesystems before revising wiki

[David Christensen]

On 2020-12-22 09:11, rhkra...@gmail.com wrote:

See the quoted paragraph, below, quoted from the
[[https://wiki.debian.org/LVM#Encrypted_LVM][LVM#Encrypted_LVM]] wiki.

It seems to me that the idea of creating and saving backup passwords is
something of a red herring (to borrow a "Briticism").

The way I see it:

* if, in the future: "somehow you first password is no longer working"
-- I'm guessing that whatever that "somehow" is, it is likely to affect all the
passwords (all of which are stored in the LUKS header)

* or if: "you simply forget your password" -- it seems unlikely that you'll
forget the "normal" password (the one you most often use) but remember a
backup password (although maybe you'd use something really easy to remember
(for you), and hope that because you don't normally use it, it is less exposed
and less likely to be captured somehow)

* or if: "something unexpected happens such as a bug after a kernel update
and somehow the password is no longer working" -- it seems likely to me that
if a kernel bug makes one password no longer work, it would be likely that
none of the passwords not to work (although I think I can think of exceptions,
e.g., your password contains a special symbol, but a kernel bug (or bug
somewhere) prevents entry of that special symbol

My point is this: I think creating and saving backup passwords is of minimal
value.  Far more important (but not mentioned) is making and keeping backup
copies of your encrypted data (possibly not encrypted but stored in a bank
vault ;-), yet that is not mentioned.

I am capable (or think I'm capable ;-) of revising the wiki to add a statement
to the effect that, more important than storing backup passwords is storing
backups of the actual data.  I just wanted to provoke some discussion before
making such a revision.  (I might even downplay the emphasis on creating and
storing backup passwords.)


Note: The password(s) of a encrypted LVM volume are stored inside its Linux
Unified Key Setup (LUKS) header(s). Creating backup passwords is important
because if in the future somehow you first password is no longer working, or
you simply forget your password, or you do remember your password but
something unexpected happens such as a bug after a kernel update and somehow
the password is no longer working, then without backup password(s) you risk to
permanently lose all your valuable data stored into that encrypted LVM
storage.



Thank you for offering to improve Debian documentation.  :-)


I agree that the content of "LVM" Debian Wiki page "Encrypted LVM" 
section could use some improvement.



AIUI backing up aLinux Unified Key Setup (LUKS) header will save a copy 
of the metadata for a LUKS volume, which includes secure hashes of the 
passphrases (and/or keys) used to access the contents (such as a Linux 
Volume Manager (LVM) volume).  So, while "Backup passwords" -> "Step" -> 
2.1 and "Restore password" -> 1.1 may describe useful system 
administration procedures, these subsections have conceptual and 
technical issues.



The subjects of multiple passphrases and/or keys for encrypted items 
(volumes, filesystems, directories, files, etc.) and disaster 
preparedness/ recovery of encrypted volumes and/or containers are 
related, but different.  Regarding the first subject and LUKS, I would 
expect the first to appear on a wiki page for "LUKS" (which does not 
appear to exist).  The latter subject for LUKS could be a useful 
addition to the "BackupAndRecovery" wiki page:


https://wiki.debian.org/BackupAndRecovery


David

Re: Discussion about backup passwords for LUKS encrypted filesystems before revising wiki

[rhkramer]

Roberto,

Thanks for the reply!

Good points, both of them.  I might (or might not) add your use case (the 
multiple user case) to the wiki as it sounds like a more plausible need.

On Tuesday, December 22, 2020 12:34:12 PM Roberto C. Sánchez wrote:
> On Tue, Dec 22, 2020 at 12:11:19PM -0500, rhkra...@gmail.com wrote:
> > My point is this: I think creating and saving backup passwords is of
> > minimal value.
> 
> Maybe to you as a single user.  However, I have worked in places where
> resources are protected by multiple passwords.  For instance there was a
> "normal" password given to the admins (or users, as the case may be) and
> a backup password was kept locked in a safe.  The backup password could
> be used if there was some sort of emergency where for some reason those
> who would normally have the password were not available.  (Think
> disaster recovery.)
> 
> Based on the content in the wiki it seems appropriate to inform the
> reader of the presence of the ability to store multiple passwords which
> can unlock an encrypted device.
> 
> > Far more important (but not mentioned) is making and keeping backup
> > copies of your encrypted data (possibly not encrypted but stored in a
> > bank vault ;-), yet that is not mentioned.
> 
> It probably is not mentioned since backups are not something which are
> unique to encrypted devices.  A general reminder would not be wrong or
> bad, but it would seem out of place to me.  I mean, we could also add
> reminders to make sure the firewall is up to date, secured, and enabled
> or to have SMART enabled and configured to send alerts if a HDD begins
> to exhibit symptoms of a potential failure.
> 
> Regards,
> 
> -Roberto

Re: Discussion about backup passwords for LUKS encrypted filesystems before revising wiki

[Roberto C . Sánchez]

On Tue, Dec 22, 2020 at 12:11:19PM -0500, rhkra...@gmail.com wrote:
> 
> My point is this: I think creating and saving backup passwords is of minimal 
> value.  

Maybe to you as a single user.  However, I have worked in places where
resources are protected by multiple passwords.  For instance there was a
"normal" password given to the admins (or users, as the case may be) and
a backup password was kept locked in a safe.  The backup password could
be used if there was some sort of emergency where for some reason those
who would normally have the password were not available.  (Think
disaster recovery.)

Based on the content in the wiki it seems appropriate to inform the
reader of the presence of the ability to store multiple passwords which
can unlock an encrypted device.

> Far more important (but not mentioned) is making and keeping backup 
> copies of your encrypted data (possibly not encrypted but stored in a bank 
> vault ;-), yet that is not mentioned.
> 

It probably is not mentioned since backups are not something which are
unique to encrypted devices.  A general reminder would not be wrong or
bad, but it would seem out of place to me.  I mean, we could also add
reminders to make sure the firewall is up to date, secured, and enabled
or to have SMART enabled and configured to send alerts if a HDD begins
to exhibit symptoms of a potential failure.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Discussion about backup passwords for LUKS encrypted filesystems before revising wiki

[rhkramer]

See the quoted paragraph, below, quoted from the 
[[https://wiki.debian.org/LVM#Encrypted_LVM][LVM#Encrypted_LVM]] wiki.  

It seems to me that the idea of creating and saving backup passwords is 
something of a red herring (to borrow a "Briticism").

The way I see it:

   * if, in the future: "somehow you first password is no longer working" 
-- I'm guessing that whatever that "somehow" is, it is likely to affect all the 
passwords (all of which are stored in the LUKS header)

   * or if: "you simply forget your password" -- it seems unlikely that you'll 
forget the "normal" password (the one you most often use) but remember a 
backup password (although maybe you'd use something really easy to remember 
(for you), and hope that because you don't normally use it, it is less exposed 
and less likely to be captured somehow)

   * or if: "something unexpected happens such as a bug after a kernel update 
and somehow the password is no longer working" -- it seems likely to me that 
if a kernel bug makes one password no longer work, it would be likely that 
none of the passwords not to work (although I think I can think of exceptions, 
e.g., your password contains a special symbol, but a kernel bug (or bug 
somewhere) prevents entry of that special symbol

My point is this: I think creating and saving backup passwords is of minimal 
value.  Far more important (but not mentioned) is making and keeping backup 
copies of your encrypted data (possibly not encrypted but stored in a bank 
vault ;-), yet that is not mentioned.

I am capable (or think I'm capable ;-) of revising the wiki to add a statement 
to the effect that, more important than storing backup passwords is storing 
backups of the actual data.  I just wanted to provoke some discussion before 
making such a revision.  (I might even downplay the emphasis on creating and 
storing backup passwords.)


Note: The password(s) of a encrypted LVM volume are stored inside its Linux 
Unified Key Setup (LUKS) header(s). Creating backup passwords is important 
because if in the future somehow you first password is no longer working, or 
you simply forget your password, or you do remember your password but 
something unexpected happens such as a bug after a kernel update and somehow 
the password is no longer working, then without backup password(s) you risk to 
permanently lose all your valuable data stored into that encrypted LVM 
storage.

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[Brian]

On Wed 02 Sep 2020 at 18:31:43 -0500, John Hasler wrote:

> While storage in a file fine for trivial passwords such as those for
> social sites storing important ones on the computer is a bad idea,
> encrypted or not.  So is copying and pasting them.

Storing passords on paper in the clear ok, but encrypted in a file
is not? I do not have any trivial passwords; all are important. Copy
and paste may be dispensed with.

-- 
Brian.

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[John Hasler]

While storage in a file fine for trivial passwords such as those for
social sites storing important ones on the computer is a bad idea,
encrypted or not.  So is copying and pasting them.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[tomas]

On Wed, Sep 02, 2020 at 08:38:41PM +0100, Brian wrote:
> On Wed 02 Sep 2020 at 11:34:27 -0500, John Hasler wrote:
> 
> > tomas writes:
> > > When a passphrase is long (16) I keep a little scrap until it is
> > > memorized.
> > 
> > I just follow Bruce Schneier's advice and write all of my (random)
> > passwords down.  I end up memorizing the ones I use most, though.
> 
> This memorisation of a vast number of passwords is the killer, of
> course, so writing all passwords down is a good idea. Why not record
> them in passwd.text? Then
> 
>   scrypt enc passwords.txt passwords.enc
> 
> For access:
> 
>   scrypt dec passwords.enc
> 
> and copy and paste.
> 
> A password is required for decrypting passwords.enc. *M05o05m19m19a?
> would do nicely. Just a single password to remember. It couldn't get
> simpler.

Basically this is what I said I do: The passwords I use regularly
are in L1 cache (my head), the others in an encrypted text file
(additionally protected by the LUKS encryption around it).

Cheers
-- t


signature.asc
Description: Digital signature

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[Brian]

On Wed 02 Sep 2020 at 11:34:27 -0500, John Hasler wrote:

> tomas writes:
> > When a passphrase is long (16) I keep a little scrap until it is
> > memorized.
> 
> I just follow Bruce Schneier's advice and write all of my (random)
> passwords down.  I end up memorizing the ones I use most, though.

This memorisation of a vast number of passwords is the killer, of
course, so writing all passwords down is a good idea. Why not record
them in passwd.text? Then

  scrypt enc passwords.txt passwords.enc

For access:

  scrypt dec passwords.enc

and copy and paste.

A password is required for decrypting passwords.enc. *M05o05m19m19a?
would do nicely. Just a single password to remember. It couldn't get
simpler.

-- 
Brian.

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[John Hasler]

tomas writes:
> When a passphrase is long (16) I keep a little scrap until it is
> memorized.

I just follow Bruce Schneier's advice and write all of my (random)
passwords down.  I end up memorizing the ones I use most, though.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[tomas]

On Wed, Sep 02, 2020 at 09:20:18AM -0400, rhkra...@gmail.com wrote:
> On Wednesday, September 02, 2020 03:34:30 AM to...@tuxteam.de wrote:
> > The thing is... I didn't know I can easily memorize that until I
> > tried! It's like getting up early without an alarm clock. If you
> > trust yourself, it kind of magically works.
>  
> Until you (and/or your brain reach a certain age, when you start forgetting 
> things you once had memorized.  Make sure you have "hard copy" backups 
> somewhere (could be on paper, electronic, or ).

I'm millionaire (in years, and in binary, FWIW :)

When a passphrase is long (16) I keep a little scrap until it is memorized.
Then it's in. Things happen, but then, I can be run over by a bus, too.

Cheers
 - t


signature.asc
Description: Digital signature

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[rhkramer]

On Wednesday, September 02, 2020 05:16:12 AM Andrei POPESCU wrote:
> On Ma, 01 sep 20, 19:39:53, rhkra...@gmail.com wrote:
> > That can be a good approach, but a modern approach seems to be tending
> > towards multiple whole words, e.g. "book swimming Wednesday conduct"
> > (all together as a password.

> > I've read articles about the approach, but don't remember enough to
> > explain it very well.
> 
> https://xkcd.com/936/

Ahh, yes, thank you -- one of the most memorable (even though I forgot it) and 
easy to understand!!

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[rhkramer]

On Wednesday, September 02, 2020 03:34:30 AM to...@tuxteam.de wrote:
> The thing is... I didn't know I can easily memorize that until I
> tried! It's like getting up early without an alarm clock. If you
> trust yourself, it kind of magically works.
 
Until you (and/or your brain reach a certain age, when you start forgetting 
things you once had memorized.  Make sure you have "hard copy" backups 
somewhere (could be on paper, electronic, or ).

> I love tech, I'm a geek. But if the only raison d'être of tech is
> to avoid discovering one's own capabilities, I'd rather pass.
> 
> YMMV, but generally speaking, the quintessence is that yo're capable
> of things you never knew of.

!!

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[Andrei POPESCU]

On Ma, 01 sep 20, 19:39:53, rhkra...@gmail.com wrote:
> 
> That can be a good approach, but a modern approach seems to be tending 
> towards 
> multiple whole words, e.g. "book swimming Wednesday conduct" (all together as 
> a password.
> 
> A password like this can be easier for a person to remember (especially if 
> you 
> create a mnemonic to go with it) and be harder for a computer to guess.
> 
> I've read articles about the approach, but don't remember enough to explain 
> it 
> very well.

https://xkcd.com/936/

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[tomas]

On Wed, Sep 02, 2020 at 11:30:44AM +1200, Ben Caradoc-Davies wrote:
> On 02/09/2020 06:42, Mike McClain wrote:
> >On Mon, Aug 31, 2020 at 09:41:06PM +, Long Wind wrote:
> >
> >>my memory is poor, i can't remember many accounts and passwords
> > The more experience you have the harder it is to find the
> >memory you're searching for. That's my story and I'm sticking to it.
> Yes, you can't pour a gallon of knowledge into a shot glass without
> spilling a few drops (for those of us old enough to remember Married
> with Children).

And still -- you all know this model is flawed.

After dabbling with mnemonics and things for *years*, I got fed up
with all of that and tried... semi-random passwords. Like those made
up by pwgen.

My hard disk encryption password is 16 characters long, likewise
my backup's encryption (they're different, thanks for asking :)

They look like this:

  tomas@trotzki:~$ pwgen -N 1 -n 16
  ORoonaif5uqueo6o

Less sensitive things, like my login are eight chars.

Of course, that's only good for passwords I use often (the L1 cache,
roughly five entries). For the others, I have an encrypted plain
text file. This last passphrase has to be in cache, like that of
the LUKS disk encryption (ORed with the backup, phew ;-)

The thing is... I didn't know I can easily memorize that until I
tried! It's like getting up early without an alarm clock. If you
trust yourself, it kind of magically works.

I love tech, I'm a geek. But if the only raison d'être of tech is
to avoid discovering one's own capabilities, I'd rather pass.

YMMV, but generally speaking, the quintessence is that yo're capable
of things you never knew of.

Cheers
 - tomás



signature.asc
Description: Digital signature

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[Tom Dial]

On 9/1/20 17:39, rhkra...@gmail.com wrote:
> On Tuesday, September 01, 2020 02:42:50 PM Mike McClain wrote:
>> On Mon, Aug 31, 2020 at 09:41:06PM +, Long Wind wrote:
>> 
>>
>>> my memory is poor, i can't remember many accounts and passwords
>>
>> The more experience you have the harder it is to find the
>> memory you're searching for. That's my story and I'm sticking to it.
> 
> +1 ;-)
> 
>> Mnemonics can make passwords relatively easy to remember and can
>> be very secure if chosen carefully.
>> Mom's birthday is 5 May 1919, a secure password is *M05o05m19m19a?
>> I have an AT&T account and an address I haven't lived at in 50 years is
>> 5535 El Campo, Ft. Worth, Texas 75107, so :A5535t75107t;.
>> That should give you the idea, a mix of upper and lower case,
>> numerals and punctuation selected from things no longer current can make
>> good passwords easy to remember.
> 
> That can be a good approach, but a modern approach seems to be tending 
> towards 
> multiple whole words, e.g. "book swimming Wednesday conduct" (all together as 
> a password.
> 
> A password like this can be easier for a person to remember (especially if 
> you 
> create a mnemonic to go with it) and be harder for a computer to guess.

Four randomly chosen words from the Oxford English Dictionary would be
comparable to a 14 character random (or cryptographically secure
pseudorandom) string chosen from upper and lower case letters and digits.

Much is made of the fact that most people can remember a string of words
more effectively than a meaningless string of letters and numbers.
However, that is not at all self-evident if the common recommendation of
unique and unrelated authentication secrets per account is incorporated.
I have, overall, more than a hundred distinct accounts on systems and
with vendors, nearly all of them unique; I find a password manager
(KeepassX) a much easier way to generate and manage the authentication
secrets, and use a pass phrase word combination only to secure the
password database.

Regards,
Tom Dial

> 
> I've read articles about the approach, but don't remember enough to explain 
> it 
> very well.
> 
> 
> 
>> GRC.com has a password checker

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[rhkramer]

On Tuesday, September 01, 2020 02:42:50 PM Mike McClain wrote:
> On Mon, Aug 31, 2020 at 09:41:06PM +, Long Wind wrote:
> 
> 
> > my memory is poor, i can't remember many accounts and passwords
> 
> The more experience you have the harder it is to find the
> memory you're searching for. That's my story and I'm sticking to it.

+1 ;-)

> Mnemonics can make passwords relatively easy to remember and can
> be very secure if chosen carefully.
> Mom's birthday is 5 May 1919, a secure password is *M05o05m19m19a?
> I have an AT&T account and an address I haven't lived at in 50 years is
> 5535 El Campo, Ft. Worth, Texas 75107, so :A5535t75107t;.
> That should give you the idea, a mix of upper and lower case,
> numerals and punctuation selected from things no longer current can make
> good passwords easy to remember.

That can be a good approach, but a modern approach seems to be tending towards 
multiple whole words, e.g. "book swimming Wednesday conduct" (all together as 
a password.

A password like this can be easier for a person to remember (especially if you 
create a mnemonic to go with it) and be harder for a computer to guess.

I've read articles about the approach, but don't remember enough to explain it 
very well.



> GRC.com has a password checker

Re: passwords + bad memory - Was (Re: how to test disk for bad sector)

[Ben Caradoc-Davies]

On 02/09/2020 06:42, Mike McClain wrote:

On Mon, Aug 31, 2020 at 09:41:06PM +, Long Wind wrote:


my memory is poor, i can't remember many accounts and passwords

 The more experience you have the harder it is to find the
memory you're searching for. That's my story and I'm sticking to it.
Yes, you can't pour a gallon of knowledge into a shot glass without 
spilling a few drops (for those of us old enough to remember Married 
with Children).


I use and recommend KeePassXC under Debian and KeePassDroid under 
Android to manage passwords without online services. They use the same 
.kdbx file format.


Kind regards,

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

passwords + bad memory - Was (Re: how to test disk for bad sector)

[Mike McClain]

On Mon, Aug 31, 2020 at 09:41:06PM +, Long Wind wrote:

> my memory is poor, i can't remember many accounts and passwords

The more experience you have the harder it is to find the
memory you're searching for. That's my story and I'm sticking to it.

Mnemonics can make passwords relatively easy to remember and can
be very secure if chosen carefully.
Mom's birthday is 5 May 1919, a secure password is *M05o05m19m19a?
I have an AT&T account and an address I haven't lived at in 50 years is
5535 El Campo, Ft. Worth, Texas 75107, so :A5535t75107t;.
That should give you the idea, a mix of upper and lower case,
numerals and punctuation selected from things no longer current can make
good passwords easy to remember.
GRC.com has a password checker
HTH,
Mike
--
It seems to me a little shallow that the Creator of the universes
would care whether He was called Yahweh, Allah, Jehovah, The Great
Spirit, Vishnu or any of many other names rather than caring about
how we carry out His commands.  - MM

Re: Wheezy no longer accepts my passwords to open /home and /mnt partitions on boot

[Pascal Hambourg]

Le 09/12/2016 à 04:26, David Christensen a écrit :

On 12/07/16 22:06, Ken Heard wrote:

In my Wheezy box I have two encrypted hard drive partitions,
/dev/mapper/md07_crypt for /home and /dev/mapper/md05_crypt for /mnt.

(...)

This morning, when I tried to boot this box, I found that the
passwords for those two partitions were not accepted.

(...)

BOOT was not cleanly unmounted, check forced.
BOOT: 245/120960 files (20.4% non-contiguous) 58505/241664 blocks
Fsck.ext4 No such file or directory while trying to open
/dev/mapper/md07_crypt.
Possibly non-existent device?
VAR: recovering journal


Looks like some other filesystems were not cleanly unmounted. Could it 
be related ?



[warn] A maintenance shell will now be started. CONTROL-D will
terminate the shell and resume system boot ... (warning)
Give root password form maintenance
(or type CONTROL-D to continue):

After entering the root password the root bang appeared.

(...)

I hope that somebody or bodies can tell me what to do to make this
computer usable again -- short of having to do a completely new
installation.


It depends what you mean by "usable".
If you just want to complete the init process, then comment out the 
/home line in /etc/fstab.


The first things you want to do is to check that /dev/md* exist and are 
active, and check the keyboard layout by typing the passphrases in 
cleartext.



If you don't care about the data on that drive, wipe it and do a fresh
install.

If you do care and don't have a backup


Then you are a fool. Encryption means "I prefer losing the data than 
having it disclosed". I guess you didn't make a backup of the master key 
or the LUKS header with cryptsetup ?

Re: Wheezy no longer accepts my passwords to open /home and /mnt partitions on boot

[David Christensen]

On 12/07/16 22:06, Ken Heard wrote:

In my Wheezy box I have two encrypted hard drive partitions, 
/dev/mapper/md07_crypt for /home and /dev/mapper/md05_crypt for /mnt. (Mnt is 
no longer used. That partition was originally for /tmp; in a weak moment I 
persuaded myself that I needed to encrypt /tmp. I have since changed the mount 
point for /tmp to tmpfs and consequently changed the mount point of 
/dev/mapper/md05_crypt to /mnt pending its deletion. In the meantime it still 
has to be opened.)

This morning, when I tried to boot this box, I found that the passwords for 
those two partitions were not accepted. Finally, after entering the correct 
passwords numerous times, the following messages were received.

[info] Loading kernel module loop.
[info] Loading kernel module coretemp.
[info] Loading kernel module it87.
[ok] Activating lvm and md swap ... Done
[] Checking file systems ... Fsck from util-linux 2.20.1
BOOT was not cleanly unmounted, check forced.
BOOT: 245/120960 files (20.4% non-contiguous) 58505/241664 blocks
Fsck.ext4 No such file or directory while trying to open /dev/mapper/md07_crypt.
Possibly non-existent device?
VAR: recovering journal
Fsck died with exit status 9
Failed (code 9).
[FAIL] File system check failed. A log is being saved in /var/log/fsck/checkfs 
if that location is writable.
{My note: that location was not writable; so no such log was created.}
Please repair the system manually ... Failed!
[warn] A maintenance shell will now be started. CONTROL-D will terminate the 
shell and resume system boot ... (warning)
Give root password form maintenance
(or type CONTROL-D to continue):

After entering the root password the root bang appeared.

At this point I did not know what to do by way of reparing the system manually. I 
consequently closed the box, first by running "shutdown now". After various 
messages flashed by on the monitor I was asked once more to give the password for 
maintenance or type CONTROL-D again. After typing CONTROL-D again my user login appeared, 
but of course I could not log in. At that point I was finally able to close the computer 
with the Alt-S command.

I hope that somebody or bodies can tell me what to do to make this computer 
usable again -- short of having to do a completely new installation.


If you don't care about the data on that drive, wipe it and do a fresh 
install.



If you do care and don't have a backup, disconnect that drive, add 
another drive, do a fresh install on the additional drive (you might 
want to avoid encryption), reconnect the first drive, and see what you 
can recover.



David

Wheezy no longer accepts my passwords to open /home and /mnt partitions on boot

[Ken Heard]

In my Wheezy box I have two encrypted hard drive partitions, 
/dev/mapper/md07_crypt for /home and /dev/mapper/md05_crypt for /mnt. (Mnt is 
no longer used. That partition was originally for /tmp; in a weak moment I 
persuaded myself that I needed to encrypt /tmp. I have since changed the mount 
point for /tmp to tmpfs and consequently changed the mount point of 
/dev/mapper/md05_crypt to /mnt pending its deletion. In the meantime it still 
has to be opened.)

This morning, when I tried to boot this box, I found that the passwords for 
those two partitions were not accepted. Finally, after entering the correct 
passwords numerous times, the following messages were received. 

[info] Loading kernel module loop.
[info] Loading kernel module coretemp.
[info] Loading kernel module it87.
[ok] Activating lvm and md swap ... Done
[] Checking file systems ... Fsck from util-linux 2.20.1
BOOT was not cleanly unmounted, check forced.
BOOT: 245/120960 files (20.4% non-contiguous) 58505/241664 blocks
Fsck.ext4 No such file or directory while trying to open /dev/mapper/md07_crypt.
Possibly non-existent device?
VAR: recovering journal
Fsck died with exit status 9
Failed (code 9).
[FAIL] File system check failed. A log is being saved in /var/log/fsck/checkfs 
if that location is writable.
{My note: that location was not writable; so no such log was created.}
Please repair the system manually ... Failed!
[warn] A maintenance shell will now be started. CONTROL-D will terminate the 
shell and resume system boot ... (warning)
Give root password form maintenance
(or type CONTROL-D to continue):

After entering the root password the root bang appeared.

At this point I did not know what to do by way of reparing the system manually. 
I consequently closed the box, first by running "shutdown now". After various 
messages flashed by on the monitor I was asked once more to give the password 
for maintenance or type CONTROL-D again. After typing CONTROL-D again my user 
login appeared, but of course I could not log in. At that point I was finally 
able to close the computer with the Alt-S command.

I hope that somebody or bodies can tell me what to do to make this computer 
usable again -- short of having to do a completely new installation.

Regards, Ken Heard

-- 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Where are WiFi passwords (WPA keys) stored?

[Brian]

On Tue 06 Dec 2016 at 23:09:59 +0100, Christian Seiler wrote:

> On 12/06/2016 09:26 PM, Brian wrote:
> 
> That all said: I'm not a huge fan of NetworkManager, I think
> some aspects of it are not well enough thought out to my
> taste - but it does it's job in the case of WiFi, and it does
> it well, better than the alternatives I've seen so far.

I've never really used NetworkManager, not because I think it is lacking
in some way but because the alternatives of ifupdown, wpa_supplicant and
ConnMan etc do a good job for me and my users when at home or roaming.
 
> > However, it is worth acknowledging that Debian has the most complete
> > integration of ifupdown with wpa_supplicant you will find. It also has
> > excellent documentation to help with explaining this integration. There
> > are some things Debian does so well that they are unsurpassable.
> 
> Yes, and the primary use case I see for this are headless
> servers or similar that are connected via WiFi, where the
> connection rarely changes. I would not want to use that on a
> laptop though, because you never know when you'll want to
> connect to a different network.

The author of the README.Debian doesn't appear to take the same view as
you. I use what is in it as the basis for my roaming setup on a laptop.
I've just refreshed my memory on the what needs to be done: a stanza or
two in /e/n/i, a couple of lines in a wpa_supplicant.conf and an install
of wpa_gui. Connecting to a different network with wpa_gui doesn't seem
to be any more difficult than using any other GUI application.
 
> > Just in case you think you
> > cannot point and click when you have direct enduser control over the
> > supplicant, think again. There is wpa-gui.
> 
> Last time I tried wpa_gui troubleshooting with it was a huge
> mess, and I had to resort to wpa_cli to actually get some
> sensible information about what was going on. Maybe that has
> improved since (it's been a couple of years), but my
> experiences with it have been bad.

I think any serious debugging of a wireless issue would inevitably
involve wpa_cli at some point. I do agree, though, that wpa_cli as a way
of end-user interaction isn't desirable in the normal course of events.
Thank goodness for NetworkManager and all the other GUI stuff.

-- 
Brian.

Re: Where are WiFi passwords (WPA keys) stored?

[Christian Seiler]

On 12/06/2016 09:26 PM, Brian wrote:
> On Tue 06 Dec 2016 at 11:14:56 +0100, Christian Seiler wrote:
> 
>> Note that when using NetworkManager, it configures its own
>> instance of wpa_supplicant, so you should never touch a
>> configuration file for wpa_supplicant yourself in this kind of
>> setup.
>>
>> (You could of course stop using NetworkManager and configure
>> wpa_supplicant manually, but I really wouldn't recommend that;
>> I don't think wpa_supplicant is designed in a way that makes
>> direct end-user usage easy - there's a reason why NetworkManager
>> exists instead of desktop environments communicating directly
>> with wpa_supplicant.)
> 
> Direct interaction with the supplicant is not easy?

If you want to dynamically connect to a network that's not in
your wpa_supplicant.conf, then yes, that's not easy to do via
wpa_cli. (It's doable, just not easy or user-friendly.) If
you then want to combine a dynamically-added configuration
with something like DHCP, then it's even worse.

Of course, if you edit the wpa_supplicant.conf every time you
want to connect to a new network, and tear down and restart
the entire wifi interface, sure, that'll work, but it doesn't
fit well into the WiFi model.

That all said: I'm not a huge fan of NetworkManager, I think
some aspects of it are not well enough thought out to my
taste - but it does it's job in the case of WiFi, and it does
it well, better than the alternatives I've seen so far.

> However, it is worth acknowledging that Debian has the most complete
> integration of ifupdown with wpa_supplicant you will find. It also has
> excellent documentation to help with explaining this integration. There
> are some things Debian does so well that they are unsurpassable.

Yes, and the primary use case I see for this are headless
servers or similar that are connected via WiFi, where the
connection rarely changes. I would not want to use that on a
laptop though, because you never know when you'll want to
connect to a different network.

> Just in case you think you
> cannot point and click when you have direct enduser control over the
> supplicant, think again. There is wpa-gui.

Last time I tried wpa_gui troubleshooting with it was a huge
mess, and I had to resort to wpa_cli to actually get some
sensible information about what was going on. Maybe that has
improved since (it's been a couple of years), but my
experiences with it have been bad.

Regards,
Christian

Re: Where are WiFi passwords (WPA keys) stored?

[Brian]

On Tue 06 Dec 2016 at 11:14:56 +0100, Christian Seiler wrote:

> Note that when using NetworkManager, it configures its own
> instance of wpa_supplicant, so you should never touch a
> configuration file for wpa_supplicant yourself in this kind of
> setup.
> 
> (You could of course stop using NetworkManager and configure
> wpa_supplicant manually, but I really wouldn't recommend that;
> I don't think wpa_supplicant is designed in a way that makes
> direct end-user usage easy - there's a reason why NetworkManager
> exists instead of desktop environments communicating directly
> with wpa_supplicant.)

Direct interaction with the supplicant is not easy? Mmm, probably a
sustainable view if the only objective is to point and click.

However, it is worth acknowledging that Debian has the most complete
integration of ifupdown with wpa_supplicant you will find. It also has
excellent documentation to help with explaining this integration. There
are some things Debian does so well that they are unsurpassable.

Users wanting a simple or complex supplicant setup could find dealing
with the organ grinder (rather than the monkey) a more satisfying
experience when managing wireless networks. Just in case you think you
cannot point and click when you have direct enduser control over the
supplicant, think again. There is wpa-gui.

-- 
Brian.

Re: Where are WiFi passwords (WPA keys) stored?

[Liam O'Toole]

On 2016-12-06, Celejar  wrote:
> On Tue, 06 Dec 2016 11:12:45 +0100
> Yvan Masson  wrote:
>
> ...
>
>> I am almost sure that installing a XFCE desktop also installs
>> NetworkManager to handle connections.
>
> I use (much / most of) Xfce without NM. I just looked at what would
> happen if I selected the xfce4 metapackage for installation, and NM
> still will not get installed, and doesn't even show up in aptitude as
> recommended or suggested.
>
> Celejar
>
>

The task package task-xfce-desktop recommends network-manager-gnome. So
the latter would have been installed if the OP selected Xfce at the
'Software selection' stage of the installation of Debian.

-- 

Liam

Re: Where are WiFi passwords (WPA keys) stored?

[Teemu Likonen]

cele...@gmail.com [2016-12-06 12:44:19-05] wrote:

> I just looked at what would happen if I selected the xfce4 metapackage
> for installation, and NM still will not get installed, and doesn't
> even show up in aptitude as recommended or suggested.

Task named task-xfce-desktop has network-manager-gnome package in its
"recommends" list. Network Manager is the default way of configuring
network for desktop Linux systems.

$ aptitude --disable-columns -F%p search '?recommends(network-manager)'
cinnamon 
education-networked
education-standalone
gnome-control-center
gnome-core
lxde
plasma-nm
strongswan-nm
task-gnome-desktop
task-mate-desktop
task-xfce-desktop
wader-core

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


signature.asc
Description: PGP signature

Re: Where are WiFi passwords (WPA keys) stored?

[Brian]

On Tue 06 Dec 2016 at 12:44:19 -0500, Celejar wrote:

> On Tue, 06 Dec 2016 11:12:45 +0100
> Yvan Masson  wrote:
> 
> ...
> 
> > I am almost sure that installing a XFCE desktop also installs
> > NetworkManager to handle connections.
> 
> I use (much / most of) Xfce without NM. I just looked at what would
> happen if I selected the xfce4 metapackage for installation, and NM
> still will not get installed, and doesn't even show up in aptitude as
> recommended or suggested.

Try installing task-xfce4-desktop. This is what d-i does. (But you
are correct. Installing xfce4 does not install network-manager).

-- 
Brian.

Re: Where are WiFi passwords (WPA keys) stored?

[Celejar]

On Tue, 06 Dec 2016 11:12:45 +0100
Yvan Masson  wrote:

...

> I am almost sure that installing a XFCE desktop also installs
> NetworkManager to handle connections.

I use (much / most of) Xfce without NM. I just looked at what would
happen if I selected the xfce4 metapackage for installation, and NM
still will not get installed, and doesn't even show up in aptitude as
recommended or suggested.

Celejar

Re: Where are WiFi passwords (WPA keys) stored?

[Celejar]

On Tue, 6 Dec 2016 09:04:08 +0100
Robert Latest  wrote:

> Not in /etc/wpa_supplicant/wpa_supplicant.conf, despite suggestions in
> every bit of documentation that I got my hands on. In fact, that file
> doesn't even exist on my jessie system. Nevertheless, when I
> configured the WiFi network using some GUI tool in the XFCE desktop,
> it worked. Even after a reboot, with no desktop running, I could ssh
> into the system via WiFi.
> 
> So there must be a place, somewhere, where the WiFi passowrd ist
> stored, outside the realm of some specific user. Where is it?

No idea about the GUI tool that you used, but I use Xfce and manage my
WiFi manually with ifupdown - /etc/network/interfaces. My WiFi keys are
stored in e/n/i.

Celejar

Re: Where are WiFi passwords (WPA keys) stored?

[Robert Latest]

Hi Christian (and everybody else),

thanks for all the helpful answers. NetworkManager was what I was
looking for. I was just not aware of any additional layer on top of
wpa-supplicant.

robert


On Tue, Dec 6, 2016 at 11:14 AM, Christian Seiler  wrote:
> On 12/06/2016 09:04 AM, Robert Latest wrote:
>> Not in /etc/wpa_supplicant/wpa_supplicant.conf, despite suggestions in
>> every bit of documentation that I got my hands on. In fact, that file
>> doesn't even exist on my jessie system. Nevertheless, when I
>> configured the WiFi network using some GUI tool in the XFCE desktop,
>> it worked.
>
> Disclaimer: I'm not a user of XFCE, so if that does something
> really weird, this may not apply.
>
> However, most graphical tools interface with NetworkManager, and
> that stores its configuration in /etc/NetworkManager.
>
> You'll likely find your password stored in
> /etc/NetworkManager/system-connections/$SSID
> (file only readable/writable as root; also please don't modify it
> while NetworkManager is running, it will overwrite it without
> warning; modifying it when NetworkManager is stopped is fine
> though)
>
> where you replace $SSID with the SSID of your WiFi.
>
> On some desktops (e.g. GNOME) the Password can be stored in the
> personal user's keyring/wallet/password manager instead, but
> then you need to be logged in for NetworkManager to have access
> to the password - which is not true in your case because you
> mentioned:
>
>> Even after a reboot, with no desktop running, I could ssh
>> into the system via WiFi.
>
> So that means that NetworkManager has the password stored
> directly.
>
> Note that when using NetworkManager, it configures its own
> instance of wpa_supplicant, so you should never touch a
> configuration file for wpa_supplicant yourself in this kind of
> setup.
>
> (You could of course stop using NetworkManager and configure
> wpa_supplicant manually, but I really wouldn't recommend that;
> I don't think wpa_supplicant is designed in a way that makes
> direct end-user usage easy - there's a reason why NetworkManager
> exists instead of desktop environments communicating directly
> with wpa_supplicant.)
>
>> BTW, I did find a wpa_supplicant.conf file in some deep subdir of
>> /etc/dbus-1/...
>
> That's just the DBus policy, that doesn't configure how
> wpa_supplicant reacts, but only how the DBus daemon handles
> the access policy for wpa_supplicant. (DBus is a communication
> bus used on Linux and other systems; most desktop envirnoments,
> including XFCE, use it internally for some things.) Unless you
> know what you're doing, I wouldn't touch that, otherwise you
> could end up stopping NetworkManager from communicating with
> wpa_supplicant and then your WiFi could stop working altogether.
>
> Regards,
> Christian

Re: Where are WiFi passwords (WPA keys) stored?

[Mart van de Wege]

Robert Latest  writes:

> Not in /etc/wpa_supplicant/wpa_supplicant.conf, despite suggestions in
> every bit of documentation that I got my hands on. In fact, that file
> doesn't even exist on my jessie system. Nevertheless, when I
> configured the WiFi network using some GUI tool in the XFCE desktop,
> it worked. Even after a reboot, with no desktop running, I could ssh
> into the system via WiFi.
>
> So there must be a place, somewhere, where the WiFi passowrd ist
> stored, outside the realm of some specific user. Where is it?
>
Assuming you're running Network-Manager, you can find the individual
connections defined in /etc/NetworkManager/system-connections, with each
connection having a psk= attribute line with the psk.

Note that these files are only root-accessible.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: Where are WiFi passwords (WPA keys) stored?

[Christian Seiler]

On 12/06/2016 09:04 AM, Robert Latest wrote:
> Not in /etc/wpa_supplicant/wpa_supplicant.conf, despite suggestions in
> every bit of documentation that I got my hands on. In fact, that file
> doesn't even exist on my jessie system. Nevertheless, when I
> configured the WiFi network using some GUI tool in the XFCE desktop,
> it worked.

Disclaimer: I'm not a user of XFCE, so if that does something
really weird, this may not apply.

However, most graphical tools interface with NetworkManager, and
that stores its configuration in /etc/NetworkManager.

You'll likely find your password stored in
/etc/NetworkManager/system-connections/$SSID
(file only readable/writable as root; also please don't modify it
while NetworkManager is running, it will overwrite it without
warning; modifying it when NetworkManager is stopped is fine
though)

where you replace $SSID with the SSID of your WiFi.

On some desktops (e.g. GNOME) the Password can be stored in the
personal user's keyring/wallet/password manager instead, but
then you need to be logged in for NetworkManager to have access
to the password - which is not true in your case because you
mentioned:

> Even after a reboot, with no desktop running, I could ssh
> into the system via WiFi.

So that means that NetworkManager has the password stored
directly.

Note that when using NetworkManager, it configures its own
instance of wpa_supplicant, so you should never touch a
configuration file for wpa_supplicant yourself in this kind of
setup.

(You could of course stop using NetworkManager and configure
wpa_supplicant manually, but I really wouldn't recommend that;
I don't think wpa_supplicant is designed in a way that makes
direct end-user usage easy - there's a reason why NetworkManager
exists instead of desktop environments communicating directly
with wpa_supplicant.)

> BTW, I did find a wpa_supplicant.conf file in some deep subdir of
> /etc/dbus-1/...

That's just the DBus policy, that doesn't configure how
wpa_supplicant reacts, but only how the DBus daemon handles
the access policy for wpa_supplicant. (DBus is a communication
bus used on Linux and other systems; most desktop envirnoments,
including XFCE, use it internally for some things.) Unless you
know what you're doing, I wouldn't touch that, otherwise you
could end up stopping NetworkManager from communicating with
wpa_supplicant and then your WiFi could stop working altogether.

Regards,
Christian

Re: Where are WiFi passwords (WPA keys) stored?

[Yvan Masson]

Hi,

Le mardi 06 décembre 2016 à 09:04 +0100, Robert Latest a écrit :
> Not in /etc/wpa_supplicant/wpa_supplicant.conf, despite suggestions
> in
> every bit of documentation that I got my hands on. In fact, that file
> doesn't even exist on my jessie system. Nevertheless, when I
> configured the WiFi network using some GUI tool in the XFCE desktop,
> it worked. Even after a reboot, with no desktop running, I could ssh
> into the system via WiFi.
> 
> So there must be a place, somewhere, where the WiFi passowrd ist
> stored, outside the realm of some specific user. Where is it?
> 
> BTW, I did find a wpa_supplicant.conf file in some deep subdir of
> /etc/dbus-1/... (I'm not at that computer at the moment). But that is
> in some XML format that has nothing to do with the syntax described
> in
> the wpa_supplicant.conf man page, and my WPA key doesn't seem to be
> in
> there.

I am almost sure that installing a XFCE desktop also installs
NetworkManager to handle connections.

NetwokManager runs as a system service, uses wpasupplicant to connect
to WiFi, and offers a sytem tray applet (nm-applet), a GUI (nm-
connection-editor), a CLI (nmcli) and a TUI (Text User Interface -
nmtui).

Networks' configurations, including WiFi password, are stored in
/etc/NetworkManager/system-connections/, and are
readable by root.

Regards,
Yvan

signature.asc
Description: This is a digitally signed message part

Re: Where are WiFi passwords (WPA keys) stored?

[Ben Finney]

Robert Latest  writes:

> […] when I configured the WiFi network using some GUI tool in the XFCE
> desktop,

You'll need to be more specific than that :-) Exactly which tool did you
use?

> So there must be a place, somewhere, where the WiFi passowrd ist
> stored, outside the realm of some specific user. Where is it?

That will depend on what version of Debian, and which tool you used.


The most likely answer is: You used the GNOME tool that interacts with
NetworkManager https://wiki.gnome.org/Projects/NetworkManager>, but
that could be wrong. Please tell us the details so we can know better
what your system is doing.

-- 
 \  “I went to a garage sale. ‘How much for the garage?’ ‘It's not |
  `\for sale.’” —Steven Wright |
_o__)  |
Ben Finney

Where are WiFi passwords (WPA keys) stored?

[Robert Latest]

Not in /etc/wpa_supplicant/wpa_supplicant.conf, despite suggestions in
every bit of documentation that I got my hands on. In fact, that file
doesn't even exist on my jessie system. Nevertheless, when I
configured the WiFi network using some GUI tool in the XFCE desktop,
it worked. Even after a reboot, with no desktop running, I could ssh
into the system via WiFi.

So there must be a place, somewhere, where the WiFi passowrd ist
stored, outside the realm of some specific user. Where is it?

BTW, I did find a wpa_supplicant.conf file in some deep subdir of
/etc/dbus-1/... (I'm not at that computer at the moment). But that is
in some XML format that has nothing to do with the syntax described in
the wpa_supplicant.conf man page, and my WPA key doesn't seem to be in
there.

Thanks!

systemd and plymouth not caching LUKS passwords

[Ramon Diaz-Uriarte]

Dear All,

It is my understanding that both systemd per se from v227 and plymouth
will cache passwords[1]. However, there is no caching of LUKS passwords in
my setting, a laptop with two encrypted partitions, corresponding to root
and swap, and where both share the passphrase.

I am using systemd 230-2 and plymouth 0.9.2-3+b1 and running kernel
linux-image-4.6.0-1-amd64 (kernel 4.5 behaves the same way). Trying with or
without plymouth makes no difference (i.e., I am always asked for both
passwords).

I wonder if there is something I need to set/unset, or if I need to create
some (which?) script in /etc/systemd/system. 

My /etc/crypttab is

crypt-sda5  UUID=   noneluks
crypt-sda2  UUID=   noneluks


And my /etc/fstab is

proc/proc   procdefaults0   0
UUID= /boot   ext3defaults  
  0   2
/dev/mapper/crypt-sda5 / ext4 errors=remount-ro,user_xattr 0 1
/dev/mapper/crypt-sda2  noneswapsw  
0   0


Best,



[1] Changes in v227:
https://lists.freedesktop.org/archives/systemd-devel/2015-October/034509.html,
or for instance the step-by-step instructions on setting full disk
encryption at htps://thesimplecomputer.info/full-disk-encryption-with-ubuntu


-- 
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid 
Arzobispo Morcillo, 4
28029 Madrid
Spain

Phone: +34-91-497-2412

Email: rdia...@gmail.com
   ramon.d...@iib.uam.es

http://ligarto.org/rdiaz

Re: Still no wifi passwords after routine Jessie upgrade.

[Brian]

On Sun 28 Sep 2014 at 21:28:35 +, Hendrik Boom wrote:

> Near the beginning of September, I reported suddenly being unable to 
> connect to wifi in coffee shops.  Around the same time, I has done a 
> routine upgrade to my jessie system; I do this every week or two.  
> 
> Everything had been working fine before.
> 
> I am now unable to connect to any hot spot that has a password, even if I 
> know the password.  Luckily, my wifi at home is open -- no password 
> required -- so I can still use wifi here.

So there is the first thing you do to test. You put a password on your
home WiFi. Can you still connect to it?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/28092014224035.a41acb55f...@desktop.copernicus.demon.co.uk

Still no wifi passwords after routine Jessie upgrade.

[Hendrik Boom]

Near the beginning of September, I reported suddenly being unable to 
connect to wifi in coffee shops.  Around the same time, I has done a 
routine upgrade to my jessie system; I do this every week or two.  

Everything had been working fine before.

I am now unable to connect to any hot spot that has a password, even if I 
know the password.  Luckily, my wifi at home is open -- no password 
required -- so I can still use wifi here.

It was suggested to me that network-manager might be to blame and that I 
should try wifi-radar instead.  No luck here, either.  At home, 
everything's OK; elsewhere, no dice.

So it seems that something has changed in my system that no longer allows 
me to use passwords when connecting to wifi.

Any further ideas?

I'm running a regularly updated "testing" system on an i386 netbook; 
specifically, an ASUS HE1000 (if I remember the model number correctly. 
it was the  first ASUS netbook to require no proprietary drivers at all; 
ironically, it was available only with Windows preinstalled).  It has 
performed well for years.

-- hendrik


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m09ui3$7ml$1...@ger.gmane.org

Re: Upgraded apache 2.2 -> 2.4 and cannot get passwords to work

[Scott Ferguson]

On 29/12/13 07:28, Tom H wrote:
> On Sat, Dec 28, 2013 at 7:36 PM, Scott Ferguson
>  wrote:
>> On 29/12/13 03:52, Dave Woyciesjes wrote:
>>> On 12/28/2013 11:09 AM, Kevin O'Gorman wrote:


> 
> 
>> I have a number of web servers updated from Squeeze to Wheezy several
>> months ago - I've had no problems with "authentication".
> 
> Wheezy has 2.2 not 2.4


As packaged by Debian, yes, though someone (Florian?) 'was' going to
backport it. AFAIK that hasn't happened - yet. It might be possible to
install from Sid but I haven't tried.

Installed from source easily on testing Wheezy boxes - Apache 2.4.1,
MySQL Ver 14.14 Distrib 5.1.49, PHP 5.3.10 (and 5.4 and 5.5).

> 
> 
>> Please expand on your authentication system and the problems plus error
>> messages.
> 
> +1
> 
> 

I suspect (hope?) the OP means mod_security when referring to
"authentication".
I prefer other security solutions, plus it's a nightmare to test in dev
environment as it doesn't travel/transfer well.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52bf56e2.4010...@gmail.com

Re: Upgraded apache 2.2 -> 2.4 and cannot get passwords to work

[Tom H]

On Sat, Dec 28, 2013 at 7:36 PM, Scott Ferguson
 wrote:
> On 29/12/13 03:52, Dave Woyciesjes wrote:
>> On 12/28/2013 11:09 AM, Kevin O'Gorman wrote:
>>>
>>> My modest-sized web server was recently upgraded. There were problems
>>> with access control, fairly well documented and fairly easily fixed.
>>>
>>> Authentication, on the other hand, acts as if it's not there -- anyone
>>> and everyone is let into the few parts that used to be controlled. So
>>> I have them offline for now. I don't see any writeups of problems
>>> with this, so perhaps the way I solved access control borked the
>>> authentication.
>>>
>>> I have everything in /var/www and /www, and the authenticated parts
>>> are in /www, with a Directory stanza containing authentication info
>>> for each of the two (but apache is apparently ignoring them). I don't
>>> have /srv. Authentication is by a simple text file with less than 100
>>> entries.
>>>
>>> Does anyone have a similar setup in apache 2.4 that works? Care to
>>> share how?
>>
>> What else is on it, and how was it setup? Plain Debian Wheezy, or
>> Ubuntu-fied Debian?


> I have a number of web servers updated from Squeeze to Wheezy several
> months ago - I've had no problems with "authentication".

Wheezy has 2.2 not 2.4


> Please expand on your authentication system and the problems plus error
> messages.

+1


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAOdo=Sz+WBn6+eYG8byhG2u55NkM_U3x=y10r-4l4scnmoe...@mail.gmail.com

Re: Upgraded apache 2.2 -> 2.4 and cannot get passwords to work

[Scott Ferguson]

On 29/12/13 03:52, Dave Woyciesjes wrote:
> On 12/28/2013 11:09 AM, Kevin O'Gorman wrote:
>> My modest-sized web server was recently upgraded.  There were problems
>> with access control, fairly well documented and fairly easily fixed.
>>
>> Authentication, on the other hand, acts as if it's not there -- anyone
>> and everyone is let into the few parts that used to be controlled.  So
>> I have them offline for now.  I don't see any writeups of problems
>> with this, so perhaps the way I solved access control borked the
>> authentication.
>>
>> I have everything in /var/www and /www, and the authenticated parts
>> are in /www, with a Directory stanza containing authentication info
>> for each of the two (but apache is apparently ignoring them).  I don't
>> have /srv.  Authentication is by a simple text file with less than 100
>> entries.
>>
>> Does anyone have a similar setup in apache 2.4 that works?  Care to
>> share how?
>>
> What else is on it, and how was it setup? Plain Debian Wheezy, or
> Ubuntu-fied Debian?
> 
1++


I have a number of web servers updated from Squeeze to Wheezy several
months ago - I've had no problems with "authentication".
Multi-user/multi-site so I have nothing being served from /var/www (suexec).

Please expand on your authentication system and the problems plus error
messages.

Kind regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52bf2837.2050...@gmail.com

Re: Upgraded apache 2.2 -> 2.4 and cannot get passwords to work

[Dave Woyciesjes]

On 12/28/2013 11:09 AM, Kevin O'Gorman wrote:

My modest-sized web server was recently upgraded.  There were problems
with access control, fairly well documented and fairly easily fixed.

Authentication, on the other hand, acts as if it's not there -- anyone
and everyone is let into the few parts that used to be controlled.  So
I have them offline for now.  I don't see any writeups of problems
with this, so perhaps the way I solved access control borked the
authentication.

I have everything in /var/www and /www, and the authenticated parts
are in /www, with a Directory stanza containing authentication info
for each of the two (but apache is apparently ignoring them).  I don't
have /srv.  Authentication is by a simple text file with less than 100
entries.

Does anyone have a similar setup in apache 2.4 that works?  Care to share how?

What else is on it, and how was it setup? Plain Debian Wheezy, or 
Ubuntu-fied Debian?


--
--- Dave Woyciesjes
--- ICQ# 905818
--- CompTIA A+ Certified IT Tech - http://certification.comptia.org/
--- HDI Certified Support Center Analyst - http://www.ThinkHDI.com/
Registered Linux user number 464583

"Computers have lots of memory but no imagination."
"The problem with troubleshooting is that trouble shoots back."
- from some guy on the internet.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/52bf01e3.1070...@sbcglobal.net

Upgraded apache 2.2 -> 2.4 and cannot get passwords to work

[Kevin O'Gorman]

My modest-sized web server was recently upgraded.  There were problems
with access control, fairly well documented and fairly easily fixed.

Authentication, on the other hand, acts as if it's not there -- anyone
and everyone is let into the few parts that used to be controlled.  So
I have them offline for now.  I don't see any writeups of problems
with this, so perhaps the way I solved access control borked the
authentication.

I have everything in /var/www and /www, and the authenticated parts
are in /www, with a Directory stanza containing authentication info
for each of the two (but apache is apparently ignoring them).  I don't
have /srv.  Authentication is by a simple text file with less than 100
entries.

Does anyone have a similar setup in apache 2.4 that works?  Care to share how?

-- 
Kevin O'Gorman

programmer, n. an organism that transmutes caffeine into software.
Please consider the environment before printing this email.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cagvxcsaypczstam-grgwqvdsnza1gdwrz5panvpu+iursf7...@mail.gmail.com

Re: Integrate passwords LDAP for samba users.

[Arun Khan]

On Wed, Jan 16, 2013 at 8:53 PM, rodrigo tavares
 wrote:
> Hello,
>
> I have a debian  with smb +ldap.
>
> Its possible when I to create ldap users send  this password for samba users
> ?
> So, i dont´t need make to password for samba users.

Install smbldap-tools package.   It provides utilities to manage
users/groups their passwords for Samba and Linux


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cahhm8gb7xla+eefdvzty15rwvtrdb9rng+ajdofknv1fu0r...@mail.gmail.com

Re: [OT] secure passwords (was Re: is it rational to close the 139 port)

[Andrei POPESCU]

On Ma, 31 iul 12, 17:57:38, Bob Proulx wrote:
> 
> The problem is how many of those can you keep straight in your head?
> How many web sites and systems all need one of those unique passwords?
> And you aren't reusing those passwords on multiple unrelated sites are
> you?
> 
> As with all things xkcd has already addressed this problem.
> 
>   http://xkcd.com/792/

Thanks!
 
> Reusing passwords is a problem.  Which means that trying to remember
> the unique password for that site is going to be a burden.  If you
> have some scheme of encoding the site into the password using some
> algorithm unique and secure to you then great.

There is a password manager that does exactly this... (searching), well 
it's not exactly a manager...

http://passwordmaker.org

Kind regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: [OT] secure passwords (was Re: is it rational to close the 139 port)

[Glenn English]

On Jul 31, 2012, at 9:00 PM, Bob Proulx wrote:

> Fortunately for most of us there is the support group of family.They
> know these things and would help me with them.   

I was 67 years old when it happened, and the family I have left 
is 1000 miles away. Fortunately, my sister flew here to take care 
of me. She dealt with the bank and the lawyers, and would have 
brought me the passwords so I could do my rootly duties from the 
hospital.

> If I become
> incapacitated there is an envelope of instructions that I keep updated
> with current information on my accounts.  Mostly it tells how to get
> into particular computer files where I keep my current account
> information stored.  

I didn't have that at the time. I do now -- that and a lot more.

> Of course not everyone is fortunate enough to have a
> supportive family to draw upon for help.

My friends were a lot of help, too. 

Stay away from bicycles. Get a recumbent trike -- it won't toss your 
brain into a pile of rocks...

-- 
Glenn English
hand-wrapped from my Apple Mail




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/76273137-cb5f-4540-a2e1-cf9232ca7...@slsware.com

Re: [OT] secure passwords (was Re: is it rational to close the 139 port)

[Bob Proulx]

Stan Hoeppner wrote:
> Glenn English wrote:
> > Dud'n work, guys. I fell off my bike a couple years ago and completely 
> > lost all my passwords. Rebuilding my servers (and laptops and iPads) was 
> > no fun at all. Write 'em down and put the paper in a safe-deposit box.
> 
> If you can't remember the passwords due to injury, it seems pretty clear
> you wouldn't remember renting the box at the bank either.

Fortunately for most of us there is the support group of family.  They
know these things and would help me with them.  If I become
incapacitated there is an envelope of instructions that I keep updated
with current information on my accounts.  Mostly it tells how to get
into particular computer files where I keep my current account
information stored.  If I had amnesia this would be sufficient for me
to recover.  If I do not recover then it would facilitate the transfer
of my estate.  Of course not everyone is fortunate enough to have a
supportive family to draw upon for help.

Bob


signature.asc
Description: Digital signature

Re: [OT] secure passwords (was Re: is it rational to close the 139 port)

[lina]

On Wed, Aug 1, 2012 at 8:03 AM, Glenn English  wrote:
>
> On Jul 31, 2012, at 4:57 PM, Stan Hoeppner wrote:
>
>> On 7/31/2012 10:51 AM, Mike McClain wrote:
>>
>>>If a password is any place but in your head I question its
>>> security
>>
>> Agreed.
>
> Dud'n work, guys. I fell off my bike a couple years ago and completely
> lost all my passwords. Rebuilding my servers (and laptops and iPads) was
> no fun at all. Write 'em down and put the paper in a safe-deposit box.
I backup my password on the notebook but in a very ancient encrypted way,
even people read it, but also not easy to guess well.
so here avoid the safe-deposit box.
>
>>>Take a name and a number out of your childhood that you'll
>>> remember forever like your first pet and the first phone number
>>> you memorized, scrambled together.
>
> That's pretty much what mine were: first letters and punctuation of
> a well known line from a song or poem. When your brain is hit real hard
> by a sharp rock, they're gone.
>
> --
> Glenn English
> hand-wrapped from my Apple Mail
>
>
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/4d7d08ce-7bd8-4dc0-8bc9-6306e6750...@slsware.com
>


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cag9cjmmc72v0gkvwr-srbja9+ed1b84p0tsqiwd8pgp_omc...@mail.gmail.com

Re: [OT] secure passwords (was Re: is it rational to close the 139 port)

[Stan Hoeppner]

On 7/31/2012 7:03 PM, Glenn English wrote:

> Dud'n work, guys. I fell off my bike a couple years ago and completely 
> lost all my passwords. Rebuilding my servers (and laptops and iPads) was 
> no fun at all. Write 'em down and put the paper in a safe-deposit box.

If you can't remember the passwords due to injury, it seems pretty clear
you wouldn't remember renting the box at the bank either.

-- 
Stan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50189858.8090...@hardwarefreak.com

Re: [OT] secure passwords (was Re: is it rational to close the 139 port)

[lina]

On Wed, Aug 1, 2012 at 6:57 AM, Stan Hoeppner  wrote:
> On 7/31/2012 10:51 AM, Mike McClain wrote:
>
>> If a password is any place but in your head I question its
>> security
>
> Agreed.
>
>> Take a name and a number out of your childhood that you'll
>> remember forever like your first pet and the first phone number
>> you memorized, scrambled together. For instance: Spottie and 765-4321,
>> becomes S7p6o5t4t3i2e1. Now throw in a little punctuation:
>> ..S7p6o5t4t3i2e1!! and you have a password that's personal, easy to
>> remember and quite difficult to crack. Don't take my word for it,
>> take your password to GRC.com or another password checker on the web
>> and see for yourself.
>
> Disagreed.  Too complicated.  E.g.
>
> ***dash***
>
> GRC says: 2.43 billion centuries to crack @ 100 trillion guesses/sec.
> Length is the key to strong passwords, not complication.  The Sun will
> turn into a Red Giant and destroy the solar system in ~4 billion years,
> so this pwd will survive the end of the world, and possibly the end of
> the universe.  And yet it's so simple to create and remember.
The computation speed is also evolving.
it's hard to imagine the speed after 100~200 years.
So I guess that password may extinguish before  the end of universe.
>
> Always practice the K.I.S.S. principle.
>
> --
> Stan
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/501862d3.3080...@hardwarefreak.com
>


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAG9cJmk9=G6O7m1dkc56Qq7=d8gx1+gkz3w13jbug-4bywh...@mail.gmail.com

Re: [OT] secure passwords

[John Hasler]

Bob writes:
> If you have some scheme of encoding the site into the password using
> some algorithm unique and secure to you then great.

> I generate truly random passwords and write them down.

So do I.  The problem is that the _general public_ is constantly being
told "Never, ever, ever write down a password!".  This leads directly to
widespread re-use of trivial passwords.  Most people would be better off
with a list of random passords taped to the monitor than with what they
use now.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehnrbgrf@thumper.dhh.gt.org

Re: [OT] secure passwords (was Re: is it rational to close the 139 port)

[Glenn English]

On Jul 31, 2012, at 4:57 PM, Stan Hoeppner wrote:

> On 7/31/2012 10:51 AM, Mike McClain wrote:
> 
>>If a password is any place but in your head I question its
>> security 
> 
> Agreed.

Dud'n work, guys. I fell off my bike a couple years ago and completely 
lost all my passwords. Rebuilding my servers (and laptops and iPads) was 
no fun at all. Write 'em down and put the paper in a safe-deposit box.

>>Take a name and a number out of your childhood that you'll
>> remember forever like your first pet and the first phone number
>> you memorized, scrambled together.

That's pretty much what mine were: first letters and punctuation of 
a well known line from a song or poem. When your brain is hit real hard 
by a sharp rock, they're gone. 

-- 
Glenn English
hand-wrapped from my Apple Mail




-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/4d7d08ce-7bd8-4dc0-8bc9-6306e6750...@slsware.com

Re: [OT] secure passwords (was Re: is it rational to close the 139 port)

[Bob Proulx]

Mike McClain wrote:
> If a password is any place but in your head I question its
> security but here's a scheme for secure passwords that are not 
> subject to dictionary lookups and are easy to remember.
> 
> Take a name and a number out of your childhood that you'll
> remember forever like your first pet and the first phone number
> you memorized, scrambled together. For instance: Spottie and 765-4321, 
> becomes S7p6o5t4t3i2e1. Now throw in a little punctuation:
> ..S7p6o5t4t3i2e1!! and you have a password that's personal, easy to 
> remember and quite difficult to crack. Don't take my word for it,
> take your password to GRC.com or another password checker on the web
> and see for yourself.

The problem is how many of those can you keep straight in your head?
How many web sites and systems all need one of those unique passwords?
And you aren't reusing those passwords on multiple unrelated sites are
you?

As with all things xkcd has already addressed this problem.

  http://xkcd.com/792/

Reusing passwords is a problem.  Which means that trying to remember
the unique password for that site is going to be a burden.  If you
have some scheme of encoding the site into the password using some
algorithm unique and secure to you then great.

I generate truly random passwords and write them down.

Bob


signature.asc
Description: Digital signature

Re: [OT] secure passwords (was Re: is it rational to close the 139 port)

[Stan Hoeppner]

On 7/31/2012 10:51 AM, Mike McClain wrote:

> If a password is any place but in your head I question its
> security 

Agreed.

> Take a name and a number out of your childhood that you'll
> remember forever like your first pet and the first phone number
> you memorized, scrambled together. For instance: Spottie and 765-4321, 
> becomes S7p6o5t4t3i2e1. Now throw in a little punctuation:
> ..S7p6o5t4t3i2e1!! and you have a password that's personal, easy to 
> remember and quite difficult to crack. Don't take my word for it,
> take your password to GRC.com or another password checker on the web
> and see for yourself.

Disagreed.  Too complicated.  E.g.

***dash***

GRC says: 2.43 billion centuries to crack @ 100 trillion guesses/sec.
Length is the key to strong passwords, not complication.  The Sun will
turn into a Red Giant and destroy the solar system in ~4 billion years,
so this pwd will survive the end of the world, and possibly the end of
the universe.  And yet it's so simple to create and remember.

Always practice the K.I.S.S. principle.

-- 
Stan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/501862d3.3080...@hardwarefreak.com

[OT] secure passwords (was Re: is it rational to close the 139 port)

[Mike McClain]

On Tue, Jul 31, 2012 at 08:31:56PM +1200, Chris Bannister wrote:
> On Mon, Jul 30, 2012 at 06:15:26PM +0100, Brad Rogers wrote:
> > On Mon, 30 Jul 2012 11:54:14 -0500
> > John Hasler  wrote:
> > 
> > Hello John,
> > 
> > >Brad Rogers writes:
> > >> Yeah, on a Post-It note.  Stuck to the monitor.  
> > >That's what people do when you tell them not to write it down.  _Tell_
> > >them to write it down and tell them _how_.
> > 
> > As it happens, I agree with you; write 'em down, and keep 'em safe.
> 
> Or just have one, but make it a good 'un, and never tell anyone.
 

    If a password is any place but in your head I question its
security but here's a scheme for secure passwords that are not 
subject to dictionary lookups and are easy to remember.

Take a name and a number out of your childhood that you'll
remember forever like your first pet and the first phone number
you memorized, scrambled together. For instance: Spottie and 765-4321, 
becomes S7p6o5t4t3i2e1. Now throw in a little punctuation:
..S7p6o5t4t3i2e1!! and you have a password that's personal, easy to 
remember and quite difficult to crack. Don't take my word for it,
take your password to GRC.com or another password checker on the web
and see for yourself.

Walk with Light,
Mike
-- 
Satisfied user of Linux since 1997.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120731155122.GA14597@playground

strong passwords (was ... Re: is it rational to close the 139 port)

[Chris Bannister]

On Mon, Jul 30, 2012 at 07:14:06AM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 30 Jul 2012, Andrei POPESCU wrote:
> > 
> > http://xkcd.com/936/
> > 
> > (I wonder how much truth there is behind this comic...)
> 
> Don't bother wondering.  Read the paper.
> 
> http://arstechnica.com/business/2012/03/passphrases-only-marginally-more-secure-than-passwords-because-of-poor-choices/
> http://www.readwriteweb.com/enterprise/2012/03/passphrases-maybe-not-as-secur.php
> 
> You need to have gibberish passphrases if you want it to be secure...

Right!, so people write it down on the side of the monitor cause they
can't remember it. Yeah, I've seen it. 

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120731075646.GE17427@tal