# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 45
# self = https://watcher.sour.is/conv/lnbbpzq
@prologic @movq this is the default behavior of pass on my machine:
I add a new password entry named example and then type pass example. The password I chose, "test", is displayed in cleartext. This is very bad default behavior. I don't know about the other clis you both mentioned but I'll check them out.
The browser plugin browserpass does the same kind of thing, though I have already removed it and I'm not going to reinstall it to make a movie. Next to each credential there's an icon to copy the username to the clipboard, an icon to copy the password to the clipboard, and then an icon to view details, which shows you everything, including the password, in cleartext. The screencap in the Chrome store is out of date; it doesn't show the offending link to show all details, which I know is there because I literally installed it today and played with it.
ignore that "cannot connect to socket" error; that's some misconfiguration in GnuPG that I haven't figured out how to fix yet.
@abucci I _think_ you raise a good point really, in that the default should be to copy to clipboard IMO. Hmmm ๐ค
@abucci I _think_ you raise a good point really, in that the default should be to copy to clipboard IMO. Hmmm ๐ค
@abucci I _think_ you raise a good point really, in that the default should be to copy to clipboard IMO. Hmmm ๐ค
@abucci I _think_ you raise a good point really, in that the default should be to copy to clipboard IMO. Hmmm ๐ค
@prologic You're almost inevitably going to type that by accident at least once, and a good proportion of newbies are going to type that, and old people with bad memories like myself are going to forget the -c half the time and type that, and some shell autocompletes are going to autocomplete to that, etc etc etc. It's why I think pass is lacking as a cli. KeePassXC makes it *difficult* to show the password in cleartext. You have to go out of your way to do it, and it's unlikely you'd go through those steps by accident or out of ignorance.
@abucci I think you've raised such a good point, I'd encourage you to raise this upstream with gopass, possibly even submit a PR ๐
@abucci I think you've raised such a good point, I'd encourage you to raise this upstream with gopass, possibly even submit a PR ๐
@abucci I think you've raised such a good point, I'd encourage you to raise this upstream with gopass, possibly even submit a PR ๐
@abucci I think you've raised such a good point, I'd encourage you to raise this upstream with gopass, possibly even submit a PR ๐
@prologic that's a good idea I'll look into that tomorrow (it's Friday night here ๐คช)
@abucci Hmm, I see what you mean. ๐ค
From a โUNIXโ point of view, the current behavior feels correct. By default, print to stdout. If you want something else, then you have to specify a flag. Thatโs what a lot of UNIX tools do.
Now, itโs up for debate if this kind of behavior is appropriate for a password manager. ๐
@abucci Hmm, I see what you mean. ๐ค
From a โUNIXโ point of view, the current behavior feels correct. By default, print to stdout. If you want something else, then you have to specify a flag. Thatโs what a lot of UNIX tools do.
Now, itโs up for debate if this kind of behavior is appropriate for a password manager. ๐
@abucci Hmm, I see what you mean. ๐ค
From a โUNIXโ point of view, the current behavior feels correct. By default, print to stdout. If you want something else, then you have to specify a flag. Thatโs what a lot of UNIX tools do.
Now, itโs up for debate if this kind of behavior is appropriate for a password manager. ๐
@movq
> Now, itโs up for debate if this kind of behavior is appropriate for a password manager. ๐
This is worth the debate for sure. As an aside, whenever I _have to_ show the password on the terminal for some reason or another, I **always** make sure I clear the terminal buffer and history with ^L^R ๐
@movq
> Now, itโs up for debate if this kind of behavior is appropriate for a password manager. ๐
This is worth the debate for sure. As an aside, whenever I _have to_ show the password on the terminal for some reason or another, I **always** make sure I clear the terminal buffer and history with ^L^R ๐
@movq
> Now, itโs up for debate if this kind of behavior is appropriate for a password manager. ๐
This is worth the debate for sure. As an aside, whenever I _have to_ show the password on the terminal for some reason or another, I **always** make sure I clear the terminal buffer and history with ^L^R ๐
@movq
> Now, itโs up for debate if this kind of behavior is appropriate for a password manager. ๐
This is worth the debate for sure. As an aside, whenever I _have to_ show the password on the terminal for some reason or another, I **always** make sure I clear the terminal buffer and history with ^L^R ๐
@abucci I suspect that people _might_ argue: โIf we change the default behavior, then a ton of tools will have to be updated as well, so we canโt do that.โ One way to alleviate this issue could be: Have pass show refuse to print clear text passwords *if stdout is a terminal*. ๐ค
@abucci I suspect that people _might_ argue: โIf we change the default behavior, then a ton of tools will have to be updated as well, so we canโt do that.โ One way to alleviate this issue could be: Have pass show refuse to print clear text passwords *if stdout is a terminal*. ๐ค
@abucci I suspect that people _might_ argue: โIf we change the default behavior, then a ton of tools will have to be updated as well, so we canโt do that.โ One way to alleviate this issue could be: Have pass show refuse to print clear text passwords *if stdout is a terminal*. ๐ค
@movq
> refuse to print clear text passwords if stdout is a terminal
But then you lose the very rare (admitely) use-case of:
1. I generate a strong password and store it
2. I then show the password on my terminal
3. Get my wife/daughter to manually type it in to another device
๐คฃ
@movq
> refuse to print clear text passwords if stdout is a terminal
But then you lose the very rare (admitely) use-case of:
1. I generate a strong password and store it
2. I then show the password on my terminal
3. Get my wife/daughter to manually type it in to another device
๐คฃ
@movq
> refuse to print clear text passwords if stdout is a terminal
But then you lose the very rare (admitely) use-case of:
1. I generate a strong password and store it
2. I then show the password on my terminal
3. Get my wife/daughter to manually type it in to another device
๐คฃ
@movq
> refuse to print clear text passwords if stdout is a terminal
But then you lose the very rare (admitely) use-case of:
1. I generate a strong password and store it
2. I then show the password on my terminal
3. Get my wife/daughter to manually type it in to another device
๐คฃ
@prologic Then weโll add a pass --force show or something. ๐ฅด
@prologic Then weโll add a pass --force show or something. ๐ฅด
@prologic Then weโll add a pass --force show or something. ๐ฅด
@prologic @movq I'm pretty certain that best practice is "never show passwords in cleartext", very much like "never store passwords in cleartext". So, no, it's not really up for debate: it's bad behavior that shouldn't be there. I get that people might have taken advantage of it for various purposes, but that doesn't change that it's bad behavior, and the concern is easily addressed by this.
@movq that'd definitely be an improvement! You'd also want to make sure the password does not end up in shell history, terminal scroll history, etc etc etc, which would probably take a bit more care.
Personally, I'd also want a kind of "This is dangerous; are you really sure you want to do this?" warning that can't be disabled to show up, just to make sure users are understanding that what they are doing is not good. And perhaps some pointers about safer alternatives to use (for instance, copying password to the clipboard, which is automatically cleared after a short time period, and then having the downstream app/script grab the password from the clipboard. Or sending the password through a local pipe or socket that's been carefully secured).
This stuff is *already* leaky because when you use something like pass the cleartext password ends up in the RAM and CPU caches for an unpredictable period of time, and can be sniffed out of there if you know what you're doing (that's why things like Yubikeys exist because they *don't* do that). Why make it *even more* leaky and invite user error on top of that when you don't have to?
@movq that'd definitely be an improvement! You'd also want to make sure the password does not end up in shell history, terminal scroll history, etc etc etc, which would probably take a bit more care.
Personally, I'd also want a kind of "This is dangerous; are you really sure you want to do this?" warning that can't be disabled to show up, just to make sure users are understanding that what they are doing is not good. And perhaps some pointers about safer alternatives to use (for instance, copying password to the clipboard, which is automatically cleared after a short time period, and then having the downstream app/script grab the password from the clipboard. Or sending the password through a local pipe or socket that's been carefully secured).
This stuff is *already* leaky because when you use something like pass the cleartext password ends up in the RAM and CPU buffers for an unpredictable period of time, and can be sniffed out of there if you know what you're doing (that's why things like Yubikeys exist because they *don't* do that). Why make it *even more* leaky and invite user error on top of that when you don't have to?
@abucci I often need to see plaintext password to input them in other devices, but I agree that it should be a second step not the default behaviour.
In many mainstream managers it requires clicking on an eye button ๐๏ธ
@abucci passwordless FTW ๐
Or Single Use Passwords, or authentication with Key Pairs. Not having to manage, see and type characters.
Sadly, _everything_ uses passwords, so... ๐
@eaplmx I use kdeconnect, and link the clipboard of my desktop computer with my phone. I copy the password to the clipboard in my computer, it is sent to the phone via kdeconnect, and I paste it where it needs to go. kdeconnect secures the connection between the computer and phone and the clipboards on both sides are automatically cleared after 30 seconds. The password is never displayed on either screen and it does not end up in the scroll or shell history on either side. It's easy, it works great, and it minimizes the most obvious user errors and leaks that you're able to protect against with this kind of setup.
@eaplmx Strongly agree! We have to jump through a lot of hoops to have a modicum of safety with passwords, and there are so many better ways.
@abucci interesting. I'll take a look. With BitWarden I don't need to do that, and it cleans the clipboard after a few secs, but I understand you use case. I'm looking for alternatives to BitWarden, but as we've discussed, there are many differences to take into consideration.
On watching passwords in plain text I mean typing passwords on some strange devices like TV sets, public or family computers (risky!), Xbox, Switch. I like that now many offer a "Login with another device" that simplifies that process if you already have a session on a mobile.
@eaplmx Have you ever checked out Vaultwarden by any chance?
I see what you mean about TVs etc. Hmm, I wonder if there's a way to self host your own "log in on another device" service so that you could add this capability to anything you wanted? ๐ค
@abucci yeah, I just found it this week, and looks very complete as a replacement to BitWarden.
I should run an instance soon. Although I'm deciding if I stay with Warden passflow or I jump to another manager. (Vector is looking cool as well)
Have you used VaultWarden? Any advice?
@eaplmx I haven't yet! It's on my ever-growing list of things to check out. I was hoping maybe you had some experience with it!
I suppose I should add Vector to my list too.
@abucci So.. The issue is that its showing the password by default? Would making an alias to always include the -c help? We can probably engage Jason with a PR to enable a more hardened approach when desired. I've spoken to him before and is generally a pretty open to ideas.
I found this app that was created by the gopass author that does copy by default and has a tui or GUI mode https://github.com/cortex/ripasso
@abucci So.. The issue is that its showing the password by default? Would making an alias to always include the -c help? We can probably engage Jason with a PR to enable a more hardened approach when desired. I've spoken to him before and is generally a pretty open to ideas.
I found this app that was created by the gopass author that does copy by default and has a tui or GUI mode https://github.com/cortex/ripasso
@xuu I haven't gone through pass thoroughly to see what I think is problematic or isn't. This is just something I've noticed while using it. I still use pass anyway, I just think it's bad behavior that shouldn't be there, and it does prevent me from using it for more than I do. I'd be happy to thumbs up and/or chime in on a PR but I'm afraid I wouldn't be able to help with coding (mostly for lack of time).
ripasso looks interesting, thanks for that!
@xuu I just played around with ripasso and it feels a bit too early days for me to use regularly. The Qt GUI doesn't work at all for me (doesn't show any available password entries). The GTK GUI doesn't have a window border. The TUI seems to work well enough. It looks like a great project and I'll definitely keep an eye on it!